
speccer
by schpet
teaching claude new tricks via skills
SKILL.md
name: speccer description: "Distill rough ideas into structured project specs with issues. This skill takes unstructured input (bullet points, rough notes, transcribed ideas) and systematically breaks it down into feature domains, uses sub-agents to deeply analyze each domain, identifies ambiguities requiring user clarification, and ultimately produces a structured spec with actionable issues. Use this skill when the user wants to transform rough project ideas into well-defined specifications and issues, or when they invoke /speccer." user-invocable: true
Speccer
Transform rough ideas into structured project specifications with actionable issues.
Overview
This skill orchestrates a multi-phase process to distill unstructured input into:
- A top-level project overview document
- Feature/domain section documents
- A consolidated list of questions for the user
- Actionable issues with acceptance criteria
All spec documents live in docs/specs/ within the project.
Document Structure
docs/specs/
├── index.md # Top-level overview, links to all sections
├── _questions.md # Consolidated questions awaiting user answers
├── _issues.md # Generated issues with acceptance criteria
└── {feature}.md # One file per feature/domain area
Workflow
Phase 1: Decomposition
When invoked with rough input:
- Read the input and identify distinct feature/domain areas
- Create
docs/specs/directory if it doesn't exist - Create initial
docs/specs/index.mdwith:- Project name/title (ask user if unclear)
- High-level summary of what the project does
- List of identified feature areas (as links to section files)
- Status: "Decomposition complete, analysis in progress"
Output a brief summary of identified features before proceeding.
Phase 2: Deep Analysis (Sub-Agents)
For each identified feature/domain area, spawn a sub-agent using the Task tool:
Use Task tool with subagent_type="general-purpose" for each feature:
Prompt template:
"Analyze the following feature area for a project spec. Your task is to:
1. Read the rough input related to this feature
2. Identify what's well-defined vs ambiguous
3. Consider implementation concerns (but don't design solutions)
4. List questions that need user clarification
5. Draft acceptance criteria for potential issues
Feature: {feature_name}
Context: {relevant_input_excerpt}
Project overview: {brief_project_context}
Output a structured analysis with:
- Summary (2-3 sentences)
- Key requirements (bullet points)
- Ambiguities/Questions (numbered list with context for why it matters)
- Suggested issues (title + draft acceptance criteria)
Write your analysis to: docs/specs/{feature_slug}.md"
Run sub-agents in parallel where possible (multiple Task tool calls in one message).
Phase 3: Consolidation
After all sub-agents complete:
- Read all generated section files in
docs/specs/ - Extract all questions/ambiguities from each section
- Create
docs/specs/_questions.mdwith:- Questions grouped by feature area
- Each question includes context for why it matters
- Numbered for easy reference
- Update
docs/specs/index.md:- Add links to all section files
- Update status: "Analysis complete, awaiting clarification"
Phase 4: User Clarification
Present questions to the user using AskUserQuestion tool:
- Group related questions where possible
- Provide context for each question
- Offer reasonable default options when applicable
- Mark questions as answered in
_questions.mdas responses come in
For complex clarifications, ask in batches of 3-4 questions max per interaction.
Phase 5: Refinement
After receiving user answers:
- Update relevant section files with clarifications
- Mark answered questions in
_questions.mdas resolved - If new questions arise from answers, add them and repeat Phase 4
- Update
index.mdstatus when all questions resolved
Phase 6: Issue Generation
When all clarifications are complete:
-
Read all section files
-
Compile issues from each section's "Suggested issues"
-
Create
docs/specs/_issues.mdwith:- Issues grouped by feature area
- Each issue has: title, description, acceptance criteria
- Issues are ordered by suggested implementation sequence
-
If user wants beads integration, for each issue:
Use beads:create skill to create the issue with: - Title from spec - Description including acceptance criteria - Labels for feature area -
Update
index.md:- Status: "Specification complete"
- Link to
_issues.md - Summary of total issues generated
Invocation
The skill can be invoked:
/speccer- Start fresh with new input/speccer refine- Continue refining existing spec (re-run Phase 4-6)/speccer issues- Skip to issue generation from existing spec/speccer issues --beads- Generate issues and create beads
Maintaining Context
The index.md file serves as the authoritative reference. When resuming work:
- Always read
docs/specs/index.mdfirst - Check status to determine which phase to continue
- Read
_questions.mdto see pending clarifications - Sub-agents should be given relevant section context
Example Index Structure
# Project: [Name]
## Overview
[2-3 sentence summary]
## Status
[Current phase and progress]
## Features
- [Feature A](./feature-a.md) - Brief description
- [Feature B](./feature-b.md) - Brief description
- [Feature C](./feature-c.md) - Brief description
## Documents
- [Open Questions](./_questions.md) - X questions pending
- [Issues](./_issues.md) - Y issues defined
## Notes
[Any project-wide context or constraints]
Tips
- Prefer more granular features over fewer large ones
- Questions should be concrete and actionable, not abstract
- Acceptance criteria should be testable/verifiable
- Keep section files focused; split if they grow beyond ~500 lines
- When uncertain about scope, err toward asking the user
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon