agentleFS
ChianWChianW/C31/skills/core/C31-coding-discipline/SKILL.md

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

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
  1. Very specific:

    If the coding task is unclear, ambiguous, or cross-cutting, run C31-brainstorm to produce a requirements doc.

    line 37
  2. Very specific:

    Verify clean test baseline: npm test / pytest / etc.

    line 48
  3. Distinctive:

    If tests fail on baseline → fix baseline first, or document known failures.

    line 49
  4. Very specific:

    Run C31-plan with No Placeholders enforced:

    line 55
  5. Distinctive:

    RED: Write one minimal failing test

    line 80
  6. Distinctive:

    Seam first (mattpocock/tdd): test only at pre-agreed public seams — before writing any test, name the seams under test and confirm with the …

    line 82
  7. Distinctive:

    Run test. Confirm it fails for the *expected* reason.

    line 86
  8. Distinctive:

    GREEN: Write simplest code to pass

    line 89
  9. Distinctive:

    Run test. Confirm pass + all other tests still pass + no warnings.

    line 92
  10. Distinctive:

    Remove duplication. Improve naming.

    line 96
  11. Distinctive:

    Run full suite after each refactor.

    line 97
  12. Very specific:

    Run C31-work with wave analysis:

    line 101
  13. Distinctive:

    After each task (or wave), run this checklist — do NOT spawn a subagent:

    line 116
  14. Distinctive:

    Only spawn subagent reviews for: security review, adversarial review, or complex architecture review (Superpowers v5.0.6: 30s checklist ≈ …

    line 130
  15. Distinctive:

    3-Fix Rule (from C31-debug): after 3 failed fix attempts on a bug, STOP — this is an architectural problem.

    line 169
  16. Distinctive:

    After completing the 7 steps:

    line 173

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 / discard

Step 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 outcome

Placeholder Detection Gate:

MarkerSeverityAction
"TBD" / "TODO" / "implement later"BLOCKINGStop. Investigate. Fill or remove.
"add appropriate error handling"BLOCKINGSpecify exact error cases and handling.
"similar to Task N"BLOCKINGInline the actual code.
Vague file paths ("the controller")BLOCKINGUse 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:

#CheckPass?
1Spec compliance: Does implementation match the plan?[ ]
2Code quality: Does it follow project conventions?[ ]
3Test coverage: Is there a test for this behavior? Does it pass?[ ]
4No placeholders: No TBD/TODO/similar-to in code?[ ]
5Type consistency: Function names/types match across tasks?[ ]
6Regression check: Full suite passes?[ ]
7Documentation: 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 # cleanup

If 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.

RuleSummary
Discriminated unionsModel variants with a kind literal discriminant so impossible states can't be represented. No optional-field bags.
Branded typesBrand primitives with & { readonly __brand: "X" } so they can't be mixed up. Validate once at creation.
Constructive modelingBuild the shape so the illegal value can't be constructed. [T, ...T[]] for non-empty, start plus duration for a range.
Simplest total typeKeep T[] while every operation stays total. Strengthen only where the loose type forces !, a cast, or a "should never happen" throw.
unknown over anyExternal data is unknown. any disables type checking everywhere it touches.
No as castsEvery as is a runtime crash waiting. Cast only after validation.
Narrowing hierarchyDiscriminant switch > in operator > typeof/instanceof > type guard > as.
Type guardsMust verify the claim — a lying guard is worse than as. Name them isX/hasX.
ExhaustivenessInline const _exhaustive: never = x; in default arms so the compiler errors on new variants.
satisfies over asValidates without widening literal types.
Boundary validationValidate where data crosses in; trust types inside.
Schema-derived typesPick/Omit/Parameters/ReturnType/Awaited before declaring a new interface.
Object argsObjects over positional args, so order is self-documenting. Skip on hot paths.
Real testsDon't mock what you can run. Mock only what you can't run locally.
Structured telemetryStructured 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.md

Anti-Rationalization Guard

ExcuseCounter
"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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.