Content
86%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A tight, highly actionable skill: it gives exact commands for both the MCP and CLI paths, gates every apply behind a dry-run plan and user confirmation, and verifies the result. The only gaps are a small duplicated explanation of bts.jsonc and the absence of an explicit fix-retry loop after a failed verification step.
Suggestions
State what bts.jsonc contains in one place only — Step 1's "It tells you the current stack" duplicates the overview paragraph's "records the stack chosen at creation".
Close the error-recovery loop: after "Prove it runs", say what to do when the plan reports a conflict or the typecheck/build fails (retry with adjusted addons, or surface the decision to the user) instead of only reporting the error.
Add one line on handling plan-reported conflicts (e.g., whether to skip the conflicting addon or ask the user), since Step 3 surfaces conflicts but no step resolves them.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and dense (interface options, edge cases like "axiom can't be added later", a tight Rules section), but Step 1's "It tells you the current stack" repeats the overview's "records the stack chosen at creation" — a minor, trimmable redundancy that keeps it below anchor 5's "every token earns its place". | 4 / 5 |
Actionability | Fully executable, copy-paste-ready guidance across both interfaces: `bunx create-better-t-stack@latest add --addons <names>`, a complete `add-json` JSON payload with `dryRun`, `npx create-better-t-stack@latest schema --name addonOptions`, plus named MCP tools (`bts_add_addons`, `bts_plan_addons`, `bts_get_schema`). It is not below anchor 5 since the common cases (shell, MCP, neither) are each covered with concrete commands. | 5 / 5 |
Workflow Clarity | Clear 6-step sequence with real checkpoints: dry-run plan, "Show the user what will change, including any conflict the plan reports", apply only "after the user agrees", and "Prove it runs… Report the exact error if a step fails". It falls short of anchor 5 because error handling is report-only — there is no fix-and-retry feedback loop and no guidance on resolving reported plan conflicts. | 4 / 5 |
Progressive Disclosure | The body is under 50 lines with no bundle files (references/, scripts/, assets/ are absent) and no need for external references, organized into clear sections (Pick the interface, Steps, What can be added, Rules). Per the rubric's simple-skill guidance, well-organized sections alone merit a 5 here. | 5 / 5 |
Total | 18 / 20 Passed |