Paul BakausandClaude Fable 5
6b3d174e93
Pairwise evals on Fable one-shot (6-task regression set, opus-4-8 judge, position-bias-cancelled): the hand-distilled ~55-line lean core beat the heavy v4 core 66% overall / 67% craft head-to-head, and moved the decisive win-rate vs frontend-design from 13% to 27% (40% with the completion-time QA scan; craft went positive 6-5 for the first time). 18/18 lean samples ran context.mjs + palette.mjs vs a minority under the heavy core: shorter instructions get followed. Context weight itself was suppressing both compliance and boldness. Structure: persona + brief-wins + existing-worlds + subject-grounding + plan/self-check + boldness + prove-don't-claim + commit + calibration + compressed craft floor + two-paragraph registers. Commands table kept; the no-arg context-aware menu logic moved to reference/routing.md (read on demand in the only case that is inherently interactive). Provider blocks and rule anchors preserved. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.9 KiB
No-argument routing: the context-aware menu
Read this when the user invokes {{command_prefix}}impeccable with no argument. They are asking "what should I do?" Make the menu context-aware instead of static.
Setup has already run context.mjs. If that reported NO_PRODUCT_MD, the project has no captured context yet: lead the menu with /impeccable init as the top recommendation (one line on why) and still show the rest below; don't silently jump into init. Otherwise run node {{scripts_path}}/context-signals.mjs once and read its JSON, then lead with the 2-3 highest-value next commands, each with a one-line reason pulled from the signals, followed by the full menu (the Commands table in SKILL.md, grouped by category). Never auto-run a command; the recommendation is a suggestion the user confirms.
Reason over the signals; there is no score to obey:
setup.hasDesignfalse whilesetup.hasCodetrue →document(capture the visual system).critique.latestisnull→ the project has never been critiqued; for a set-up project with a real surface, offering/impeccable critique <surface>is a strong default.critique.latestwith a lowscoreor non-zerop0/p1→polish(it reads that snapshot as its backlog), or re-runcritiqueif the snapshot looks stale.git.changedFilespointing at one surface → scopeauditorpolishto those files specifically, naming them.devServer.runningtrue →liveis available for in-browser iteration; if false, don't lead withlive.liveand the bundleddetect.mjsare web-only. Ifsetup.platformisios,android, oradaptive, don't lead with either; the browser overlay and the HTML rule engine don't apply to native app code.- Otherwise group by intent exactly as init's "Recommend starting points" step does (build new / improve what's there / iterate visually), tailored to
setup.register.
If scan.targets is non-empty and setup.platform is not ios/android/adaptive, run node {{scripts_path}}/detect.mjs --json <scan.targets joined by spaces> once (the bundled detector over local files: no network, no npx; it reads HTML/CSS, so skip it for native projects). scan.via tells you what they are: git-changes (the markup/style files in your dirty tree, the most relevant set), source-dir (e.g. src, app), html, or root. Fold the hits into your picks: many quality / contrast hits → audit or polish; a specific slop family → the matching command (gradient text or eyebrows → quieter / typeset, flat or gray palette → colorize, and so on). It's a real, current signal that beats guessing. If detect errors or the tree is large and slow, skip it and recommend the user run audit themselves; never block the suggestion on it.
Keep it to 2-3 pointed picks with the exact command to type. The menu stays the fallback; the recommendation is the lede.