How to use SpecKit for structured feature development in Tome
SpecKit is a structured workflow for feature development that:
- Creates consistent feature specifications
- Validates against project constitution
- Generates implementation plans
- Breaks work into actionable tasks
- Maintains documentation automatically
Benefits:
- Consistent feature documentation
- Constitution compliance checks
- Clear implementation roadmap
- Reduced scope creep
- Better collaboration
Feature Idea
↓
/speckit.specify → Creates specification
↓
/speckit.plan → Generates implementation plan (with constitution checks)
↓
/speckit.tasks → Breaks down into tasks
↓
/speckit.implement → Executes implementation (or manual implementation)
↓
Feature Complete ✅
Command: /speckit.specify [feature description]
Input: Natural language description of the feature
Output: Creates specs/###-feature-name/spec.md
Example:
/speckit.specify Add ability to filter library by publication year
Generated spec includes:
- User Stories (prioritized P1, P2, P3...)
- Functional Requirements
- Success Criteria
- Edge Cases
What to review:
- Are user stories independently testable?
- Are requirements clear and measurable?
- Are success criteria achievable?
Command: /speckit.plan
Input: Reads spec.md from current feature
Output: Creates plan.md with:
- Technical context (tech stack, dependencies)
- Constitution Check (validates against
.specify/memory/constitution.md) - Project structure
- Complexity tracking
Example Constitution Check:
## Constitution Check
- [ ] Data Integrity First: Uses repositories? Follows Database Factory Pattern?
- [ ] Layered Architecture: Routes → Services → Repositories?
- [ ] Self-Contained: No external dependencies?
- [ ] UX Standards: Smart defaults? Temporal validation?
- [ ] Observability: Pino logging? Real database tests?What to review:
- Are all constitution checks passing?
- Is the technical approach sound?
- Any violations justified?
Command: /speckit.tasks
Input: Reads spec.md and plan.md
Output: Creates tasks.md with:
- Phase 1: Setup
- Phase 2: Foundational (blocking prerequisites)
- Phase 3+: User Stories (independently implementable)
- Dependency tracking
- Parallel execution opportunities
Example:
## Phase 2: Foundational
- [ ] T001 Create PublicationYearFilter repository method
- [ ] T002 Add year filter to BookRepository.findWithFilters
## Phase 3: User Story 1 - Filter by Year (P1)
- [ ] T003 [P] [US1] Add year filter UI component
- [ ] T004 [P] [US1] Wire filter to API query params
- [ ] T005 [US1] Test filtering with real databaseTask Markers:
[P]= Can run in parallel[US1]= Belongs to User Story 1
Option A: Manual Implementation
- Work through tasks in dependency order
- Mark todos as you go
- Test each user story independently
- Run
bun testbefore marking complete
Option B: Automated Implementation
/speckit.implement- Executes tasks automatically- Reviews each task before proceeding
- Runs tests after each phase
- Creates commits
Purpose: Identify underspecified areas in spec
When to use:
- Spec feels ambiguous
- Edge cases unclear
- Requirements vague
Output: Asks up to 5 targeted clarification questions and updates spec
Purpose: Generate custom checklist for feature
When to use:
- Need QA checklist
- Need deployment checklist
- Need review checklist
Output: Creates custom checklist in specs/###-feature-name/checklist.md
Purpose: Cross-artifact consistency analysis
When to use:
- After task generation
- Before implementation
- After major spec changes
Output: Reports on:
- Spec ↔ Plan consistency
- Plan ↔ Tasks alignment
- Constitution compliance gaps
- Missing requirements
Before creating spec:
- Read
.specify/memory/constitution.md - Understand the 7 guiding principles
- Know what's in scope and out of scope (Non-Negotiables + Scope Boundaries)
Each user story should:
- Be implementable alone
- Be testable alone
- Deliver value alone
- Not block other stories
Bad:
US1: Add filter infrastructure (no value alone)
US2: Add year filter (depends on US1)
Good:
US1 (P1): Add year filter (complete feature)
US2 (P2): Add author filter (complete feature)
Don't skip constitution checks!
If a check fails:
- Rethink the approach, OR
- Document the violation with justification
Example violation with justification:
❌ Self-Contained: Requires Redis for caching
**Justification:**
Current SQLite approach cannot handle 100k+ concurrent users (performance requirement SC-002).
Redis chosen because:
- Self-hosted (Docker Compose)
- Minimal config overhead
- Industry standard for caching
**Mitigation:**
- Include Redis in docker-compose.yml
- Document setup in README.md
- Ensure fallback to no-cache mode
After implementing a user story:
- Run tests:
bun test - Manual test the user journey
- Verify constitution compliance
- Demo if possible
Before moving to next story:
- Ensure current story works independently
- No breaking changes to previous stories
- Tests pass
After running SpecKit for a feature:
specs/001-feature-name/
├── spec.md # Feature specification
├── plan.md # Implementation plan
├── tasks.md # Task breakdown
├── research.md # Optional: Research notes
├── data-model.md # Optional: Data models
├── contracts/ # Optional: API contracts
└── checklist.md # Optional: Custom checklist
SpecKit automatically validates against:
Constitution (.specify/memory/constitution.md):
- Protect User Data Above All
- Respect Calibre as Source of Truth
- Preserve Complete History
- Minimize External Dependencies
- Make Complexity Invisible
- Design for Longevity
- Trust but Verify
Patterns (.specify/memory/patterns.md):
- References patterns by name
- Validates pattern usage
- Suggests appropriate patterns
Architecture (docs/ARCHITECTURE.md):
- Validates layer structure
- Checks file organization
- Ensures tech stack consistency
Feature: Add publication year filter to library
/speckit.specify Add ability to filter library by publication year with range support (e.g., 2020-2023)
Output:
- Creates
specs/001-year-filter/spec.md - Generates 2 user stories (exact filter, range filter)
- Defines success criteria (filter works, persists in URL)
/speckit.plan
Output:
- Creates
plan.md - Constitution check passes (uses repositories, no external deps)
- Identifies needed: Repository method, API route update, UI component
/speckit.tasks
Output:
- Creates
tasks.md - Phase 1: Setup (project structure)
- Phase 2: Foundational (repository method)
- Phase 3: US1 - Exact year filter (P1)
- Phase 4: US2 - Year range filter (P2)
Work through tasks:
- T001-T003: Add repository method
- T004-T007: Implement US1 (exact filter)
- Test US1 independently ✅
- T008-T010: Implement US2 (range filter)
- Test US2 independently ✅
- All tests pass ✅
- Feature complete
- Both user stories work
- Tests passing
- Documentation updated
Skip SpecKit for:
- Bug fixes (just fix it)
- Trivial changes (1-2 line changes)
- Documentation updates
- Dependency updates
- Refactoring without new features
Use SpecKit for:
- New features
- Major refactorings
- Architecture changes
- Multi-step enhancements
- Anything requiring planning
Problem: Plan shows constitution violations
Solution:
- Re-read constitution (
.specify/memory/constitution.md) - Adjust approach to comply, OR
- Document violation with justification
Problem: Generated tasks not actionable
Solution:
- Run
/speckit.clarifyto improve spec - Add more detail to spec.md manually
- Re-run
/speckit.tasks
Problem: Can't implement US2 without US1
Solution:
- Rethink user story breakdown
- Each story should deliver standalone value
- Move shared code to "Foundational" phase
| Command | Purpose | Input | Output |
|---|---|---|---|
/speckit.specify |
Create spec | Feature description | spec.md |
/speckit.plan |
Generate plan | spec.md |
plan.md |
/speckit.tasks |
Break into tasks | spec.md + plan.md |
tasks.md |
/speckit.clarify |
Improve spec | spec.md |
Updated spec.md |
/speckit.checklist |
Custom checklist | spec.md |
checklist.md |
/speckit.analyze |
Consistency check | All artifacts | Analysis report |
/speckit.implement |
Auto-implement | tasks.md |
Code changes |
For more details:
- Constitution:
.specify/memory/constitution.md - Patterns:
.specify/memory/patterns.md - Architecture:
docs/ARCHITECTURE.md - Universal AI Guide:
AI_INSTRUCTIONS.md
Last Updated: 2025-11-24