Create detailed technical specifications, requirements documents, design documents, and system architecture specs. Use when writing technical specs, requirements docs, or design documents.
Install
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill technical-specificationSKILL.md
Technical Specification
Table of Contents
Overview
Create comprehensive technical specifications that define system requirements, architecture, implementation details, and acceptance criteria for software projects.
When to Use
- Feature specifications
- System design documents
- Requirements documentation (PRD)
- Architecture decision records (ADR)
- Technical proposals
- RFC (Request for Comments)
- API design specs
- Database schema designs
Quick Start
Minimal working example:
# Technical Specification: [Feature Name]
**Document Status:** Draft | Review | Approved | Implemented
**Version:** 1.0
**Author:** John Doe
**Date:** 2025-01-15
**Reviewers:** Jane Smith, Bob Johnson
**Last Updated:** 2025-01-15
## Executive Summary
Brief 2-3 sentence overview of what this spec covers and why it's being built.
**Problem:** What problem are we solving?
**Solution:** High-level description of the solution
**Impact:** Expected business/user impact
---
## 1. Background
### Context
Provide background on why this feature is needed:
// ... (see reference guides for full implementation)
Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| Functional Requirements | Functional Requirements |
| Non-Functional Requirements | Non-Functional Requirements |
| Database Schema | Database Schema |
| API Data Models | API Data Models |
| Authentication Endpoints | Authentication Endpoints |
| Rate Limiting | Rate Limiting |
| Phase 1: Core Authentication | Phase 1: Core Authentication (Week 1-2), Phase 2: Email Verification (Week 3), Phase 3: Social Login (Week 4), Phase 4: Security Features (Week 5) (+1 more) |
Best Practices
✅ DO
- Include acceptance criteria for each requirement
- Provide architecture diagrams
- Document API contracts
- Specify performance requirements
- List risks and mitigations
- Include implementation timeline
- Add success metrics
- Document security considerations
- Version your specs
- Get stakeholder review
❌ DON'T
- Be vague about requirements
- Skip non-functional requirements
- Forget about security
- Ignore alternatives
- Skip testing strategy
- Forget monitoring/observability
- Leave questions unanswered
Related skills
domain-modelingmattpocock714KBuild and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.to-specmattpocock576KTurn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.caveman-helpjuliusbrussee369KQuick-reference card for caveman modes, skills and commands. Trigger: /caveman-help or "caveman help".pptxanthropics228KUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates (.potx), layouts, speaker notes, or comments. Trigger whenever the u