2.8 KiB
No-argument routing: the context-aware menu
Read this when the user invokes /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 .github/skills/impeccable/scripts/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 (build new / improve what's there / iterate visually), tailored to the current surface and
setup.platform.
If scan.targets is non-empty and setup.platform is not ios/android/adaptive, run node .github/skills/impeccable/scripts/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.