product-tech-spec
/product-tech-spec — Technical Specification
Write technical specs that bridge product requirements and implementation plans. Covers architecture, APIs, data models, and component hierarchy.
When to Use
- User says "tech spec", "technical spec", "architecture doc"
- After writing a PRD and before planning implementation
- When architecture decisions need to be documented
Process
Step 1: Gather Context
Check for existing artifacts:
docs/prds/— Read the PRD this spec implementsdocs/brainstorms/— Additional context if available- User-provided description or
$ARGUMENTS
More from elliottrjacobs/bench-skills
product-prd
Write product requirements documents from feature ideas or brainstorm output. Use when the user says "write a PRD", "product requirements", "feature spec", or needs to formalize a product concept into a structured document.
17product-naming
Expert naming process for products, companies, and features based on David Placek's methodology. Use when the user says "name this", "brainstorm names", "naming process", or needs to find a name for a product, feature, company, or project.
10knowledge-compound
Document solutions, decisions, and learnings into a searchable knowledge base. Use when the user says "document this", "compound this", "save this solution", "capture this", or after completing significant work that uncovered reusable knowledge.
8security-audit
Deep security audit of codebase with parallel domain-focused agents. Use when the user says "security audit", "check for vulnerabilities", "security review", or before a launch/deployment. More thorough than the security reviewer in /engineer-review.
8engineer-review
Comprehensive multi-agent code review with parallel specialist reviewers. Use when the user says "review this", "code review", "review my PR", provides a PR number or branch, or after completing a /engineer-work cycle.
8product-brainstorm
Guided requirements exploration through structured dialogue. Use when the user says "brainstorm", "explore this idea", "help me think through", or when requirements are fuzzy and need clarification before writing specs.
8