菜单
Synthesize a PRD (Product Requirements Document) for a big new feature. Synthesis (not interview) — uses existing project context and explicit ADRs. Asks before gh issue create. Use when scoping a substantial new feature in PRD shape (e.g., before a sprint).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Clarify intent, propose 2-3 approaches, embedded grill to stress-test the chosen path. Use before any creative work — new features, components, behavior changes, design questions. Mockup-only requests use mockup quick-mode (no spec/plan ceremony).
Manage long-session context to prevent drift and degradation. Strategies for proactive summarization, branch isolation, and /clear decisions. Invoke when context feels heavy, when accuracy starts slipping, or proactively after a major phase boundary. Addresses the
Root-cause discipline for bugs, test failures, and unexpected behavior. Embedded grill on the hypothesis before writing fix code. Use when encountering any bug, failing test, or behavior that doesn't match expectation.
Design a module's interface using parallel sub-agents producing radically different designs ("design it twice"). Compare on depth, simplicity, and efficiency. Embedded grill on the synthesized choice. Use when designing a new API, exploring interface options, or deciding the shape of a refactor before writing code.
Execute a written implementation plan task-by-task with inline verification. Stop and ask on blockers. No forced sub-skill chains. Use when a plan exists and you're ready to implement.
Extract canonical domain terms into CONTEXT.md. Flag ambiguities (same word, different meanings) and synonyms (different words, same meaning). Re-invoking updates the file in place. Use when authoring or updating CONTEXT.md, or when a new domain term emerges in conversation.
| name | polyflow-prd |
| description | Synthesize a PRD (Product Requirements Document) for a big new feature. Synthesis (not interview) — uses existing project context and explicit ADRs. Asks before gh issue create. Use when scoping a substantial new feature in PRD shape (e.g., before a sprint). |
See polyflow meta-skill.
SKIP when: the work is small enough for polyflow-brainstorming → polyflow-writing-plans directly.
The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:
CLAUDE.md for project conventionsCONTEXT.md for domain languagedocs/adr/ for prior architectural decisionsdocs/stakeholder/*.md for in-flight initiativesOnly ask the user for things you genuinely cannot derive.
Sketch the modules to build/modify, emphasizing deep modules (small interface, complex internals). Apply the deletion test to each — does this module earn its existence?
Confirm with the user:
Default location: docs/specs/YYYY-MM-DD-<feature>.md. Use the user's preferred path if they have one.
Structure:
# [Feature Name] PRD
## Problem
One paragraph: what's broken or missing in the current product, and who feels the pain.
## Solution
One paragraph: the shape of the answer, named in domain language.
## User stories
- As a <role>, I can <action> so that <outcome>.
- (List 5-15)
## Architecture
Module list with one-line responsibility per module. Reference existing files where relevant. No code paths.
## Testing strategy
What behaviors must be covered. Integration vs. unit. Real services vs. test doubles.
## Scope
In:
- ...
Out:
- ...
## Open questions
Things needing decision before the plan can be written.
If the user wants the PRD as a GitHub issue, ASK before running gh issue create. Never auto-file.
CONTEXT.md. Use canonical terms.gh issue create. No auto-file.polyflow-writing-plans.polyflow-glossary to update CONTEXT.mdpolyflow-improve-architecture firstpolyflow-design-interface before plan