Menu
Internal methodology for the PRD discovery stage. Produces a concise Product Reference Document for implementation planning.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Instructions for using gcode CLI for code search and retrieval. Loaded on demand when project has a code index.
Pre-transition checklist for closing or reviewing tasks. Covers fresh verification evidence, commits, and memory gates.
Use when processing CodeRabbit review comments, CodeRabbit CLI reports, or `$gobby coderabbit [findings]` requests.
Use when creating, editing, or validating Gobby skills, especially when a skill must change agent behavior or become discoverable through gobby-skills.
Use when coordinating a full gobby build run for an epic or task, especially when the user assigns the current session as coordinator, asks for a coordination epic, wants build agents/worktrees monitored, or wants gobby build bugs fixed so future runs work unattended.
Router contract for provider-aware Gobby help and installed skill dispatch.
| name | prd |
| description | Internal methodology for the PRD discovery stage. Produces a concise Product Reference Document for implementation planning. |
| version | 1.0.0 |
| category | methodology |
| internal | true |
| triggers | prd, product requirements, acceptance criteria |
| metadata | {"gobby":{"audience":"agent","depth":0}} |
Use this skill when acting as the product-manager discovery-stage agent.
Turn upstream discovery into product-readable requirements for planning. The PRD should define goal, users, scope, explicit non-scope, acceptance criteria, and the planning handoff.
Write only this section shape:
## Product Reference Document
### Goal
- <outcome>
### Users
- <user or system actor>
### Scope
- <included behavior>
### Out of Scope
- <excluded behavior>
### Acceptance Criteria
- <observable acceptance criterion>
### Planning Handoff
- <constraint, dependency, or note for planner>
Do not write an implementation plan or task manifest. Preserve uncertainty explicitly instead of silently broadening scope.