Code Writing

Understand the Change

1. Extract the requested behavior and what done means from the request or user-spec. Resolve ambiguity from repository evidence; ask only when a substantive choice changes the result or scope.
2. Read repository instructions, affected code, its usages, and only the project documentation needed to change it safely. A localized edit needs local context; cross-cutting work needs its contracts, architecture, and relevant patterns.
3. For non-trivial work, read every source file that will change, find affected contracts and reusable code, and establish the smallest useful baseline check. Inspect generated, lock, snapshot, or other mechanical artifacts through their generator, relevant diff, and deterministic validation rather than an unhelpful full read.
4. Before editing non-trivial work not covered by an approved user-spec or user-approved plan, briefly explain in simple user-facing language how the result will work end to end and why this is the simplest sufficient approach, then wait for approval.
5. Treat a new idea, risk, edge case, or opportunity discovered during implementation or review as a proposal, not authorization. A rare or unagreed scenario is a user decision even when its correction looks local. Correct autonomously only an authorized local defect in agreed normal behavior; ask before adding behavior, state, entities, contracts, dependencies, architecture, or material complexity.

Implement and Verify

1. Implement only the requested behavior. Reuse existing capabilities before adding abstractions or dependencies. Do not add speculative validation, fallbacks, configuration, optimization, or future flexibility without a current requirement or realistic project condition.
2. Validate untrusted input at its boundary, keep secrets out of source, preserve useful error information, and handle failures where the program can recover or add context.
3. Let straightforward code explain itself. Comment only when code cannot communicate the reason for a business rule, safety invariant, external constraint, compatibility workaround, deliberate tradeoff, or required ordering.
4. Apply test-master only to deterministic executable behavior or another explicit deterministic contract. For LLM-produced results, presentation-only layout, or freely editable copy, use agent, manual, or visual verification instead. If there is no test subject, do not create artificial assertions.
5. Run the smallest supported lint, format, type, build, render, and user-requested checks that cover the change. Use a project-wide command only when it is the available entrypoint or the change is cross-cutting. Separate unrelated baseline failures from regressions.

Run Fresh Reviews

After every completed implementation, launch one fresh review stage with the complete applicable reviewer set in parallel against the same revision. Include reviewers required by other active skills in that stage instead of starting a separate review sequence.

Include a fresh code-reviewer without a model override. Its review scope matches the change: a localized edit gets focused connected context; a broad change gets all affected contracts and architecture.

Also launch in parallel when applicable:

• security-auditor when a security boundary changed or the user requested a security review.

test-master owns the additional test-reviewer invocation when meaningful test code changed. Include that reviewer in the same review stage.

Give each reviewer the user request or user-spec, applicable repository instructions, validation evidence, every touched source file with relevant callers and dependencies, deleted or renamed file evidence, generator/diff/validation evidence for mechanical artifacts, and a short explanation of what changed, how the result works, why this approach was chosen, deliberate limits, and assumptions. The reviewer verifies that explanation against the request, project evidence, and code rather than accepting it as fact.

After reviewers return, apply no finding and do not repeat the review automatically. Explain what you implemented and how it works, then what reviewers found, what it can cause, whether you agree and why, and what you recommend. Group related points, avoid internal process terms, and wait for the user's approval before editing.