/ultracook

When to invoke: Retired — /ultracook no longer exists as a standalone skill. Any /ultracook invocation resolves to /cook, which now owns the single implementation pathway (including the fan-out mechanics this skill used to run). Use /cook instead.

/ultracook (retired)

/ultracook is retired as a top-level skill. Its mechanics — decompose, wave-fan curds, harvest, wire, post-merge review, plate — now live inside /cook’s single pathway, dispatched via /cook --auto, each phase still running as a fresh, isolated sub-agent context blind to the prior phase’s reasoning. See ../cook/SKILL.md’s ## Fan pathway section.

Redirect

Any /ultracook <spec> [flags] invocation resolves to /cook <spec> [flags]. Carry --open-pr, --resume <slug>, and --auto forward verbatim — their semantics are unchanged, just hosted inside /cook now.

What did not move

skills/ultracook/scripts/ and skills/ultracook/references/ remain at their existing paths — nothing here vaporized. /cook’s fan-pathway prose points at these retained files by their current relative path (e.g. ../ultracook/scripts/ultracook.pyz, ../ultracook/references/decomposer-prompt.md, ../ultracook/references/curd-prompt.md, ../ultracook/references/manifest-schema.json) rather than duplicating or moving them.
The manifest path stays .cheese/ultracook/<slug>/manifest.yaml for continuity — the identity of the skill that reads/writes it changed, not the path; its shape is references/manifest-schema.json, and each curd’s dispatch prompt is references/curd-prompt.md, both read by /cook’s fan pathway.
src/fanout/mode.py and src/fanout/curd_block.py remain decomposer/fanout internals — /cook’s fan pathway calls them directly rather than through this retired skill.
The retained scripts/references still do source-code I/O under /cook’s ownership — that follows code-intelligence-routing.md same as everywhere else.

If you are here because muscle memory typed /ultracook, run /cook with the same arguments.

Per-curd phase prompt template

Loaded by /ultracook for each top-level phase spawn. Substitute {N}, {slug}, {phase}, {worktree_path}, {file_list}, {behaviour}, {acceptance_criterion}, {test_target}, {spec_summary}, {baseline}, {prior_handoff}, {review_context}, and {agent_resolution}.

You are executing {phase} for curd #{N} of spec {slug}.

Worktree: {worktree_path}
Prior phase handoff: {prior_handoff}

## Behaviour and scope

Behaviour: {behaviour}
Acceptance criterion: {acceptance_criterion}
Intended files: {file_list}
Focused test: {test_target}
Spec summary: {spec_summary}
Baseline: {baseline} — the run manifest's classified `baseline:` block, carried down for the cook phase's baseline-vs-regression check; a curd never captures its own baseline.

Stay inside this behaviour. The file list may be stale; add only files directly required by the acceptance criterion and record any expansion.

## Phase

Run only `/{phase} --auto` for this curd, then stop. Do not chain forward. The parent dispatches the next fresh phase into the same worktree.

Phase sequence and types:

1. coder: cook
2. coder: press
3. reviewer: age
4. coder: cure (`--stake medium+`)
5. reviewer: final age

A first age reporting `next: done` clean-completes the curd — the parent records that age's review context as the final review identity and skips cure and final age. On any other `next:` value all five phases run and only the final age may terminate the table.

For age phases, review exactly this explicit context and copy it into the age handoff:

```yaml
review_context: {review_context}
```

`review_context` contains `base_commit` (commit SHA), `reviewed_tree_oid` (tree object ID, including uncommitted state), `diff_hash`, and `scope`. Never call the tree object ID a head commit SHA.

## Resolution provenance

Copy this resolved record unchanged into the phase output:

```yaml
agent_resolution: {agent_resolution}
```

## Handoff

Write `.cheese/ultracook/{slug}/curds/{N}/{phase}.md` with:

```yaml
status: ok | halt: <one-line reason>
next: <next phase | done | cure>
artifact: <phase report path>
agent_resolution: <shared block>
review_context: <required for age>
```

Every age writes `next: done` only when publishable. A final-age `next: cure` halts the curd. After the final age succeeds (or the first age clean-completes), return control; the parent invokes `/plate` commit-only and writes the aggregate `.cheese/ultracook/{slug}/curds/{N}.md`.

Do not push, publish, harvest, plate, spawn another phase, or run outside `{worktree_path}`.

Retained legacy-manifest decomposer prompt template

This retained legacy-manifest template is consumed by /cook’s fan-path internals when they need the run-manifest decomposition. It is not a live /ultracook phase. Substitute {spec_text}, {slug}, and {quality_gate} before dispatch.

Scope note: this template produces the legacy manifest schema (seed[]/curds[] with id/behavior/retry_count, wiring[]), validated by validate_manifest — NOT the curd-block schema (curds[]/waves[]/decomposer{}) validated by validate_curd_block. Curd-block producers must use ../../cheese/references/decomposer.md.

You are the legacy-manifest decomposer sub-agent for /cook's fan-path run: {slug}

## Your job

Read the spec below and produce a decomposition into three artifact lists:

1. `seed[]` — foundational types / interfaces / enums that 2+ curds depend on.
2. `curds[]` — parallel units of behaviour, file-disjoint, one acceptance criterion each.
3. `wiring[]` — integration tasks with topological dependencies (barrel exports,
   DI registrations, route wiring, event subscriptions, config entries).

Produce one curd per independent behaviour. Two or more file-disjoint curds fan out in parallel; a single curd runs in linear mode. Only an empty decomposition (zero curds) is rejected — there is no minimum-curd floor.

## The five criteria

Every curd you produce must satisfy ALL FIVE criteria. Token budgets are NOT a criterion — do not estimate token usage. The five behavioural criteria substitute.

1. **One behaviour per curd.** Describable in a single declarative sentence ("adds X",
   "extracts Y", "renames Z", "fixes A"). If the description needs "and" between two
   distinct behaviours, split into two curds.
2. **One acceptance criterion.** Maps to exactly one list item (bulleted or numbered) in
   the spec's Acceptance Criteria / User Story list. Curds collectively cover every
   acceptance criterion 1:1.
3. **One test target.** A single focused test command verifies this curd alone. If the
   curd needs N test commands, it's N curds.
4. **File-disjoint.** No two curds list the same file. HARD CONSTRAINT.
5. **Commit-worthy alone.** After this curd's commit, `{quality_gate}` passes without
   sibling curds merged. Implied by criterion 4 plus seed carrying any shared deps.

If criterion 4 cannot be satisfied because two curds genuinely share a file, the shared
content belongs in `seed` (if foundational) or `wiring` (if integration). Curds never
share files.

## When NOT to parallelize (stop before decomposing)

Before producing curds, check each of these against the spec:

1. **Shared state across all behaviours.** If every behaviour requires the same mutable
   global (DB schema, app singleton, global config struct), a change in one curd
   breaks every sibling. Move the shared object to seed if possible; if it cannot be
   isolated, the spec cannot be safely parallelized — return the single
   relevant curd (or the few you can isolate); a sub-threshold decomposition is valid
   and runs in linear mode.
2. **Sequential correctness dependency.** If behaviour B can only be verified after
   behaviour A has landed (e.g., B calls A's new API that doesn't exist yet and can't
   compile without it), they are not file-disjoint in practice. Check whether the
   dependency belongs in seed; if not, the foundational files that behaviour depends on
   belong in seed — and if they cannot be isolated, the spec cannot be safely
   parallelized: return the curds you can isolate; a sub-threshold decomposition is
   valid and runs in linear mode.
3. **Only one independent behaviour.** If you cannot identify two file-disjoint curds,
   return the single curd and stop. A one-curd decomposition is valid — it runs in
   linear mode rather than fanning out; only a zero-curd manifest is rejected. A short
   manifest is the correct signal — do not pad curds to reach the parallel threshold.
4. **Test target cannot be isolated.** If every acceptance criterion shares a single
   integration test command that exercises all behaviours together, splitting into curds
   gives no parallel safety. Return the single curd; it runs in linear mode.

When any of these applies, return the curds you can genuinely identify. Do NOT force an
artificial decomposition and do NOT pad curds to reach the parallel threshold.

## Trivial curds — fold, don't emit standalone

A curd touching 1 file or fewer (a pure config/allowlist entry, a one-line
wiring stub) is trivial. Prefer folding a trivial curd into `seed` (if
foundational), `wiring` (if integration), or a substantial sibling curd's
`files[]`/`behavior` rather than emitting it standalone — a dominant curd
plus a trivial one is not worth the parallel fan-out overhead. Only emit a
trivial curd standalone when folding would violate criterion 4
(file-disjointness) or genuinely obscures an independent acceptance
criterion.

## Validation
The orchestrator will run `${CLAUDE_SKILL_DIR}/scripts/ultracook.pyz validate_manifest` on your output for required
sections and field shapes, then `${CLAUDE_SKILL_DIR}/scripts/ultracook.pyz validate_decomposition` against the checks
below. Your output will be rejected on any failure:

- **Behaviour overlap**, **Spec coverage**, **Test target**, **File disjointness** — enforce criteria 1–4 above.
- **Wiring DAG check** — no cycles, no cross-branch overlap, barrel files included where curds create new slices.
- **Seed minimality** — seed contains only files that 2+ curds depend on.

You get up to 2 retries if validation fails. After the third failed attempt, the
orchestrator escalates to the user.

## Output shape

Produce a manifest scaffold (YAML) at `.cheese/ultracook/{slug}/manifest.yaml`
matching `skills/ultracook/references/manifest-schema.json`. Use only the
JSON-compatible subset of YAML: mappings, lists, strings, numbers, booleans, and nulls.
Do not use anchors, aliases, custom tags, or multi-document streams. Fill in:

- `slug`, `spec_path`, `created`, `quality_gates`, and the orchestrator-provided `agent_resolution` block.
- `seed.items[]` — each with `description`, `files[]`, `status: "pending"`.
- `curds[]` — each with `id`, `behavior`, `acceptance_criterion`, `files[]`,
  `test_target`, `status: "pending"`, `retry_count: 0`.
- `wiring[]` — each with `id` (e.g. `W1`), `type` (`barrel_export` | `di_registration` |
  `route_wiring` | `event_subscription` | `config_entry`), `file`, `depends_on[]`,
  `status: "pending"`.

Leave `commit_sha`, `branch`, `worktree_path`, `pr_plan`, and `post_review` empty —
they're populated as later phases run.

## Tools

You were resolved as the planner/general role through `skills/cheese/references/agent-resolution.md`. Stay read-only except for the manifest artifact. Use `/culture` for codebase exploration, `/briesearch` for external grounding, and call the selected source-code backends directly according to `skills/cheese/references/code-intelligence-routing.md`.

Do NOT write any production code in this phase — your only artifact is the manifest. Preserve the orchestrator's `agent_resolution` block unchanged.

## Spec

{spec_text}

## Return

Write the manifest, then return a brief one-paragraph summary naming the curd count and
any tricky decomposition decisions you made (e.g. files you considered shared but moved
to seed). The orchestrator presents this in the user-approval gate.

PR planner sub-agent prompt template

Loaded by /ultracook at Phase 7. Substitute {slug}, {manifest_path}, {merged_diff_path}, {plate_layout}, and {spec_summary} before dispatch.

You are the PR planner sub-agent for /ultracook spec: {slug}

## Your job

Read the manifest at {manifest_path}, the merged diff at {merged_diff_path}, and the
spec summary below. Emit a PR layout plan to
`.cheese/ultracook/{slug}/pr-plan.yaml`.
`/plate` resolved topology before parallel-mode commits. The persisted, authoritative resolution is `{plate_layout}`. Copy it exactly into the plan. The plan may explain why the decomposition supports a stack, but it must not change or re-ask an explicit or previously verified choice.

## Layout shapes

Choose ONE of the four shapes based on the dependency structure:

| Shape | When | PR layout |
|---|---|---|
| `single` | The persisted choice is single; all groups form one cohesive review unit | All commits in one PR |
| `orthogonal_flat` | The persisted choice is stacked; curds are independently reviewable with no ordering dependency | N PRs each branching from main |
| `stacked_linear` | The persisted choice is stacked; reviewable layers have linear dependencies | provider selected by `/plate` |
| `diamond_stack` | The persisted choice is stacked; a shared base and final wiring surround independent curds | seed PR (base) → N parallel curd PRs → wiring PR |

Review-shape criteria, in priority order:

1. If `{plate_layout}` is `single`, emit one `single` group. The persisted
   choice is authoritative even when the decomposition could support a stack.
2. For `stacked`, identify layers with a named purpose, their own validation,
   and a stable boundary that lets each layer be reviewed independently.
3. Use `orthogonal_flat` only when curds have no ordering dependency. Use
   `diamond_stack` when a shared base and final wiring surround independent
   curds. Otherwise use `stacked_linear`.
4. Do not use line-count or file-count thresholds. If the plan cannot name
   honest review boundaries, report the conflict instead of manufacturing them.

## Output: pr-plan.yaml

```yaml
plate_layout: single | stacked
shape: single | orthogonal_flat | stacked_linear | diamond_stack
groups:
  - branch: ultracook/{slug}/pr-1-seed
    title: "feat(orders): shared types"
    body: Adds the shared OrderId type and protocol used by every order curd.
    base: main
    commits:
      - <sha1>
      - <sha2>
    depends_on: []
  - branch: ultracook/{slug}/pr-2-curd-1
    title: "feat(orders): order entity"
    body: Adds the order entity with full test coverage.
    base: ultracook/{slug}/pr-1-seed
    commits:
      - <sha3>
    depends_on:
      - ultracook/{slug}/pr-1-seed
```

`plate_layout` must equal `{plate_layout}` from the manifest. For `single`, emit
exactly one `single` group. For `stacked`, emit an ordered multi-PR shape and
explicit commit/file boundaries; place shared durable writes in the
bottom/common group or an explicit wiring group.

Each group:

- `branch` — branch name (kebab-case, slug + sequence + role).
- `title` — Conventional Commits-style PR title.
- `body` — 1–3 sentence PR body describing what the group ships.
- `base` — the branch the PR should target. `main` for the root of a stack or any
  orthogonal-flat PR; otherwise the previous stack member's branch.
- `commits` — ordered list of commit SHAs from the manifest.
- `depends_on` — branches that must be merged before this PR.

For `single`, emit exactly one group. For `orthogonal_flat`, emit one group per curd
with `base: main` and empty `depends_on`. For stacks, the orchestrator runs
`${CLAUDE_SKILL_DIR}/scripts/ultracook.pyz pr_plan_to_branches` to convert the plan to
branch-creation commands. The orchestrator validates your output with
`${CLAUDE_SKILL_DIR}/scripts/ultracook.pyz validate_pr_plan` before running the branch converter.

Keep the YAML in the JSON-compatible subset: mappings, lists, strings, numbers, and
booleans only — no anchors, aliases, tags, or multi-document streams. The shape is
defined by `references/pr-plan-schema.json`.

## Spec summary

{spec_summary}

## Return

Write `pr-plan.yaml` and return a one-paragraph rationale. The orchestrator passes it to `/plate` with the matching persisted resolution; `/plate` verifies the values agree and does not ask twice.

Spawn-primitive reference

/ultracook resolves each fresh phase through the shared ../../cheese/references/agent-resolution.md contract. Host syntax is transport; role, power, permissions, isolation, and topology are the contract.

Invariants

Every phase dispatch must:

start in fresh context;
meet the phase’s tool, permission, isolation, and minimum-power floor;
run only its named phase and never chain forward;
return control synchronously;
write the phase handoff with the shared agent_resolution block.

Missing required tools, write capability, fresh context, or worktree isolation halts. Known underpowered candidates are rejected. Unknown power is final fallback only and records degraded: true.

Role policy

Work	Preferred type	Permission/isolation	Minimum power	Effort
Decompose	planner, then general	write (manifest only); fresh context	powerful	high
Cook, press, cure, seed, wiring	coder	write; isolated worktree	default	high
Every age pass	reviewer	read-only; fresh context	powerful	high
Harvest and plate	parent	parent repository state	powerful	high

Harvest and plate are never delegated. A general worker can fill a read-only role only through prompt-only no-write enforcement with degraded: true; a general worker cannot substitute for missing write capability.

Same-worktree phase handoff

For each parallel curd, the parent creates one worktree and performs five top-level sequential spawns into that same path:

coder(cook) → coder(press) → reviewer(age) → coder(cure) → reviewer(final age)

After each return, the parent reads the phase handoff, records its agent_resolution, and passes the artifact path plus worktree path to the next fresh spawn. Before each age dispatch, the parent records and passes explicit review context: base commit SHA, reviewed tree object ID, normalized diff hash, and scope. The final age must return next: done; next: cure or a missing value halts and is not publishable. The parent then runs /plate in commit-only mode.

Host examples

On Claude Code, render the resolved type in Agent(subagent_type: <resolved-type>, prompt: ...). On Codex, use the host spawn capability with fork_turns: "none" so no conversation turns are inherited. On OMP, render the same record through task(...). Do not add a call-site model override that contradicts the resolved power.

The phase prompt includes: phase name, slug, worktree path, prior handoff path, no-chain directive, required artifact path, and the resolved agent record. Wait for completion before dispatching the next phase.

If no host primitive satisfies a required invariant, halt /ultracook and recommend /cook --auto; do not silently collapse the fresh-context topology.

Per-wiring task worker prompt template

Loaded by /ultracook at Phase 4. Substitute {id}, {slug}, {type}, {file}, {description}, {spec_summary}, and {agent_resolution} before dispatch.

You are performing integration wiring task: {id} for spec {slug}

Resolved role: coder
Agent resolution: {agent_resolution}

## Task

Type: {type} (barrel_export | di_registration | route_wiring | event_subscription | config_entry)
File: {file}
Description: {description}

## Constraints

- Touch ONLY the named file.
- 20 tool calls max — this is a small task.
- No business logic — integration only.
- Commit your change via `/plate` commit-only mode before returning.

## Spec summary

{spec_summary}

## Workflow

1. Read the file with the backend that will validate the write anchor.
2. Apply the integration change through a stale-safe edit according to `skills/cheese/references/code-intelligence-routing.md`.
3. Run the project's quality gate command — STOP and write
   `status: halt: quality gate failed` if it fails.
4. Commit via `/plate` commit-only mode.
5. Write the handoff slug.

## Handoff slug

Write `.cheese/ultracook/{slug}/wiring/{id}.md` with:

```
status: ok | halt: <one-line reason>
next: merge | done
artifact: <path-to-richer-report-if-any>
<one-line orientation: what this wiring task did>
agent_resolution: {agent_resolution}
```

## Do NOT

- Modify any file other than {file}.
- Add business logic — wiring is glue only.
- Push or create PRs (the orchestrator handles that).
- Chain forward (the orchestrator owns the chain).
- Retry on failure — write the halt and return; the orchestrator decides retry policy.