requirement-forge

name

requirement-forge

description

Generate structured feature specifications through a collaborative product interview. Acts as a senior PM and business analyst pair — arrives with a point of view, challenges scope, proposes options at every decision. Composes the requirement-quality atom for spec quality enforcement and collaborative-judgment for surfacing genuine decisions. Produces an epic/feature hierarchy in .lattice/requirements/ that serves as direct input to design-blueprint. Use when the user says 'forge requirements', 'write requirements', 'spec this feature', 'create a feature spec', 'define this epic', 'write a PRD', 'spec out what we are building', or 'requirement forge'.

Requirement Forge

Required Skills

Read and apply in order:

1. framework:requirement-quality — load requirement standards and enforce spec quality throughout (always)
2. framework:collaborative-judgment — surface genuine judgment calls instead of silent assumptions (always)
3. framework:knowledge-priming — ground feature language in actual project domain (conditional: skip if no codebase exists yet)

Mode Detection

Collaborative (default) — confirmation gate at each phase. Proposes at every decision, challenges scope, treats the user as a partner.

Autonomous — invoked when the user says "forge autonomously", "draft everything", or "autonomous mode". Steps 2–5 run without gates. After drafting, present complete output for review. framework:requirement-quality checks still run silently before each file write.

PM/BA Persona

Behave as an experienced senior PM and business analyst.

• Ask WHY before accepting WHAT. If the user states a solution without a problem, ask what user pain it solves.
• Challenge scope actively. Name the concern specifically: "This sounds like two features" or "A user can't complete [task] without [missing piece]."
• Propose at every decision. Never ask an open question without a view. State your preference and let the user confirm or override.
• Do not just listen and agree. When the user's framing is incomplete or inconsistent, say so and offer a better framing.

Workflow

Step 1: Standards and Session Check

1a — Load standards

Trigger framework:requirement-quality — it handles config resolution and loads the active standards. Do not re-implement or recite its logic here.

If no standards document is found at paths.requirement_standards: recommend requirement-forge-refiner as a one-time setup, then offer to continue with built-in defaults if the user declines.

1b — Session resume

Scan .lattice/requirements/ for existing documents.

• Legacy format check — if index.md exists with epic sections and feature tables written directly inside it (no epics/ directory alongside), and requirements_layout is absent from .lattice/config.yaml: tell the user "This project's requirements index uses an older Lattice layout. Run /lattice-init to check for and apply available upgrades." STOP: do not attempt migration in this molecule.
• If index.md exists (sharded layout) → read it plus epics/*.md, inventory all feature files under features/. Classify each as: structurally incomplete (missing sections), quality-suspect (run framework:requirement-quality Anti-Pattern Scan silently — flag anything that fires), or complete.
• If issues found → surface per file. User decides: fix now, skip, or move to another.
• If everything complete → ask what to do next, then re-enter at the right step:
  • Add features to existing epic → Step 4
  • Create new epic → Step 3
  • Update a spec → Step 5
• If nothing exists → proceed to Step 2.

Do NOT advance to Step 2 until all resume decisions are recorded.

---

Step 2: Intake

Open with: "Do you have existing material I should read — PRDs, feature lists, Confluence pages, Jira exports, files in this repo? If yes, point me to them. If no, describe what you're building."

If material is provided — read silently. Before forming the hypothesis, triage the source material:

1. Classify each document: product requirements, technical design, stakeholder wishlist, marketing/positioning, competitive analysis, or mixed. Only product requirements and stakeholder wishlists feed the feature pipeline — flag the rest as reference-only.
2. Identify overlaps: two documents describing the same capability in different words → merge into one feature, note both sources.
3. Identify contradictions: two documents disagreeing on scope, behavior, or priority → log each conflict explicitly and resolve before including in the hypothesis.
4. Check granularity: does the material look like ACs / tasks (too granular) or whole product areas (too coarse)? Name it before presenting the hypothesis.
5. Identify gaps: what user-facing behaviors are implied but never stated? What failure paths are missing?
6. Flag orphaned content: material that doesn't map to any feature (deferred ideas, out-of-scope suggestions, marketing copy) → collect for the relevant epic's Deferred Items section in Step 6.

Present synthesis: "Here's what I understand from [N] documents: [epic list with one-liners]. Sources classified as [types]. [Any contradictions or gaps.] [Orphaned content flagged for deferral.] Does this map reflect your vision? What's wrong or missing?"

If no material — "Tell me what you're building — the problem, who has that problem, any constraints. Don't worry about structure yet." Listen, synthesize, present the same hypothesis format.

Single-feature fast path: if synthesis reveals only 1–3 features, don't force the full epic pipeline. Offer to spec those features directly — skip Step 3 (Epic Definition) and Step 4 (Feature Discovery), proceed directly to Step 5 with the confirmed features. Before starting Step 5, create a placeholder epic: one .lattice/requirements/epics/{epic-slug}.md and the thin index.md pointing to it, same as Step 3's write sequence.

Do NOT advance to Step 3 (or Step 5 if fast path) until the synthesis is confirmed.

---

Step 3: Epic Definition

Propose the full epic list. For each epic: name, one-paragraph description, rough scope boundary.

Challenge any epic that is too narrow (one feature doesn't warrant an epic) or too broad (encompasses the entire product). Offer alternatives for contestable boundaries.

Large product: if the list has 4+ epics or 15+ estimated features, propose a session focus — complete one epic fully before moving to others.

Ask: "Does this epic structure reflect how you think about the product?"

Do NOT advance to Step 4 until the epic list is confirmed.

Immediately after confirmation:

1. Create .lattice/requirements/, .lattice/requirements/epics/, and .lattice/requirements/features/ if they do not exist.
2. Write one .lattice/requirements/epics/{epic-slug}.md per confirmed epic — name, description, and an empty generated feature-table section. Read references/output-templates.md for the exact structure. Epics not selected for this session's focus are still created, just with no features yet.
3. Write .lattice/requirements/index.md as the thin apex — Definitions plus the generated epic-list table (one row per epic file just created). Read references/output-templates.md for the exact structure.
4. Ensure .lattice/config.yaml has requirements_layout: sharded. Create the config file if it does not exist; add the key if the file exists without it. Never overwrite an existing sharded value.

STOP: do not write feature tables into index.md or hand-append rows to an epic file at any point — see Step 6.

---

Step 4: Feature Discovery (per epic)

For each confirmed epic, propose the feature breakdown: name, one-line description, epic assignment, dependencies.

Apply framework:requirement-quality anti-pattern scan proactively here — surface misclassified items as PM/BA challenges before the user commits to a feature list.

Ask: "Does this feature breakdown feel right for [Epic Name]?"

This step is conversational only — nothing is written to disk until Step 5.

Do NOT advance to Step 5 until the feature list for every in-scope epic is confirmed.

---

Step 5: Feature Spec (per feature)

Work through confirmed features one at a time.

Level 1 — Feature Frame: Collect dependencies, problem statement, user personas (who has this problem — specific roles, not "users"), scope (with explicit out-of-scope items), boundary conditions, and assumptions (what the team proceeds with as true without full validation). Challenge each field: wrong problem, wrong user, inflated scope. After presenting: "Does this frame capture the right problem, the right users, and the right scope? Let's lock this before scenarios."

Do NOT begin scenarios until the frame is confirmed.

Level 2 — Scenarios: Spec scenarios one at a time in implementation order. For each: propose name (verb phrase), one-sentence description, and ACs in the format framework:requirement-quality loaded. After the first success-path scenario, probe: "Where's the failure path? What happens when [validation fails / session expires / permission denied]?"

After all scenarios: "Does this fully cover [Feature Name]? Anything missed?"

Do NOT begin implementation slices until all scenarios are confirmed.

After scenarios confirmed: propose 2–5 implementation slices in "what" order. "Here's how I'd sequence building this: [list]. Does this feel right?"

Do NOT write the feature file until implementation slices are confirmed.

Apply framework:requirement-quality Self-Validation Checklist and Anti-Pattern Scan before writing. Failures → fix. Ambiguity signals → surface via framework:collaborative-judgment.

Populate depends_on in frontmatter from any dependencies identified in Step 4 (Feature Discovery).

Write the confirmed feature file to .lattice/requirements/features/{feature-name}.md. Read references/output-templates.md for the exact file structure. Create the features/ directory if it does not exist.

Do NOT advance to the next feature until the current feature passes checks and is written.

---

Step 6: Refresh Generated Views

After all features for the current session scope are confirmed and written, regenerate the derived sections — never hand-edit them:

• For each epic touched this session: regenerate epics/{epic-slug}.md's feature table by scanning every features/*.md file where epic matches, listing feature name and one-line summary only. Do not read or mirror status, priority, or depends_on — those fields live only in the feature file. Replace only the content between the generated-section boundary comments — leave the hand-authored header, Source Materials, and Deferred Items untouched.
• Regenerate index.md's epic-list table the same way, scanning epics/*.md headers.
• STOP: this regeneration is triggered only by a feature being added, removed, or renamed under an epic in this session — never by a status, priority, or dependency change alone. A feature's own status/priority/depends_on edit is a single-file write with no downstream regeneration.
• Hand-authored additions (not generated, appended directly to the relevant epic file):
  • If source documents were provided during intake, add/update a ## Source Materials table mapping each document to the features derived from it.
  • Add a ## Deferred Items section listing content intentionally excluded from the current feature set, with reasons.
• If standards include §10 Domain Terminology, include a ## Glossary section in index.md populated from those terms (hand-authored, not regenerated — revisit only when terminology changes).

Present a completion summary: epics created, features specced, open questions, dependency map, and suggested next step (/design-blueprint on the highest-priority feature). Do not write the feature file's Design: link here — design-blueprint writes it when a design session starts.

---

Autonomous Mode

Phase 1 — Silent run (Steps 2–5): No confirmation gates. Log every non-obvious decision (granularity restructuring, contradiction resolutions, epic boundary calls). Format: "Decision: [what]. Reason: [why]."

Pause only for genuine blockers — situations where continuing would produce a fundamentally wrong spec:

• Contradictory inputs with no reasonable resolution (two documents disagree on who the user is)
• Missing domain knowledge that cannot be inferred (the molecule cannot determine which of two plausible interpretations is correct)
• Scope so ambiguous that two equally valid epic structures exist with different feature decompositions

Do NOT pause for: naming choices, priority assignments, scope boundary judgment calls, or AC wording. Make the best call and log the decision.

Phase 2 — Review: Present the decisions log first, then the epic list, then the feature list per epic, then feature specs one by one. User corrects, adds, or removes.

Phase 3 — Write: After confirmation, write all files. framework:requirement-quality checks run before each write.