---
name: driving-bibifi-cycles
description: >-
  Maximizes knowledge discovery through Experimental and Formal Methods using short BIBIFI cycles.
  Use for Strong Inference, アノマリーからアブダクション, 競合仮説・予測表・排除表,
  実験計画, 6分イテレーション, マイクロチケット, massive parallelism, ETA/JST,
  idle CPU/RAM/VRAM, 理論研究の実行, 研究を進めて, and an authorized discovery loop that is stalling.
  Selects useful work, expands independent agent microtickets, consumes results and replans immediately.
  Owns ITERATION_PLAN/LOG in existing records; targets ~2-minute experiments, maximum 10 minutes.
  Dispatch and enforceable limits→orchestrating-agents; evidence→validating-experimental-evidence;
  proof→proving-theorems; theory→systematizing-theories; section admission→directing-research-sections.
  Workflow-native: selection and acceptance stay with their owner; independent work runs concurrently.
  English skill; respond in the user's language.
---

# Driving BIBIFI cycles

> **Version**: v2609.7.0 (2026-09-28) — preserve experiment budgets and decision latency under contention.

```sh
for f in assets/ITERATION-PLAN.md assets/STRONG-INFERENCE.md \
  references/microticket-patterns.md references/scientific-loop.md references/skill-composition.md \
  tests/triggers.md tests/decision-cases.md tests/scheduling-cases.md \
  tests/operational-rehearsal.md tests/forge-verification-ledger.md; do test -f "$f" || exit 1; done
bun ../forging-skills/scripts/skill-check.ts .
```

## On invocation — do the work

`/driving-bibifi-cycles` means execute/resume the current authorized discovery loop, not print its report format.
Unless the user explicitly requests status only, inspect the current evidence and take the next justified action now.
Consume a result, perform a bounded check, start a ready microticket or intervene on a real blocker within your role.
Then report what actually changed. A report is a checkpoint; continue the authorized work after it.
If no action can advance the goal, establish why with the dependency search below.
Do not invent activity to satisfy a quota.
Repeated status or a later ETA, without new evidence or justified intervention, does not fulfill the invocation.

## LAW — maximize valid discovery per unit time

Maximize the throughput of knowledge discovery from Experimental and Formal Methods.
Select new, valid, goal-relevant evidence, falsifications, counterexamples and checked proof results.
A repair matters through the next discovery it enables. Report that enabling work separately.
Ticket counts, code volume, reports, device utilization and agent count are not discovery units.
Do not inflate progress with known results, duplicate observations or irrelevant easy questions.

Attack the current critical dependency; use remaining capacity for useful independent questions.
Expand across available agent slots. GPU scarcity does not serialize source, proof or isolated preparation work.
Each result may obsolete work already running. Commit to a short return, then select again.
The parent owns coordination even when the work is delegated. A plan or dispatch message is not execution.

Stable tokens: `BIBIFI`, `MICROTICKET`, `ITERATION_PLAN`, `ITERATION_LOG`, `ontime`, `delta`, `pivot`.

## Ownership — one loop, existing records

`authorized goal + current evidence/resources -> select -> execute -> consume -> reselect`.
Own the rolling work selection and its plan/log inside the project's existing ticket/run/finding system.
Do not create another database, launcher, authority hierarchy or blanket approval step.
This is the default execution owner for ordinary authorized R&D, including theoretical research.
Recover the bounded goal from the task before selecting work; a bare request grants no invented goal or mandate.
Question clarification within that goal stays with the relevant content owner. Programme allocation is a different decision.
One question per microticket does not mean one active question for the fleet.
Under a formal section, preserve its admission, whole-cycle WIP and distinct learning-commit owners.
Partial build returns can unblock authorized work but are not terminal run receipts or LEARN commits.

## Start with a checkable result, not a large plan

Read the prior release ETA, completion criteria, open work and latest accepted evidence.
Check available/reserved CPU, RAM, VRAM, GPU load, agent slots and live write ownership.
Unknown values stay `未確認` / `UNKNOWN`; never infer execution or free capacity from a sent message.
Choose the first result that can change the next decision and the dependency preventing it.
Retrieve the relevant predecessor, interface and failure witness before replacing or reimplementing it.
Record the transferable part and current mismatch; do not commission a whole-history survey to begin one repair.

For the next action, consume orchestration C0's current capability receipts:
launcher/identity, worker update/stop, resource cap/release, and consumer hand-back as applicable.
Missing capability becomes one bounded repair/probe. Unrelated useful work proceeds immediately.
A skill installed on disk is not proof a live worker loaded it; bind important rules into the current brief.
Reuse unchanged valid receipts; do not rerun a readiness ceremony before every ticket.

## Scientific direction before scheduling

For a scientific anomaly or a Strong Inference request, use `references/scientific-loop.md` before choosing jobs.
Use `references/skill-composition.md` when choosing between explanation, generation, testing, evidence and theory work.
Skill boundaries separate decisions, not mandatory agents or pauses. Apply the needed operation in the current context when possible.
Retain responsibility for consuming its return and taking the next authorized action; a packet or routing decision is not task completion.
Join the current observation or failure to an observed-versus-expected contrast under matched conditions.
Keep explicit rivals, auxiliary conditions and an open residual. Do not assume one cause or exhaustive candidates.
Before measuring, derive rival-dependent predictions and the result-to-exclusion/next-action table.
Drop a prediction that cannot separate its named rivals. Do not drop the hypothesis by rhetoric.
Parallelize independent discriminators and formal counterexamples. Consume each result at its own scope immediately.
Return a candidate revision of the hypothesis, model, design or procedure: retain, change, predict and check first.
A promising idealized construction or local repair does not certify the whole target or every operating condition.
Use the four compact tables in `assets/STRONG-INFERENCE.md`; inherit existing evidence instead of duplicating it.
Routine deterministic repairs need only their smallest failing witness, not an invented hypothesis portfolio.

## The microticket — one useful decision within reach

Use the compact card in `assets/ITERATION-PLAN.md`, inheriting unchanged context by exact locator.

| Field | Must determine |
|---|---|
| Question / consumer | Which live decision changes, or which discovery dependency is removed? |
| Build → Break → Fix | Small artifact/witness; discriminating check; conditional repair/retain/reject action |
| Binding / validity | Current premise, input/code or statement version; baseline/control/criterion before measurement |
| Work / resources | Owner, read/write scope, agent versus compute phase; footprint, actual device reason and critical-work headroom |
| Return / cancellation | First decision-changing result and deadline; budget source, effective stop, invalidation, release and consumer |

A whole component, inventory, port or multi-stage revision is a container, not an executable microticket.
Slice by a consumed outcome, not an arbitrary function count. Preserve mechanism, power and claim scope when shrinking.
Use diagnostic expected-vs-observed checks for implementation work; do not invent scientific hypotheses for forms.
For formal work, pin the exact statement and proof status; a sketch cannot silently become a checked theorem.

| Clock | Rule |
|---|---|
| First useful return | Within the next six-minute window; earlier if pending evidence could invalidate the assignment |
| Experiment | About two minutes target; ten minutes maximum or the tighter active cap, including launched setup/compile |
| Worker / queue | Finite return and lifetime, covering preparation, admission wait and recording as well as execution |

Two minutes is a target, not a launch ban. Six minutes is feedback/report cadence, not a process kill boundary.
Bind the user/domain budget before dispatch. The operator compares the launch envelope against it before P7 admission.
Record target duration separately from the hard cap. A two-minute target does not impose a two-minute hard limit.
The effective experiment cap is the minimum of ten minutes, stricter user/domain limits and remaining ticket lifetime.
Tests and profiling use that cap, including launched setup/compile; P7 owns stop/release enforcement.
An ETA exceeding it is a rejected experiment design, not permission to lengthen the envelope or reclassify the same run.
Choose a smaller discriminating witness, reuse valid setup/evidence, or report that no valid test fits this budget.
Do not obtain a long run by relaunching timed-out work or chaining slices that return no independent decision.
Keep real partial evidence and its limits; a short prefix cannot certify a full benchmark.
Use GPU for GPU-capable experiments. Record a concrete CPU reason and obey stricter active device constraints.
Prompt deadlines alone enforce nothing. Cleanup grace is not extra experiment time.
No sweeps or large experiments; renaming their cells microtickets does not change their information value.

## Execute continuously — decide on each event

| Observed state/event | Action now | Evidence to consume |
|---|---|---|
| Critical action ready or blocker cleared | Launch the smallest real path and confirm it actually starts through C0 | Start receipt or explicit admission wait/blocker, not an assumed retry |
| Independent useful agent work ready | Launch across fitting slots/host capacity, even while GPU phases wait | Disjoint scope, short return, named consumer |
| Critical dependency blocked | Assign its smallest unblocker and continue unaffected work | Exact missing input, owner and next check |
| Partial result arrives | Check its boundary and pass it to its consumer immediately | Artifact plus consumer receipt, or explicit pending/blocker |
| Result changes a premise | Reassess affected running/queued tickets; continue, shrink or stop | Version delta and observed owner action/release |
| First return missed | Inspect actual phase/job/artifact now; unblock, re-slice or cancel | C0 intervention; do not grant another long first-return window |
| Priority work waits behind an owned side job | Reconsider that job at its declared safe stop point | Reservation and confirmed release; no unauthorized external kills |
| Experiment cannot finish within its bound | Reject before launch, or stop through its owner; redesign the test | Preserved partial evidence, inherited cap and observed release; no larger retry envelope |
| Resource/process cap exceeded | Stop through the owner and fix the stop path before reusing it | Partial evidence, effective cap, stop/cleanup receipt |
| Launcher/setup failure | Repair and exercise one fixture; stop identical queue retries | Accepted/rejected invocation and record read-back |
| No useful work fits | Challenge the claimed dependency and inspect independent evidence work before waiting | Checked alternatives, actual constraints and next changing event |

Act when the event arrives; never wait for the report tick or every worker in a wave.
Do not require another parent reply for a preauthorized branch whose scope, premises and resources still hold.
Preserve raw failures and falsifications. An operation failure is not a scientific negative and does not erase valid evidence.

## Parallelism without whole-component handoffs

Keep agent-ready work separate from compute-admission waits in the same board.
Parallelize distinct source, proof, counterexample and interface checks, plus isolated patch proposals.
Use a single writer/integrator per live shared file; parallel thinkers return bounded proposals on frozen inputs.
NONCOMPUTE means the declared workload, not zero host cost or permission for hidden tests/fanout.
Actual platform, host, data-access and write constraints apply; a fixed small-team cap does not.

Compute admission proves capacity eligibility, not that another job improves discovery throughput.
Before adding a contender, inspect current progress/rate and the next critical return's resource needs.
Use comparable retained timing evidence or one bounded probe; do not infer speed from utilization or load average alone.
Keep the added job only if its useful return fits without delaying the critical return beyond its declared budget.
On unexpected slowdown, stop adding contenders and inspect shared CPU, memory bandwidth, VRAM and device phases.
Re-slice or stop the lowest-value conflicting owned job at its safe boundary; confirm release before replacement.
Continue useful independent agent work within host limits. This is not a one-job-per-GPU rule.
Throttle identified or plausible compute contention. Sharing a research goal does not make a source or proof task a contender.
If an independent task's host fit is unknown, check that fit now. Do not park all thinking until compute ends.
See `references/microticket-patterns.md` for contention and admission-wait decisions.

Consume compact artifact returns and exception deltas rather than every transcript.
Use deterministic joins for mechanical aggregation; domain owners retain scientific judgment and acceptance.
If results backlog, repair routing/consumption first. Throttle only branches blocked by contention or stale decisions.
Respect blind-review visibility; orchestration owns what may cross each role boundary.
Never create duplicate work just to occupy slots or leave a useful ready question idle because another stream is slow.
Tie each next ticket to consumed evidence or a cited primary source and its authorized question.
Free capacity or an unsupported worker assertion is not a basis for inventing new work.

Before declaring “waiting for X,” test which specific observation needs X and which can be obtained without it.
Inspect plausible independent options in blocker evidence, reference/measurement checks or consumer prerequisites.
Reuse current valid receipts. If they already establish the sole missing input and no useful independent option, wait.
Use `references/microticket-patterns.md` for this dependency search; an empty prewritten queue proves nothing.
A pending release does not block every check on stable predecessors, retained observations or separate proposals.
Do not duplicate a worker's live edit or disturb valid ongoing work merely to appear active.

## Integrate early; keep future work conditional

Before scaling, exercise the smallest valid path from the changed element to its actual observation or consumer.
Include a relevant negative case; isolated component checks cannot certify their interaction.
Execution prerequisites must hold. Interpretation/promotion gaps block those claims, not every useful scoped diagnostic.
Use evidence EV1 for loaded code/input identity, including material imports, configuration and warm-worker state.
Use supported immutable run inputs while development continues. Otherwise serialize only the required read/write window.
Do not freeze development until a long benchmark queue drains.

Select the next discriminator per dependency chain; fixed comparison arms may run together for that one question.
Recheck each queued launch against current evidence, binding, priority, capacity and remaining lifetime.
Do not rerun every arena on every revision. A newly decisive result cancels obsolete successors now.
Keep one necessary baseline if useful; sunk work and an old assignment do not justify finishing the rest.
Reuse bounded warm workers and immutable references, resetting experimental state and charging retained resources.

## Qualification and the six-minute report

Evidence EV2/EV3 owns information access, protocol equivalence, effective interventions and comparison footing.
A changed procedure need not preserve the original behavior. Historical performance is not current evidence.
For GPU work, its specialist owns stage budgets/profiles. Select by recoverable whole-run cost, not an isolated ratio.
The theory owner consumes qualified findings and returns versioned premise/prediction changes to this loop.
Report new discovery, enabling work, failure and open uncertainty separately; repeated status earns no cycle credit.
Report only observed starts, completions and consumed results; a requested batch is not an executed batch.
Separate evidence dispositions from goal acceptance. Valid low scores remain evidence; published rows need qualification.

Every six minutes while active, report briefly in JST:

1. Checked artifacts, measured results or proof status, and the decisions they changed.
2. Ticket changes, current blocker, parent intervention and worker/job stop/release state.
3. Next agent microtickets and CPU/RAM/VRAM allocation, measured peaks/releases and any idle-capacity reason.
4. Release ETA versus the previous schedule: `ontime` unchanged, `delta` date changed, `pivot` goal/approach changed.

No previous schedule means initial baseline. Keep run-return ETA separate from release ETA; give the change rationale.
If nothing landed, say so and state the intervention. Do not invent progress or replace the required report with silence.
Do not repeat an old finding as a newly closed cycle. Reporting compliance cannot offset missed useful work.
Stop at completion, user stop or a real authority boundary. Hand back accurate partial state and release owned resources.

## Owners and supporting material

| Need | Owner / reference |
|---|---|
| Dispatch, receipt states, lifetime, admission, interruption and isolation | `orchestrating-agents` C0/C3a/P7; this skill chooses work |
| Experimental validity, scope and comparisons | `validating-experimental-evidence` |
| Exact proof and theory changes | `proving-theorems`, then `systematizing-theories` as applicable |
| Explanatory candidate generation | `forming-hypotheses-from-anomalies` for one contrast; `forging-novel-theses` for a seeded batch under its entry contract |
| Code repair or GPU path | `implementing-and-debugging` plus language/GPU owner |
| Formal section admission or programme allocation | `directing-research-sections` / `supervising-research-programmes` |
| Costly irreversible commitment | `acting-on-hypotheses` owns the discriminator, threshold, interpretation and Commit/Pivot/Kill; this loop may schedule its Build→Measure slice |
| Concrete slices, dependencies and parallel examples | `references/microticket-patterns.md` |
| Compact board, ticket, return and report | `assets/ITERATION-PLAN.md` |
| Skill validation | `tests/triggers.md`, `tests/decision-cases.md`, `tests/scheduling-cases.md`, `tests/operational-rehearsal.md` |
| Historical audits and measured verification limits | `tests/forge-verification-ledger.md` |

No harness → execute ready work serially with observed receipts; do not claim parallelism or enforced cancellation.