write-code

name	write-code
description	Implement, modify, and verify code in existing repositories with minimal-risk, evidence-driven changes. Use when requests involve feature implementation, bug fixes, refactors with behavior parity, test creation, CI or build updates, or review follow-up code changes. Use when this capability is needed.
metadata	{"author":"doggy8088"}

Write Code

Follow this workflow to deliver correct, minimal, and verified code changes.

1. Define the target before editing

• Restate requested behavior in concrete input and output terms.
• Define acceptance criteria that are testable.
• List assumptions that can be falsified by a command or test.
• Ask one targeted question only when blocked; provide a recommended default.

2. Discover authoritative context

• Read the closest tests first, then public interfaces and types, then implementation details.
• Find existing patterns with focused search (rg for symbols, file names, and config keys).
• Identify repository invariants: architecture boundaries, lint and type rules, and CI expectations.
• For non-trivial work (3+ steps, multi-file, behavior change), maintain tasks/todo.md with:
  • checklist steps
  • explicit verification tasks
  • risk level and rollback notes for medium or high risk
  • working notes for constraints, decisions, and pitfalls

3. Plan a minimal safe change

• Prefer the smallest change that satisfies acceptance criteria.
• Reuse existing abstractions and conventions before adding dependencies.
• Avoid drive-by refactors unless they materially reduce risk in the current task.
• Gate high-risk changes (auth, billing, migrations, secrets, deployment) behind a safe rollout strategy.

4. Implement in thin slices

• Implement one observable behavior slice at a time.
• Keep one step in progress and verify it before expanding scope.
• Preserve explicit control flow and readable naming.
• Stop immediately when unexpected failures appear; diagnose before adding more changes.

5. Add regression protection

• For bug fixes, reproduce first and add a failing test when feasible.
• Add the smallest test that would have caught the issue.
• Prefer:
  • unit tests for pure logic
  • integration tests for boundaries (database, network, queue)
  • e2e tests only for critical user flows
• Validate boundary inputs and error paths, not only happy paths.

6. Verify before declaring done

Run the highest relevant verification tier and record outcomes.

• Tier 1: targeted tests plus lint and typecheck
• Tier 2: integration tests plus deterministic local repro
• Tier 3: e2e or staging checks plus rollout monitoring signals (when applicable)

If any check cannot run, state why and provide exact commands to run later.

7. Report with evidence

Provide a concise diff-oriented summary:

• what changed
• what behavior changed and what stayed the same
• commands run and outcomes
• remaining risks, assumptions, and rollback notes (if applicable)

Reference concrete artifacts: file paths, test names, and command lines.

Optional parallelization

• Use focused subagents for repository discovery, failing test triage, and risk review.
• Require structured deliverables from subagents: files, symbols, constraints, and verification commands.

Guardrails

• Never invent paths, APIs, or config keys; verify in-repo before asserting.
• Never expose secrets in code, logs, or output.
• Fail loudly and safely when behavior cannot be proven.
• Prefer reversible changes and explicit diagnostics over silent fallback behavior.

---

Converted and distributed by TomeVault — claim your Tome and manage your conversions.