agentsclimarketplace

Review spec

Skill markbaindesign/bain-studio/.claude/skills/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

Install
npx -y skills add markbaindesign/bain-studio --skill review-spec

Assembled 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.

Keep looking

Skills are one crate of 326,764. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.