tech-spec
Tech Spec Skill
Trigger
- Keywords: tech spec, technical specification, spec review, review spec, feature design
When NOT to Use
- Creating request documents (use /create-request)
- Code implementation (use feature-dev)
- Architecture consulting (use /codex-architect)
Commands
| Command | Purpose | When |
|---|---|---|
/tech-spec |
Create or update tech spec | Auto-detects create/update from filesystem state |
/deep-analyze |
Deepen spec + roadmap | After initial concept |
/review-spec |
Review tech spec | Spec confirmation |
Context-Aware Mode (Upsert)
When invoked without a full requirement description, the skill auto-detects the target feature using the 5-level cascade from references/feature-context-resolution.md.
| Filesystem State | Action |
|---|---|
docs/features/<key>/2-tech-spec.md exists |
Update mode: read existing spec, research code changes since last update, incrementally update changed sections |
docs/features/<key>/2-tech-spec.md absent |
Create mode: generate new spec from template |
| Feature not resolved | Gate: Need Human |
In update mode, focus on sections affected by recent code changes (use git diff to identify). Preserve unchanged sections.
Workflow
sequenceDiagram
participant A as Analyst
participant C as Codebase
participant D as Document
A->>A: 1. Requirement clarification
A->>C: 2. Code research
C-->>A: Related modules
A->>A: 3. Solution design
A->>A: 4. Risk assessment
A->>A: 5. Work breakdown
A->>D: 6. Output document
Spec Structure
- Requirement summary (problem + goals + scope)
- Existing code analysis
- Technical solution (architecture + data model + API + core logic)
- Risks and dependencies
- Work breakdown
- Testing strategy
- Open questions
Output
Numbered tech spec document with sections: Overview, Requirements, Architecture, Implementation plan, Work breakdown, Testing strategy, Open questions.
Verification
- Solution covers all requirement points
- Architecture diagrams use Mermaid
- Risks have mitigation strategies
- Work can be broken into trackable items
References
references/template.md- Spec template + review dimensions
File Location
docs/features/{feature}/
├── 2-tech-spec.md # Technical spec (numbered per docs-numbering rule)
├── requests/ # Request documents
└── README.md # Feature description
Examples
Input: /tech-spec "Implement user asset snapshot feature"
Action: Requirement clarification -> Code research -> Solution design -> Output document
Input: /review-spec docs/features/xxx/2-tech-spec.md
Action: Read -> Research -> Review -> Output report + Gate
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6project-audit
Project health audit with deterministic scoring. Use when: evaluating project quality, onboarding to new codebase, periodic health checks. Not for: runtime performance analysis, security-specific audits (use /codex-security). Output: 5-dimension score + actionable findings.
6