phase: Skill for Claude Code

Engine Planner

Produce an implementation plan for the phase.rs engine. Design for the class, not the card. Never propose bandaids, workarounds, or shortcuts — everything lives in its rules-correct place.

This skill produces the plan only. The plan-review loop belongs to the caller — when invoked from /engine-implementer, the orchestrator owns the loop. When invoked standalone, run /review-engine-plan against the plan yourself and iterate until clean.

Input

A task description: parser enhancement/fix, or engine mechanic enhancement/fix. May reference cards, Oracle text patterns, CR rules, or coverage gaps.

A scout fact pack may accompany the task (the engine-implementer scout produces it; standalone, you may run it yourself). Its facts are located, quoted lines, and its unknowns are things the scout looked for and did not find. Use both as leads for Steps 2 and 3. The pack may be incomplete or misleading: verify what you rely on, explore beyond it, and never treat a missing fact as evidence of absence. It discharges no step: you still verify the premise, trace the analogous feature, read every file you will touch, and probe.

On a revision, prior reviewer findings arrive as constraints. Apply a finding's supplied replacement text verbatim and add no sentence beyond it; anything else you believe is wrong goes in your report, not into the plan.

Modes

Ordinary mode is the default and produces a full single plan via the Process below. Three additional modes are activated when the caller's spawn inputs name them (the /engine-implementer phase-fit pipeline is the caller). Each mode scopes this file's mandatory language explicitly here, in this file — a spawn prompt never overrides this file's text; this section does.

Charter mode (spawn inputs: a plan or draft plus the phase-fit firing context)

Output contract: a phase charter, not a plan.

• Input mapping (three shapes): a decomposition proposed at an orchestrator stop runs only through an accepted expansion case; T1/T2 decomposition remains subject to the shared run limits. A draft plan, with whatever findings have accumulated (the initial gate firing on a fresh draft carries none; a mid-loop firing or a stop-proposed decomposition carries the round history) → derive the charter from the draft. A review-clean plan (scope-freeze or pre-existing-clean firing) → partition, not re-plan: carve the converged content into phases; nothing is rewritten, so the split does not invalidate the reviewed artifact. A review-clean plan with landed candidates (a decomposition proposed from the implementation-review loop) → derive phase 1 from the stabilized current candidate and partition the remainder.
• Step survival (enumerated): Step 0 (premise verification) survives — a fabricated premise poisons every phase. Step 1 (identify applicable skills) survives — the checklist inventory informs unit boundaries and seams. Step 2 (analogous trace) survives — it informs seam choice. Step 3 (read every file) survives, scoped to the files the charter's phases will touch. Steps 4 and 5 (the architectural sections and the step-by-step plan) are replaced by the charter output contract below — they apply later, to each phase plan in phase-plan mode.
• Charter output contract: linearly ordered phases; per phase, a goal statement, a scope rule — the subsystems and anchor paths the phase owns, as literal paths or directories, no globs (T2 directory expansion and the orchestrator's SCOPE_PATHS materialization consume concrete paths), with the standing inclusion classes /engine-implementer defines (compiler-forced sites, shared registration files, comment-only edits) implied rather than enumerated; the orchestrator materializes the list at scope-freeze; the architecture decisions the phase carries out (the charter is a contract about architecture and sequencing, not a snapshot of the code: acceptance rows, verification and the claims a phase must establish about today's code belong to its phase plan); its addenda file, <run-root>/addenda/phase-<k>; and a deferral list — everything the full task needs that the phase intentionally omits, attributed to the phase that will land it, including a discriminating test that structurally cannot exist until a consumer phase lands (DEFERRED(phase n), the defining property of a dependency seam; that phase's interim verification is structural: green tree, existing suites, unit-level assertions); seam notes (shared files such as effects/mod.rs, surfaces held green via strict-failure tags); and a recursive check that no individual phase itself trips the T1∧T2 phase-fit conjunction defined in /engine-implementer.
• Feasibility exit: if no green-tree seam exists, report that instead of a charter — name every candidate split point and show why each leaves the tree non-compiling or tests red.