New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Prd To Spec

by smallnest in smallnest/goal-workflow

Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts.

MITAuto-check passedProduct & Project Management

Install Prd To Spec

skills CLI
$ npx skills add smallnest/goal-workflow --skill prd-to-spec -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install smallnest/goal-workflow prd-to-spec --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/smallnest/goal-workflow.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/prd-to-spec .claude/skills/prd-to-spec && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
prd-to-spec
GitHub stars
290
Token cost
~3.1k tokens
SKILL.md length
813 words
Files
1
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts.

  • Works in 6 steps: Locate PRD → Analyze Context (Optional) → Clarifying Questions → …
  • Generate spec from prd
  • SKILL.md covers When to Use, The Job, Step 1: Locate PRD and Step 2: Analyze Context…, plus 9 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Prd To Spec is an agent skill from smallnest/goal-workflow. Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts. Triggers on: prd-to-spec, prd to spec, prd转spec, 需求转设计, 需求转规格, generate spec from prd, design from prd, 技术方案, 设计方案.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Product & Project Management, covering PRD writing. The repository describes itself as: AI-driven development workflow with /prd, /goal, /review-it and /ship-it skills. The licence is MIT.

When your agent uses it

  • Generate spec from prd
  • Design from prd

Example prompts

  • “/prd-to-spec”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Locate PRD
  2. Analyze Context (Optional)
  3. Clarifying Questions
  4. SPEC Document Structure
  5. Review & Iteration
  6. Save

What it can do on your machine

Read from SKILL.md and the folder at commit b06ab3c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Prd To Spec loads about 3.1k tokens when it runs. Until then it costs about 65 tokens; SKILL.md has 813 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~65
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from smallnest/goal-workflow at commit b06ab3c, republished under its MIT licence (© smallnest). 813 words, ~3,122 tokens.

Download SKILL.mdSave it as .claude/skills/prd-to-spec/SKILL.md (or your agent's skills folder).
name
prd-to-spec
description
Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts. Triggers on: prd-to-spec, prd to spec, prd转spec, 需求转设计, 需求转规格, generate spec from prd, design from prd, 技术方案, 设计方案.
user-invocable
true

prd-to-spec — PRD to Technical Specification

Transform a Product Requirements Document (PRD) into a detailed technical SPEC that an engineer or AI agent can implement against. The PRD says what to build; the SPEC says how to build it.

When to Use

  • A /prd has been generated and you need to bridge the gap to implementation
  • You want architecture decisions documented before coding starts
  • Multiple developers/agents will implement the feature and need a shared contract
  • You need to validate technical feasibility before committing to a PRD
  • You want to catch design issues early — before code is written

The Job

  1. Locate PRD — find or receive the PRD document
  2. Analyze context (optional) — if a codebase exists, scan it to understand current architecture, patterns, and constraints
  3. Ask clarifying questions — resolve technical ambiguities (max 3-5 questions)
  4. Generate SPEC — produce a structured technical specification
  5. Review — present to user for feedback and iteration
  6. Save — write final SPEC to agreed location

Step 1: Locate PRD

Find the input PRD in one of these ways:

Provide the PRD to convert:

A. File path (e.g., tasks/prd-priority-system.md)
B. GitHub Issue URL
C. Paste PRD content directly
D. Auto-detect: scan tasks/ directory for recent PRDs

If auto-detecting, list available PRDs and let the user choose:

Found PRDs in tasks/:
  1. tasks/prd-priority-system.md (2024-03-15)
  2. tasks/prd-user-auth.md (2024-03-10)

Which PRD should I convert? [1/2]

Step 2: Analyze Context (Optional)

Skip this step if no codebase exists yet (greenfield project). In that case, the SPEC will propose architecture from scratch based on the PRD requirements and clarifying questions.

If a codebase exists, scan it to understand:

  • Existing architecture — how the current system is structured
  • Tech stack — languages, frameworks, libraries already in use
  • Patterns — naming conventions, file organization, error handling approach
  • Database — current schema, migration tool, ORM
  • API style — REST/GraphQL/gRPC, authentication method, response format
  • Testing — test framework, coverage patterns, test utilities

This ensures the SPEC aligns with the existing system rather than proposing incompatible solutions.

Step 3: Clarifying Questions

Ask only when the PRD leaves technical decisions ambiguous. Focus on:

  • Architecture choices — where does this feature live? New service or extend existing?
  • Data storage — new table? Extend existing? Cache strategy?
  • API design — new endpoints? Extend existing? Breaking changes?
  • Dependencies — any new libraries needed? Version constraints?
  • Performance — expected load? Latency requirements? Batch size limits?

Format:

Technical questions before I generate the SPEC:

1. Where should the priority logic live?
   A. Extend existing TaskService
   B. New PriorityService
   C. Inline in controller
   D. Let me decide based on the codebase

2. Database migration approach?
   A. Add column to existing tasks table
   B. New priority table with FK
   C. JSON field on tasks
   D. Let me decide based on current schema

3. API versioning concern?
   A. Add to existing v1 endpoints
   B. New v2 endpoints
   C. No versioning needed

If user selects "let me decide" options, make the best choice based on codebase analysis and document the rationale in the SPEC.

Step 4: SPEC Document Structure

markdown
# SPEC: [Feature Name]

> Technical specification derived from: [PRD filename/link]
> Generated: [date] | Target branch: [branch] | Commit: [short-hash]

## 1. Summary

### 1.1 What This SPEC Covers
[One paragraph: what feature this specifies and the scope of implementation]

### 1.2 PRD Reference
- Source: [path or URL to PRD]
- User Stories covered: [US-001, US-002, ...]
- Functional Requirements covered: [FR-1, FR-2, ...]

### 1.3 Design Decisions Summary
| Decision | Choice | Rationale |
|----------|--------|-----------|
| ... | ... | ... |

---

## 2. Architecture

### 2.1 System Context
[Where this feature fits in the overall system — diagram or description]

### 2.2 Component Design
[New components/modules introduced, their responsibilities, and boundaries]

### 2.3 Module Interactions
[How new components interact with existing ones — sequence or data flow]

### 2.4 File Structure
[New files to create and existing files to modify]

src/ ├── services/ │ └── priority.service.ts [NEW] ├── controllers/ │ └── task.controller.ts [MODIFY: add priority endpoints] ├── models/ │ └── priority.model.ts [NEW] └── migrations/ └── 20240315_add_priority.ts [NEW]


---

## 3. Data Model

### 3.1 Schema Changes
[New tables, columns, indexes — with SQL or ORM notation]

### 3.2 Entity Definitions
[TypeScript interfaces / Go structs / Python dataclasses for new entities]

### 3.3 Relationships
[How new entities relate to existing ones — FK, embedded, reference]

### 3.4 Migration Plan
[Migration steps, backward compatibility, rollback strategy]

---

## 4. API Design

### 4.1 Endpoints

| Method | Path | Description | Auth | Request | Response |
|--------|------|-------------|------|---------|----------|
| ... | ... | ... | ... | ... | ... |

### 4.2 Request/Response Schemas
[Detailed shapes with field types, validation rules, and examples]

### 4.3 Error Responses
[Error codes, messages, and HTTP status codes for each failure mode]

### 4.4 Breaking Changes
[Any backward-incompatible changes and migration path for consumers]

---

## 5. Business Logic

### 5.1 Core Algorithms
[Step-by-step logic for key operations — pseudocode or structured description]

### 5.2 Validation Rules
[Input validation, business rule validation, with specific constraints]

### 5.3 State Machine
[If applicable: states, transitions, guards, and side effects]

### 5.4 Edge Cases
[Known edge cases and how they should be handled]

---

## 6. Error Handling

### 6.1 Error Taxonomy
| Error Code | HTTP Status | Condition | User Message |
|------------|-------------|-----------|--------------|
| ... | ... | ... | ... |

### 6.2 Retry Strategy
[Which operations are retryable, backoff policy, max attempts]

### 6.3 Failure Modes
[What happens when dependencies fail — graceful degradation plan]

---

## 7. Security

### 7.1 Authentication & Authorization
[Who can access what, permission model, role checks]

### 7.2 Input Validation
[Sanitization rules, injection prevention, size limits]

### 7.3 Data Protection
[Sensitive fields, encryption at rest/transit, audit logging]

---

## 8. Performance

### 8.1 Expected Load
[Estimated QPS, data volume, growth projection]

### 8.2 Optimization Strategy
[Caching, pagination, lazy loading, batch processing]

### 8.3 Database Considerations
[Index strategy, query patterns, N+1 prevention]

---

## 9. Testing Strategy

### 9.1 Unit Tests
[What to test, test boundaries, mock strategy]

### 9.2 Integration Tests
[API tests, database tests, service interaction tests]

### 9.3 Edge Case Tests
[Specific scenarios to cover based on Section 5.4]

### 9.4 Acceptance Criteria Mapping
| US/FR | Test | Type | Description |
|-------|------|------|-------------|
| US-001 | ... | unit | ... |
| FR-2 | ... | integration | ... |

---

## 10. Implementation Plan

### 10.1 Phases
[Order of implementation — what to build first, dependencies between steps]

### 10.2 Issue Mapping
[Map SPEC sections to PRD Issues for implementation tracking]

| Issue | SPEC Sections | Priority | Depends On |
|-------|--------------|----------|------------|
| #1 | 3.1, 3.4 | high | — |
| #2 | 4.1, 4.2, 5.1 | high | #1 |
| ... | ... | ... | ... |

### 10.3 Incremental Delivery
[How to ship incrementally — feature flags, dark launches, gradual rollout]

---

## 11. Open Questions & Risks

### 11.1 Unresolved Questions
- [Questions that need product/engineering input before implementation]

### 11.2 Technical Risks
| Risk | Impact | Mitigation |
|------|--------|-----------|
| ... | ... | ... |

### 11.3 Assumptions
- [Technical assumptions made during SPEC creation — validate before implementing]

Step 5: Review & Iteration

After generating the SPEC, present it and ask:

SPEC generated from PRD. Please review:

- Are the architecture choices appropriate?
- Are there missing edge cases or error scenarios?
- Is the API design consistent with existing patterns?
- Should any section have more/less detail?

Reply OK to save, or provide feedback for iteration.

Step 6: Save

Ask user for save location:

Where should I save the SPEC?

A. tasks/spec-[feature-name].md (alongside PRD, recommended)
B. docs/spec-[feature-name].md
C. Custom path: [specify]

Mapping Strategy: PRD → SPEC

How PRD elements translate to SPEC sections:

PRD SectionSPEC Section(s)Transformation
User Stories5. Business Logic, 9.4 Acceptance MappingStories → algorithms + test cases
Functional Requirements4. API Design, 5. Business LogicFRs → endpoints + logic
Acceptance Criteria9. Testing StrategyCriteria → specific test scenarios
Non-Goals11.1 Open QuestionsClarify what's explicitly excluded
Technical Considerations2. Architecture, 8. PerformanceConstraints → design decisions
Success Metrics8.1 Expected Load, 10.3 DeliveryMetrics → monitoring + rollout plan
Show full SKILL.md (334 more words)Show less

Quality Criteria

A good SPEC should pass these checks:

  • Every PRD User Story has corresponding SPEC sections
  • Every Functional Requirement maps to an API endpoint or business logic rule
  • Every Acceptance Criterion maps to at least one test case
  • Architecture choices are justified with rationale
  • API schemas are specific enough to generate client code
  • Error handling covers all identified failure modes
  • Implementation order respects dependencies
  • No "TBD" or "TODO" items — resolve or move to Open Questions

Edge Cases & Fallback

ScenarioHandling
PRD is vague or incompleteGenerate SPEC with best-effort choices, mark assumptions in Section 11.3
PRD conflicts with existing codeFlag conflicts explicitly, propose resolution in Section 11.1
Feature is too large for one SPECSplit into multiple SPECs (one per service boundary), link them
No existing codebase (greenfield)Skip Step 2, propose architecture from scratch based on PRD + clarifying questions
PRD has no User Stories (just bullet points)Infer structure, map bullets to SPEC sections, note in Summary
User wants SPEC without reading codebaseSkip Step 2, note that assumptions about existing code are unverified
Multiple PRDs need one SPECMerge PRD inputs, deduplicate requirements, note source for each

Anti-Patterns to Avoid

  • Don't restate the PRD. The SPEC adds technical depth, not a copy of requirements in different words.
  • Don't over-specify trivial operations. CRUD with no special logic doesn't need a full algorithm section.
  • Don't pick technologies without context. Always check what the project already uses before suggesting new tools.
  • Don't design in isolation. The SPEC must fit the existing system — same patterns, same conventions, same style.
  • Don't leave decisions implicit. If you made a choice (e.g., "add column to existing table"), state it and say why.
  • Don't write implementation code. The SPEC describes contracts and behavior, not code. Pseudocode is acceptable for complex algorithms.

Relationship to Other Skills

/prd  →  /prd-to-spec  →  /goal  →  /review-it  →  /ship-it
 │              │              │
 │  Requirements │  Technical   │  Implementation
 │  (what)       │  (how)       │  (code)
  • /prd produces the PRD (input to this skill)
  • /prd-to-spec produces the SPEC (this skill)
  • /goal implements Issues with SPEC as the technical reference
  • /code-to-spec reverse-engineers SPEC from existing code (complementary — forward vs. reverse)

© smallnest, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/prd-to-spec of smallnest/goal-workflow.

Open the folder on GitHubat commit b06ab3c

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders. This page covers the copy in smallnest/goal-workflow, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Prd To Spec next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Prd To Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Prd To Spec this skillsmallnest/goal-workflow290—~3.1kAutomated safety check: PassMIT
CCPM Project Managementautomazeio/ccpm8.4k—~1.1kAutomated safety check: PassMIT
Ralph Tui Create Beadssubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
Trellis Brainstormanjiemo/SunnyBeach1787 repos~4kAutomated safety check: PassApache-2.0
Ralph Tui Create Beads Rustsubsy/ralph-tui2.5k1 repos~2.8kAutomated safety check: PassMIT
Ralph Tui Create JSONsubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT

Similar skills

  • CCPM Project Management

    automazeio/ccpm

    Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.

    8.4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Product & Project ManagementAuto-check passed

  • Ralph Tui Create Beads

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed

  • Trellis Brainstorm

    anjiemo/SunnyBeach

    Guides collaborative requirements discovery before implementation.

    178 GitHub starsUsed in 7 repos~4k tokens
    Product & Project ManagementAuto-check passed

  • Ralph Tui Create Beads Rust

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI).

    2.5k GitHub starsUsed in 1 repo~2.8k tokens
    Product & Project ManagementAuto-check passed

  • Ralph Tui Create JSON

    subsy/ralph-tui

    Convert PRDs to prd.json format for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed

  • Prd Generator

    jamesrochabrun/skills

    Generate comprehensive Product Requirements Documents (PRDs) for product managers.

    216 GitHub starsUsed in 2 repos~3.8k tokens
    Product & Project ManagementAuto-check passed

More from smallnest/goal-workflow

All 20 skills in this repo

  • Article Icons

    smallnest/goal-workflow

    Illustrate an article (Markdown, HTML, etc.) with animated-style icons from itshover.com/icons.

    290 GitHub stars~1.6k tokensUpdated 26 days ago
    Auto-check passed

  • Graph

    smallnest/goal-workflow

    Graph engineering for parallel task execution: convert a task, PRD, SPEC, or issue set into a dependency graph (DAG), layer it into supersteps, then implement each independent node concurrently with…

    290 GitHub stars~3.9k tokensUpdated 26 days ago
    Auto-check passed

  • Walkthrough

    smallnest/goal-workflow

    Generate a Phase-2 Walkthrough artifact (walkthrough.md) once implementation and verification are complete.

    290 GitHub stars~4.7k tokensUpdated 26 days ago
    Auto-check: notes

  • Insight Diagram

    smallnest/goal-workflow

    为任意项目生成 UML 图、架构图和流程图。分析代码库后让用户选择要生成的图表类型，使用 architecture-diagram skill 渲染为 HTML+SVG，保存到 docs/ 目录。适用于任何软件项目的文档可视化。

    290 GitHub stars~1.6k tokensUpdated 26 days ago
    Auto-check passed

  • Code To Spec

    smallnest/goal-workflow

    Reverse-engineer a SPEC document from an existing project. An agent skill from smallnest/goal-workflow.

    290 GitHub stars~2.7k tokensUpdated 26 days ago
    Auto-check passed

  • Design It

    smallnest/goal-workflow

    A skill your agent uses when turning a requirement, spec, or feature brief into a single self-contained HTML design document in a fixed house style — one styled HTML page with a table-of-contents…

    290 GitHub stars~1.1k tokensUpdated 26 days ago
    Auto-check passed

Categories

Questions about Prd To Spec

What does Prd To Spec do?

Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts. Prd To Spec is an agent skill from smallnest/goal-workflow. Transform a PRD into a technical SPEC document — architecture, API design, data model, error handling, and implementation contracts.

When should I use Prd To Spec?

Prd To Spec fits situations like: generate spec from prd; design from prd.

How do I install Prd To Spec in Claude Code?

Run `npx skills add smallnest/goal-workflow --skill prd-to-spec -a claude-code`. Or copy the skill folder (skills/prd-to-spec in smallnest/goal-workflow) into .claude/skills/prd-to-spec in your project. Claude Code loads it when a task matches its description.

How do I install Prd To Spec in Codex?

Run `npx skills add smallnest/goal-workflow --skill prd-to-spec -a codex`. Or copy the skill folder (skills/prd-to-spec in smallnest/goal-workflow) into .agents/skills/prd-to-spec in your project. Codex loads it when a task matches its description.

Can I use Prd To Spec in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add smallnest/goal-workflow --skill prd-to-spec -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/prd-to-spec, .gemini/skills/prd-to-spec, .github/skills/prd-to-spec and .opencode/skills/prd-to-spec in your project.

What does Prd To Spec need to run?

SKILL.md names no scripts, command-line tools or credentials: Prd To Spec is instructions for the agent only. Our summary lists: Python 3.

Does Prd To Spec access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Prd To Spec safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Prd To Spec use?

Prd To Spec is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Prd To Spec use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Prd To Spec?

Skills that share tags, products or a category with Prd To Spec: CCPM Project Management (automazeio/ccpm, 8.4k stars), Ralph Tui Create Beads (subsy/ralph-tui, 2.5k stars), Trellis Brainstorm (anjiemo/SunnyBeach, 178 stars) and Ralph Tui Create Beads Rust (subsy/ralph-tui, 2.5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Prd To Spec?

smallnest (a GitHub user) maintains it in smallnest/goal-workflow, which has 290 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on September 13, 2026.

Source: smallnest/goal-workflow on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.