From spec-plugin
Build a comprehensive project specification through conversational refinement. Adapts to any project type — code, business, research, consulting. Reads workspace context to understand where it is and what kind of project this is. Use at the very start of a new project or major initiative.
npx claudepluginhub nexaedge/nexaedge-marketplace --plugin spec-pluginThis skill uses the workspace's default tool permissions.
Your task: produce a comprehensive project specification through iterative conversation with the user. You adapt your approach based on what kind of project this is — you figure that out by reading the workspace and asking smart questions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.
Your task: produce a comprehensive project specification through iterative conversation with the user. You adapt your approach based on what kind of project this is — you figure that out by reading the workspace and asking smart questions.
Before asking the user anything, read the environment:
specs/ directory already exist? Are there prior specs?clients/acme/ inside a larger workspace)specs/, check CLAUDE.md (project and user level) for references to a second-brain, specs repository, or external project management directory. Search that location for a folder matching the current project (by name, git remote, or project name). If found, this is where specs should be read from and written to.From this, form an initial understanding:
specs/, an external specs repo like a second-brain, or somewhere informed by the workspace structure)Do NOT assume the project type yet — let Phase 2 confirm it.
Start by asking the user what they want to build. Use AskUserQuestion and adapt based on the workspace context you discovered.
Round 1 — What and Why:
If you recognized workspace structure (e.g., a workspace organized by client or project type), ask a smart follow-up:
Round 2 — Shape and Scope:
Adapt these questions based on what you're learning about the project:
If it's becoming a code/product project:
If it's becoming a business/consulting project:
If it's becoming a research/exploration project:
If you're not sure yet:
Round 3 — Constraints and Context:
Adapt questions based on answers — skip what's already clear, dig deeper where it's vague. Don't front-load questions that aren't relevant yet.
Based on what you've learned, decide where the spec goes:
specs/<project-name>.md at the repo rootspecs/ directoryclients/acme/billing-project/specs/spec.md)specs/<project-name>.md — this directory IS the projectIf uncertain, ask the user: "Where should I save the spec? Here's what I'm thinking: [path]. Does that work?"
Write a first draft. The structure adapts to the project type, but always includes these core elements:
Add a context block at the top of the spec so downstream skills understand the project:
## Project Context
- **Type**: code | business | research | consulting | hybrid
- **Language**: en | pt-BR | (whatever the workspace convention is)
- **Location**: where this spec lives relative to the workspace root
- **Code Repository**: absolute path to the code repo (only if specs and code live in different directories)
- **Workspace**: brief description of the workspace (e.g., "monorepo with multiple projects", "Rust CLI project", "empty directory")
- **Stakeholders**: who's involved (if applicable)
Code / Product projects — add:
Business / Consulting projects — add:
Research / Exploration projects — add:
Hybrid projects — mix sections as needed.
Present the draft to the user. Use AskUserQuestion to refine:
Iterate until the user is satisfied. Expect 2-4 refinement rounds.
Write the final document to the determined location.
Present a summary to the user:
/architect to define the implementation approach, or /plan to design the delivery milestones."