fable-discipline
Reusable workflow discipline for Claude Code agents.
fable-discipline is a Claude Code plugin that makes agentic software work follow repeatable working patterns: design before code, verify after edits, separate author from reviewer, preserve verified state between sessions, and report uncertainty honestly.
It is not a model upgrade and not a magic prompt pack. It shapes procedure, not raw capability — a checklist, not a capability transplant. It can't raise a model's reasoning ceiling.
It runs on a three-layer model:
- The plugin — the generic HOW: how to plan, build, verify, review, remember, and report.
- Your repo docs — the local WHAT:
CLAUDE.md, DESIGN.md, STATE.md hold the product truth.
- Your prompt — the current goal: e.g. "Review the new onboarding flow."
Install
/plugin marketplace add petrkindlmann/fable-discipline
/plugin install fable-discipline@kindlmann-workflows
Or add the marketplace from a local path or git URL, then install.
How users actually use this
You do not read the skills manually before every session. Install the plugin, then work normally in Claude Code. The relevant skill auto-applies based on the situation.
Example prompts:
Plan the next billing milestone.
Build the analytics dashboard redesign.
Review the v1.8 changes before I merge.
Resume where we left off and check the project state first.
Build a CLI that scans Playwright tests for flaky selectors.
For serious product work, use the explicit milestone commands:
/milestone-research checkout-redesign
/milestone-build checkout-redesign
/milestone-review checkout-redesign
Use them in order. Approve the design doc between research and build.
Which command should I run?
| Situation | What to do |
|---|
| You are not sure what to build yet | /milestone-research name |
| You have an approved design and want implementation | /milestone-build name |
| You want a review before merge, release, or deploy | /milestone-review name |
| You are building a CLI, plugin, MCP server, library, SDK, or skills pack | Describe the artifact. artifact-build should trigger. |
| You are redesigning UI or using Stitch/Figma output | Describe the redesign. design-workflow should trigger. |
| You are running audits, scans, benchmarks, or recurring reports | Describe the measurement job. measurement-pipeline should trigger. |
| You are testing a hypothesis or writing an evidence-backed report | Describe the investigation. research-investigation should trigger. |
| You are delegating to subagents or running loops | Describe the fan-out. agent-orchestration should trigger. |
| You are resuming old work | Ask Claude to read state first. compounding-memory should trigger. |
The three main flows
1. Ship a product milestone
Use this for feature work inside an existing app.
/milestone-research checkout-redesign
Expected behavior: Claude reads the repo's CLAUDE.md, researches the feature, checks constraints, and writes a scoped design doc. It should not start coding yet.
/milestone-build checkout-redesign
Expected behavior: Claude builds from the approved design in atomic, verified steps. It runs the repo's smallest meaningful checks after each step.
/milestone-review checkout-redesign
Expected behavior: Claude runs an adversarial review, classifies findings honestly, and fixes them in numbered batches.
2. Build a standalone artifact
Use this for CLIs, MCP servers, plugins, libraries, SDKs, and skills packs.
Example:
Build a new CLI that scans Playwright tests and reports flaky selectors. Start with a design spec, then a checkbox implementation plan, then build it with tests.
Expected behavior: design spec first, implementation plan second, modular TDD build, review pass, live validation, release packaging.
3. Redesign product UI
Use this when creating a design system, writing a DESIGN.md contract, generating screens in Stitch/Figma, or porting generated UI to code.
Example:
Create a DESIGN.md contract for the analytics dashboard, then port the generated Stitch screen into real components. Verify the implementation against both the screen and the contract.
Expected behavior: read the full design contract, port screen-by-screen, avoid fake numbers and generic AI UI clichés, and verify against the real viewport.
Skills
Each skill is small, composable, and situation-triggered. Shared detail lives in skills/<name>/references/ so the same instructions are not duplicated.
Building and shipping
