From devops-data
Writes technical specifications for post-decision implementation details including API contracts, database schemas, system architecture, and developer guides.
How this skill is triggered — by the user, by Claude, or both
Slash command
/devops-data:technical-specificationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill automatically activates when documenting implementation details for a solution. Unlike RFC (which evaluates options), Tech Specs document **how** to build something when the approach is already decided.
This skill automatically activates when documenting implementation details for a solution. Unlike RFC (which evaluates options), Tech Specs document how to build something when the approach is already decided.
| Aspect | RFC | Tech Spec |
|---|---|---|
| Purpose | Evaluate options, make decision | Document implementation details |
| Options Analysis | Required (min 2) | Not applicable |
| When Used | Before decision | After decision (or when no decision needed) |
| Audience | Decision makers, stakeholders | Implementers, developers |
| Lifecycle | DRAFT → REVIEW → APPROVED → COMPLETED | DRAFT → APPROVED → REFERENCE |
Use Tech Spec when:
Use RFC instead when:
Header Metadata
---
tech_spec_id: TS-XXXX
title: [Component/Feature Name]
status: DRAFT | APPROVED | REFERENCE | ARCHIVED
decision_ref: RFC-XXXX # Optional - link to RFC if one exists
author: [Name]
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
---
Executive Summary (1 paragraph)
Design Overview
Detailed Specifications For each component:
Data Model / Schema
API Specification
Security Implementation
Performance Considerations
Testing Strategy
Deployment & Operations
Dependencies
Implementation Checklist
DRAFT → APPROVED → REFERENCE
↓
ARCHIVED (when superseded or deprecated)
| Status | Description |
|---|---|
| DRAFT | Being written, not yet reviewed |
| APPROVED | Ready for implementation |
| REFERENCE | Implementation complete, serves as documentation |
| ARCHIVED | Superseded or no longer relevant |
Tech Specs can optionally link to an RFC:
decision_ref: RFC-0042 # Links to the decision that led to this spec
When to link:
When standalone is fine:
Before marking APPROVED:
Be Specific
Include Examples
Document Constraints
Reference Don't Duplicate
TS-XXXX-<short-description>.md
Examples:
TS-0001-user-authentication-api.mdTS-0015-payment-integration.mdTS-0042-cache-layer-design.mdtech-specs/
├── draft/ # Work in progress
├── approved/ # Ready for implementation
├── reference/ # Implementation complete
└── archive/ # Superseded/deprecated
└── YYYY/
The CTO Architect uses this skill for:
Post-RFC Implementation Planning
Standalone Specifications
Delegation to Specialists
| Command | Description |
|---|---|
/create-tech-spec <name> | Create new Tech Spec from template |
/list-tech-specs | List all Tech Specs with status |
/tech-spec-status <id> | View or update Tech Spec status |
./references/tech-spec-template.md./references/tech-spec-checklist.mdnpx claudepluginhub jpoutrin/product-forge --plugin devops-dataCreates structured technical specification documents bridging product requirements and engineering implementation. Covers problem framing, data model, API design, alternatives, security, testing, and rollout.
Creates detailed technical specifications for software projects covering requirements, architecture, APIs, and testing strategies. Use for feature planning, system design docs, or ADRs.
Defines clear, testable technical specifications from requirements, including target architecture, API contracts, data models, error handling, testing strategies, and security considerations.