phase-implement ยท diff
git:20260718.7cc9d66 to git:20260718.188cd11
11 added, 28 removed. Audit A to A.
---
name: phase-implement
- description: Implement exactly one selected phase from a repository plan. Use when the user identifies a PLAN.md phase or equivalent scoped implementation unit and expects surgical implementation plus verification without later-phase work.
+ description: Implement exactly one selected phase from an authoritative repository plan. Use when a named phase or equivalent scoped implementation unit must be completed without later-phase work.
---
# Phase Implementation
- Implement exactly one selected plan phase.
-
- ## Inputs
-
- Establish:
-
- - the selected phase or scoped unit;
- - the authoritative plan or contract document;
- - applicable repository instructions.
+ Own phase scope and orchestrate only the work required to implement it.
## Workflow
- 1. Read repository instructions, the selected phase, and directly linked context.
- 2. Map the files, tests, commands, and local patterns relevant to that phase.
- 3. State assumptions only when they affect the implementation.
- 4. If the plan requires complexity that current evidence does not justify, identify the exact defect and correct it through `plan-update`; do not silently redesign or skip the requirement.
- 5. Before changing production behavior, use `behavior-implement` for each coherent behavior change. Do not proceed without a demonstrated failing test unless that skill's exception is stated first with alternative verification and residual risk.
- 6. Implement the selected phase without skipping ahead.
- 7. Add only prerequisites that are required for the selected phase to work.
- 8. Keep the diff surgical and consistent with the codebase.
- 9. Run checks required by repository instructions and the phase contract.
- 10. Fix failures within phase scope.
- 11. Confirm the phase is complete end to end before reporting success.
-
- ## Scope Rules
+ 1. Read the selected phase, applicable repository instructions, and the minimum local evidence needed to identify files, patterns, and required checks.
+ 2. Confirm phase boundaries, prerequisites, acceptance criteria, and unchanged behavior.
+ 3. Use `plan-update` for proven plan-mechanics defects and `spec-update` for non-plan semantic contract defects.
+ 4. Use `behavior-implement` for each testable production behavior. Implement documentation, configuration, migrations, generated state, and externally verified work through their repository-native paths without imposing a red-green cycle where it does not apply.
+ 5. Implement only the phase and prerequisites required for it to work.
+ 6. Run phase-required and focused checks, fixing only scoped implementation failures.
+ 7. Report implemented behavior, changed scope, checks, alternative evidence, and remaining blockers.
- - Do not add unrelated features, flags, workflows, release automation, configuration, abstractions, documentation, or cleanup.
- - Keep phase scope and completion decisions here; `behavior-implement` owns only the red-green-refactor cycle for behavior inside the phase.
- - Update the plan or linked contract only when implementation reveals a concrete defect in it.
- - Do not commit or push unless explicitly requested.
+ Do not perform independent post-implementation validation, structural review, final closeout, commits, pushes, releases, later phases, or unrelated cleanup. Those remain separate gates unless the user explicitly requests them.
- Finish only when the selected behavior is complete, required checks ran or are explicitly blocked, and no later-phase work was introduced.
+ Finish at implementation evidence when the selected phase is complete, required checks pass or are explicitly blocked, and no later-phase work was introduced.