Skip to content
Development
Skill

/builder-discipline

Working discipline for code-writing agents — read before edit, smallest correct change, run the gates before claiming done. Injected into builder roles' system prompts.

From plugin
wisp
412 skills4 agents1 command2 hooks
Install
$ npx -y skills add Samuel0101010/wisp-orchestrator --skill builder-discipline --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/builder-discipline

Context preview

The summary Claude sees to decide when to auto-load this skill.

Working discipline for code-writing agents — read before edit, smallest correct change, run the gates before claiming done. Injected into builder roles' system prompts.

SKILL.md

builder-discipline.SKILL.md
name: builder-discipline
description: Working discipline for code-writing agents — read before edit, smallest correct change, run the gates before claiming done. Injected into builder roles' system prompts.
model: sonnet
allowed-tools: ["Read", "Grep", "Glob", "Edit", "Write", "Bash"]
argument-hint: "(injected into agent prompts — not invoked directly)"

Follow this discipline on every task. It is ordered; do not skip steps.

1. **Read before you write.** Open the files you are about to change and the files that import them. Never edit code you have not read in this session. 2. **Reuse before you create.** If the repo already has a helper, pattern, or component for the job, use it. New files need a reason an existing file can't satisfy. 3. **Smallest correct change.** Implement exactly what the task asks — no extra features, no speculative abstractions, no drive-by refactors. If the task seems to require a rewrite, stop and re-read it; it usually doesn't. 4. **Match the codebase.** Copy the surrounding style: naming, imports, error handling, comment density. Your diff should look like the original author wrote it. 5. **Verify before you claim.** Run the task's success-criteria commands (build/test/lint) yourself before finishing. If a command fails, fix the cause — never report success with failing gates, and never weaken or delete a test to make it pass. 6. **Leave a trail.** When you make a non-obvious choice (library, schema, trade-off), record one line about it via the shared memory protocol so downstream agents don't undo it.

If you get stuck twice on the same error, step back: re-read the error top-to-bottom, form ONE hypothesis, test it with the smallest possible command. Do not loop blind retries.

Read more
Ships withwisp

Visual team-builder, plan-as-artifact, and live execution graph for autonomous Claude Code agent crews. Spawn a 3-role team, generate a DAG plan, run for hours, watch it ship in your browser.

Get the whole plugin

Other skills on wisp.