From pm-delivery
Creates structured technical specification documents with problem statements, goals, architecture diagrams, data models, API designs, alternatives, security, and performance analysis. Use for complex features spanning multiple systems.
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-deliveryThis skill uses the workspace's default tool permissions.
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
Creates detailed technical specifications for software projects covering requirements, architecture, APIs, and testing strategies. Use for feature planning, system design docs, or ADRs.
Creates detailed technical specifications, requirements documents, design documents, and system architecture specs. Use for feature specs, PRDs, ADRs, RFCs, API designs, and database schemas.
Creates technical specifications interactively by gathering requirements, exploring codebases, running planning interviews, drafting with Mermaid diagrams, expert review, and iteration. For new features or projects needing architecture and decisions.
Share bugs, ideas, or general feedback.
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
Write a tech spec when:
Skip the spec for trivial bug fixes or 1-2 hour changes.
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]
[2–3 sentences. What problem are we solving and why now? No solution language here.]
Goals (in scope):
Non-Goals (explicitly out of scope):
[Any prior art, related systems, or context engineers need to understand the decision space. Link to previous specs, ADRs, or research.]
High-Level Approach: [2–4 sentences describing the chosen solution. Why this approach vs alternatives?]
System Architecture Diagram: [Describe or embed: which services are involved, how data flows, what APIs are called]
Data Model Changes:
-- New tables or schema changes
[Include DDL or schema definition]
API Design:
[Endpoint] [Method]
Request: { [fields and types] }
Response: { [fields and types] }
Error codes: [list]
Key Implementation Details:
| Option | Pros | Cons | Why Rejected |
|---|---|---|---|
| [Alt 1] | [Benefits] | [Drawbacks] | [Reason not chosen] |
| [Alt 2] | [Benefits] | [Drawbacks] | [Reason not chosen] |
| Question | Owner | Due Date | Resolution |
|---|---|---|---|
| [Unresolved question] | [Name] | [Date] | [Pending] |
| Phase | Work | Estimated Effort |
|---|---|---|
| [Phase 1] | [What gets built] | [X days/points] |
| [Phase 2] | [What gets built] | [X days/points] |
| Total | [X story points] |