requirement-forge-refiner

Name: requirement-forge-refiner
Author: techygarg

165stars12forks

How to install requirement-forge-refiner?

techygarg/lattice/requirement-forge-refiner

$npx -y skills add techygarg/lattice --skill requirement-forge-refiner

Installs into the current project.

Summary

Facilitate a structured conversation to define requirement standards for a project — epic and feature definitions, scenario structure, AC format, priority notation, status workflow, and naming conventions. Produces a formal requirement-standards.md that the requirement-quality at

Files · 1

View on GitHub

SKILL.md

1	# Requirement Forge Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/requirement-standards.md` (or custom path from `.lattice/config.yaml` → `paths.requirement_standards`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the built-in defaults. The `requirement-quality` atom reads its embedded `defaults.md` first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams whose product process differs fundamentally from the defaults.
9	- Default mode: Overlay — produces only what the team wants to change
10	- Config key: `paths.requirement_standards` in `.lattice/config.yaml`
11	- Consumed by: `requirement-quality` atom (via config resolution) → `requirement-forge` molecule (composes the atom)
12	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
13
14	## Scope Clarification
15
16	This refiner defines how requirements are structured and expressed for this project. It does not define:
17
18	- What to build (that is the requirement-forge molecule's job)
19	- Architecture or technical design (that is the architecture-refiner's job)
20	- Domain modeling patterns (that is the ddd-refiner's job)
21
22	The standards produced here answer: what is an epic, what is a feature, what is a scenario, how are ACs written, how are features named and prioritized. These are the rules the `requirement-quality` atom enforces — the molecule composes the atom and inherits those rules automatically.
23
24	## Before You Begin
25
26	### Check for an existing standards document
27
28	1. Read `.lattice/config.yaml` — check `paths.requirement_standards`.
29	2. If the path exists, read that file. Ask the user:
30	- "You already have a requirement standards document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
31	- Revise: load the existing document, walk through only the sections the user wants to change, update in place.
32	- Start fresh: proceed with the full interview flow below.
33	- Add to it: skip to the "New Sections" part of the interview.
34	3. If no config or no existing document, proceed with the full interview.
35
36	### Ask two orienting questions first
37
38	Before the formal interview, ask:
39
40	1. "Does your team already have a way of writing requirements — any existing PRDs, Confluence templates, or Jira conventions I should be aware of?"
41	2. "Is there a specific product domain or terminology I should know before we define the standards?"
42
43	These two questions are the only free-form listening before the structured interview begins. Synthesize what you hear and carry it forward — do not ask follow-up questions at this stage.
44
45	## Choosing the Mode
46
47	Present the three options:
48
49	"How would you like to define your requirement standards?
50
51	1. Customize specific sections (overlay) — Keep the built-in defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
52	2. Define everything from scratch (override) — Walk through all sections and produce a comprehensive standalone document.
53	3. Add project-specific sections only (overlay with additions) — Keep all defaults as-is and add new sections, such as domain terminology or custom status workflows.
54
55	The built-in defaults cover standard product spec practices well. Option 1 is recommended unless your team's conventions are fundamentally different."
56
57	Map the choice:
58	- Options 1 and 3 → `mode: overlay`
59	- Option 2 → `mode: override`
60
61	## Facilitation Approach
62
63	### Conversation style
64
65	- One section at a time. Do not present all questions at once. Walk through the template sequentially.
66	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read defaults verbatim — summarize key points and ask.
67	- Propose, don't just ask. When the user's answer is ambiguous, propose the most reasonable interpretation and ask them to confirm or correct. "It sounds like you want MoSCoW priorities — so 'Must', 'Should', 'Could', 'Won't'. Is that right?"
68	- Record decisions, not discussion. The o

People who liked this also viewed

6 picks

Type

requirement-forge-refiner

165stars12forks

View on GitHub

How to install requirement-forge-refiner?

techygarg/lattice/requirement-forge-refiner

$npx -y skills add techygarg/lattice --skill requirement-forge-refiner

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Requirement Forge Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/requirement-standards.md` (or custom path from `.lattice/config.yaml` → `paths.requirement_standards`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the built-in defaults. The `requirement-quality` atom reads its embedded `defaults.md` first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams whose product process differs fundamentally from the defaults.
9	- Default mode: Overlay — produces only what the team wants to change
10	- Config key: `paths.requirement_standards` in `.lattice/config.yaml`
11	- Consumed by: `requirement-quality` atom (via config resolution) → `requirement-forge` molecule (composes the atom)
12	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
13
14	## Scope Clarification
15
16	This refiner defines how requirements are structured and expressed for this project. It does not define:
17
18	- What to build (that is the requirement-forge molecule's job)
19	- Architecture or technical design (that is the architecture-refiner's job)
20	- Domain modeling patterns (that is the ddd-refiner's job)
21
22	The standards produced here answer: what is an epic, what is a feature, what is a scenario, how are ACs written, how are features named and prioritized. These are the rules the `requirement-quality` atom enforces — the molecule composes the atom and inherits those rules automatically.
23
24	## Before You Begin
25
26	### Check for an existing standards document
27
28	1. Read `.lattice/config.yaml` — check `paths.requirement_standards`.
29	2. If the path exists, read that file. Ask the user:
30	- "You already have a requirement standards document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
31	- Revise: load the existing document, walk through only the sections the user wants to change, update in place.
32	- Start fresh: proceed with the full interview flow below.
33	- Add to it: skip to the "New Sections" part of the interview.
34	3. If no config or no existing document, proceed with the full interview.
35
36	### Ask two orienting questions first
37
38	Before the formal interview, ask:
39
40	1. "Does your team already have a way of writing requirements — any existing PRDs, Confluence templates, or Jira conventions I should be aware of?"
41	2. "Is there a specific product domain or terminology I should know before we define the standards?"
42
43	These two questions are the only free-form listening before the structured interview begins. Synthesize what you hear and carry it forward — do not ask follow-up questions at this stage.
44
45	## Choosing the Mode
46
47	Present the three options:
48
49	"How would you like to define your requirement standards?
50
51	1. Customize specific sections (overlay) — Keep the built-in defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
52	2. Define everything from scratch (override) — Walk through all sections and produce a comprehensive standalone document.
53	3. Add project-specific sections only (overlay with additions) — Keep all defaults as-is and add new sections, such as domain terminology or custom status workflows.
54
55	The built-in defaults cover standard product spec practices well. Option 1 is recommended unless your team's conventions are fundamentally different."
56
57	Map the choice:
58	- Options 1 and 3 → `mode: overlay`
59	- Option 2 → `mode: override`
60
61	## Facilitation Approach
62
63	### Conversation style
64
65	- One section at a time. Do not present all questions at once. Walk through the template sequentially.
66	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read defaults verbatim — summarize key points and ask.
67	- Propose, don't just ask. When the user's answer is ambiguous, propose the most reasonable interpretation and ask them to confirm or correct. "It sounds like you want MoSCoW priorities — so 'Must', 'Should', 'Could', 'Won't'. Is that right?"
68	- Record decisions, not discussion. The o

People who liked this also viewed

6 picks

Type