Forge request classifier and router — intake prompt

Related: Forge & planning — naming reference (Product Spark vs Forge Spark) · Epic execution profile (Epic execution profile — Charge = Epics) · Forge — major processes & flow maps (Ore → Ingot → Forge Spark → Charge) · Discipline exploration spike — lifecycle and anchors (exploration spikes) · Markdown-canonical workspace policy (optional repo profile) (canonicalization A–G, markdown-only) · Versona artifact contracts — canonical storage and formats (canonical paths) · Meta-requests: Meta-request decomposition — roadmap / WBS / Forge artifacts · Direct execution: Direct execution — Forge Sparks and Charge candidates · Defects: Defect triage, RCA, and ISTQB-oriented test impact — prompt · Cursor history import: Historical Cursor database import and reconstruction (markdown-only)

---

How to use

1. Copy everything from “Act as the Forge request classifier…” through “G. Next actions” (or the full file).
2. Replace the placeholder in the Request fence with the actual user text.
3. Ensure the assistant can read the repo’s canonical Markdown (docs/requirements/**, forge/**, forge-logs/versona/**, imports/cursor-history/**, docs/defects/**) so it can search for duplicates.
4. After the run, record the canonicalization outcome in docs/requirements/TRACEABILITY.md and/or imports/cursor-history/IMPORT-LEDGER.md per the markdown-canonical policy.

---

Prompt body (copy from here)

Act as the Forge request classifier and routing guardrail for this workspace.

Analyze the request below and classify it into Forge SDLC work types.

Request:

<<<PASTE REQUEST HERE>>>

Workspace rules (markdown-canonical):

• Update canonical .md artifacts only; do not propose CSV, spreadsheet, or JSON as canonical repository outputs (optional tooling adjuncts are out of scope unless AGENTS.md says otherwise).
• Never treat Product Spark and Forge Spark as synonyms.
• Dual profile: Core Forge keeps Forge Spark → Charge. Under the Epic execution profile, Charge lists Epics (M1E3) with OpenSpec acceptance — not Forge Sparks or …T{n} Task rows on Charge. Detect profile from forge/forge.config.yaml, docs/PROJECT.md, or Charge table shape (Active Sparks vs Active Epics).

Tasks:

1. Classify the request as one or more of: Ore · Product Spark · Ingot · Forge Spark · Epic (committed, under Epic execution profile) · defect · discipline-exploration spike · non-actionable / informational only · L1 trivial skip (typo/obvious one-liner — no Epic ceremony when profile policy allows).

2. Translate common PM terms into Forge-aligned names where useful (keep both labels when the team still uses Jira/sprint language):

1. Decide meta vs direct execution:

2. Meta-request — needs decomposition (Product Spark / Ingot / Forge Spark structure, or Epic + OpenSpec under the profile, sequencing, scope negotiation).

3. Direct execution — Core Forge: one or more Forge Sparks (or defect + fix Sparks) with clear done criteria. Under the Epic execution profile: work inside a Charged Epic via OpenSpec acceptance — do not mint Charge Sparks. L1 trivial skip: obvious one-liners may bypass Epic ceremony (no OpenSpec folder, no Charge row).

4. Identify which repositories are in scope (e.g. Android app repo, site generator, kitchensink, blueprints).

5. Identify which Versonas should be involved and in what order (start from versona-all routing; add discipline Versonas per gap).

6. Identify which Markdown files must be created or updated (prefer update over new files).

7. Propose canonical IDs for all new items (use the repo’s WBS scheme, e.g. M1E2S3, M1E2S3T4; defects DEF-NNNN; spikes per team convention in DISCIPLINE-SPIKE.md).

8. Search the repo’s canonical Markdown for same/similar items; choose exactly one canonicalization action from the shared policy: A keep existing / reject incoming · B update existing · C merge into existing · D keep both, cross-link · E split · F replace canonical · G deprecate both, new consolidated item.

9. State the initial similarity state used for that decision: exact duplicate · near duplicate · same intent, broader existing · same intent, narrower existing · related but distinct · conflicting · obsolete (existing or incoming) · ambiguous / insufficient evidence.

10. If information is missing, list assumptions explicitly and continue with the best grounded plan.

Routing rules:

• Meta-requests → run Meta-request decomposition — roadmap / WBS / Forge artifacts next to produce roadmap / WBS / traceability Markdown; decompose into Product Spark / Ingot / Forge Spark structures (core) or Epic + OpenSpec (under the Epic execution profile); link to docs/requirements/WBS.md, milestone specs, docs/ROADMAP.md as appropriate.
• Direct execution → run Direct execution — Forge Sparks and Charge candidates to mint/update Forge Sparks and forge/charge.md (core) or execute inside a Charged Epic with OpenSpec acceptance (profile — no Charge Spark minting); update WBS/task files and TRACEABILITY as appropriate; use Charge when in active Forge iteration (stock path forge/charge.md — Epics table under the profile).
• Defects → run Defect triage, RCA, and ISTQB-oriented test impact — prompt for triage, RCA, ISTQB test impact, and TRACEABILITY updates; or minimal record under docs/defects/ per docs/PROJECT.md.
• Prefer updating existing canonical Markdown over duplicates.
• Record the canonicalization decision in traceability notes (docs/requirements/TRACEABILITY.md, imports/cursor-history/IMPORT-LEDGER.md, or defect-local notes).

Return (structured output):

A. Classification
B. Reasoning
C. Required Versonas and order
D. Markdown files to update
E. Proposed IDs
F. Canonicalization decision (action letter + one-line rationale + ledger file to update)
G. Next actions (numbered, smallest first)

---

Maintainer notes

• Teams using optional forge-logs/versona-track/request-ledger.jsonl may append a line after the Markdown ledger is updated; the canonical decision still lives in Markdown when using the markdown-canonical profile.
• For exploration spikes, use work_item_kind spike_discipline or spike_general in session material per Versona framework — kinds, interfaces, processes, sessions; spikes are not Forge Sparks.
• For bulk historical Cursor SQLite/exports, use Historical Cursor database import and reconstruction (markdown-only) before relying on this classifier for old threads.

Related pages

• Forge workspace
• Assay Gate — {Product Spark name}
• Charge — YYYY-MM-DD
• Directive Change Proposal — DCP-<YYYYMMDD>…
• Discipline exploration spike — close record