| name | task-prd |
| description | Use to create a product requirements document for larger D2E work needing product, technical, and architecture alignment. |
PRD Workflow
Use for multi-file features, ambiguous requirements, or work needing product/architecture alignment.
Workflow
- Create or choose a project folder under
${D2E_DOCS_REPO:-repos/docs}/projects.
- Create an issue tracker from
${D2E_DOCS_REPO:-repos/docs}/templates/issue-tracker.md when available.
- Gather product context, existing patterns, architecture notes, and known pitfalls by routing through
knowledge/INDEX.md.
- Draft
<issue-number>-prd.md using the PRD template when available.
- Include overview, user stories, requirements, success criteria, out of scope, open questions, and technical notes.
- Keep absolute paths out of the PRD; use workspace-relative paths such as
repos/Data2Evidence and repos/docs.
Scope Guardrails
- This skill is documentation-only.
- Do not implement or modify application code, tests, configs, or runtime behavior when running this skill.
- The output should be PRD artifacts only (for example: project folder, issue tracker, and
<issue-number>-prd.md).
Review Loop
For PRDs with meaningful product or architecture uncertainty, run a bounded review loop before treating the PRD as ready.
- The coordinator owns the canonical PRD markdown file.
- Reviewers produce notes, objections, and proposed edits; they do not directly co-edit the canonical file.
- Prefer subagents for reviewer passes when subagent tooling is available; this preserves coordinator context and gives an independent review surface.
- Codex requires the user request to explicitly mention subagents, delegation, or parallel agent work before spawning subagents. Tell users to invoke this workflow as
/task-prd <issue-or-project> use subagents when they want reviewer subagents. If the request does not explicitly mention subagents, use the sequential fallback.
- Run at most two review rounds. If disagreement remains, capture it as a
Decision Needed item with the competing options and tradeoffs.
Reviewer roles:
- Product Manager: reviews user value, target users, scope, requirements, success criteria, non-goals, and ambiguous product decisions.
- Software Architect: reviews feasibility, architecture fit, integration points, data and service boundaries, operational risks, migration needs, and rollback concerns.
After reviewer feedback, reconcile the PRD into a compromise draft. Preserve unresolved questions explicitly instead of smoothing over uncertainty.
