Implement

Implementation

Deliver the requested behavior with evidence from the code path and the place where its output is consumed. Choose the smallest useful feedback loop for the change; increase verification when uncertainty, integration, or consequences increase.

The user's instructions take precedence over this skill's guidelines. Carry existing authorization forward and finish the work within scope. Resolve routine reversible choices with stated assumptions when useful. Ask only when missing information materially changes the result or an applicable boundary requires it; a skill workflow does not itself create a new approval gate.

Orient to the Change

Inspect repository status before edits and read existing diffs on touched files. Treat the checkout as shared space. Preserve work you did not create and respect claimed ownership.

Trace the behavior through its actual callers and consumers. Locate the nearest relevant pattern, tests, and real gate commands. Search by syntax when the question concerns code structure; use text search for names and prose. Read enough to understand the change, without a minimum file-read count or a broad context dump.

Recall non-obvious prior decisions through the configured memory workflow. Recheck volatile API, dependency, and deployment claims against current primary evidence or the installed version. Load specialized tool guidance when the task needs it, rather than guessing unfamiliar flags.

Distinguish diagnosis from implementation. "Why does this happen?" calls for a confirmed cause first. Once fixing is authorized, define a check that can distinguish the broken and intended behaviors.

Select a Verifiable Slice

Keep implementation and its verification together. Do not defer all tests until the feature is complete when an earlier test can guide the design. Equally, do not create tests for a reversible text edit merely to satisfy ceremony.

Break work at coherent behavior or contract boundaries. File count and number of edits are not useful universal cadence rules. Run the cheapest check that can expose the next likely failure before building more work on a potentially false premise.

Keep the Design Accountable

Follow local patterns unless a concrete problem justifies departing from them. Explain the reason, not a generic preference for a different style.

An abstraction can be valuable before a second caller when it enforces a real boundary. A shorter implementation can be worse when it obscures error behavior or compatibility. Judge the concepts and contracts, not line count alone.

Keep edits within the requested scope. Remove imports, stale labels, and dead branches your own change creates. Route unrelated findings to the project's sidequest or issue workflow when required; do not absorb them silently into the implementation.

When a scale problem appears, identify the contended resource. Fix isolation, indexing, batching, ownership, or capacity at the cause. A temporary concurrency reduction may help a controlled diagnosis or an authorized incident mitigation; it must not quietly become the permanent solution.

Verify the Claim You Intend to Make

Choose checks from the actual repository and affected behavior:

Use scoped checks for the inner loop and run required repository gates before the relevant commit or delivery boundary. Broaden testing when shared dependencies, failures, or residual risk justify it. Once appropriate checks pass, continue to completion instead of repeatedly running unrelated suites.

Preserve command exit codes and raw failure logs. A pipeline into tail can hide a failed command unless pipeline status is handled. Summarize verbose logs after capturing them. Do not impose arbitrary timeouts or run autofix across other agents' work. Discover the actual test framework's selection semantics before relying on a filtered run.

A useful receipt names the command, revision or working-tree state, environment when relevant, exit status, and what actually ran. A filter selecting zero intended tests does not verify the change. Cached results can be legitimate when their inputs match; disclose them rather than describing them as fresh execution. Wall-clock duration alone neither proves work nor proves a defective gate.

Check the Consumption Boundary