Menu
Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
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
Bootstrap AI-ready repo governance, traceability, cascade, catalog audits, validation. Deprecated compatibility aliases: init-ai-repo, ai-sdlc-init. Use when setting up AI SDLC.
Deprecated compatibility alias for ai-catapult-init. Use only when legacy prompts invoke "ai-sdlc-init"; otherwise use "ai-catapult-init".
Ship a northstar handoff's goals in an ai-catapult-init repo — ultragoal one-PR-per-goal, deterministic engine-pick, peer review, CI gate, fail-closed merge, cascade closure.
Scaffold a structurally valid eval triplet for a target skill under .ai/evals/. CI checks structure only; the LM-judge runs out-of-band, never in CI.
Deprecated compatibility alias for ai-catapult-init. Use only when legacy prompts invoke "init-ai-repo"; otherwise use "ai-catapult-init".
Intake intent into a tracked, sliced plan in an ai-catapult-init repo — deep-interview + skippable grill-me, always raise an issue, ralplan, write the A→B handoff.
| name | to-prd |
| description | Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context. |
This skill takes the current conversation context, optional BRD, and codebase understanding and produces a PRD. Do NOT interview the user — synthesize what you already know and publish directly.
The issue tracker and triage label vocabulary should have been provided to you — run setup-skills if not.
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. Look for opportunities to extract deep modules (simple interface, complex implementation, rarely changes) that can be tested in isolation. Default to writing tests for all new modules.
Write the PRD using the template below, preserving any BRD source ID/link and acceptance criteria traceability, then publish it to the project issue tracker. Apply the ready-for-agent triage label — 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:
State the compatibility/release impact and rationale. If signals conflict, use highest-signal-wins: PRD/spec/acceptance criteria/ADR first, ticket/work-item fields second, commit/diff inference third, operator defaults last. Preserve conflicts in notes rather than downgrading a spec-declared breaking change.
A description of the things that are out of scope for this PRD.
Any further notes about the feature.
