# Code Writing > Guides code implementation through proportional context reading, focused changes, verification, and fresh reviews. Use whenever code needs to be written — from a short ad-hoc edit to a full user-spec. Use when: "напиши код", "закодь", "реализуй", "write code", "implement" Do NOT use for pure layout from Figma, Claude Design, screenshots, or an existing visual style ("сверстай", "подвинь блок", responsive) — use layout-writing instead. Direct mixed layout + business-logic work uses both layout-writing and code-writing. For creating a user-spec → user-spec-planning skill. - Skill: `pavel-molyanov/code-writing` (Agent Skill) - Install (CLI): `npx skillmds@latest add pavel-molyanov/code-writing` - Raw SKILL.md: https://api.skillmd.com/api/skills/pavel-molyanov/code-writing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: pavel-molyanov (https://skillmd.com/u/pavel-molyanov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/pavel-molyanov/code-writing --- # 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. Discuss the approach before editing only when evidence exposes a substantive fork, risk, or scope decision. Otherwise choose the smallest safe implementation that follows project or framework conventions. 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. When the change can alter observable behavior, apply `test-master` to select and run the protecting tests. If it has no test subject, state that instead of creating 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 Run no more than two review waves. One wave launches the complete reviewer set selected for the implementation in parallel against the same revision. Use that same complete set in both waves. Include reviewers required by other active skills in these same waves instead of starting a separate wave sequence. After every completed implementation, 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 every wave for this implementation. 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, and generator/diff/validation evidence for mechanical artifacts. Review findings are diagnoses, not a work queue. Check the evidence and exact correction. Apply only an authorized local correction to agreed normal behavior. If the scenario is rare or unagreed, or the correction adds behavior, state, entities, contracts, dependencies, architecture, or material complexity, reject it with a short reason or ask the user before editing. `user_decision_required: false` does not replace this check. Reject unsupported findings with evidence and report unrelated findings without expanding the task. After wave 1, correct only authorized local defects in agreed normal behavior that do not require a user decision, then rerun affected direct checks. If those corrections changed the reviewed result, launch wave 2 with the same complete reviewer set. Stop after a clean wave or when no authorized correction changes the result. After wave 2, do not launch another reviewer automatically. Correct remaining local defects only in agreed normal behavior and only when they do not require a user decision, rerun the applicable direct checks, and hand off any remaining findings or required decisions about scope, behavior, approach, or material complexity. Briefly explain rejected rare findings in the handoff.