/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.

Additional Instructions

**STOP: Before Step 1, read `additional_instructions.requirement_forge` (one line or a list) from `.lattice/config.yaml`.** No file or no key → skip silently.

When lines are found:

1. Show them verbatim under "Additional instructions (from config):". 2. **Highest priority — apply them for the whole session, including on resume.** On any conflict with anything else in this skill — steps, gates, STOP rules — or with its Required Skills, standards documents, or operational learnings, the config line wins.

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` or set to `flat`: 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 (→ re-enter Step 5 for that file), skip, or move to another (record the decision and continue the inventory).
• **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.

**STOP:** 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 t