scoped-implementation

Scoped Implementation

Use this skill when a plan already exists and the job is to implement one narrow slice without redrawing the lane.

Preconditions

Before coding, identify the frozen contract:

• intended slice
• acceptance criteria
• allowed files/functions/components
• tests allowed or expected to change
• explicit non-goals
• risky surfaces and approval status
• validation plan
• rollback path

If the contract is missing or too vague, stop after drafting a candidate contract and ask the user to approve it. Do not implement a non-trivial change without an auditable slice.

When the style-guide skill is available in this session, load its applicable standard here, before writing code — see its write mode: the project's own drafted guide if one exists, or its baseline otherwise. This is the point where style guidance is worth the most and costs the least: it shapes code as it is written instead of flagging it afterward. No separate skill invocation is required; reading the relevant portions is cheap enough to fold into this step. When style-guide is not available in this session, this step is skipped — scoped-implementation remains fully self-contained and follows the project's own documented conventions and dominant local pattern, as it already does for every other aspect of the code it writes.

Workflow

1. Confirm contract - restate the authorized surface and non-goals briefly.
2. Check starting state - inspect git status and relevant files. Do not overwrite unrelated user changes.
3. Implement only the slice - keep edits inside the authorized files/functions. Do not perform opportunistic cleanup.
4. Validate - run the targeted checks from the contract. Add or update tests when the contract requires it. Then run the lint skill differentially against the slice's starting commit (check --base <ref>) and account for every new finding: fix it inside the authorized surface, or record why it stands. If a fix needs an unauthorized file, stop and report rather than widening the surface. Report an uncovered language as a gap, never as a pass.
5. Prepare drift audit input - collect the frozen contract, changed files, diff summary, and validation results for the user's next explicit call to the drift-audit skill.
6. Report receipt - finish with the implementation receipt below. Do not run the drift-audit skill as part of this skill unless the user explicitly calls both skills in the same request.