X2 Stories
Define the problem domain with the human and produce the epic-level story set. This is the first of the
three gates: nothing is designed, seeded, or built until the stories are approved.
What you produce
- The owner's motivation, verbatim, first. Before any analysis, capture the owner's own
statement of why this product should exist, in their words, as a durable artifact. The problem
statement derives from that motivation and is evidenced by any reference material, never the
reverse: the third project's problem statement missed the centre twice because two sessions
worked from reference material alone while the motivation lived only in the owner's head.
- A handful of epic-level stories, one line each. Thin by design. Roles are human stakeholders
(developer, operator, end user), never "the system" or "an AI agent".
- Where the product's core is a novel domain behaviour (a method, a protocol, a way of working that
makes the product not a commodity), capture it as a behaviour spec. It is a domain source of
truth for the designer, not acceptance criteria and not screen design. It lands in the repo's
design/ directory once seed runs.
- A turn note for every human turn ideation costs (number, what, why a human was needed). These are
carried into the ledger the moment seed creates it.
Everything this skill produces has a named home once seed runs: the story set, the motivation
statement, the behaviour spec and any prior reference material land under design/; turn notes go
to the ledger under docs/work/. Nothing lands at the repo root: the kernel's docs-lint allowlists
that surface, and the third project had to relocate two governed files it had put there (record:
the placement finding, P3).
How to work the discovery
- Spend time on the problem before any solution talk. Challenge, reframe, think laterally; be a
thinking partner, not a yes-machine. Do not converge early.
- Aim for the minimal story set that captures the full problem. Prefer a shape with more than one
module, so the build exercises real seams.
- Propose candidate framings and let the human pick. They drive the choice.
- When the owner rejects the same framing twice, stop iterating in place: the context is anchored.
Restart the analysis in a fresh context from the primary sources (the motivation statement
first), carried across by a written handover, and apply nothing until the owner cuts. The third
project's centre was found exactly this way after two anchored sessions missed it.
Stress-testing the set
When the set looks settled and before gate 1 is requested, offer an adversarial stress test:
bounded, grounded in the story set, any reference material, and knowledge of comparable products;
hunting gaps and overlooked needs inside the current scope, never gold plating or new directions.
Before it runs, enumerate every role the story set names and confirm each role has its own lens
walking its journey end to end. The third project's stress test looked complete while omitting the
product's largest constituency, and only the owner caught it.
The story-prototype loop
Stories are dynamic. Owners iterate them heavily, and there is an entire loop from stories to UI
prototype and back that refines the set until acceptance: seeing the product's shape changes what
the owner knows they want. Gate 1 is therefore provisional until that loop settles. Re-approving a
revised set is a normal gate turn, not a breach; expect it, request it explicitly, and revise
D-000 before design reads it. The evidence: the second project's story set was its highest-churn
decision (14 post-approval revisits before settling through the prototype), and the churn was the
work, not a defect (record: NS-1).
Human-turn contract
- Requests gate 1: stories approved (the first MET-07 gate), taken when the story set is tight
and both sides agree. The gate blocks seed and everything after it. Each later revision requests
the gate again.
- The gate request is put in plain language, the owner's own words; method vocabulary rides
alongside, never instead (P3).
- Ideation turns are part of the measured flow and are logged.
What this skill must NOT produce
- No acceptance criteria and no behaviour lists for the UI. Those derive from the locked prototype
later; authoring them here was the pilot's turn 8 defect.
- No requirements document. The story set is recorded in D-000 by decompose; a second
requirements doc duplicating it was the pilot's turn 8b defect.
- No screens, no architecture, no code investigation, no file paths.
Next
Gate 1 on record, then seed.
1---2name: stories3description: Use when starting an X2 project, when the problem domain has no approved epic story set, or when new scope needs stories added to an existing set. Runs problem discovery and produces epic-level stories, then requests gate 1 (stories approved). Do not use to author acceptance criteria or a requirements document, and do not use for anything downstream of gate 1.4---56# X2 Stories78Define the problem domain with the human and produce the epic-level story set. This is the first of the9three gates: nothing is designed, seeded, or built until the stories are approved.1011## What you produce1213- **The owner's motivation, verbatim, first.** Before any analysis, capture the owner's own14 statement of why this product should exist, in their words, as a durable artifact. The problem15 statement derives from that motivation and is evidenced by any reference material, never the16 reverse: the third project's problem statement missed the centre twice because two sessions17 worked from reference material alone while the motivation lived only in the owner's head.18- A handful of epic-level stories, one line each. Thin by design. Roles are human stakeholders19 (developer, operator, end user), never "the system" or "an AI agent".20- Where the product's core is a novel domain behaviour (a method, a protocol, a way of working that21 makes the product not a commodity), capture it as a behaviour spec. It is a domain source of22 truth for the designer, not acceptance criteria and not screen design. It lands in the repo's23 `design/` directory once seed runs.24- A turn note for every human turn ideation costs (number, what, why a human was needed). These are25 carried into the ledger the moment seed creates it.2627Everything this skill produces has a named home once seed runs: the story set, the motivation28statement, the behaviour spec and any prior reference material land under `design/`; turn notes go29to the ledger under `docs/work/`. Nothing lands at the repo root: the kernel's docs-lint allowlists30that surface, and the third project had to relocate two governed files it had put there (record:31the placement finding, P3).3233## How to work the discovery3435- Spend time on the problem before any solution talk. Challenge, reframe, think laterally; be a36 thinking partner, not a yes-machine. Do not converge early.37- Aim for the minimal story set that captures the full problem. Prefer a shape with more than one38 module, so the build exercises real seams.39- Propose candidate framings and let the human pick. They drive the choice.40- When the owner rejects the same framing twice, stop iterating in place: the context is anchored.41 Restart the analysis in a fresh context from the primary sources (the motivation statement42 first), carried across by a written handover, and apply nothing until the owner cuts. The third43 project's centre was found exactly this way after two anchored sessions missed it.4445## Stress-testing the set4647When the set looks settled and before gate 1 is requested, offer an adversarial stress test:48bounded, grounded in the story set, any reference material, and knowledge of comparable products;49hunting gaps and overlooked needs inside the current scope, never gold plating or new directions.50Before it runs, enumerate every role the story set names and confirm each role has its own lens51walking its journey end to end. The third project's stress test looked complete while omitting the52product's largest constituency, and only the owner caught it.5354## The story-prototype loop5556Stories are dynamic. Owners iterate them heavily, and there is an entire loop from stories to UI57prototype and back that refines the set until acceptance: seeing the product's shape changes what58the owner knows they want. Gate 1 is therefore provisional until that loop settles. Re-approving a59revised set is a normal gate turn, not a breach; expect it, request it explicitly, and revise60D-000 before design reads it. The evidence: the second project's story set was its highest-churn61decision (14 post-approval revisits before settling through the prototype), and the churn was the62work, not a defect (record: NS-1).6364## Human-turn contract6566- Requests **gate 1: stories approved** (the first MET-07 gate), taken when the story set is tight67 and both sides agree. The gate blocks seed and everything after it. Each later revision requests68 the gate again.69- The gate request is put in plain language, the owner's own words; method vocabulary rides70 alongside, never instead (P3).71- Ideation turns are part of the measured flow and are logged.7273## What this skill must NOT produce7475- No acceptance criteria and no behaviour lists for the UI. Those derive from the locked prototype76 later; authoring them here was the pilot's turn 8 defect.77- No requirements document. The story set is recorded in D-000 by decompose; a second78 requirements doc duplicating it was the pilot's turn 8b defect.79- No screens, no architecture, no code investigation, no file paths.8081## Next8283Gate 1 on record, then seed.
teklabsdigital