القائمة
Turn the current conversation context into a PRD and write it as a local markdown file. Use when the user wants to create a PRD from the current context.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets, and resolve them one at a time until the way to the destination is clear.
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.
Break a plan, spec, or PRD into independently-grabbable work items written as local markdown files, binding the set to the worktree you run it in. Use when the user wants to convert a plan into tasks, create implementation tickets, or break down work into actionable items. Accepts `managed` (isolated pop-owned worktree) and `auto-drain` (queue drains it unattended) arguments.
Fold accumulated glossary fragments (from `.grill-context/`, plus any legacy colocated CONTEXT.<counter>.<uuid>.md) into canonical CONTEXT.md files, reconcile clashing sequential ADR numbers (re-sequencing duplicates and fixing the links that pointed at them), and stub superseded ADRs down to their forward pointer, as a deliberate single-writer maintenance pass. Use when the user asks to consolidate, fold, merge, reconcile, clean up, or resolve concurrent context/glossary fragments, duplicate ADR numbers, or superseded ADRs produced by grill-with-docs.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise — conflict-free under parallel agents and teams via generation-numbered glossary fragments and sequential-id ADRs. Use when user wants to stress-test a plan against their project's language and documented decisions.
| name | to-prd |
| description | Turn the current conversation context into a PRD and write it as a local markdown file. Use when the user wants to create a PRD from the current context. |
| disable-model-invocation | true |
This skill takes the current conversation context and codebase understanding and produces a PRD as a local markdown file. Do NOT interview the user — just synthesize what you already know.
Wayfinder Map source: When the breakdown source is a Map (the user names a map id, or the session is handing off from wayfinder), read $(pop work show-path)/wayfinder/<map-id>/map.md and each resolved ticket under issues/ — at minimum every ticket linked from Decisions so far, plus any other resolved tickets whose ## Answer should inform the PRD. Synthesize from the map's Destination, Decisions so far, and those answers alongside conversation context; you need not load open or unresolved tickets.
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.
prd.md inside its own task-set folder (ADR-0088), co-located with the task files that to-tasks will add later: <tasks-dir>/<task-set-name>/prd.md, where <tasks-dir> is $(pop work show-path)/tasks — run pop work show-path for the storage root and append /tasks, or equivalently run pop tasks show-path (same directory; ADR-0130 compatibility alias). Create the <tasks-dir>/<task-set-name>/ directory now — it holds only prd.md at this stage; the set stays inert (invisible to the dashboard, never scheduled) until it is later registered with pop tasks register.When the source is a Map, include Source map: <map-id> as the first line of prd.md (before the template headings), then append <task-set-name> under the map's ## Spawned sets section in map.md (create the section if absent) — the forward link both ways (ADR-0129).
<task-set-name> is <timestamp>-<slug>, where <slug> is a descriptive hyphen-delimited name (e.g. user-auth). The slug carries over to the task set when this PRD is later broken down with to-tasks — to-tasks fills in the task markdown and index.json alongside this prd.md.
YYYY-MM-DD (e.g. 2026-05-31)YYYY-MM-DD-HHMM (24-hour local time, e.g. 2026-05-31-2036)Examples: 2026-05-31-user-auth/prd.md, 2026-05-31-2036-user-auth/prd.md
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.