Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
Creates detailed technical specifications for software projects covering requirements, architecture, APIs, and testing strategies. Use for feature planning, system design docs, or ADRs.
npx claudepluginhub secondsky/claude-skills --plugin technical-specificationHow this skill is triggered — by the user, by Claude, or both
Slash command
/technical-specification:technical-specificationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create comprehensive technical specifications for software projects.
Creates structured technical specification documents bridging product requirements and engineering implementation. Covers problem framing, data model, API design, alternatives, security, testing, and rollout.
Defines clear, testable technical specifications from requirements, including target architecture, API contracts, data models, error handling, testing strategies, and security considerations.
Creates technical specifications interactively by gathering requirements, exploring codebases, running planning interviews, drafting with Mermaid diagrams, expert review, and iteration. For new features or projects needing architecture and decisions.
Share bugs, ideas, or general feedback.
Create comprehensive technical specifications for software projects.
# Technical Specification: [Feature Name]
## Metadata
- **Status**: Draft | In Review | Approved
- **Author**: [Name]
- **Reviewers**: [Names]
- **Last Updated**: [Date]
## Executive Summary
[2-3 sentences: What problem does this solve? What's the proposed solution?]
## Background & Context
- Current pain points
- Why now?
- Related work
## Goals
### Primary Goals
1. [Measurable goal]
### Non-Goals
- [What this spec explicitly does NOT cover]
## Functional Requirements
| ID | Requirement | Priority |
|----|-------------|----------|
| FR-1 | [Description] | P0 |
| FR-2 | [Description] | P1 |
## Non-Functional Requirements
- **Performance**: Response time < 200ms
- **Scalability**: Support 10K concurrent users
- **Availability**: 99.9% uptime
- **Security**: [Requirements]
## Technical Design
### Architecture
[Diagram or description]
### API Design
POST /api/v1/resource Request: { "field": "value" } Response: { "id": "123", "field": "value" }
### Database Schema
```sql
CREATE TABLE resources (
id UUID PRIMARY KEY,
field VARCHAR(255)
);
| Phase | Timeline | Deliverables |
|---|---|---|
| 1 | Week 1-2 | Core functionality |
| 2 | Week 3 | API endpoints |
| 3 | Week 4 | Testing & docs |
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| [Risk] | Medium | High | [Plan] |
## Full Template
See [references/template.md](references/template.md) for a comprehensive copy-paste template including:
- Complete metadata section
- Success metrics tables
- Architecture diagrams
- Detailed API design sections
- Security threat analysis
- Monitoring & observability
- Risk assessment matrix
- Rollout and rollback plans
- Dependencies tracking
- Open questions section
## Best Practices
**Do:**
- Include measurable acceptance criteria
- Add architecture diagrams
- Define explicit API contracts
- Quantify performance targets
- Document risks and mitigations
- Get stakeholder review before implementation
- Include security considerations
- Define rollback procedures
**Don't:**
- Use vague requirements ("fast", "scalable")
- Skip non-functional requirements
- Ignore security considerations
- Leave alternatives unexplored
- Omit testing strategy
- Forget dependencies and risks