Stats
Actions
Tags
From skills
Turns requirements into structured specs before implementation. Accepts Linear URL, GitHub issue URL, Jira URL, or plain text. Prompts user approval before coding.
How this skill is triggered — by the user, by Claude, or both
Slash command
/skills:spec [linear-url, github-issue-url, or description][linear-url, github-issue-url, or description]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The point of this skill is the pause. Generating a spec and waiting for approval before implementing ensures you and the user are aligned on scope before writing a line of code. Don't skip to implementation.
The point of this skill is the pause. Generating a spec and waiting for approval before implementing ensures you and the user are aligned on scope before writing a line of code. Don't skip to implementation.
Linear URL (https://*.linear.app/*/issue/*):
mcp__plugin_linear_linear__get_issue
GitHub issue URL (https://github.com/*/issues/*):
gh issue view <number> --json title,body,labels,assignees
Jira URL (https://*.atlassian.net/browse/*):
Use WebFetch to retrieve the page content.
Plain text: treat the input as the raw requirement and proceed.
Display a brief summary (2–3 sentences) of what you fetched so the user can confirm you're working from the right source.
# Spec: [Title]
## Problem
What user pain or business need does this address? Why does it matter now?
## Solution
What are we building? Describe the approach, not the implementation details.
## Acceptance Criteria
- [ ] Specific, testable condition 1
- [ ] Specific, testable condition 2
- [ ] Edge cases and error states are handled
## Out of Scope
Explicit list of what this does NOT include. This prevents scope creep.
## Technical Notes
Dependencies, migration needs, API contracts, performance constraints.
Leave empty if there's nothing notable.
Present the spec and ask: "Does this capture what you need? Any changes before I implement?"
Only offer to implement after the user explicitly approves. If they request changes, revise and re-present before offering to implement.
Acceptance criteria should be testable by a QA engineer who wasn't in the room:
Each criterion should be falsifiable — you should be able to write a failing test before the feature exists.
| Priority | Load when | Reference |
|---|---|---|
| 1 — High | Spec involves frontend — need performance, bundle, rendering, or accessibility checklist items | references/frontend-spec-checklist.md |
npx claudepluginhub kriscard/skillsConverts vague feature ideas into written, agreed specifications through structured questioning across nine dimensions. Produces docs/specs/*.md with acceptance criteria for planning, scaffolding, and TDD tools.
Conducts focused interview to draft spec.md for upcoming tasks in SDD workflow. Covers goal, behaviors, acceptance criteria, edge cases, out-of-scope one branch at a time; writes to disk. Pauses to split multi-features.
Conducts multi-round interviews to refine rough SPEC.md into complete, implementation-ready specifications with tasks. Use for new features, requirements refinement, or ideas to actionable specs.