Implement a Plan

Read anti-ai-writing before drafting text. Establish implementation authorization from the user's request or host Build handoff. Do not ask again for unchanged authorized work. A planning-only request does not authorize implementation, and Build does not automatically authorize commits or remote actions.

1. Establish intent and candidate

Read the accepted plan and its authoritative requirements, including accepted decisions and unresolved choices. Use jira-tickets in intake mode when necessary issue context is missing. Inspect repository instructions, branch/base, working changes, relevant execution paths, and dependency versions. Read task skills linked by the plan and applicable repository-local skills or instructions. Preserve unrelated work and reuse suitable task context rather than restarting intake.

Verify plan paths, interfaces, contractual values, dependencies, and check commands against the repository. Treat the plan as a proposal to reconcile, not proof of correctness. Use agent-planning only for material gaps or changes needing a revised plan. Do not rewrite user-protected plans; record proposed changes separately. Pause only tasks dependent on unresolved intent or scope.

Confirm a suitable task branch before implementation in a Git repository, preserving existing ancestry and changes. Follow repository branch conventions. Work on a protected/shared integration branch only when the user specifically requests it; resolve unsafe branch or isolation conditions before dependent edits.

2. Establish each task's evidence before editing

For each task, select its before-and-after checks before production edits:

• For new behavior or a bug repair, prefer a focused behavioral test that fails on the unchanged implementation. Confirm the failure is the intended assertion, then run the same test and applicable checks after the change. If a pre-change test cannot run safely or meaningfully, record why, establish the strongest available baseline or reproduction, and choose the post-change check before editing. Do not claim observed regression sensitivity from an unrun comparison.
• For behavior-preserving refactoring, establish the relevant passing baseline and check it again after the change. Follow test-authoring for coverage and sensitivity choices rather than duplicating its procedure here.
• For documentation-only work, select document checks. A reproduction-only request does not authorize production repair.

Confirm actual test selection and results; a successful command with zero selected tests is not verification. If a required check is unavailable, report the gap and pause only work that depends on it. Apply the selected checks during implementation and after repairs; this phase is not permission to defer pre-edit evidence.

3. Implement and verify tasks

Execute tasks in dependency order using writing-clean-simple-code. Load domain procedures when needed: api-design, frontend-engineering, safe-migrations, or ci-cd-workflows. Do not load all skills or add scope solely because a domain is mentioned.

Before production edits to a stateful, asynchronous, or interactive task, reconcile its plan criteria with the actual state owners, invariants, and high-risk transitions in the source. If an important failure, retry, overlap, or identity-change case is missing, add the needed criterion and verification to the existing task before implementation. Use scope and state coverage to select scenarios without expanding into unrelated combinations.

Use test-authoring for independently justified behavioral coverage. Run focused checks in verified package directories and confirm actual test selection. Run the before-and-after checks selected for the task. Investigate unexpected failures through root-cause-debug, preserving evidence and distinguishing introduced failures from unrelated ones.

Track each task's intended outcome, verification, observed result, and material decisions in the existing plan or host task artifact. Before a dependent task, compare the interface, value, or invariant it expects with what the earlier task actually produced; resolve conflicts against source requirements. Mark a task complete only when its outcome and checks match. Reconcile changes with requirements as evidence develops. Update affected documentation through technical-documentation when the behavior or setup changes. Keep temporary diagnostics out of the final diff.

For a high-risk task with interacting state transitions, run a focused read-only code-review on its completed delta after relevant checks pass and before dependent tasks proceed. Verify the fix against its trigger, then search the full candidate and affected callers for sibling instances of the same failure pattern. This targeted review does not replace final whole-candidate review; skip it for tasks whose behavior does not carry comparable risk.

When committing is authorized, create local commits at coherent, verified checkpoints using git-delivery. Each commit should capture a complete, reviewable change and pass applicable repository checks. Prefer checkpoints after completed tasks or closely related task groups rather than a fixed time or file count. Avoid accumulating unrelated completed tasks into one large commit. Preserve unrelated work and do not commit incomplete work merely to reach a checkpoint. Push only when separately authorized; local checkpoint commits do not require an immediate push or replace final whole-candidate verification and independent review.

Before final review, inspect the complete candidate, including relevant untracked files, for omissions, accidental changes, and contract mismatches. Run applicable integration/build checks and browser verification for affected UI behavior. A completed todo list or passing unrelated suite does not establish requirement coverage.

4. Independently review the complete candidate

Final independent code-review is a required step unless the user explicitly skips it. Use a fresh read-only reviewer when available and permitted by the host. Supply repository instructions, source requirements and accepted decisions, comparison base, and exact candidate including working/untracked changes. Provide raw evidence, not author reasoning, the implementation plan as proof, self-review conclusions, or suggested findings.

A task-level review does not replace whole-candidate review. If independent context is unavailable or prohibited, perform a separate evidence-based assessment when useful, disclose the limit, and leave independent review incomplete. An aborted, empty, or partial attempt remains pending; do not reinterpret it as approval. Retry a failed attempt when feasible without spawning redundant reviews of unchanged clean work.

Verify findings against actual triggers, consumers, and source contracts before repairing. Make supported repairs within existing authorization. Resolve consequential intent conflicts before dependent changes; retain unresolved or accepted deferred findings explicitly. Rerun affected checks after repairs and independently re-review the complete final candidate after material changes. A clean review covers only the candidate and scope it actually assessed.

5. Deliver actual state

Reconcile requirements, final diff, checks, and review coverage. Report implemented behavior, meaningful verification, remaining blockers, and unavailable checks/review. Do not claim the required review gate is complete when only self-review occurred. Preserve checkpoints across resumed work, validating them against current candidate state rather than repeating unchanged verified work or trusting completion labels.

When explicitly authorized, use git-delivery for commits, pushes, or PR preparation. Do not hide unmet required steps behind a delivery request; report limits if the user asks to proceed despite them. Preserve approvals and review history. Live deployment uses authorized release-readiness, not an automatic consequence of Build.