菜单
Turn the current conversation context into a PRD and publish it to the local markdown tracker. Use when user wants to create a PRD from the current context.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Configure this repo's productivity skills for the local markdown tracker and domain docs. Use before triage, to-prd, or to-issues when tracker setup docs are missing or stale.
Use when setting up or reviewing React server state with TanStack Query v5, writing query/mutation hooks, configuring QueryClient, adding optimistic updates, handling offline/network mode, building infinite queries, or testing data-fetching flows. Also use when fixing v4 to v5 migration errors such as object syntax, gcTime, isPending, keepPreviousData, throwOnError, or SSR/hydration behavior.
Break a plan, spec, or PRD into independently-grabbable local markdown issues using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
| name | to-prd |
| description | Turn the current conversation context into a PRD and publish it to the local markdown tracker. Use when user wants to create a PRD from the current context. |
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
Use the local tracker, triage metadata, and domain docs in skills/productivity/setup-skills/. Run /setup-skills if those docs are missing or stale.
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
.scratch/<feature-slug>/PRD.md. Include Status: ready-for-agent near the top - no need for additional triage.The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this PRD.
Any further notes about the feature.