Project Specification Skill for Claude
Transforms project briefs into testable specifications with user stories and acceptance criteria. Use after brainstorming, before planning.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/athola/claude-night-market --skill project-specificationThe instruction itself
10 sections, as written by the authorDelegation
For detailed specification writing workflows, this skill delegates to spec-kit:spec-writing as the canonical implementation. Use this skill for quick specification needs; use spec-kit for thorough specification documents.
When To Use
- After brainstorming phase completes
- Have project brief but need detailed requirements
- Need testable acceptance criteria for implementation
- Planning validation and testing strategy
- Translating business requirements into technical specs
- Defining scope boundaries and out-of-scope items
When NOT To Use
- Still exploring problem space (use
Skill(attune:project-brainstorming)instead) - Already have detailed specification (use
Skill(attune:project-planning)instead) - Refining existing implementation (use code review skills)
- Making strategic decisions (use
Skill(attune:war-room)for complex choices)
Integration
With spec-kit:
- Delegates to
Skill(spec-kit:spec-writing)for methodology - Uses spec-kit templates and validation
- Enables clarification workflow
Without spec-kit:
- Standalone specification framework
- Requirement templates
- Acceptance criteria patterns
Record the Tradeoff (decision journal)
If the specification settled a design decision with real alternatives (a chosen
data model, an interface boundary, a constraint accepted), record it to
docs/tradeoffs.md before continuing (draft and confirm):
- If leyline is installed, invoke
Skill(leyline:decision-journal)and append
a tradeoff entry (the decision, the options weighed, and what was
sacrificed; set phase to specify). Show the draft; append on
confirmation.
- Fallback (leyline absent): append to
docs/tradeoffs.mdusing the in-file
ENTRY TEMPLATE; assign the next TR-NNN id.
Post-Completion: Workflow Continuation (REQUIRED)
Automatic Trigger: After Quality Checks pass and docs/specification.md is saved, MUST auto-invoke the next phase.
When continuation is invoked:
- Verify
docs/specification.mdexists and is non-empty - Display checkpoint message to user:
Specification complete. Saved to docs/specification.md.
Proceeding to planning phase...
- Invoke next phase:
Skill(attune:project-planning)
Bypass Conditions (ONLY skip continuation if ANY true):
--standaloneflag was provided by the userdocs/specification.mddoes not exist or is empty (phase failed)- User explicitly requests to stop after specification
Do NOT prompt the user for confirmation: this is a lightweight checkpoint, not an interactive gate. The user can always interrupt if needed.
Exit Criteria
- [ ]
docs/specification.mdexists, is non-empty, and passes Quality Checks. - [ ] Every functional requirement has testable acceptance criteria.
- [ ] Any design decision with real alternatives is recorded to
docs/tradeoffs.md (or there was no meaningful design fork).
- [ ] The next phase is auto-invoked unless a bypass condition holds.
Related Skills
Skill(spec-kit:spec-writing)- Spec-kit methodology (if available)Skill(attune:project-brainstorming)- Previous phaseSkill(attune:project-planning)- AUTO-INVOKED next phase after specificationSkill(attune:mission-orchestrator)- Full lifecycle orchestration
Related Commands
/attune:specify- Invoke this skill/attune:specify --clarify- Run clarification workflow/attune:blueprint- Next step in workflow
Examples
See /attune:specify command documentation for complete examples.
Other skills for the same job
different authors, same section of the catalogue
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Intelligently organizes your files and folders across your computer by understanding context, finding duplicates, suggesting better structures, and automating cleanup tasks. Reduces cognitive load and keeps your digital workspace tidy without manual effort.
Generates creative domain name ideas for your project and checks availability across multiple TLDs (.com, .io, .dev, .ai, etc.). Saves hours of brainstorming and manual checking.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Implements Manus-style file-based planning for complex tasks. Creates task_plan.md, findings.md, and progress.md. Use when starting complex multi-step tasks, research projects, or any task requiring >5 tool calls.
Creative research ideation and exploration. Use for open-ended brainstorming sessions, exploring interdisciplinary connections, challenging assumptions, or identifying research gaps. Best for early-stage research planning when you do not have specific observations yet. For formulating testable hypotheses from data use hypothesis-generation.
Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
How to use it
Take athola/project-specification from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.