Implementation spec

Turn accepted software design into one temporary contract that an implementer can execute slice by slice. Constrain outcomes, consequential boundaries, and proof; leave reversible coding choices to implementation.

Process

1. Establish readiness. Identify the intended outcome, accepted product and design inputs, protected behavior, repository revision, applicable project instructions, and coding standards. Inspect the current repository rather than relying on conversation alone. If a missing decision could change user-visible behavior, a public contract, important data or security behavior, or costly-to-reverse architecture, return Not ready with the exact gap. Do not redesign it inside the specification.
2. Choose one temporary location. Use a path supplied by the user, then an established repository convention for local work artifacts, otherwise .work/implementation/<change-slug>.md. Keep the document local and outside version control. Work in the current worktree; do not create or manage worktrees, branches, commits, tracker items, goal directories, or execution state.
3. Write the validation contract. Define the evidence that slices and the completed product must produce, using commands and thresholds from accepted executable project configuration and reviewer-judged obligations from the project's coding standards. Include the rules under Validation. Confirm method feasibility against the existing product: launch the intended target and establish control and observation with the proposed method. Reuse directly applicable session evidence. This checks access, not behavior that has yet to be implemented; do not run implementation gates or record their later results in the specification.
4. Derive one linear slice sequence. Number slices in their only permitted execution order. Slice N consumes the integrated result of slices 1..N-1; never define parallel waves, dependency graphs, or alternate execution orders. Map every accepted requirement and protected risk to a slice or final validation, and expose anything intentionally cut.
5. Keep each slice vertical and bounded. A slice should deliver one narrow end-to-end behavior or operational capability, fit a fresh implementation context and one focused commit, and leave the repository coherent and verifiable. Put setup, schema, service, interface, tests, and documentation inside the slice whose outcome needs them. A contract change includes the compatibility updates its existing callers require in that same slice; for example, making an edit field required includes passing its current value from existing callers, even when new UI controls belong to a later slice. Allow a non-user-visible enabling slice only when later vertical work genuinely cannot proceed without it and the slice is independently green. For a wide mechanical change that cannot stay green vertically, use an explicit expand–migrate–contract sequence and justify the exception.
6. Run an independent preflight. Give one fresh read-only reviewer the complete draft and its accepted inputs. The reviewer checks coverage, fidelity, verticality, sequential coherence, handoffs, observable evidence, hidden decisions, unjustified work, overlap, and stale implementation prescription. It returns findings, not a replacement specification. Repair supported findings and rerun only affected checks. Return Inconclusive if independent review cannot establish that the bounded specification is safe to execute.
7. Ask for one acceptance. Explain in the human's language what will exist, what will not, the ordered slices, validation, material risks, assumptions, and cuts. Incorporate accepted feedback and ask for explicit acceptance of the whole specification. Mark the document Accepted only after that response, then stop without implementing a slice.

Document contract

Keep one Markdown document with: