dummyindex-build

name

dummyindex-build

description

Drive a dummyindex proposal to completion through grounded checklist execution one dependency wave at a time. Reads the proposal spec and plan, asks the deterministic CLI for the earliest incomplete wave, dispatches independent items concurrently, verifies each result separately, and only then checks it off. Claude Code uses its equipment manifest and stops when that toolkit is missing; Codex needs no Claude equipment and routes directly to native `worker`, `explorer`, or `default` subagents. Reconciles completed code into the curated `.context/` index rather than merely rebuilding it. Use for `/dummyindex-build`, `$dummyindex-build`, build the proposal, execute the plan, implement the checklist, or continue proposal work.

/dummyindex-build / $dummyindex-build — grounded execution of a proposal

Installed from dummyindex __VERSION__. Run dummyindex --version to confirm the CLI matches. If they diverge, diagnose with dummyindex context check --versions (it reports which layer is stale), then run /dummyindex-update on Claude or $dummyindex-update on Codex to bring the CLI, skills, and this repo's wiring back into sync — the update skill is non-destructive on a curated .context/. Don't reach for a blunt dummyindex install to "fix" a version skew.

You are the build conductor. The dummyindex context build CLI is deterministic checklist STATE — it tells you the next wave of items (a ## Wave N group whose items are mutually independent), the agent that fits each one, and the files to ground those agents in. You do the actual work: dispatch the wave's agents in parallel, verify each result, then tell the CLI to tick each box. The CLI never runs an agent and never verifies — that discipline is yours.

Resolve the active host before step 0. The installed portable-host preamble and the $dummyindex-build invocation select the portable host path; /dummyindex-build selects Claude Code. If uncertain, take the portable host path and do not mutate .claude/**.

Waves. The plan step groups checklist.md items under ## Wave N — <label> headings; items in one wave touch disjoint files and share no dependencies, so they dispatch concurrently. Waves themselves run strictly in order — wave N+1 never starts until every wave-N box is ticked. A flat checklist (no wave headings) is just N single-item waves: the loop below degrades to the old serial behaviour with zero changes.

Inputs

• A proposal at .context/proposals/<slug>/ with spec.md, plan.md, checklist.md (a flat - [ ] list), proposal.json. The <slug> is what the user is building; if they didn't name it, list .context/proposals/ and ask.
• On Claude Code, a .context/equipment.json equipment manifest. Claude's plan flow auto-equips, so a new proposal normally has one.
• On the portable host path (e.g. Codex), no equipment manifest is required. The plan skill's portable host path intentionally does not create Claude equipment; built-in subagents are the normal execution path.

The closing reconciliation procedure belongs to the installed main dummyindex skill, not this sibling. Resolve it at <skills-root>/dummyindex/council/65-reconcile.md — equivalently, ../dummyindex/council/65-reconcile.md relative to this installed SKILL.md. That main skill ships the rest of the council companions the procedure may reference.

The loop (run it literally)

0. Read routing state using the active-host branch. Run the first --next-wave --json and read equipped.

   • Claude Code: if equipped is false, stop and tell the user the Claude toolkit is missing. Recommend /dummyindex-equip, or offer dummyindex context equip apply --for-proposal <slug>. Proceed unequipped only after the user explicitly accepts generic dispatch.
   • Portable host path: an equipped: false result and the CLI's no .context/equipment.json warning are expected and must not stop the build. Continue with native routing. Do not offer equip apply, do not ask for confirmation to use the fallback, and do not create .claude/**.

1. Read the spec first. Open .context/proposals/<slug>/spec.md and plan.md end to end before touching any checklist item. This is the contract; everything downstream must conform to it. Do not start flipping boxes before you've read the spec.

2. Ask the CLI for the next wave:

   dummyindex context build --proposal <slug> --next-wave
   

   It prints every unchecked item in the earliest incomplete wave plus the shared grounding paths (spec, plan, and .context/conventions/). On Claude, agent and subagent_type select equipped dispatch. On Codex they are advisory compatibility metadata; apply the native mapping in step 3. Add --json if you want to parse it. On a flat checklist the wave is one item.

   If it prints "all items checked", jump to step 6.

3. Dispatch the whole wave in parallel through the active host. Launch one subagent per dispatchable wave item concurrently. On Claude, use the emitted subagent_type, with general-purpose as its normal fallback. On the portable host path (skill-native hosts such as Codex), use built-in worker for implementation/fix items, explorer for read-only inspection or review, and default for anything else; do this even when no manifest exists. If an available native custom agent (e.g. a Codex custom agent) is an exact fit, it may replace the built-in, but never depend on a .claude/agents/ file.

   In every prompt, inline the task mandate and tell the subagent to read the grounding paths first (spec.md, plan.md, .context/conventions/), then implement exactly its one quoted checklist item. Name concurrent siblings so it does not touch their files. If two items collide on a file, dispatch those two serially and report why.

   Before dispatching, separate the dispatchable subagent units from the main-session items. The CLI already classifies each wave item: read its dispatch field (--json) or the dispatch: main-session — … line (text mode). Two kinds of item are main-session and must never be handed to a subagent:

   • gate items — human-decision / approval items (the plan marks them with a leading **GATE**). These need your / the user's judgment: handle them in this session (ask the user, settle the decision), then proceed. Dispatching a decision gate to a subagent is the failure the user interrupts on — don't.
   • — via <tool> items where the tool can only run in the main session — a plugin slash-command a subagent can't invoke, or a tool grounded in an MCP server only the main session has. Run those yourself from the main session (around any dispatch), never inside a subagent. A skill-only plugin likewise is not an agent. On Claude, a — via /<skill> tag invokes that skill; on the portable host path (e.g. Codex), the equivalent is — via $<skill>. If a delegated subagent cannot invoke it, handle the tagged item in the main session. Only delegate items whose dispatch is subagent.

   Honor — via <tool> tags — BINDING routing, not a hint. A checklist item may carry a trailing — via <tool> tag the plan step added (— via <plugin>:<command> for a plugin slash-command, — via /<skill> for a skill). That tag is binding routing: the item must be executed by the named tool.

   • Route the item through that tool: for a skill, invoke it through the active host's native skill mechanism (/<skill> on Claude or $<skill> on Codex); for a slash-command a subagent can't run, run it from the main session around the dispatch.
   • Substitution is a build failure. If the tagged tool is unavailable, errors out, or can't complete, leave the item unticked, STOP, and report — never let an agent hand-write the output the tool was supposed to produce. A hand-implemented — via-tagged item is a failed item even if its code works. The CLI's agent/subagent_type mapping is unchanged — the tag layers a binding execution instruction on top of it; it does not replace the matched agent.

4. VERIFY each item before you tick — independently, one verdict per item. This is the load-bearing step. Do not trust any agent's self-report. After the whole wave returns, confirm each item against the spec:

   • run the relevant tests / build / linter once for the whole wave (e.g. uv run pytest for this repo) — then attribute any failure to the item(s) that caused it,
   • read the files each agent claimed to change,
   • check each change satisfies the spec's intent for its item, not just "something happened".
   • For a — via <tool>-tagged item, confirm the tool actually ran and produced the result. If the tool records run state or artifacts, read that evidence (its provenance) and verify the output came from the tool. Output that bypassed the tagged tool fails verification regardless of code quality — leave it unticked and report it as a substitution failure.

   Tick the items that pass (step 5). If any item fails or is blocked (ambiguous spec, missing dependency, failing tests you can't resolve, a decision the user must make) — tick only the verified siblings, then STOP. Do not tick the failing item, and do not start the next wave: waves gate on full completion. Report what's blocking, what you tried, and the smallest decision/input you need to proceed. A half-done item left unchecked is correct; a ticked box over unverified work is a lie the next session will trust.

5. Tick each verified box — only now:

   dummyindex context build --proposal <slug> --check "<item text or index>"
   

   One call per verified item — this atomically flips exactly that - [ ] → - [x] (idempotent — re-running is harmless). Pass either a unique substring of the item text or its index from --next-wave.

6. Check status and decide:

   dummyindex context build --proposal <slug> --status
   

   • Not all done → go back to step 2 for the next wave.
   • All done → the CLI prints the closing command, dummyindex context reconcile (that is the closer the --status output names — match it; do not substitute a bare rebuild --changed, which would leave the new files unassigned). The build added new code, so closing the loop means reconciling it into .context/. Commit the code you built, then run the reconcile procedure in the main skill (../dummyindex/council/65-reconcile.md, resolved relative to this installed SKILL.md):

     dummyindex context reconcile          # what to fold in (drift + unassigned)
     

     reconcile is read-only and non-destructive — it writes nothing and never re-clusters the curated taxonomy. It only reports the delta; don't skip it for fear of losing curated work. Then place each new file (scaffold-feature / assign-files), enrich it, and dummyindex context reconcile-stamp to advance the anchor. The loop is closed once .context/ reflects — and is anchored to — the code you built.

7. Report. Summarise: items completed, what each agent built, anything you left unchecked and why, and confirm the reconcile ran (anchor advanced).

8. Learn using the active-host branch (optional, judgment step). On the portable host path, skip this equipment-patch step: do not call dummyindex context equip patch and do not edit .claude/**. If a durable lesson belongs in repo guidance (e.g. on Codex), report it as a suggested active project instruction-file or native-skill follow-up; do not expand this build's scope automatically.

   On Claude, consider whether anything learned should be folded back into a generated agent or verify skill. Trigger a learning patch in exactly these three cases (and only when the lesson is durable, not task-specific):

   • A complex task succeeded via an approach the generated agent didn't already encode (a sequencing rule, a project-specific gotcha, a verification step that caught a real bug).
   • An error → working-path discovery — you hit a failure, found the fix, and the fix is a general rule the agent should have known.
   • A user correction — the user redirected the approach, and that correction should persist.

   When one fires, draft the minimal old/new patch for the relevant generated tool (the implementer/tester/reviewer agent, or the <proj>-verify skill), show the old→new intent to the user, then apply it through the sanctioned seam (never a hand-edit — a hand-edit makes the file USER_MODIFIED and refresh will stop maintaining it):

   printf '%s' '{"old": "<exact unique snippet>", "new": "<snippet + the lesson>"}' > /tmp/equip-patch.json
   dummyindex context equip patch --item <NAME> --from-file /tmp/equip-patch.json
   

   old must match exactly once. The patch re-baselines the tool's origin-hash and patch-bumps its version, so it stays PRISTINE and refresh-able. Keep edits small and grounded — a learning patch teaches a rule, it does not rewrite the agent. If no trigger fired, skip this step; speculative edits are worse than none.

Discipline (non-negotiable)

• Spec-led. The spec is the source of truth. Read it before the loop and re-check against it at every verify step. The checklist is the order of work; the spec is the definition of done.
• One wave at a time, waves in order. Within a wave, dispatch everything in parallel; across waves, never start wave N+1 while wave N has an unticked box. Don't reorder waves, don't pull an item forward out of a later wave — the wave order encodes dependencies.
• Verify before tick. Every single box, individually — a wave that "mostly worked" is N separate verdicts, not one. Evidence (a passing test, a read of the diff) before each --check.
• Stop on block. When you can't verify an item or you hit a decision point, tick only the verified siblings, stop, and report — never tick to "keep moving", never start the next wave over an incomplete one.
• Stay in scope. Each dispatched agent implements one item, inside existing conventions, without touching its wave-siblings' files. New abstractions need their own proposal.
• — via tags are binding; substitution is a failed item, never a fallback. A via-tagged item must be executed by the named tool, with provenance that it ran. Hand-writing the output the tool was supposed to produce is a build failure even if the code works.
• GATE / main-session items are not dispatchable. Items the CLI marks dispatch: main-session (a **GATE** human decision, or a tool only the main session can run) are handled in this session — never handed to a subagent.

CLI reference (deterministic state only)

dummyindex context build --proposal <slug> --next-wave [--json]
    → ALL unchecked items in the earliest incomplete wave (## Wave N group),
      each with its `dispatch` (subagent | main-session), `gate`, `via`, its
      matched equipment (agent) + subagent_type (Claude dispatch metadata) +
      shared grounding paths. The portable host path maps by task to
      worker/explorer/default even when equipment is absent. A `main-session` item
      (GATE or `— via` you must run yourself) carries an `instruction` instead of
      an agent — NEVER dispatch it. Flat checklist → exactly one item. THIS is
      the loop's driver.
dummyindex context build --proposal <slug> --next [--json]
    → the single first unchecked item, same mapping (serial fallback for
      debugging / one-at-a-time runs)
    → may also carry `missing_capability: [<cap>…]` — present ONLY when an item
      truly matched no equipped agent AND its text implies a specialist capability
      (security / database / performance / docs / search / frontend). It is a
      signal, not a command. On Claude, with user approval, you MAY pause for the
      gated discover→install flow and then re-run `--next`; installation is never
      silent. On Codex, do not run Claude equip discovery or installation: route
      the item to worker/explorer/default and report any external-tool gap.
dummyindex context build --proposal <slug> --check "<item text or index>"
    → atomically flip that item to - [x] (idempotent; one call per item)
dummyindex context build --proposal <slug> --status [--json]
    → done/total; when complete, prints `dummyindex context reconcile`
      (close the loop via the main skill's reconcile procedure at
      ../dummyindex/council/65-reconcile.md, relative to this SKILL.md).
      `reconcile` is read-only/non-destructive — run it, don't substitute rebuild.

dummyindex context equip patch --item <NAME> --from-file <F>   # Claude only
    → (Claude learning step) apply a sanctioned old→new patch to a generated tool;
      re-baselines + version-bumps so it stays PRISTINE. F is {"old","new"}.