# Requirement Forge > 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'. - Skill: `techygarg/requirement-forge` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add techygarg/requirement-forge` - Raw SKILL.md: https://api.skillmd.com/api/skills/techygarg/requirement-forge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: techygarg (https://skillmd.com/u/techygarg) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/techygarg/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` 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 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` named for the feature area (confirm the name with the user), and the thin `index.md` pointing to it, same as Step 3's write sequence. **STOP:** 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?"* **STOP:** 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. **STOP:** 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."* **STOP:** 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?"* **STOP:** 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?"* **STOP:** 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 the frontmatter**: `depends_on` from dependencies identified in Step 4 (Feature Discovery); `personas` from Level 1; `source_docs` from intake documents; `priority` using the notation from the loaded standards — surface it for the user's decision per `framework:requirement-quality` Ambiguity Signals, never assign silently. 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. **STOP:** 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 — including priority, which is assigned autonomously using the loaded standards' notation and reviewed in Phase 2. **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, then run Step 6 to regenerate the derived views. `framework:requirement-quality` checks run before each write.