technical-spec-template

Solid

Create structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Produces a complete spec with problem statement, proposed solution, data model, API design, alternatives considered, security considerations, testing plan, and rollout strategy.

Data & Documents 915 stars 165 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%
99
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Technical Spec Template Skill Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs. ## Required Inputs Ask the user for these if not provided: - **Feature or system description** (what needs to be specced) - **Related PRD or product brief** (if available) - **Engineering reviewers** (whose sign-off is needed) - **Known constraints** (technical limitations, security requirements, performance targets) ## When to Write a Tech Spec Write a tech spec when: - The feature requires changes to 2+ systems - There are significant architectural decisions to make - More than one engineer will work on the implementation - The feature has security, privacy, or compliance implications - Estimated effort is >5 story points Skip the spec for trivial bug fixes or 1-2 hour changes. --- ## Technical Spec Output Format ### Technical Specification — [Feature Name] **Author:** [Name] **Status:** Draft | In Review | Approved | Implemented **Created:** [Date] | **Last Updated:** [Date] **Reviewers:** [Eng Lead, Architect, PM, Security if needed] **Related PRD:** [Link] | **Jira Epic:** [Link] --- #### 1. Problem Statement > [2–3 sentences. What problem are we solving and why now? No solution language here.] #### 2. Goals & Non-Goals **Goals (in scope):** - [Specific, measurable outcome] - [Specific, measurable outcome] **Non-Goals (explicitly out of scope):** - [What this spec does ...

Details

Author
mohitagw15856
Repository
mohitagw15856/pm-claude-skills
Created
4 months ago
Last Updated
3 days ago
Language
Shell
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

technical-spec-design

Transforms product requirements into structured technical specifications. Auto-triggers when requirements are unclear, multiple implementation approaches exist, or component-level/architecture design is needed. Auto-trigger conditions: - User asks "how to implement a feature" - Requests design of technical specs / architecture / APIs / components - Mentions "multiple implementation approaches, need comparison" - Provides PRD / requirements description, wants technical specs - Requirements contain uncertainty or ambiguity NOT applicable for: - Simple bug fixes - Simple features with clear implementation path - Pure coding tasks (no design decisions)

2 Updated 2 months ago
wjszxli
Testing & QA Solid

technical-specification

Creates detailed technical specifications for software projects covering requirements, architecture, APIs, and testing strategies. Use when planning features, documenting system design, or creating architecture decision records.

160 Updated 2 weeks ago
secondsky
Code & Development Listed

technical-writing

Write clear, comprehensive technical documentation. Use when creating specs, architecture docs, runbooks, or API documentation. Handles technical specifications, system design docs, operational guides, and developer documentation with industry best practices.

335 Updated today
aiskillstore
Testing & QA Solid

spec-writing

Create clear, testable specifications from feature descriptions with user stories, acceptance criteria, and success metrics.

294 Updated today
athola
Code & Development Listed

spec

Write a feature spec — the "what & why" of a kandev product feature, before coding. Use ONLY for a product-feature surface (user-visible capability the app supports). Do NOT use for bug fixes, incident postmortems, refactors that preserve behavior, or infra-only work — those get ADRs (if a new convention emerged) and/or regression tests, not specs. Use when the user says "let's spec X" or starts a new product feature.

298 Updated today
kdlbs