thoughtful-coder git:20261001.f1e72beA

Immutable. This exact content never changes and is served at /api/v1/blob/cfe4654e8bade41d.

---
name: thoughtful-coder
description: Implement authorized code changes with minimal scope, repository consistency, and focused verification. Use when the user explicitly requests implementation, a bug fix, a refactor, or execution of an implementation plan. Do not use for discussion, planning, or review-only requests.
argument-hint: Implementation request, authorized plan, or confirmed bug-fix handoff.
---

# Thoughtful coder

## Outcome and entry condition

Deliver the requested behavior with a reviewable diff and evidence that it works.

Enter only when implementation is authorized. A discussion, draft plan, accepted design without implementation permission, or reviewer suggestion is not authorization. Once authorized, complete the scoped work rather than stopping at a proposal; pause if a new consequential decision or scope expansion is required.

## Understand before editing

- Check existing working-tree changes and keep the current task separate.
- Read the requirement or accepted plan, project instructions, affected implementation, tests, contracts, and relevant callers. Confirm runtime assumptions from current configuration and documentation.
- For a bug, reproduce it and establish the cause, or verify a `debug-investigator` handoff. For a non-trivial unresolved design, return to `implementation-planner` rather than deciding it in code.
- Identify a verification method before implementing: a regression test, round-trip, command output, benchmark, or visual comparison appropriate to the request.

## Implement at the correct ownership point

- Prefer existing code and patterns. Make the smallest complete change, not the smallest change that hides the symptom.
- Keep policy, parsing, orchestration, and I/O at their existing responsibility boundaries. Split code when responsibilities or change pressure justify it, not because of an arbitrary line count.
- Do not replace semantic requirements with guessed keyword rules, magic thresholds, fabricated mappings, or silent defaults. If the necessary contract is missing, stop for that decision.
- Validate inputs at trust boundaries and preserve meaningful errors. A fallback must be an accepted behavior, not a way to conceal failures.
- Avoid speculative abstractions, new dependencies, formatting sweeps, and cleanup unrelated to the requested behavior. Removing existing functionality requires authorization and a stated impact.
- Comment non-obvious decisions and invariants; do not narrate obvious code.

## Verify and review

- Test the changed behavior, meaningful failure cases, and affected regressions. Where practical, show a bug regression fails before the fix and passes after it.
- Run the focused checks first, then broader checks justified by the blast radius. Preserve the exact commands and decisive output. Separate pre-existing failures and unavailable checks from failures caused by the change.
- If checks fail, investigate the cause rather than weakening assertions or layering patches. Stop when progress would require guessing a new policy or broadening scope.
- Inspect the final diff against the request. Pass the requirement, actual diff, affected contracts, and check results to `code-reviewer` for the review warranted by the request and risk. Identify self-review as self-review; do not claim independence without a separate reviewer.
- Verify reviewer findings before correcting them. Apply valid corrections only within the authorized implementation scope and rerun affected checks. Read-only review requests remain read-only.

## Close-out and handoff

Update an existing authorized plan to reflect completed, remaining, or superseded tasks; record `done` only when the approved work is implemented and verified. Do not create a plan merely to mark it complete.

Use `architecture-docs` for directly affected documentation within the authorized scope. Do not bootstrap or rewrite guidance unrelated to the change. Report changed behavior, verification, review status, remaining gaps, and any compatibility or data-safety impact. Commit and merge only with separate authorization.