Task to PRD Generator
User-facing entry point for the task → PRD pipeline. The user runs
/task-to-prd and this skill dispatches to the companion babysitter
process via /babysitter:call (interactive — Five Whys, clarification
loop, scope-lock, per-finding gates, final approval) or
/babysitter:yolo (non-interactive, auto-approve every gate).
Usage
/task-to-prd <tracker-id | file-path | inline-text>
Examples:
/task-to-prd JIRA-1234/task-to-prd path/to/email.txt/task-to-prd "Eden asked to change the donut to show lessons" (inline)
Companion process
- Library path:
library/specializations/product-management/task-to-prd.js
- Locally installed:
~/.a5c/processes/task-to-prd.js
The process file is the source of truth for the pipeline. This skill
intentionally stays thin so users only need to remember /task-to-prd.
What this skill does when invoked
Parse input — detect whether it's a tracker ticket ID, a file
path, or inline text.
Infer featureBranch — read the current git branch via
git branch --show-current. If unsuitable (e.g., main), ask the
user to provide a feature-branch name.
Detect optional inputs from the project context:
contextDoc — project conventions doc (default CLAUDE.md)archiveDir — past PRD archive directory (default empty)trackerHint — hint like jira, linear, gh-issues (default empty)secondaryReviewer — hint like codex, gemini, peer (default empty)
Ask the user to pick the run mode:
Run mode for the babysitter task-to-prd process:
- Interactive (
/babysitter:call) — recommended. The Five
Whys + clarification loop is intrinsically interactive — every
question goes through the user. Verification findings each get
a per-finding approval gate.
- Auto / yolo (
/babysitter:yolo) — non-interactive. Skips
the clarification loop (uses defaults from Five Whys), auto-
approves every gate, applies all proposed PRD changes
automatically. Use only when the input is already well-defined
and you want a fast first draft.
Default to option 1 if the user does not respond.
Dispatch by invoking the chosen babysitter command via the Skill tool:
For interactive:
Skill('babysitter:call', 'Run the product-management/task-to-prd process with inputs: input=<resolved>, featureBranch=<resolved>, contextDoc=<resolved>, archiveDir=<resolved>, trackerHint=<resolved>, secondaryReviewer=<resolved>')
For auto / yolo:
Skill('babysitter:yolo', '<same instruction as above>')
Return the PRD path, the Decision Log, and the follow-up
/prd-to-spec prompt produced by the process to the user.
Fallback (no babysitter runtime)
If neither /babysitter:call nor /babysitter:yolo is available:
- Read the process source at the location above.
- Execute each task's agent prompt manually, in phase order.
- Pause at every
ctx.breakpoint(...) for explicit user approval
(interactive equivalent) or skip every breakpoint (yolo equivalent),
matching the mode the user picked in step 4.
- Return the same outputs the process would have returned.
Optional Integration Hooks
All flow through the process inputs (none required):
- Tracker integration —
trackerHint input. Examples: Jira
(/jira skill or acli jira workitem view), Linear (CLI / MCP),
GitHub Issues (gh issue view).
- Secondary reviewer —
secondaryReviewer input. Examples: Codex
(/codex:review), Gemini (/gemini-review), deep-verify-plan
(/deep-verify-plan), peer (notify a teammate).
- Stakeholder attribution — the Decision Log records each Q&A with
attribution to
user or a named stakeholder (e.g., product owner,
tech lead, designer).
The process works end-to-end without any of them.
Pipeline shape (executed by the process)
| Phase |
What happens |
Interactive in /babysitter:call? |
| 1a. Load source |
Detect tracker / file / inline |
no |
| 1b. Five Whys |
Root-cause analysis |
no |
| 1c. Clarification loop |
Q&A one at a time |
YES |
| 1d. Scope Lock |
Approve scope before drafting |
YES |
| 2. Draft (parallel) |
Codebase scan + draft PRD via embedded skill instructions |
no |
| 3a. Verification (5 parallel) |
what-could-go-wrong + consistency + conventions + adversarial + quality checklist |
no |
| 3b. Per-finding gate |
Approve each proposed PRD change |
YES |
| 4a. Final review |
Approve final PRD |
YES |
| 4b. Tracker update |
Push reference to tracker (if applicable) |
no |
| 4c. Follow-up prompt |
Output /prd-to-spec <path> |
no |
In /babysitter:yolo mode, every gate marked YES is auto-approved.
Rules
- The skill itself does not produce the PRD. It only sets up inputs
and dispatches to the process via
/babysitter:call or /babysitter:yolo.
- Default to
/babysitter:call (interactive) when in doubt.
- Phase 1 (clarification) is the most user-intensive — yolo mode
effectively turns it into a shallow first-draft using only Five-Whys
defaults. Recommend interactive mode for any non-trivial task.
- The PRD must be proportional to the task size (the process honors this).
1---2name: task-to-prd3description: Convert a raw task (tracker ticket, email, or text) into a fully characterized PRD. User-facing entry point that dispatches to the task-to-prd babysitter process via /babysitter:call (interactive) or /babysitter:yolo (auto). Stack-agnostic.4---56# Task to PRD Generator78User-facing entry point for the task → PRD pipeline. The user runs9`/task-to-prd` and this skill dispatches to the companion babysitter10process via `/babysitter:call` (interactive — Five Whys, clarification11loop, scope-lock, per-finding gates, final approval) or12`/babysitter:yolo` (non-interactive, auto-approve every gate).1314## Usage1516```17/task-to-prd <tracker-id | file-path | inline-text>18```1920Examples:21- `/task-to-prd JIRA-1234`22- `/task-to-prd path/to/email.txt`23- `/task-to-prd "Eden asked to change the donut to show lessons"` (inline)2425## Companion process2627- Library path: `library/specializations/product-management/task-to-prd.js`28- Locally installed: `~/.a5c/processes/task-to-prd.js`2930The process file is the source of truth for the pipeline. This skill31intentionally stays thin so users only need to remember `/task-to-prd`.3233## What this skill does when invoked34351. **Parse input** — detect whether it's a tracker ticket ID, a file36 path, or inline text.372. **Infer `featureBranch`** — read the current git branch via38 `git branch --show-current`. If unsuitable (e.g., `main`), ask the39 user to provide a feature-branch name.403. **Detect optional inputs** from the project context:41 - `contextDoc` — project conventions doc (default `CLAUDE.md`)42 - `archiveDir` — past PRD archive directory (default empty)43 - `trackerHint` — hint like `jira`, `linear`, `gh-issues` (default empty)44 - `secondaryReviewer` — hint like `codex`, `gemini`, `peer` (default empty)454. **Ask the user to pick the run mode:**4647 > Run mode for the babysitter `task-to-prd` process:48 >49 > 1. **Interactive (`/babysitter:call`)** — recommended. The Five50 > Whys + clarification loop is intrinsically interactive — every51 > question goes through the user. Verification findings each get52 > a per-finding approval gate.53 > 2. **Auto / yolo (`/babysitter:yolo`)** — non-interactive. Skips54 > the clarification loop (uses defaults from Five Whys), auto-55 > approves every gate, applies all proposed PRD changes56 > automatically. Use only when the input is already well-defined57 > and you want a fast first draft.5859 Default to option 1 if the user does not respond.60615. **Dispatch** by invoking the chosen babysitter command via the Skill tool:6263 For interactive:64 ```65 Skill('babysitter:call', 'Run the product-management/task-to-prd process with inputs: input=<resolved>, featureBranch=<resolved>, contextDoc=<resolved>, archiveDir=<resolved>, trackerHint=<resolved>, secondaryReviewer=<resolved>')66 ```6768 For auto / yolo:69 ```70 Skill('babysitter:yolo', '<same instruction as above>')71 ```72736. **Return** the PRD path, the Decision Log, and the follow-up74 `/prd-to-spec` prompt produced by the process to the user.7576## Fallback (no babysitter runtime)7778If neither `/babysitter:call` nor `/babysitter:yolo` is available:79801. Read the process source at the location above.812. Execute each task's agent prompt manually, in phase order.823. Pause at every `ctx.breakpoint(...)` for explicit user approval83 (interactive equivalent) or skip every breakpoint (yolo equivalent),84 matching the mode the user picked in step 4.854. Return the same outputs the process would have returned.8687## Optional Integration Hooks8889All flow through the process inputs (none required):9091- **Tracker integration** — `trackerHint` input. Examples: Jira92 (`/jira` skill or `acli jira workitem view`), Linear (CLI / MCP),93 GitHub Issues (`gh issue view`).94- **Secondary reviewer** — `secondaryReviewer` input. Examples: Codex95 (`/codex:review`), Gemini (`/gemini-review`), `deep-verify-plan`96 (`/deep-verify-plan`), `peer` (notify a teammate).97- **Stakeholder attribution** — the Decision Log records each Q&A with98 attribution to `user` or a named stakeholder (e.g., product owner,99 tech lead, designer).100101The process works end-to-end without any of them.102103## Pipeline shape (executed by the process)104105| Phase | What happens | Interactive in `/babysitter:call`? |106|-------|--------------|-----------------------------------|107| 1a. Load source | Detect tracker / file / inline | no |108| 1b. Five Whys | Root-cause analysis | no |109| 1c. Clarification loop | Q&A one at a time | YES |110| 1d. Scope Lock | Approve scope before drafting | YES |111| 2. Draft (parallel) | Codebase scan + draft PRD via embedded skill instructions | no |112| 3a. Verification (5 parallel) | what-could-go-wrong + consistency + conventions + adversarial + quality checklist | no |113| 3b. Per-finding gate | Approve each proposed PRD change | YES |114| 4a. Final review | Approve final PRD | YES |115| 4b. Tracker update | Push reference to tracker (if applicable) | no |116| 4c. Follow-up prompt | Output `/prd-to-spec <path>` | no |117118In `/babysitter:yolo` mode, every gate marked YES is auto-approved.119120## Rules121122- The skill itself does not produce the PRD. It only sets up inputs123 and dispatches to the process via `/babysitter:call` or `/babysitter:yolo`.124- Default to `/babysitter:call` (interactive) when in doubt.125- Phase 1 (clarification) is the most user-intensive — yolo mode126 effectively turns it into a shallow first-draft using only Five-Whys127 defaults. Recommend interactive mode for any non-trivial task.128- The PRD must be proportional to the task size (the process honors this).
deedeeharris