From lattice
Generates structured feature specifications via collaborative PM/BA interview. Challenges scope, proposes options at decisions, outputs epic/feature hierarchy in .lattice/requirements/.
npx claudepluginhub techygarg/lattice --plugin latticeThis skill uses the workspace's default tool permissions.
Read and apply in order:
Writes structured feature specs or PRDs from problem statements or ideas. Covers problem, goals/non-goals, user stories, prioritized requirements, and success metrics.
Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format requirements, acceptance criteria, and implementation checklists. Use for defining new features or gathering requirements.
Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format requirements, acceptance criteria, and implementation checklists. Use for defining new features or gathering requirements.
Share bugs, ideas, or general feedback.
Read and apply in order:
framework:requirement-quality — load requirement standards and enforce spec quality throughout (always)framework:collaborative-judgment — surface genuine judgment calls instead of silent assumptions (always)framework:knowledge-priming — ground feature language in actual project domain (conditional: skip if no codebase exists yet)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.
Behave as an experienced senior PM and business analyst. This governs the HOW of the conversation — quality enforcement is framework:requirement-quality's job.
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.
index.md exists → read it, inventory all feature files. Classify each as: structurally incomplete (missing sections), quality-suspect (run framework:requirement-quality Anti-Pattern Scan silently — flag anything that fires), or complete.Do NOT advance to Step 2 until all resume decisions are recorded.
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:
index.md 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. Write a placeholder index.md with a single epic before starting Step 5 so the structure exists from the start.
Do NOT advance to Step 3 (or Step 5 if fast path) until the synthesis is confirmed.
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, write .lattice/requirements/index.md with the confirmed epics — names, descriptions, and empty feature tables. Create .lattice/requirements/ if it does not exist. Read references/output-templates.md for the exact structure. Epics not selected for this session's focus are listed as planned with no feature rows. This establishes the skeleton before any feature work begins — if the session ends early, the epic structure is preserved.
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. Do not wait for Step 5 to catch granularity problems and technical tasks masquerading as features.
Ask: "Does this feature breakdown feel right for [Epic Name]?"
After confirming each epic's feature list, update index.md — add the confirmed feature rows (name, one-line summary, status draft, priority, dependencies) under that epic's table. The index grows incrementally as each epic's features are confirmed.
Do NOT advance to Step 5 until the feature list for every in-scope epic is confirmed and written to index.md.
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). Apply the PM/BA challenge lens to each field. 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.
After all features for the current session scope are confirmed and written, do a final update to .lattice/requirements/index.md:
depends_on cross-references discovered during feature spec that were not visible at Step 4## Glossary section populated from those terms## Source Materials table mapping each document to the features derived from it, and a ## Deferred Items section listing content intentionally excluded from the current feature set with reasonsPresent a completion summary: epics created, features specced, open questions, dependency map, and suggested next step (/design-blueprint on the highest-priority feature). Note that when design-blueprint runs on a feature, it will create a context anchor doc linked back to the requirement file — the Design: link in the feature file should be updated at that point.
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:
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.