From code-discipline
Coding methodology for production-grade software development. Enforces structured thinking before coding, verifying reality, simplicity, surgical changes, contract awareness, and verifiable success criteria. Use when writing, reviewing, or refactoring code that needs to remain reliable over time, including production code, shared libraries, or code others will maintain. Triggers include "fix a bug", "add a feature", "refactor", "review code", "clean up", or explicit "apply code-discipline". Do NOT use for throwaway scripts, one-off prototypes, or quick demos.
How this skill is triggered — by the user, by Claude, or both
Slash command
/code-discipline:code-disciplineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A coding methodology for production systems that must last.
A coding methodology for production systems that must last. Not a communication standard. Not an honesty protocol. Purely: how to write code well.
Tradeoff: This discipline biases toward correctness and simplicity over speed and cleverness. For throwaway scripts, apply judgment. For production code — apply everything.
Every technical decision is evaluated in this order:
The goal is not "it works" — it is "it works correctly and reliably one year from now."
Don't assume. Surface tradeoffs. Map blast radius.
Before writing any code, present all four:
Rules:
Don't code from memory. The codebase is the source of truth.
Before writing or changing code:
The test: Every function call, import, type, and field in your code must trace to a verified source — an actual file, an actual signature, or documentation you read.
Evidence standard for claims: When stating that code works, that a test passes, or that a file does something specific, cite file:line and the quoted code or output. Paste actual command output rather than summarizing it. "It should work" and "I believe" are not evidence.
Minimum code that solves the problem. Nothing speculative.
All code must be modular, readable, testable, and defensible in a code review. There must be no magic numbers, hidden state, overly clever constructs, or silent failures.
Ask: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
Touch only what you must. Clean up only your own mess.
When editing existing code:
Required steps:
BEFORE — Read the file completely. Map dependencies and blast radius. Identify affected tests. Check if a suitable solution already exists in the project.
DURING — Change only what's needed. No unrelated refactoring. Preserve working behavior. No duplication.
AFTER — Run affected tests. Run full test suite. Verify zero regressions. Verify tests assert real-world behavior, not just mock matches. Document in changelog with facts, not narrative.
BEFORE COMMIT — Get explicit approval. Show exactly what's being committed. No hidden files.
The test: Every changed line should trace directly to the request.
Public surfaces are commitments. Treat them as such.
Before changing behavior, identify the contracts your change touches. Contracts include:
Rules:
The test: If your change crosses a system boundary, you must name the boundary and the consumers before changing it.
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
For multi-step tasks, state a plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
Checkpoint between steps: Complete and verify each step before starting the next. Do not chain steps without confirming the previous one succeeded. Catching divergence at step 2 is much cheaper than catching it at step 5.
Testing principles:
Strong success criteria let you work independently. Weak criteria ("make it work") require constant clarification.
| Prohibition | Detail |
|---|---|
| ❌ No guessing or inventing | If information is missing — stop and ask. Never fill gaps independently. |
| ❌ No unrequested features | No "we could also" implemented. Any addition requires explicit approval. |
| ❌ No broad refactors | Change only what was requested. No "while I'm here" modifications. |
| ❌ No band-aids | No temporary values without expiry. No hardcoded test values in production. No silent error swallowing. |
| ❌ No claims without evidence | When stating that code works, that a test passes, or that a file does something — cite file:line plus the quoted code or output. Paste actual command output, do not summarize it. "It should work" is not evidence. |
| ❌ No fake completion | Never claim "done" without verification. If something was not verified, say so explicitly: "Implemented, but not verified because..." |
| ❌ No dangerous actions without approval | Explicit approval required before destructive actions: deleting files, dropping schemas, force-pushing, removing tests, disabling checks, large rewrites, or modifying authentication or authorization logic. |
| ❌ No committing without approval | The user must say "commit now" before git commit, "push now" before git push, "deploy now" before deployment. |
Before each step, answer all four:
Only if all four answers are positive — proceed.
These guidelines are working if: changes are smaller and more focused, no unrequested features appear in diffs, every task has a verifiable definition of done before work begins, and contracts are preserved unless an explicit migration is agreed upon.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
npx claudepluginhub eliranpv11/code-discipline-skills --plugin code-discipline