fable-discipline MCP Server
fable-discipline เป็นปลั๊กอินของ Claude Code ที่ทำให้การทำงานซอฟต์แวร์แบบเอเจนต์เป็นไปตามรูปแบบการทำงานที่ทำซ้ำได้: ออกแบบก่อนเขียนโค้ด ตรวจสอบหลังแก้ไข แยกผู้เขียนออกจากผู้ตรวจสอบ รักษาสถานะที่ตรวจสอบแล้วระหว่างเซสชัน และรายงานความไม่แน่นอนอย่างตรงไปตรงมา
เอกสาร
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.mdhold 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
| Skill | User-facing label | Fires when | Discipline |
|---|---|---|---|
milestone-workflow | Ship a milestone | Shipping a feature inside an existing app | Research and design, then build, then adversarial review. Also powers /milestone-research, /milestone-build, /milestone-review. |
artifact-build | Build an artifact | Building a CLI, MCP server, library, plugin, SDK, or skills pack | Design spec, checkbox TDD plan, modular build, review pass, live validation, release packaging. |
design-workflow | Design system workflow | Building or redesigning product UI | DESIGN.md contract, generated screens ported to code, verification against the contract and rendered screen. |
Investigating and measuring
| Skill | User-facing label | Fires when | Discipline |
|---|---|---|---|
research-investigation | Research with controls | Empirical analysis, forensics, reverse engineering, evidence-backed reports | Pre-registration, positive and negative controls, calibrated negatives, source-engagement ledger, capability-bound caveats. |
measurement-pipeline | Measurement audit | Recurring audits, benchmark matrices, scans, dashboards | Complete gap accounting, evidence as proof, infra-vs-real failure classification, one-command recurring run, stakeholder report. |
Always-on support
| Skill | User-facing label | Fires when | Discipline |
|---|---|---|---|
agent-orchestration | Agent orchestration | Multi-agent, fan-out, delegation, loops | Model-tier routing, verifier is not author, rubric-gated loops, dynamic workflows, worktree isolation. |
compounding-memory | Project memory | STATE.md, MEMORY.md, resume work, persistence | Fail, investigate, verify, distill, consult. Write before leaving, read at start, tag facts with Verified-by:. |
execution-rules | Execution discipline | Any hands-on coding or agent task | Literal instruction-following, thinking calibration, sufficient context, act then verify, no AI slop. |
Docs
- How to use this
- Copy-paste examples
- Troubleshooting — when the agent goes off the rails
Suggested repo setup
The plugin works best when each project has a clear CLAUDE.md:
# CLAUDE.md
## Verify commands
- npm run lint
- npm run typecheck
- npm test
## Deploy model
Describe what deploys on push, what requires approval, and what must not be touched casually.
## Project-specific rules
List the product's moat, data honesty rules, commit style, and file locations.
## State files
- .planning/STATE.md
- .planning/ROADMAP.md
The plugin provides the working discipline. The repo provides commands, constraints, and product truth.
Contributing
The collection grows by distilling repeatable workflow patterns out of real agentic work. Contribute patterns of work, never proprietary text.
See CONTRIBUTING.md for the method and the ethical line. See PROVENANCE.md for source attribution.