GitHub Spec-Kit integration for constitution-based spec-driven development. 7-phase workflow. Triggers: "spec-kit", "speckit", "constitution", "specify", ".specify/", "规格驱动开发", "需求规格".
/plugin marketplace add tianzecn/myclaudecode/plugin install tianzecn-feiskyer-plugins-feiskyer@tianzecn/myclaudecodeThis skill is limited to using the following tools:
Official GitHub Spec-Kit integration providing a 7-phase constitution-driven workflow for feature development.
This skill works with the GitHub Spec-Kit CLI to guide you through structured feature development:
Storage: Creates files in .specify/specs/NNN-feature-name/ directory with numbered features
First, verify if spec-kit CLI is installed:
command -v specify || echo "Not installed"
If not installed:
# Persistent installation (recommended)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# One-time usage
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
Requirements:
If CLI is installed but project not initialized:
# Initialize in current directory
specify init . --ai claude
# Initialize new project
specify init <project-name> --ai claude
# Options:
# --force: Overwrite non-empty directories
# --script ps: Generate PowerShell scripts (Windows)
# --no-git: Skip Git initialization
Before proceeding, always detect the current state:
if command -v specify &> /dev/null || [ -x "$HOME/.local/bin/specify" ]; then
echo "CLI installed"
else
echo "CLI not installed - guide user through installation"
fi
if [ -d ".specify" ] && [ -f ".specify/memory/constitution.md" ]; then
echo "Project initialized"
else
echo "Project not initialized - guide user through 'specify init'"
fi
# Get latest feature directory
LATEST=$(ls -d .specify/specs/[0-9]* 2>/dev/null | sort -V | tail -1)
echo "Latest feature: $LATEST"
Detect phase by checking file existence in latest feature:
FEATURE_DIR=".specify/specs/001-feature-name"
if [ ! -f ".specify/memory/constitution.md" ]; then
echo "Phase: constitution"
elif [ ! -d "$FEATURE_DIR" ]; then
echo "Phase: specify"
elif [ -f "$FEATURE_DIR/spec.md" ] && ! grep -q "## Clarifications" "$FEATURE_DIR/spec.md"; then
echo "Phase: clarify"
elif [ ! -f "$FEATURE_DIR/plan.md" ]; then
echo "Phase: plan"
elif [ ! -f "$FEATURE_DIR/tasks.md" ]; then
echo "Phase: tasks"
elif [ -f "$FEATURE_DIR/tasks.md" ] && grep -q "\\- \\[ \\]" "$FEATURE_DIR/tasks.md"; then
echo "Phase: implement"
else
echo "Phase: complete"
fi
Establish foundational principles that govern all development decisions.
Create .specify/memory/constitution.md with:
Gather Context
Draft Constitution
Structure
# Project Constitution
## Core Values
1. **[Value Name]**: [Description and implications]
2. **[Value Name]**: [Description and implications]
## Technical Principles
### Architecture
- [Principle with rationale]
### Code Quality
- [Standards and expectations]
### Performance
- [Performance criteria]
## Decision Framework
When making technical decisions, consider:
1. [Criterion with priority]
2. [Criterion with priority]
# Project Constitution
## Core Values
1. **Simplicity Over Cleverness**: Favor straightforward solutions that are easy to understand and maintain over clever optimizations.
2. **User Experience First**: Every technical decision should improve or maintain user experience.
## Technical Principles
### Architecture
- Prefer composition over inheritance
- Keep components loosely coupled
- Design for testability
### Code Quality
- Code reviews required for all changes
- Unit test coverage > 80%
- Documentation for public APIs
### Performance
- Page load < 3 seconds
- API response < 200ms
- Progressive enhancement for slower connections
## Decision Framework
When choosing between approaches:
1. Does it align with our core values?
2. Is it maintainable by the team?
3. Does it scale with our growth?
4. What's the long-term cost?
Define what needs building and why, avoiding technology specifics.
# Create new feature
.specify/scripts/bash/create-new-feature.sh --json "feature-name"
# Expected JSON output:
# {"BRANCH_NAME": "001-feature-name", "SPEC_FILE": "/path/to/.specify/specs/001-feature-name/spec.md"}
Parse JSON: Extract BRANCH_NAME and SPEC_FILE for subsequent operations.
Load .specify/templates/spec-template.md to understand required sections, then create specification at SPEC_FILE location.
Focus on functional requirements:
# Feature Specification: [Feature Name]
## Problem Statement
[What problem are we solving?]
## User Stories
### Story 1: [Title]
As a [role]
I want [capability]
So that [benefit]
**Acceptance Criteria:**
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
### Story 2: [Title]
[Continue...]
## Non-Functional Requirements
- Performance: [Specific metrics]
- Security: [Requirements]
- Accessibility: [Standards]
- Scalability: [Expectations]
## Success Metrics
- [Measurable outcome]
- [Measurable outcome]
## Out of Scope
[Explicitly state what's NOT included]
The script automatically:
001-feature-name)Resolve underspecified areas through targeted questioning.
Before planning implementation, ensure specification is complete and unambiguous.
Analyze Specification
Generate Questions (Maximum 5)
Question Format
## Clarifications
### Q1: [Clear, specific question]
**Context**: [Why this matters]
**Options**: [If multiple approaches exist]
### Q2: [Clear, specific question]
**Context**: [Why this matters]
**Impact**: [What decisions depend on this]
## Clarifications
### Q1: How should the system handle conflicts when two users edit the same document simultaneously?
**Context**: This affects data model design and user experience.
**Options**:
- Last-write-wins (simple, may lose data)
- Operational transforms (complex, preserves all edits)
- Locked editing (simple, limits collaboration)
**Answer**: [User provides answer]
### Q2: What's the maximum number of concurrent users we need to support?
**Context**: Affects infrastructure planning and architecture decisions.
**Impact**: Determines caching strategy, database choices, and scaling approach.
**Answer**: [User provides answer]
Create technical implementation strategy based on clarified specification.
# Setup plan phase
.specify/scripts/bash/setup-plan.sh --json
# Expected JSON output:
# {"FEATURE_SPEC": "/path/spec.md", "IMPL_PLAN": "/path/plan.md", "SPECS_DIR": "/path/specs", "BRANCH": "001-feature"}
plan.md)# Implementation Plan: [Feature Name]
## Technology Stack
### Frontend
- Framework: [Choice with rationale]
- State Management: [Choice with rationale]
- Styling: [Choice with rationale]
### Backend
- Language/Framework: [Choice with rationale]
- Database: [Choice with rationale]
- API Style: [REST/GraphQL/etc with rationale]
## Architecture
### System Overview
```mermaid
graph TD
A[Client] --> B[API Gateway]
B --> C[Service Layer]
C --> D[Data Layer]
[Continue for all components...]
#### 2. Data Model (`data-model.md`)
```markdown
# Data Model
## Entity Relationship
```mermaid
erDiagram
USER ||--o{ DOCUMENT : creates
USER {
string id
string email
string role
}
DOCUMENT {
string id
string title
string content
}
interface User {
id: string;
email: string;
role: 'admin' | 'editor' | 'viewer';
createdAt: Date;
}
[Continue for all entities...]
#### 3. API Contracts (`contracts/`)
Create API specifications:
- `api-spec.json` (OpenAPI/Swagger)
- `signalr-spec.md` (if using SignalR)
- Other contract definitions
#### 4. Research (`research.md`) - Optional
Document technology investigations:
```markdown
# Research: [Topic]
## Options Evaluated
### Option 1: [Technology]
**Pros**: [Benefits]
**Cons**: [Drawbacks]
**Fit**: [How well it matches our needs]
### Option 2: [Technology]
[Same structure...]
## Recommendation
[Chosen option with rationale]
## References
- [Source 1]
- [Source 2]
quickstart.md) - OptionalSetup instructions for developers.
Before finalizing:
Generate dependency-ordered, actionable implementation tasks.
# Check prerequisites
.specify/scripts/bash/check-prerequisites.sh --json [--require-tasks] [--include-tasks]
# Output: {"FEATURE_DIR": "/path", "AVAILABLE_DOCS": ["spec.md", "plan.md", ...]}
Create .specify/specs/NNN-feature/tasks.md:
# Implementation Tasks: [Feature Name]
## Phase 1: Foundation
- [ ] 1.1 Set up project structure
- Create directory layout per architecture doc
- Configure build tools
- Initialize testing framework
- **Depends on**: None
- **Requirement**: R1.1
- [ ] 1.2 [P] Configure development environment
- Set up linters and formatters
- Configure CI/CD pipeline basics
- **Depends on**: 1.1
- **Requirement**: R1.2
## Phase 2: Core Implementation
- [ ] 2.1 Implement User model and persistence
- Create User entity with validation
- Implement repository pattern
- Write unit tests
- **Depends on**: 1.1
- **Requirement**: R2.1, R2.3
- [ ] 2.2 [P] Implement Document model
- Create Document entity
- Define relationships with User
- Write unit tests
- **Depends on**: 1.1
- **Requirement**: R2.2
- [ ] 2.3 Implement API endpoints
- Create REST controllers
- Add request/response validation
- Write integration tests
- **Depends on**: 2.1, 2.2
- **Requirement**: R3.1, R3.2
[Continue with all phases...]
## Phase N: Integration & Testing
- [ ] N.1 End-to-end testing
- Write E2E test scenarios
- Test critical user paths
- **Depends on**: [all previous]
- **Requirement**: All
## Notes
- `[P]` indicates tasks that can be parallelized
- Always check dependencies before starting
- Reference requirements for acceptance criteria
Each task should:
Task Types:
Exclude:
Cross-artifact consistency and quality validation (read-only).
Before implementation, verify:
Read All Documents
Coverage Check
# Extract requirements
grep -E "R[0-9]+\.[0-9]+" spec.md | sort -u > requirements.txt
# Extract referenced requirements in tasks
grep -E "Requirement.*R[0-9]+" tasks.md | sort -u > covered.txt
# Compare
comm -23 requirements.txt covered.txt
Constitution Alignment:
Requirement Coverage:
Technical Coherence:
Task Dependencies:
# Analysis Report
## ✅ Passing Checks
- All requirements covered
- Constitution alignment verified
- No circular dependencies
## ⚠️ Warnings
- Requirement R3.4 has no corresponding task
- Task 5.2 references undefined dependency
## 🔴 Critical Issues
None found
## Recommendations
1. Add task for Requirement R3.4
2. Clarify dependency for task 5.2
3. Consider breaking task 6.1 into smaller tasks (estimated 8 hours)
Execute tasks systematically, respecting dependencies and test-driven development.
Phase-by-Phase Execution
Task Execution Pattern
# For each task:
# 1. Read context
cat .specify/specs/001-feature/spec.md
cat .specify/specs/001-feature/plan.md
cat .specify/specs/001-feature/data-model.md
# 2. Check dependencies
# Verify all depends-on tasks are complete
# 3. Implement
# Write code per task description
# 4. Test
# Write and run tests
# 5. Validate
# Check against requirements
# 6. Mark complete
# Update tasks.md: - [x] task completed
For each task:
Before marking task complete:
If implementation reveals issues:
Update tasks.md as you go:
- [x] 1.1 Set up project structure ✓ Complete
- [x] 1.2 [P] Configure development environment ✓ Complete
- [ ] 2.1 Implement User model ← Currently here
- [ ] 2.2 [P] Implement Document model
Feature is complete when:
.specify/
├── memory/
│ └── constitution.md # Phase 1
├── specs/
│ └── 001-feature-name/ # Numbered features
│ ├── spec.md # Phase 2
│ ├── plan.md # Phase 4
│ ├── data-model.md # Phase 4
│ ├── contracts/ # Phase 4
│ │ ├── api-spec.json
│ │ └── signalr-spec.md
│ ├── research.md # Phase 4 (optional)
│ ├── quickstart.md # Phase 4 (optional)
│ └── tasks.md # Phase 5
├── scripts/
│ └── bash/
│ ├── check-prerequisites.sh
│ ├── create-new-feature.sh
│ ├── setup-plan.sh
│ └── common.sh
└── templates/
├── spec-template.md
├── plan-template.md
└── tasks-template.md
Spec-Kit provides a rigorous, constitution-based approach to feature development with clear phases, explicit dependencies, and comprehensive documentation at every step. The workflow ensures alignment from principles through implementation.
For advanced detection logic and automation scripts, see:
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.