Creator's demonstrated workflow
This section records only the workflow directly described in the supplied creator sources. It is source evidence, not a statement that Fable, /loop, Workbench.md, ShadCN, ultracode, or any feature is available in a given environment.
1. Give Fable the goal, not the steps
Give Fable “big, sweeping, underspecified work” as a goal rather than spelling out how to do it. The creator describes handing Fable a goal “the way you’d hand a goal to a brilliant person you trust and let them find the best way there.” The creator says Fable has more room to determine the “how,” and that each dictated step can override its judgment.
Input: A broad desired outcome.
Action: State what should be achieved without prescribing an implementation sequence, except for necessary constraints.
2. Set house rules so Fable can work within them
Fence an underspecified goal with a few rules Fable cannot cross. The creator calls these house rules: the handful of things that should always be true regardless of how Fable reaches the goal.
Creator example: When building an agent, models may over-engineer by reaching for a regex filter for a specific case. The creator’s standing rule is essentially: do not hard-code special cases; describe the desired behavior in the agent’s system prompt and let the agent reason.
For extra protection, the creator says Fable can hand a sub-agent one job: check the work against the house rules before anything is pushed.
Inputs: A short set of non-negotiable house rules.
Actions:
- Provide the house rules with the goal.
- Have a Fable sub-agent check the work against the house rules before anything is pushed.
Check: The sub-agent checks the work against the house rules.
3. Give Fable a real bar for “done”
Do not use adjectives such as “high quality.” Give Fable a hard bar it can check itself against. The creator says to give it “a bar it can never reach, but can always improve against.”
The creator’s example of a concrete bar is: “a stranger can’t tell our render from the real photo.” The creator also describes giving Fable the problem of determining how to measure an outcome when the measurement is not known in advance.
Demonstrated ShadCN component-library example
A friend was trying to clone a component library and was building on top of ShadCN. The creator identifies two problems:
- Fable was fighting ShadCN’s conventions instead of building the components.
- There was no way to say when the clone was done; the instruction was only “clone this.”
The reported actions were:
- Throw out ShadCN and start from scratch, because the component library was considered buildable from nothing and the existing code was considered baggage.
- Ask Fable to determine how to measure whether the result matched the original.
In this example, Fable took a screen recording of the real components in use, turned it into a heat map of where everything moved, and kept working until its version matched. The creator says it was not told how to make that measuring stick; it was told what “done” meant.
Inputs: A hard, concrete bar for the result, or the problem of determining an appropriate measurement.
Actions:
- Provide the bar.
- If the measure is unknown, hand that measurement problem to Fable.
Check: Use a measure tied to the real output-for example, the screen recording and movement heat map in the demonstrated component-library case.
4. Separate building from grading
The creator’s stated rule is: whatever builds something never gets to grade it. The creator describes the build agent as potentially biased by its trajectory and by its rationale for earlier choices.
Use a separate Fable sub-agent with a fresh context window. Point it at the real output-for example, actual pixels or the actual running app-and have it try to prove that the work is not passing.
Inputs:
- The goal.
- The house rules.
- The hard bar.
- The real output.
Actions:
- Have Fable build the work.
- Spin up a separate Fable sub-agent with a fresh context window.
- Give that sub-agent the real output.
- Have it try to prove the result does not pass the bar.
Check: The grading sub-agent evaluates the actual output, rather than the builder’s explanation.
5. Use /loop until the bar is hit, especially for creative tasks
Once there is a bar, put Fable on a loop against it. The creator says they use /loop constantly, especially on creative work.
The demonstrated loop is:
- Fable builds.
- Fable checks itself.
- Fable finds the biggest gap.
- Fable closes the gap.
- Fable goes again.
The creator reports letting this run for hours, sometimes days.
Fable does not decide that it is finished. In the creator’s description, there is always a next gap. The loop stops when the creator says it is done, or when Fable genuinely cannot find anything left to fix; the creator says the latter is rare when the workflow is set up this way.
Stop conditions demonstrated by the creator:
- The creator says it is done.
- Fable genuinely cannot find anything left to fix.
6. Use Workbench.md for long-run visibility and direction
For every long run, the creator has Fable post progress to Workbench.md. The source describes Workbench.md as an agent-first Markdown editor supporting images, in-line chat and progress-tracking boards, videos, HTML, and other content.
As Fable works, it keeps the document updated with screenshots, notes, and other indications of current status. The creator can glance at the document on a phone, see progress, and add comments to adjust the agent’s direction.
Action: For a long run, have Fable update a Workbench.md document with progress, including screenshots, notes, and other status evidence.
Output: An updated Workbench.md document showing where work stands and accepting creator comments.
Creator-provided Workbench.md setup prompt
The source provides this prompt for Claude Code, Cursor, or another URL-fetching agent:
Read https://workbench.md/pub/IbaCrTjLJT.md - that's this doc as plain markdown; it's live, so re-reading it always gets the latest. Then fetch https://workbench.md/agents.md, create a live doc for our current project - a board fence for tasks, a status fence set to `building`, a chat fence - and reply with the doc link. We'll work from there.
The source says the resulting Workbench.md document uses a board fence for tasks, a status fence set to building, and a chat fence.
7. Let Fable build on what has already been done
The creator says old work becomes fuel for new work.
The creator’s example sequence is:
- The first real thing built with Fable was a photorealistic 3D forest. It required a carefully written initial prompt because there was no reference point, quality example, or known approach.
- For the Hogwarts demo, the creator pointed Fable at the forest’s code and quality bar and instructed it to match that work and go beyond it.
- Fable could also read traces of old Claude Code sessions: what it tried while building the forest, and what worked and did not work.
- Rather than prescribing “use a separate sub-agent for each object in the scene,” the creator could say, “read the forest traces and learn what worked.”
Inputs: Prior code, quality bars, and, where available, prior Claude Code session traces.
Action: Point Fable to prior work and tell it to use or learn from that work.
8. Get out of its way
The creator clears obstacles up front so Fable does not need to stop and ask questions repeatedly.
For a real-world service that costs money, the creator gives Fable a budget rather than requiring permission for every use, tells it where keys and credentials live, and instructs it in writing to make its own calls and return only when it is truly blocked or reaches a decision only the creator can make.
Creator’s planning exception
For “huge, extremely consequential things,” the creator wants the plan before any code and wants Fable to ask every question it is unsure about up front. Once the plan is settled, it runs without stopping.
Inputs:
- A budget when using a real-world service that costs money.
- The location of keys and credentials.
- A written instruction to make its own calls and return only when truly blocked or when only the creator can decide.
Exception action: For a huge, extremely consequential build, obtain the plan before code and resolve Fable’s uncertainties up front.
9. Use the creator’s two coordination models
Engineering: run a team
For engineering, the creator runs several Fable sessions at once. They pull tasks from a list, a Linear board, the Trello-style board in Workbench.md, or direct assignment.
The demonstrated engineering coordination model is:
- Several Fable sessions work at once.
- Each session does its task.
- Each one triple-checks its work with sub-agents.
- Each one opens a PR with the evidence described above.
- One more Fable does nothing but integrate: it merges the PRs, runs everything, tests like a real user, and keeps the whole thing green.
When two features overlap, the creator tells one Fable to watch the other’s traces while it is being built and stay compatible. The Fables coordinate in the Workbench.md chat; one watches the other, flags conflicts as they arise, and integrates as work lands.
Outputs: Task evidence, PRs, and an integrated result tested like a real user.
Creative work: lean on momentum and detail
For creative work, the creator uses the same loop and hard bar, but fans out sub-agents to perfect individual pieces rather than having one Fable do all work.
Creator example: Use a separate sub-agent to perfect each kind of tree in a forest.
The creator sometimes runs a few completely separate attempts at once, keeps the best one, and carries what worked into the next round.
Outputs: Improved individual pieces, selected best attempt or attempts, and lessons carried into the next round.
10. When to spend on ultracode
The creator describes ultracode as a heavier mode that costs much more and says they almost never use it.
The creator says a good loop with an ambitious enough goal usually gets the result without ultracode. The described case where ultracode earns its cost is foundations: a new system built from scratch that will be worked on for months, such as the core of a business or codebase.
The creator relates this to throwing out ShadCN: a good foundation makes later work easier, while a bad foundation makes it harder indefinitely. For this kind of foundation work, and “pretty much only” this kind, the creator says the extra cost is worth it.
Limitation: The creator does not present ultracode as the default mode for ordinary work.
XSkills operational adaptations
The following execution aids are compiled by XSkills. They are not creator-stated requirements, tools, or results.
XSkills operational adaptation: create an executable run brief
Before starting, record the demonstrated inputs and decision boundaries:
## Run brief
- Goal: [broad desired outcome]
- House rules: [few non-negotiable rules]
- Hard bar: [concrete definition of done]
- Real output to inspect: [actual pixels, running app, recording, etc.]
- Prior work to consult: [code, quality bars, Claude Code traces]
- Progress location: [authorized Workbench.md document, if used]
- Budget and approved service scope: [if relevant]
- Decisions reserved for the responsible human: [list]
Check: Confirm that the bar identifies evidence from real output, not merely a builder explanation.
Fallback: If no hard bar is available, the run may propose a measurement, but its output is exploratory or unverified-not passed against a defined bar-until a bar is established.
XSkills operational adaptation: portable builder fallback when Fable is unavailable
Use Fable first when it is available and authorized, since it is the source-specific tool. If Fable is unavailable, use one authorized builder agent or coding session capable of modifying the relevant work and inspecting its real output.
Actions:
- Give the portable builder the same goal, house rules, hard bar, and relevant prior work.
- Require an inspectable output artifact after each cycle.
- Use a separate reviewer with a fresh, independent context to try to disprove passing against the bar.
- Use an available repeatable execution mechanism to repeat the demonstrated build → check → biggest-gap → close-gap sequence.
Output: The current artifact, evidence against the hard bar, the largest identified gap, and the next proposed action.
XSkills operational adaptation: limitation. This fallback preserves the described roles and sequence where possible; it is not Fable, /loop, or a claim that the creator used a substitute.
XSkills operational adaptation: distinguish /loop from generic planning and ordinary iteration
The creator’s demonstrated execution sequence is a bar-driven /loop: build, check, identify the biggest gap, close it, and go again. Do not relabel generic project planning, a one-off revision, routine test-and-fix work, or ordinary iteration as this workflow.
Action: Start a loop only when there is a stated hard bar, real output to inspect, and a repeatable biggest-gap decision.
Check: Each cycle must name the real-output evidence, the biggest gap, and the action intended to close that gap.
Fallback: If these conditions are absent, do not represent the work as a /loop run. Use ordinary execution without claiming it follows the creator’s loop.
XSkills operational adaptation: planning boundary. Do not add a general planning phase to this workflow. The only creator-described planning case is the exception for huge, extremely consequential work, before code.
XSkills operational adaptation: record loop evidence
Use a minimal record for each bar-driven loop cycle:
## Loop cycle [number]
- Change or attempt:
- Real output inspected:
- Hard-bar evidence:
- Biggest gap found:
- House-rule check:
- Fresh-context reviewer attempt to disprove passing:
- Next action:
- Status: continuing | blocked | creator stopped | no gap found
Check: A builder self-check does not replace the creator’s separate fresh-context grading model.
XSkills operational adaptation: preserve the creator’s engineering coordination model
When using the creator’s engineering-team setup, retain its specific sequence: parallel task sessions, sub-agent triple-checking, PRs with evidence, then a dedicated integrating Fable that merges, runs everything, tests like a real user, and keeps the whole thing green.
Action: For each task handoff, identify the task, evidence, triple-check status, dependencies or overlaps, and readiness for the integrating Fable.
Fallback: If parallel Fable sessions or PRs are unavailable, maintain a shared task-to-evidence-to-integration record. Do not claim this reproduces the creator’s multi-session Fable-and-PR model.
XSkills operational adaptation: handle ShadCN and ultracode decisions as decisions
The source describes throwing out ShadCN in one component-library example and using ultracode for long-lived foundations. These are examples, not general instructions.
Action: Before discarding an existing foundation or incurring a higher-cost mode, identify the proposed change, its expected consequence, and whether the work is a long-lived foundation.
Stop condition: Do not discard ShadCN or another existing foundation, and do not incur paid-mode cost, without approval from the responsible decision-maker.
XSkills safety adaptations
The following safeguards are added by XSkills and are not creator-stated requirements.
XSkills safety adaptation: authorize and review privacy before Workbench.md updates
Before posting progress, screenshots, notes, traces, task details, or other material to Workbench.md, obtain authorization for that document and review the material for privacy, confidentiality, credentials, personal data, proprietary code, and third-party content.
Actions:
- Confirm who may access the Workbench.md document and whether posting is authorized.
- Review each proposed progress update and screenshot before posting.
- Redact, omit, or use approved substitutes for material not approved for that audience.
Check: Confirm that the content and the document’s sharing scope are authorized before each post containing new evidence.
Fallback: Keep progress in an approved private location or provide a non-sensitive status summary.
Stop condition: Do not post to Workbench.md when authorization or privacy review is unavailable, or when content cannot be safely redacted.
XSkills safety adaptation: protect credentials and paid-service limits
The creator’s workflow says to tell Fable where keys and credentials live and to provide a budget for costly real-world services. Do not place secret values in prompts, Workbench.md documents, screenshots, chats, PRs, or logs.
Action: Provide an approved credential location or mechanism rather than the credential value.
Check: Confirm the authorized budget, spending limit, and service scope before paid service use.
Stop condition: Stop and request a decision if required credential access, budget, or service authorization is unavailable.
XSkills safety adaptation: gate consequential actions
The source discusses pushes, PRs, integrations, real-world services, and long-running execution, but does not establish authorization boundaries for production or other consequential actions.
Action: Require explicit authorization before deployment, merging into a protected branch, deleting data, spending beyond an approved budget, contacting third parties, or changing production systems.
Fallback: Prepare the evidence, proposed action, and expected impact for authorized review; do not perform the action.
XSkills safety adaptation: do not pass work that cannot be inspected
The creator’s fresh-context grading model depends on access to real output.
Stop condition: If the separate reviewer cannot inspect the relevant actual pixels, running app, recording, or other real output, mark the result unverified, not passed.
Fallback: Restore access, collect the relevant real output, or pause for a responsible decision.
XSkills safety adaptation: scope long-running execution
The creator reports /loop runs lasting hours and sometimes days.
Action: Set authorized runtime, spend, and scope boundaries before a long run.
Check: Periodically record elapsed time, the current biggest gap, and relevant cost.
Stop condition: Stop at the agreed boundary; preserve the latest artifact and any authorized progress record; report the remaining gap and required decision.
Source attribution
XSkills compiled this skill independently from the supplied sources:
- Matt Shumer, X post:
https://x.com/mattshumer_/status/2075294138463822151 - Matt Shumer, Workbench.md article:
https://workbench.md/pub/IbaCrTjLJT
Independently compiled by XSkills from the supplied sources. Matt Shumer did not author or review this skill. Attribution does not imply endorsement.