Forge request classifier and router — intake prompt

Related: Forge & planning — naming reference (Product Spark vs Forge Spark) · 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.

Tasks:

1. Classify the request as one or more of: Ore · Product Spark · Ingot · Forge Spark · defect · discipline-exploration spike · non-actionable / informational only.

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, sequencing, scope negotiation).

3. Direct execution — can be expressed as one or more Forge Sparks (or a defect record + fix Sparks) with clear done criteria.

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; 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, forge/charge.md, WBS/task files, and TRACEABILITY; use Charge when in active Forge iteration (stock path forge/charge.md).
• 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.