Breaking down prds

Skill vemodalen-x/VEMO_SKILLS/skills/orchestration/breaking-down-prds

Public reusable skill hub for agent workflows

Install

npx -y skills add vemodalen-x/VEMO_SKILLS --skill breaking-down-prds

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Decompose a PRD / requirements document into a structured, governable breakdown — functional & non-functional requirements, acceptance criteria, work-breakdown by stage/agent, requirement→stage traceability, and a coverage check. Use at project kickoff or a major new feature, when the orchestrator must turn a PRD into actionable, traceable work before research/build begins. Owned by Framework 0 (orchestration).

SKILL.md

3.6 KB, as published. Nobody here has run it

PRD Breakdown

Turn a PRD into a structured breakdown that anchors all downstream work and is traceable to the project's governance frameworks. The orchestrator (Framework 0) owns this activity; this skill standardizes it. Borrows decomposition discipline from spec-kit (PRD-as-source → spec → tasks), BMAD-METHOD (analyst/PM decomposition), and OpenSpec (current-state vs proposals separation).

When to use

Project kickoff or a major new feature: a PRD / requirements doc exists and must be decomposed before substantive research or build.
Trigger phrases: "拆解 PRD", "PRD breakdown", "decompose requirements".

Inputs

The PRD / requirements document (path or content).
The project's attached frameworks from project_profile.yaml (for traceability).

Procedure

Read the PRD as the source of truth (spec-kit). Extract intent, scope, hard constraints.
Functional Requirements (FR) — enumerate what the system must do (features, user scenarios, triggers); give each a stable id FR1, FR2, ...; cite PRD sections.
Non-Functional Requirements (NFR) — metrics & constraints (accuracy/latency/power/robustness/privacy/ platform/compatibility); id NFR1, ...; cite PRD sections.
Acceptance criteria — from the PRD's acceptance section; map each to the owning stage.
Work breakdown → owning stage/agent (BMAD analyst/PM pattern) — which stage owns which scope and which FR/NFR it serves.
Requirement → stage traceability matrix — each requirement → owning stage(s) → verification evidence; sync into the orchestration instance traceability table.
Coverage check (OpenSpec current-vs-proposed) — confirm the first/next task is in the PRD direction; explicitly log requirements deferred to later stages so nothing is lost.
Open items — facts to confirm with the user; mark pending, never assume.

Output

A PRD-breakdown deliverable containing: FR table, NFR table, acceptance→stage, work-breakdown→stage, coverage check, open items. Stable ids enable traceability.
Filed as a single authoritative file under the project deliverables convention: deliverables/<task-id>_prd_breakdown.md. One file only — no parallel language copies.
Language follows the project language policy (instance-owned): a PRD breakdown is a published outward deliverable, so its language is whatever the instance's language policy assigns to outward deliverables. The skill reads this from the instance; it hardcodes no language.

Rules

Requirements must be traceable to the project's governance frameworks (orchestration instance matrix).
Ask-don't-assume for missing facts (chip/model/targets) → pending.
This skill produces the breakdown only; it does not perform the research/build.
Adoption/build of this skill is governed by Framework 0 skill_spec; recorded in the orchestration catalog.
Decoupling (skill_spec §9): this body is generic — project values (deliverable naming, language policy, framework set) are read from the business-repo instance at runtime; nothing project-specific is hardcoded here.