Meta-request decomposition — roadmap / WBS / Forge artifacts

Related: Planning flow — vision to daily Sparks · Product planning · Forge & planning — naming reference · Documentation structure — proposal (nested requirements layout) · Markdown-canonical workspace policy (optional repo profile) · Versona contract · Then execute: Direct execution — Forge Sparks and Charge candidates

How to use

1. Run the classifier prompt first; confirm output A includes meta-request (or equivalent).
2. Copy everything from “Act as Product Manager…” through “E. Missing Versonas…” below.
3. Paste the same original user request (or the classified summary + raw request) into the Input request fence.
4. Prefer editing existing docs/requirements/** files over adding parallel trees.
5. Never commit project-specific history under blueprints/ (submodule is read-only framework).

Prompt body (copy from here)

Act as Product Manager + BA + Forge planning orchestrator for this workspace.

Convert the classified meta-request into markdown-based repository artifacts using Forge SDLC concepts and the existing docs/ structure.

Input request:

<<<PASTE REQUEST HERE>>>

Workspace rules:

• Canonical outputs: .md only — Markdown tables, lists, front matter, linked detail files. No CSV, spreadsheets, or JSON as canonical SoT.
• Terminology: Use Ore, Product Spark, Ingot, Forge Spark, Forge iteration, Charge, Ember Log, Assay consistently. Product Spark (release / roadmap slice) ≠ Forge Spark (executable task). Roadmap and release-slice planning stay at Product Spark level; implementation commitment for the current cycle appears as Forge Spark rows and on forge/charge.md when the repo uses Forge daily ops.
• Layout: Follow the repo’s adopted tree (typically docs/requirements/milestones/M{n}/… with epic.md, story.md, tasks/*-task.md per Documentation structure — proposal; if the team uses a sparks/ folder for Forge Spark files, stay consistent with docs/PROJECT.md).

Tasks:

1. Derive and list:
2. Business driver or roadmap intent (problem/opportunity, “why now”).
3. Product Spark candidates (coarse shippable slices — PoC / MVP / phase / milestone-aligned).
4. Ingot candidates (refined items with acceptance shape — often story-level M{n}E{n}S{n}).

5. Forge Spark candidates (executable slices — often task-level …T{n}, phase-prefixed where the team uses discover: / specify: / build: / verify: / release:).

6. Map the decomposition to the current Markdown WBS and ID scheme documented in docs/requirements/WBS.md, docs/requirements/STRUCTURE-PROPOSAL.md (if present), and docs/PROJECT.md. Do not invent a second ID namespace.

7. Search for existing same/similar items in at least:

8. docs/ROADMAP.md
9. docs/requirements/INDEX.md
10. docs/requirements/WBS.md
11. Related milestone / epic / story Markdown files under docs/requirements/milestones/…
12. Forge Spark–level task files (e.g. tasks/M1E1S1T1-task.md or team sparks/*.md)
13. docs/requirements/TRACEABILITY.md

14. Optionally docs/requirements/ESTIMATES.md if it exists.

15. For each candidate item, choose exactly one canonicalization action from the shared workspace policy — A through G — and give a one-line why (duplicate / merge / split / replace / etc.).

16. Create or update Markdown artifacts, including where applicable:

17. docs/ROADMAP.md
18. docs/requirements/INDEX.md
19. docs/requirements/WBS.md
20. docs/requirements/TRACEABILITY.md
21. docs/requirements/ESTIMATES.md (if used — estimation placeholders only until sized)
22. Milestone / epic / story / task (Forge Spark) files under docs/requirements/…

23. If the repo uses forge/releases/ for Product Spark plans, add or update the appropriate release-plan Markdown there and link from ROADMAP.md / WBS.

24. For each new or materially updated item, capture in YAML front matter (preferred) or a consistent “Item record” subsection in the body:

25. title

26. id
27. parent (parent ID)
28. type (ore | product_spark | milestone | epic | ingot | story | forge_spark | task — use the set the repo already uses)
29. status
30. rationale (short)
31. dependencies (ids or links)
32. repos (repos affected)
33. versonas (Versonas needed)
34. estimation (placeholder, e.g. TBD)
35. source_request (pointer back to intake / ticket / IMPORT-LEDGER.md line)

36. canonicalization (action letter A–G + target id if merged/replaced)

37. Update WBS and traceability sections using Markdown tables or linked section lists (no CSV).

38. If a Versona is needed but no suitable template exists in blueprints/…/versona/catalog/, propose a new discipline or workflow Versona spec (not necessarily a file in blueprints/ from this task): trigger, inputs, outputs, guardrails, and §5 expectations per Versona contract. Prefer reusing Product Management, BA, Architecture, UX, SE, Testing, PM (governance) before inventing a name.

39. Preserve traceability from the original request to every touched artifact (IDs + file paths in TRACEABILITY.md and/or a new row in imports/cursor-history/IMPORT-LEDGER.md if the request came from import).

Execution mode:

• High confidence — apply edits directly in the repo (create/update the listed Markdown files).
• Lower confidence — output exact proposed file paths and full Markdown bodies for human review before apply.

Constraints:

• Do not write project-specific narrative into blueprints/.
• Do not use CSV for canonical matrices.

Return (structured output):

A. Artifact decomposition — table or nested list: driver → Product Sparks → Ingots → Forge Sparks (with IDs).
B. File-by-file markdown change plan — path, action (create/update/deprecate stub), one-line intent.
C. Traceability map — request → artifact IDs → file paths.
D. Canonicalization decisions — per candidate: action A–G, similarity state, ledger note location.
E. Missing Versonas or skills to add — bullet list or “none”; if new, include trigger / inputs / outputs / guardrails.

Maintainer notes

• Ore that is not yet refined may live only in docs/ROADMAP.md or a backlog section until refined into Ingots — avoid minting story.md files without acceptance criteria.
• Product Spark planning depth: use templates under ../../methodologies/forge/planning/ (poc-plan, mvp-plan, phase-plan, release-plan) when the repo adopts them; store instances under forge/releases/ or docs/ per docs/PROJECT.md.
• After decomposition, use Direct execution — Forge Sparks and Charge candidates to pull Forge Sparks onto forge/charge.md, or return to Forge request classifier and router — intake prompt for re-classification.