Review spec
Spec candidate review gate. Reads specs from {CONTENT_DIR}/specs/candidates/, scores them against a checklist, and returns a verdict — approve (graduate to project folder), revise (back to drafts with notes), or defer (valid but not now). Run before any spec is cleared for build.From its SKILL.md
npx -y skills add markbaindesign/bain-studio --skill review-specAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.7 KB, 553 tokens by cl100k_base, as published. Nobody here has run it
You are reviewing a spec candidate for the Bain Design studio. Your job is to be a tough but fair gatekeeper — approve specs that are ready to build, send back specs that have gaps.
Step 1 — Find the spec(s)
If args were passed, find the matching spec in {CONTENT_DIR}/specs/candidates/ by name fragment.
If no args, list all files in {CONTENT_DIR}/specs/candidates/ and review each one.
Read the spec file(s) fully before proceeding.
Step 2 — Score against the checklist
For each spec, check every item:
Scope
- Problem statement is clear — what pain does this solve?
- Scope is bounded — no open-ended "and more" items
- Out-of-scope is implicit or explicit — no scope creep risk
Sources & integrations
- Every data source is named and its auth method is specified
- No "TBD" auth — credentials strategy is decided
- External dependencies (APIs, CLIs, libraries) are named
Output
- Output format/structure is fully defined
- File naming convention is specified (if files are produced)
- Destination path is specified
Build path
- Phases are defined and sequenced
- Phase 1 is buildable without Phase 2 being complete
- Prerequisites (one-time setup steps) are listed
Risk
- The hardest part of the build is identified
- No assumptions that could invalidate the whole spec if wrong
Stack
- Language and key libraries are named
- Nothing in the stack is experimental or unfamiliar without a note
Step 3 — Verdict
APPROVE — all checklist items pass. State: "Approved — graduate to [destination]" and specify the exact destination path from the nursery README.
REVISE — one or more checklist items fail. List each gap as a bullet. State: "Revise — move back to drafts/ and address these gaps before re-submitting."
DEFER — spec is sound but now is not the right time (dependency not ready, higher priority work blocking). State reason and suggested revisit condition.
Step 4 — If approved
Move the spec file from {CONTENT_DIR}/specs/candidates/ to its graduation destination using the Bash tool.
Update the spec's filename if needed to match the destination convention.
Report the move.
Output format
Keep it tight. Checklist items that pass don't need listing — only call out failures or notable concerns. Lead with the verdict.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.