Slash Command

/spec-refine

Critiques a V0 project spec, identifies gaps, maps each feature to concrete tools using vibe-spec references, and promotes it to a V1 spec.

documentation

Popularity

Stars

Invocation

How this command is triggered — by the user, by Claude, or both

Slash command

/vibe-spec:spec-refine

Model invocable

No pre-commands

Context Preview

The summary Claude sees in its command listing — used to decide when to auto-load this command

You are running **Step 2 of the Vibe-Spec spec-driven workflow**: promoting the **V0
spec → V1 spec**. The V1 spec becomes the single source of truth — it details exactly
*which tools* achieve each piece of functionality.

## What to do

1. Read the existing spec at **`docs/project-spec.md`** (the V0 draft from
   `/spec-draft`). If it doesn't exist, tell the user to run `/spec-draft` first.
2. **Critique it.** Identify gaps, ambiguities, and missing edge cases, and ask the
   user clarifying questions about them before deciding anything.
3. **Map functionality → tools** using the `vibe-spe...

Command Content

43 lines · ~664 tokens

Stats

LanguageAstro

Stars5

MaintenanceExcellent

Last CommitJun 18, 2026

Actions

View Source View Plugin View on GitHub View README

What to do

Read the existing spec at docs/project-spec.md (the V0 draft from /spec-draft). If it doesn't exist, tell the user to run /spec-draft first.
Critique it. Identify gaps, ambiguities, and missing edge cases, and ask the user clarifying questions about them before deciding anything.
Map functionality → tools using the vibe-spec skill. For each capability in the spec, load the relevant reference file(s) (under ${CLAUDE_PLUGIN_ROOT}/skills/vibe-spec/) and choose the documented approach:
- Web app foundation → reference/01-scaffolding.md
- Local DB / structured data → reference/03-docker.md, 04-database.md, 05-prisma.md
- Auth → reference/07-auth.md (decide OAuth vs OTP+JWT with the user)
- Roles / permissions → reference/08-rbac.md
- External APIs / webhooks / input → reference/09-validation.md
- Data pipelines / analytics → reference/06-dbt.md, 17-scripts.md
- Uploads → reference/12-s3.md; push / PWA → reference/13-push-notifications.md
- UI → reference/11-ui.md; testing → reference/10-testing.md
- CI/CD, hooks, deploy → reference/14-ci-cd.md, 15-pre-commit.md, 16-deployment.md
- Documentation governance (keep AGENTS.md / hub docs from silently rotting as the code moves) → reference/20-surface.md
- High-performance API → reference/02-nestjs.md (only if a measured need exists)
- Secrets / config → reference/19-secrets.md: for each capability needing a secret, name the env var holding it and mark it server-only (never NEXT_PUBLIC_). Considering this now makes the later /spec-secrets audit a confirmation rather than a discovery.
Use the skill's quick-reference table to avoid pulling in tools the project doesn't need. Prefer the simplest option that satisfies the requirement.
Rewrite docs/project-spec.md as the V1 spec: the same workflows, now with an explicit tech-stack section and per-feature tool choices (with a one-line rationale each). Note anything deliberately skipped and why.

This is a good step to run in planning mode. End by telling the user to run /spec-phases next.