substrate-ai 0.1.21 → 0.1.22

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,59 @@
1
+ # BMAD Stories Step 1: Epic Design
2
+
3
+ ## Context (pre-assembled by pipeline)
4
+
5
+ ### Requirements (from Planning Phase)
6
+ {{requirements}}
7
+
8
+ ### Architecture Decisions (from Solutioning Phase)
9
+ {{architecture_decisions}}
10
+
11
+ ---
12
+
13
+ ## Mission
14
+
15
+ Design the **epic structure** — high-level groupings of work organized by user value, with explicit mapping to functional requirements. This ensures full FR coverage before diving into story details.
16
+
17
+ ## Instructions
18
+
19
+ 1. **Organize epics by user value, never by technical layer:**
20
+ - GOOD: "User Authentication & Onboarding", "Dashboard & Analytics"
21
+ - BAD: "Database Setup", "API Development", "Frontend Components"
22
+ - Each epic must be independently valuable
23
+ - No forward dependencies — Epic N should not require Epic N+1
24
+
25
+ 2. **Map FRs to epics:**
26
+ - Use `fr_coverage` to list which functional requirements each epic addresses
27
+ - Every FR from the planning phase must appear in at least one epic's coverage
28
+ - This creates traceability before detailed story writing begins
29
+
30
+ 3. **Keep descriptions focused:**
31
+ - Each epic's description should explain the user value it delivers
32
+ - Include enough context for story generation in the next step
33
+
34
+ ## Output Contract
35
+
36
+ Emit ONLY this YAML block as your final output — no other text.
37
+
38
+ **CRITICAL**: All string values MUST be quoted with double quotes.
39
+
40
+ ```yaml
41
+ result: success
42
+ epics:
43
+ - title: "User Onboarding and Habit Management"
44
+ description: "Core habit tracking functionality that delivers immediate user value"
45
+ fr_coverage:
46
+ - "FR-0"
47
+ - "FR-1"
48
+ - title: "Analytics and Streak Visualization"
49
+ description: "Insight features that motivate continued usage"
50
+ fr_coverage:
51
+ - "FR-2"
52
+ - "FR-3"
53
+ ```
54
+
55
+ If you cannot produce valid output:
56
+
57
+ ```yaml
58
+ result: failed
59
+ ```
@@ -0,0 +1,78 @@
1
+ # BMAD Stories Step 2: Story Generation
2
+
3
+ ## Context (pre-assembled by pipeline)
4
+
5
+ ### Epic Structure (from Step 1)
6
+ {{epic_structure}}
7
+
8
+ ### Requirements (from Planning Phase)
9
+ {{requirements}}
10
+
11
+ ### Architecture Decisions (from Solutioning Phase)
12
+ {{architecture_decisions}}
13
+
14
+ ---
15
+
16
+ ## Mission
17
+
18
+ Expand the epic structure into **implementation-ready stories** with acceptance criteria. Each story should be sized for a single developer in 1-3 days.
19
+
20
+ ## Instructions
21
+
22
+ 1. **Write implementation-ready stories:**
23
+ - `key`: Short identifier like "1-1" or "2-3" (epic number - story number)
24
+ - `title`: Clear, action-oriented (e.g., "User registration with email verification")
25
+ - `description`: What the developer needs to build and why. Include enough context to start coding.
26
+ - `acceptance_criteria`: Specific, testable conditions. Minimum 1 per story. Use concrete language.
27
+ - `priority`: must (MVP-critical), should (high-value post-MVP), could (nice-to-have)
28
+
29
+ 2. **Ensure full FR coverage:**
30
+ - The epic structure from Step 1 maps FRs to epics — generate stories that fulfill each FR
31
+ - Cross-reference: every FR should be covered by at least one story's acceptance criteria
32
+
33
+ 3. **Respect architecture decisions:**
34
+ - Stories should reference the chosen tech stack and patterns
35
+ - If architecture specifies a project structure, Epic 1 Story 1 should be project scaffolding
36
+
37
+ 4. **Size stories appropriately:**
38
+ - Each story completable by one developer in 1-3 days
39
+ - If too large, split into multiple stories within the same epic
40
+ - If an epic has more than 8 stories, consider if the epic should be split
41
+
42
+ ## Output Contract
43
+
44
+ Emit ONLY this YAML block as your final output — no other text.
45
+
46
+ **CRITICAL YAML RULES**:
47
+ - All string values MUST be quoted with double quotes.
48
+ - Acceptance criteria must be plain English descriptions — NO code snippets, function calls, or special characters inside strings.
49
+ - BAD: `- "convertMarkdown('# hello') returns '<h1>hello</h1>'"` (embedded quotes break YAML)
50
+ - GOOD: `- "Converting a heading produces the correct HTML h1 tag"`
51
+
52
+ ```yaml
53
+ result: success
54
+ epics:
55
+ - title: "User Onboarding and Habit Management"
56
+ description: "Core habit tracking functionality that delivers immediate user value"
57
+ stories:
58
+ - key: "1-1"
59
+ title: "Project scaffolding and CLI setup"
60
+ description: "Initialize the project with TypeScript, Commander, and SQLite"
61
+ acceptance_criteria:
62
+ - "CLI binary runs and shows help text"
63
+ - "SQLite database is created on first run"
64
+ priority: must
65
+ - key: "1-2"
66
+ title: "Register and list habits"
67
+ description: "Users can create habits and view all tracked habits"
68
+ acceptance_criteria:
69
+ - "habit add command creates a new habit"
70
+ - "habit list command shows all habits with status"
71
+ priority: must
72
+ ```
73
+
74
+ If you cannot produce valid output:
75
+
76
+ ```yaml
77
+ result: failed
78
+ ```