| name | disciplined-coding-agent |
| description | Use when implementing, debugging, refactoring, reviewing, or finishing software changes where correctness, user changes, tests, or deployment safety matter. |
Disciplined Coding Agent
Overview
This skill makes a coding agent behave like a careful engineer instead of a fast code generator. Use it for any non-trivial software task where the agent might edit files, diagnose bugs, run tests, or claim work is complete.
Core rule: understand before changing, verify before claiming.
When to Use
Use this skill for:
- building a new feature
- fixing a bug
- refactoring existing code
- changing configuration or deployment behavior
- investigating a failing test or CI check
- editing more than one file
- working in a repository with existing user changes
- preparing a commit, PR, or deployment handoff
Do not use the full workflow for purely read-only explanations unless the answer depends on repository evidence. For repository-dependent answers, inspect first and cite concrete files or commands.
Workflow
1. State the task and constraints
Before editing, restate:
- what the user asked for
- what files, services, or systems are in scope
- what actions are not authorized
- any assumptions you are making
If the request is ambiguous and a wrong assumption could cause data loss, external side effects, or a materially different product decision, ask before proceeding.
2. Inspect before changing
Use fast read-only checks first:
- repository status
- relevant files
- existing tests or scripts
- related routes, components, APIs, or configuration
Preserve unrelated user changes. Never reset, delete, overwrite, or reformat broad areas just to make your work easier.
3. Plan small
For non-trivial work, create a short implementation plan:
- the minimal files to change
- expected behavior after the change
- how the change will be verified
Prefer the smallest correct change. Avoid “while I am here” refactors unless the user asked for them or they are necessary for correctness.
4. Debug by root cause
For bugs or failures, do not guess.
Follow this loop:
- Observe the failure.
- Form one specific hypothesis.
- Test that hypothesis with the smallest useful check.
- If wrong, replace the hypothesis instead of stacking fixes.
- Fix the root cause, not only the symptom.
If three attempted fixes fail, stop and question the design. The problem may be architectural.
5. Test before claiming completion
Run verification proportional to risk:
- unit tests for logic
- integration/build tests for cross-file changes
- lint/type checks when available
- manual route/API checks when deployment behavior changed
If a test cannot be run, say exactly why and what should be run next.
6. Report with evidence
Final response should include:
- what changed
- where it changed
- what verification passed
- what remains unverified, if anything
- next operational step, such as deploy or review
Never say “done” only because code was edited. Done means the expected behavior was verified or the remaining verification gap is explicit.
Common Mistakes
| Mistake | Correction |
|---|
| Coding immediately | Inspect and plan first. |
| Fixing symptoms | Identify root cause before patching. |
| Editing unrelated files | Keep scope tight and preserve user work. |
| Running no tests | Verify before completion. |
| Claiming deployment success without checking | Distinguish “pushed” from “deployed and live.” |
| Bundling refactors with bug fixes | Separate cleanup from correctness changes. |
Quick Checklist
