C31-coding-discipline
Skill1 starsChanged 3 months agoMITView on GitHub
Use when the user expresses coding intent: '帮我写', '实现', '开发', '修复', 'fix', 'bug', 'coding', 'code', '写代码', '改代码', or any request to write, modify, or debug software. Enforces a disciplined 7-step workflow with mandatory TDD, inline self-review, and No Placeholders.
- Commits and pushes
In this repository56 other files it gives its agents.
- C31-1stSkill
- C31-adopt-projectSkill
- C31-brainstormSkill
- C31-compound-refreshSkill
- C31-compoundSkill
- C31-context-engineeringSkill
- C31-curatorSkill
- c31-daily-intelSkill
- C31-debugSkill
- c31-devSkill
- C31-grillSkill
- C31-lfgSkill
- C31-planSkill
- C31-researchSkill
- C31-specSkill
- C31-stormSkill
- C31-strategySkill
- C31-workflow-bug-reproductionSkill
- C31-workSkill
- rl-workflowSkill
- C31-cvideoSkill
- c31-loopSkill
- c31-sxsSkill
- teachSkill
- video-content-analysisSkill
- agent-reachSkill
- kimiimSkill
- skillhub-preferenceSkill
- c31-communitySkill
- c31-growSkill
- c31-gutcheckSkill
- c31-marketSkill
- c31-mvpSkill
- c31-priceSkill
- c31-processSkill
- c31-sellSkill
- c31-validateSkill
- c31-valuesSkill
- growth-hackerSkill
- c31-improve-codebase-architectureSkill
- C31-multi-reviewSkill
- C31-review-adversarialSkill
- C31-review-architectureSkill
- C31-review-securitySkill
- C31-reviewSkill
- c31-wizardSkill
- external-privacy-guardSkill
- find-skillsSkill
- gsd-map-codebaseSkill
- gsd-new-projectSkill
- gsd-progressSkill
- gsd-quickSkill
- gsd-shipSkill
- humanize-aiSkill
- time-awarenessSkill
- worker-safetySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 12 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
If the coding task is unclear, ambiguous, or cross-cutting, run C31-brainstorm to produce a requirements doc.
- Very specific: line 48
Verify clean test baseline: npm test / pytest / etc.
- Distinctive: line 49
If tests fail on baseline → fix baseline first, or document known failures.
- Very specific: line 55
Run C31-plan with No Placeholders enforced:
- Distinctive: line 80
RED: Write one minimal failing test
- Distinctive: line 82
Seam first (mattpocock/tdd): test only at pre-agreed public seams — before writing any test, name the seams under test and confirm with the …
- Distinctive: line 86
Run test. Confirm it fails for the *expected* reason.
- Distinctive: line 89
GREEN: Write simplest code to pass
- Distinctive: line 92
Run test. Confirm pass + all other tests still pass + no warnings.
- Distinctive: line 96
Remove duplication. Improve naming.
- Distinctive: line 97
Run full suite after each refactor.
- Very specific: line 101
Run C31-work with wave analysis:
- Distinctive: line 116
After each task (or wave), run this checklist — do NOT spawn a subagent:
- Distinctive: line 130
Only spawn subagent reviews for: security review, adversarial review, or complex architecture review (Superpowers v5.0.6: 30s checklist ≈ …
- Distinctive: line 169
3-Fix Rule (from C31-debug): after 3 failed fix attempts on a bug, STOP — this is an architectural problem.
- Distinctive: line 173
After completing the 7 steps:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
C31 Coding Discipline
"NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST." — Iron Law of TDD
Enforced development workflow for coding tasks. Not a suggestion — a gate. Each step completes before the next begins. Skill routing conflicts (C31 vs wayfinding vs gsd) resolve in docs/SKILL-ROUTER.md.
7-Step Workflow
1. Brainstorm ← If requirements unclear, run C31-brainstorm first
2. Worktree ← git worktree add .feature-branch. Isolated development
3. Plan ← C31-plan with No Placeholders enforced
4. TDD ← RED → GREEN → REFACTOR for every unit
5. Execute ← C31-work wave execution, fresh subagent per task
6. Inline Review ← 30-second checklist (not 25-minute subagent loops)
7. Finish ← Verify tests → merge / PR / keep / discardStep 1: Brainstorm (Conditional)
If the coding task is unclear, ambiguous, or cross-cutting, run C31-brainstorm to produce a requirements doc. If already clear, skip to Step 2.
Gate: Requirements doc must exist (from brainstorm or user) before planning.
Step 2: Worktree (Mandatory for Non-Trivial Tasks)
git worktree add .worktrees/feature-name -b feature/feature-name
cd .worktrees/feature-name- Verify clean test baseline:
npm test/pytest/ etc. must pass before changes. - If tests fail on baseline → fix baseline first, or document known failures.
Trivial fast-path: single-file typo fix, one-line change → skip worktree, edit in place.
Step 3: Plan (Mandatory)
Run C31-plan with No Placeholders enforced:
Every unit must contain:
- Exact file path (repo-relative)
- Complete code blocks (not "similar to Task N")
- Exact commands with expected output
- Test scenario: input → action → expected outcomePlaceholder Detection Gate:
| Marker | Severity | Action |
| "TBD" / "TODO" / "implement later" | BLOCKING | Stop. Investigate. Fill or remove. |
| "add appropriate error handling" | BLOCKING | Specify exact error cases and handling. |
| "similar to Task N" | BLOCKING | Inline the actual code. |
| Vague file paths ("the controller") | BLOCKING | Use app/controllers/orders_controller.rb. |
Plan granularity: 2–5 minutes per unit. If a unit takes >5 minutes, split it.
Step 4: TDD — RED → GREEN → REFACTOR (Mandatory)
For every implementation unit:
RED: Write one minimal failing test
- Seam first (mattpocock/tdd): test only at pre-agreed public seams — before writing any test, name the seams under test and confirm with the user. No test at an unconfirmed seam.
- One behavior per test
- Clear descriptive name
- Real code in test (no mocks unless external API)
- Run test. Confirm it fails for the expected reason. Never skip verification.
- No tautological tests (mattpocock/tdd): the assertion must never recompute the expected value the way the code does — expected values come from an independent source of truth (known-good literal, worked example, spec). A test that passes by construction can never disagree with the code.
GREEN: Write simplest code to pass
- Minimal implementation. No gold plating.
- Run test. Confirm pass + all other tests still pass + no warnings.
REFACTOR: Clean up, keep tests green
- Remove duplication. Improve naming. Simplify.
- Run full suite after each refactor.
Step 5: Execute (Wave Parallel)
Run C31-work with wave analysis:
- Wave 1: independent tasks → parallel subagents
- Wave 2+: dependent tasks → sequential
- Fresh subagent per task (context isolation — no pollution from prior tasks)
Commit per task (atomic, bisectable, revertible; conventional-commit message; no commit without passing tests):
git add <task-specific-files>
git commit -m "feat(scope): U3 Add parser coverage"Step 6: Inline Review (30-Second Checklist)
After each task (or wave), run this checklist — do NOT spawn a subagent:
| # | Check | Pass? |
| 1 | Spec compliance: Does implementation match the plan? | [ ] |
| 2 | Code quality: Does it follow project conventions? | [ ] |
| 3 | Test coverage: Is there a test for this behavior? Does it pass? | [ ] |
| 4 | No placeholders: No TBD/TODO/similar-to in code? | [ ] |
| 5 | Type consistency: Function names/types match across tasks? | [ ] |
| 6 | Regression check: Full suite passes? | [ ] |
| 7 | Documentation: Comments explain "why", not "what"? | [ ] |
If any check fails: fix immediately before proceeding.
Only spawn subagent reviews for: security review, adversarial review, or complex architecture review (Superpowers v5.0.6: 30s checklist ≈ 25min subagent loop, same quality).
Step 7: Finish — Merge / PR / Keep / Discard
cd main-repo
npm test # full suite must pass
git merge feature/feature-name # merge to main
git push origin feature/feature-name # open PR
git worktree remove .worktrees/feature-name # cleanupIf tests fail: return to Step 4. Do not merge with failing tests.
Type System Discipline (pstack, merged 2026-08-19)
The type checker is a proof assistant — make illegal states unrepresentable at compile time instead of catching them with runtime probes. Our incident history (W21b kind never set, analog selective-copy) is the optional-field-bag disease; this table is the vaccine. Full principle: wayfinding/ pstack principle-type-system-discipline; patterns: its references/patterns.md.
| Rule | Summary |
| Discriminated unions | Model variants with a kind literal discriminant so impossible states can't be represented. No optional-field bags. |
| Branded types | Brand primitives with & { readonly __brand: "X" } so they can't be mixed up. Validate once at creation. |
| Constructive modeling | Build the shape so the illegal value can't be constructed. [T, ...T[]] for non-empty, start plus duration for a range. |
| Simplest total type | Keep T[] while every operation stays total. Strengthen only where the loose type forces !, a cast, or a "should never happen" throw. |
unknown over any | External data is unknown. any disables type checking everywhere it touches. |
No as casts | Every as is a runtime crash waiting. Cast only after validation. |
| Narrowing hierarchy | Discriminant switch > in operator > typeof/instanceof > type guard > as. |
| Type guards | Must verify the claim — a lying guard is worse than as. Name them isX/hasX. |
| Exhaustiveness | Inline const _exhaustive: never = x; in default arms so the compiler errors on new variants. |
satisfies over as | Validates without widening literal types. |
| Boundary validation | Validate where data crosses in; trust types inside. |
| Schema-derived types | Pick/Omit/Parameters/ReturnType/Awaited before declaring a new interface. |
| Object args | Objects over positional args, so order is self-documenting. Skip on hot paths. |
| Real tests | Don't mock what you can run. Mock only what you can't run locally. |
| Structured telemetry | Structured logger diagnostics with debuggable context. No console.log in shipped code. |
Guardrails
- 3-Fix Rule (from C31-debug): after 3 failed fix attempts on a bug, STOP — this is an architectural problem. Escalate to human.
Output Format
After completing the 7 steps:
✅ C31-coding-discipline complete
Branch: feature/feature-name
Commits: N
Tests: all pass (X total, 0 failures)
Inline reviews passed: N
Files changed:
- path/to/file1 (lines +X -Y)
- path/to/file2 (lines +X -Y)
Residuals (if any):
- [description] → /tmp/c31-coding-residuals.mdAnti-Rationalization Guard
| Excuse | Counter |
| "Skip TDD just this once" | Stop. This is the slipperiest slope. |
| "I'll write tests after" | Delete any code written before test. Start over. |
| "This is too simple for TDD" | If it's that simple, the test takes 30 seconds. Write it. |
| "TDD is dogmatic" | TDD is not religion. It is verification. Verify first. |
| "The plan looks good, skip TDD" | Iron Law: NO CODE WITHOUT FAILING TEST. |
| "I'll commit manually later" | Commit is part of discipline. Skipping breaks traceability. |
| "Review is slow, skip checklist" | 30 seconds. Not slow. |
| "I'll fix edge cases later" | Edge cases are the first cases. Handle now. |
| "This is just a quick script" | Quick scripts become production. Discipline always. |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

