| name | domain-story-seeder |
| description | Prepare a Domain Storytelling session by generating sample ("seed" or strawman) domain stories as text — numbered sentences in the actor → activity → work object grammar. Optionally derives them from a Wardley Map and/or a Capability Map: when the prompt doesn't already name a focus, the skill lists the map's components or capabilities and asks the user to pick up to three to center the stories on (the map itself is optional; a one-line domain description also works). Use whenever someone wants to seed, draft, generate, author, or prepare sample domain stories, kick off / warm up / prep a Domain Storytelling or event-storming-style workshop, turn a Wardley Map or Capability Map into a worked example scenario, or produce a numbered actor-action-work-object story to put in front of a room — even if they don't say "Domain Storytelling." This is the complement of interpreting a domain story: here you PRODUCE the story rather than read one. |
Domain Story Seeder
Domain Storytelling (Stefan Hofer & Henning Schwentner) captures a business
process as a concrete story in a tiny pictographic language: actors do
activities (verbs) on work objects (nouns, also called work items),
the sentences are numbered to fix the order, and groups cluster related
parts. This skill goes the generative direction: it writes such stories as
text to seed a workshop before anyone draws on the board.
Why seed stories at all
A Domain Storytelling session works best when the room has something concrete to
react to. A blank board is intimidating; a slightly-wrong strawman story is
easy — people correct it, and the corrections are exactly where the real domain
knowledge surfaces. So the job here is to produce plausible, concrete, honestly
labelled starter stories from whatever strategic artifacts already exist.
Hold onto two things:
- These stories are disposable scaffolding, not ground truth. Make them
concrete and plausible, label every inference, and frame the uncertain spots
as "is this really how it goes?" prompts for the room. Being a little wrong on
purpose is fine — it provokes the correction that teaches you the domain.
- A domain story is one concrete scenario in pure domain language — a single
happy path, present tense, no conditionals. The grammar is strict; honor
it or the output won't read as a domain story.
The grammar (this IS the output format)
Each numbered sentence:
<n> <Actor> <activity-verb> <work object> [linking-word <work object> ...]
- Actor — a person/role or a software system that acts. Always the
grammatical subject. One actor per sentence. (Dispatcher, Returning customer,
Billing system.)
- Activity — a single concrete present-tense verb (registers, books,
approves, picks, sends, confirms). Avoid vague verbs that hide the real action
(manages, handles, processes, does).
- Work object — the noun the activity acts on (Order, Invoice, Booking,
Route, Cup of tea).
- Linking words chain in more work objects and context: to, for, with,
from, via, at, in, into, about. → "Dispatcher assigns Order to Driver."
- Numbered to fix sequence. No conditionals, no loops, no branches. One
happy path. Alternatives and error cases become their own numbered story.
- Pure domain language — the words the business actually uses, not technical
jargon (unless the actor itself is a system).
Granularity — pick one level and stay consistent:
coarse (a handful of big steps; good for scoping a whole session) vs.
fine (every interaction; good for one bounded context). For session prep,
coarse-to-medium is usually right. State which you chose.
Workflow
Step 0 — Establish the inputs (all optional)
Inputs may be a Wardley Map, a Capability Map, both, or neither.
- If an artifact is provided (image or text), read it first and echo what you
found, so a misreading doesn't poison the story:
- Wardley Map → the anchor (user need) at the top, each component in
the value chain, and roughly where each sits on the evolution axis
(Genesis / Custom-built / Product / Commodity).
- Capability Map → the capabilities (stable "ability to do X" nouns),
their levels/hierarchy, and any core / supporting / generic marks.
- If nothing is provided, don't block — ask for a one-line description of the
domain or process, or proceed from whatever domain context the user has given.
A domain story can be seeded from a single sentence.
A light sanity check, not a critique. Seeding does not require a correct
map — a rough or even shaky map still seeds perfectly usable strawman stories,
and the workshop corrects the rest. So do not pause to evaluate the map's
quality. Only flag the blocking defects that would leave you nothing to seed
from, and when you see one, name it and offer the dedicated critic skill as an
optional off-ramp rather than attempting the critique yourself:
- Wardley Map with no anchor / user need, or one that's really a flow
diagram or org chart (position carries no meaning) → point to
wardley-map-critic.
- Capability Map whose entries are plainly processes, projects, or systems
rather than "ability to do X" capabilities → point to
capability-map-critic.
Phrase it as a choice ("this map looks shaky — want to pressure-test it with the
<critic> first, or shall I seed from it as-is?"), then proceed however the
user wants. Default to seeding; the off-ramp is the user's to take.
Step 1 — Pin down the focus (ask if the prompt didn't specify it)
A domain story is scenario-sized; a whole map is far too big for one story, so a
focus is required before you write. There are two cases:
(a) The prompt already names the focus (e.g. "seed a story for Ask Grandma
and Ask community", or "focus on the Claims assessment capability"). Use it
directly — don't ask again. Honor it even if it names more than three; the cap
in case (b) is only for your prompt to the user, not a limit on what they can
hand you.
(b) The prompt does not name a focus. Then you must ask — do not silently
default to a guess. Present the candidates and have the user pick at most
three:
- From a Wardley Map: offer up to ~three of the most story-worthy
components (and/or the anchor user need) as the options; the user may
select up to three components.
- From a Capability Map: offer the capabilities — lead with the core /
differentiating ones — as the options; the user may select up to three
capabilities.
Use the interactive option picker if available (a multi-select capped at three)
so it's a couple of taps. Keep the option list itself short — surface the
strongest few candidates rather than dumping every box on the map; you can note
that more exist. Only after the user picks (or, if they explicitly say "you
choose," after you pick the single most story-worthy candidate and say which and
why) do you proceed. With no map at all, focus on the process the user named;
if even that is missing, ask for a one-line description first (Step 0).
Seeding more than one focus is fine — treat each chosen capability/component as
its own spine and seed a story (plus variants) per focus, up to the three-pick
cap.
Step 2 — Mine the focus for story elements
Translate the chosen component(s) into Domain Storytelling elements.
Wardley Map → story elements
| Wardley element | Becomes in the story |
|---|
| Anchor (user need) | the primary actor and the goal the story drives toward |
| Component high in the chain (user-visible) | an activity the actor performs, on a work object |
| Component lower in the chain (supporting) | a work object, or a supporting actor/system the activity uses |
| Genesis / Custom-built component | usually a human activity done by hand — name the role doing it |
| Product / Commodity component | usually an external system actor providing a service ("Payment service confirms Payment") |
| A link in the value chain | a linking word ("via", "with", "from") joining two work objects |
Capability Map → story elements
| Capability element | Becomes in the story |
|---|
| A capability ("ability to do X") | one or more activities (the verb) on the work object that X implies |
| The actor who exercises it | the subject of those sentences (a role or a system) |
| Core / differentiating capability | the spine of the seed story — the scenario worth rehearsing |
| Supporting / generic capability | off-stage steps or system actors that serve the spine |
| Capability levels / hierarchy | candidate groups / bounded contexts if you seed more than one story |
Then trace the focus component's downstream links — this is where the best
variants hide. Don't stop at the focus component; follow the lines that run
down from it to the components it depends on, because those dependencies often
reveal that one visible activity can be fulfilled more than one way. The
sharpest case: a Custom human-activity sitting on top of an AI/automation
component (e.g. "Ask Grandma" depending on a "Specific AI" → "Gen AI"
component) almost always hides a human-vs-system fulfillment fork — the same
need answered by a person or by a system actor (an avatar/assistant). When the
dependency makes a component domain-visible (the user talks to the
avatar/assistant, not just through plumbing), promote it to a system actor in
the story; keep the deeper implementation components (Gen AI, Cloud) off the
page. Seed each branch of the fork as its own story in Step 4 — and the
escalation between them (avatar can't help → hand off to a human) is usually
the most valuable variant of all, because it's the real design decision the room
should make.
Step 3 — Write the seed story
Compose the numbered sentences for one concrete instance. Make it real:
prefer a concrete protagonist ("a returning customer", "a first-time rider")
and concrete objects. Keep strictly to one happy path. Six to twelve sentences
is plenty for a coarse story. Give the story a title naming the scenario and
its trigger ("Returning customer places a repeat order").
Step 4 — Add variants (optional, each its own story)
Because the grammar has no conditionals, seed the alternative paths and edge
cases the session should explore as separate short numbered stories ("…but
the item is out of stock", "…first-time customer with no account"). Offer one or
two; don't bury the main story. Any fulfillment fork you found in Step 2
(human path vs. system/avatar path, and the escalation from one to the other)
belongs here — each branch is its own story, and the escalation story is usually
the one worth leading the discussion with.
Step 5 — Hand-off notes for the facilitator
This is what turns a generated artifact into useful session fuel. Briefly list:
- Assumptions to confirm — every actor, verb, or ordering you guessed.
Be honest; these are the questions that will draw out real knowledge.
- Candidate groups / bounded contexts — suggested by capability levels or
value-chain clusters, if you seeded more than one story.
- Questions for the room — the deliberately uncertain spots. Name them.
Output template
Use this structure (drop sections that don't apply):
# Seed domain stories — <domain / focus>
## Source & focus
Which inputs were used; which component(s)/capability(ies) the story centers on; the granularity chosen.
## Story 1 — <scenario title>
1. <Actor> <verb> <work object> <linking-word> <work object> …
2. …
## Story 2 — <variant title> (optional)
1. …
## For the session
- Assumptions to confirm: …
- Candidate groups / bounded contexts: …
- Questions for the room: …
Quality checks before you hand it over
- No conditionals, no "if/when/unless", no loops — split branches into separate
stories instead.
- Active voice, present tense, the actor as subject of every sentence.
- Concrete, specific verbs — replace "manages/handles/processes" with the real
action.
- Domain language, not implementation. The Wardley/Capability inputs tell you
what and who, never how it's built — don't invent an architecture.
- Every guessed element shows up in "Assumptions to confirm." When in doubt
about the real business term, pick a plausible one and flag it.
References
references/worked-examples.md — four fully worked seeds (from a Wardley
Map, from a Capability Map, from a one-line description with no artifact at
all, and one that traces a downstream dependency to a human-vs-AI fulfillment
fork). Read it to pattern-match the mining tables onto real stories, especially
for how evolution stage picks human-vs-system actors, how a core capability
becomes the spine, and how following a component's downstream links surfaces
the best variant stories.
