From architect
Create domain stories using Domain Storytelling technique to visualize business processes. /architect:create-domain-story [--domain=<name>] [--auto] to invoke. Recommended prerequisite: redesign output. Supports interactive facilitation or auto-generation mode.
How this skill is triggered — by the user, by Claude, or both
Slash command
/architect:create-domain-storyopusThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Visualize the business process of a specific domain as a narrative using the Domain Storytelling technique. The story is expressed in three elements:
Visualize the business process of a specific domain as a narrative using the Domain Storytelling technique. The story is expressed in three elements:
Generate one domain story per domain, with a Mermaid sequence diagram and narrative prose.
/architect:create-domain-story [--domain=<DomainName>] [--auto]
--domain — Target domain name (e.g., Order, Inventory, Payment). Prompted interactively if omitted.--auto — Skip facilitation and generate automatically from existing analysis files.Facilitate a 7-stage process through dialogue with the user to elicit the domain story:
Stage 1 — Setting the Scene Ask the user:
--domain was not specified)?Stage 2 — Actors
Identify actors from actors-roles-permissions.md and present them for confirmation:
Stage 3 — Work Items Identify work items (data, documents, domain objects) relevant to the domain:
ubiquitous-language.md for domain term alignmentStage 4 — Main Flow Walk through the main (happy path) flow step by step:
Stage 5 — Exception Scenarios Identify alternative and error flows:
Stage 6 — Technical Context Capture system constraints and technical elements:
Stage 7 — Review and Document Summarize the elicited story and confirm with the user:
--auto)Generate the story automatically from existing analysis files without facilitation. Lower fidelity than interactive mode but suitable for bulk processing of multiple domains.
Steps:
reports/03_design/bounded-contexts-redesign.md — identify BC boundary and contained aggregatesreports/01_analysis/actors-roles-permissions.md — extract actorsreports/01_analysis/ubiquitous-language.md — build a term lookup table from the "Domain Term" column (localized when output_language is not "en", e.g. "業務用語" for ja)| File | Required/Recommended | Source |
|---|---|---|
| reports/03_design/bounded-contexts-redesign.md | Recommended | /architect:redesign |
| reports/01_analysis/ubiquitous-language.md | Recommended | /architect:analyze |
| reports/01_analysis/actors-roles-permissions.md | Recommended | /architect:analyze |
If none of these files exist, ask the user to provide domain context directly.
| File | Content |
|---|---|
reports/04_stories/domain-story-{domain}.md | Domain story — actors, work items, activity flow, Mermaid diagram, exception notes |
{domain} is the kebab-case domain name (e.g., order, inventory, payment).
Write all story content in the language configured in work/pipeline-progress.json (options.output_language). The YAML frontmatter keys remain in English regardless of the output language.
---
title: "Domain Story: {Domain}"
schema_version: 1
phase: "Phase 4: Domain Stories"
skill: create-domain-story
generated_at: "ISO8601"
domain: "{domain}"
mode: "interactive|auto"
input_files:
- reports/03_design/bounded-contexts-redesign.md
- reports/01_analysis/actors-roles-permissions.md
- reports/01_analysis/ubiquitous-language.md
---
# Domain Story: {Domain}
## Story Overview
[2–3 sentence summary of what this story describes]
## Actors
| Actor | Type | Role in This Story |
|-------|------|--------------------|
| ... | Person / System / Role | ... |
## Work Items
| Work Item | Domain Term | Description |
|-----------|-------------|-------------|
| ... | ... | ... |
## Main Flow
[Narrative prose: numbered activity sequence describing the business process]
1. [Actor] [activity verb] [work item] → [recipient Actor/System]
2. ...
## Mermaid Diagram
```mermaid
sequenceDiagram
...
[Brief description of the exception path]
[Relevant system constraints, async boundaries, transaction considerations]
## Mermaid Diagram Guidelines
- Use `sequenceDiagram` for all domain stories
- Actor names: use the configured output language for display labels, English IDs for node identifiers
- Number each activity message to match the Main Flow numbering
- Keep to the main flow in the primary diagram; use a separate diagram block for major exceptions if needed
- Apply rules from @rules/mermaid-best-practices.md
Example structure:
```mermaid
sequenceDiagram
participant Customer as Customer
participant OrderSvc as Order Service
participant Inventory as Inventory
Customer->>OrderSvc: 1. Place order (Order)
OrderSvc->>Inventory: 2. Reserve items (Reservation)
Inventory-->>OrderSvc: 3. Confirm reservation
OrderSvc-->>Customer: 4. Order confirmed (Order ID)
reports/04_stories/domain-story-{domain}.mdubiquitous-language.md (if available)work/pipeline-progress.json if running as part of the pipeline| Skill | Relationship |
|---|---|
| /architect:analyze | Upstream — provides actors and ubiquitous language |
| /architect:redesign | Upstream — provides bounded context definitions |
| /architect:map-domains | Related — domain classification context |
| /architect:report | Downstream — stories can be included in the final HTML report |
npx claudepluginhub wfukatsu/nexus-architect --plugin scalardbGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.