Use this skill while editing code. The goal is to make the intended change with the least necessary structure, clear behavior, and concrete verification.
Workflow
- Reconfirm the requested behavior, current behavior, relevant tests, and the design shape if one was chosen.
- Keep edits scoped to the requested path and the files required by the change.
- Preserve external behavior unless the request explicitly changes it.
- Match local patterns, naming, framework conventions, and helper APIs before adding a new abstraction.
- Separate concerns only where the code is already mixing parsing, validation, business rules, persistence, formatting, orchestration, or side effects.
- Make side effects visible and keep error behavior, data shapes, and public contracts stable unless intentionally changed.
- Keep strong coupling close. Weaken coupling that crosses modules, services, public contracts, or many call sites.
- Add or update focused tests and checks near the behavior being changed.
- Stop for redesign only when the current plan cannot be implemented safely.
State And Data Checks
Apply this pass when the edit touches databases, files, queues, caches, search indexes, event streams, jobs, external APIs, or production records:
- Source of truth: what data is created, read, updated, deleted, cached, derived, or emitted?
- Invariant: what must remain true for the feature to be correct, and where does the code assert it?
- Compatibility: can old readers, old writers, new readers, and new writers coexist during deploy and rollback?
- Idempotency: can retry, replay, or duplicate delivery create duplicate records, emails, money movement, jobs, or notifications?
- Concurrency: can two actors update the same entity or run the same operation at once?
- Consistency: what needs strong consistency, and what can be reconciled later?
- Observability: how would an operator detect and repair a silent or partial failure?
Code Quality Checks
Use these as editing pressure, not as a rewrite license:
- Names express intent and domain language.
- Functions and modules have one clear responsibility at the current granularity.
- Control flow is simple enough to review.
- Duplication is removed only when it represents the same concept and same reason to change.
- Comments explain business rules, external constraints, security, performance, or history.
- Invariants the code relies on are asserted where they must hold, and an assertion failure is treated as a bug — never caught and continued.
- Positional arguments, magic values, hidden ordering, shared mutable state, and duplicated algorithms are weakened when they are distant or high risk.
- New helpers reduce real complexity instead of hiding it.
Output Contract
After completing edits made while this skill is active, report:
changed: what was edited.behavior: whether behavior changed or was preserved.risk_guarded: the main design, data, or code quality risk addressed.verification: tests or checks run, or why they could not run.
Gotchas
- Do not expand scope to clean unrelated code.
- Do not add layers, services, helpers, or dependencies because they sound tidy.
- Do not hide domain rules behind generic utilities.
- Do not leave architecture or data concerns as commentary when a test or check can guard them.
- Do not weaken harmless local coupling if the cure adds more indirection than clarity.