Skip to content

Implement a change

Goal: a correct, minimal change with real verification evidence. Skill: Implement · Walkthroughs: WT-03 (tiny edit), WT-04 (feature with tests)

1. State intent, behavior, and boundaries

Section titled “1. State intent, behavior, and boundaries”

Implement needs actual change intent. Give the behavior, the scope, and anything that must not change:

Fix the supplied boundary error and add its regression test; preserve unrelated edits.
Implement the approved export requirement within the agreed module; add necessary tests and run authorized local checks after inspecting their effects.

An explicit change request authorizes ordinary bounded edits. You do not need to approve every file.

2. What the agent does before editing

Section titled “2. What the agent does before editing”
  1. Records the baseline: root, branch or HEAD, staged, unstaged, and untracked changes. If Git is absent, it says so and does not initialize it.
  2. Reads the relevant Memory entries and validates them against current code.
  3. Inspects the existing implementation, the closest safe pattern, and relevant tests.
  4. States a short plan for Normal work, or a single scope sentence for Tiny work.
  5. Assesses dependency, schema, API, security, and data effects. If policy makes something sensitive, it asks only for the missing scoped approval (see Handle sensitive actions).

3. Verification you should expect

Section titled “3. Verification you should expect”

Before running anything, the agent inspects the command, its scripts, and its target. Then it runs only applicable, permitted checks and reports each one:

Illustrative check record
**Name:** CHK-1 regression test for the boundary error (AC-2)
**Applicability:** required — acceptance criterion AC-2
**Command/method:** npm test -- --run src/orders/limits.test.ts
**Inspected scope:** src/orders/limits.ts and its test; working tree with this change
**Execution status:** PASS
**Observed result:** 1 file, 4 tests passed (runner output, exit code 0)
**Evidence location:** runner output in this conversation
**Limitations:** full suite not run; integration tests need a database (NOT_RUN)
**Baseline relation:** test is new; the pre-change run reproduced the failure

Watch for:

  • NOT_RUN or BLOCKED with a reason, instead of an implied pass;
  • baseline failures kept separate from new regressions;
  • no “all tests pass” when only a subset ran.

4. When a check fails

Section titled “4. When a check fails”

The agent classifies the failure (baseline, regression, environment, unresolved, or flaky) and repairs only within scope. At most two unsuccessful repair cycles follow before it stops with evidence and alternatives. It does not disable a failing test, weaken an assertion, or widen the change.

5. Verify the result yourself

Section titled “5. Verify the result yourself”
PowerShell
git diff --stat
git diff

The diff should contain only the requested change and its tests. Implement never commits, pushes, or opens a pull request. Those remain your actions.

Common pitfalls

Section titled “Common pitfalls”
Pitfall What happens
“Review this and fix what you find” That is a mixed request; the agent confirms the implementation scope before editing
No test environment Checks are BLOCKED or NOT_RUN; the task can end PARTIALLY COMPLETE, not DONE
Migration needed Writing the migration file is in scope; applying it needs its own approval under policy
Unsafe existing pattern The agent flags it with a safer proposal rather than copying it
Section titled “Related”