substrate-ai 0.1.20 → 0.1.22

package/packs/bmad/prompts/planning-step-3-nfrs.md

@@ -0,0 +1,75 @@
+# BMAD Planning Step 3: NFRs, Tech Stack, Domain Model & Scope
+
+## Context (pre-assembled by pipeline)
+
+### Product Brief (from Analysis Phase)
+{{product_brief}}
+
+### Project Classification (from Step 1)
+{{classification}}
+
+### Functional Requirements (from Step 2)
+{{functional_requirements}}
+
+---
+
+## Mission
+
+Complete the PRD by defining **non-functional requirements**, **tech stack**, **domain model**, and **out-of-scope items**. These constrain HOW the system is built and what it explicitly does NOT do.
+
+## Instructions
+
+1. **Define non-functional requirements:**
+   - Each NFR must have a category (performance, security, scalability, accessibility, reliability)
+   - Be concrete: "API responses under 200ms at p95" not "System should be fast"
+   - Minimum 2 NFRs covering different categories
+   - NFRs should align with the project type and constraints
+
+2. **Specify the tech stack:**
+   - Key-value pairs mapping technology concerns to specific choices
+   - Use real, current technologies — do not fabricate frameworks
+   - Cover at minimum: language, framework, database, testing
+   - Choices should align with the product brief constraints
+
+3. **Build the domain model:**
+   - Key entities and their relationships
+   - Each entity as a key with its attributes/relationships as the value
+   - This informs database design and API structure downstream
+
+4. **Define out-of-scope items** to prevent scope creep — what this product explicitly does NOT do.
+
+## Output Contract
+
+Emit ONLY this YAML block as your final output — no other text.
+
+**CRITICAL**: All string values MUST be quoted with double quotes.
+
+```yaml
+result: success
+non_functional_requirements:
+  - description: "CLI commands complete within 200ms for local operations"
+    category: "performance"
+  - description: "All user data encrypted at rest using AES-256"
+    category: "security"
+tech_stack:
+  language: "TypeScript"
+  framework: "Node.js CLI with Commander"
+  database: "SQLite via better-sqlite3"
+  testing: "Vitest"
+domain_model:
+  Habit:
+    attributes: ["name", "frequency", "created_at"]
+    relationships: ["has_many: Completions"]
+  Completion:
+    attributes: ["habit_id", "completed_at"]
+    relationships: ["belongs_to: Habit"]
+out_of_scope:
+  - "Web or mobile interface"
+  - "Cloud sync or multi-device support"
+```
+
+If you cannot produce valid output:
+
+```yaml
+result: failed
+```

package/packs/bmad/prompts/stories-step-1-epics.md

@@ -0,0 +1,59 @@
+# BMAD Stories Step 1: Epic Design
+
+## Context (pre-assembled by pipeline)
+
+### Requirements (from Planning Phase)
+{{requirements}}
+
+### Architecture Decisions (from Solutioning Phase)
+{{architecture_decisions}}
+
+---
+
+## Mission
+
+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.
+
+## Instructions
+
+1. **Organize epics by user value, never by technical layer:**
+   - GOOD: "User Authentication & Onboarding", "Dashboard & Analytics"
+   - BAD: "Database Setup", "API Development", "Frontend Components"
+   - Each epic must be independently valuable
+   - No forward dependencies — Epic N should not require Epic N+1
+
+2. **Map FRs to epics:**
+   - Use `fr_coverage` to list which functional requirements each epic addresses
+   - Every FR from the planning phase must appear in at least one epic's coverage
+   - This creates traceability before detailed story writing begins
+
+3. **Keep descriptions focused:**
+   - Each epic's description should explain the user value it delivers
+   - Include enough context for story generation in the next step
+
+## Output Contract
+
+Emit ONLY this YAML block as your final output — no other text.
+
+**CRITICAL**: All string values MUST be quoted with double quotes.
+
+```yaml
+result: success
+epics:
+  - title: "User Onboarding and Habit Management"
+    description: "Core habit tracking functionality that delivers immediate user value"
+    fr_coverage:
+      - "FR-0"
+      - "FR-1"
+  - title: "Analytics and Streak Visualization"
+    description: "Insight features that motivate continued usage"
+    fr_coverage:
+      - "FR-2"
+      - "FR-3"
+```
+
+If you cannot produce valid output:
+
+```yaml
+result: failed
+```

package/packs/bmad/prompts/stories-step-2-stories.md

@@ -0,0 +1,78 @@
+# BMAD Stories Step 2: Story Generation
+
+## Context (pre-assembled by pipeline)
+
+### Epic Structure (from Step 1)
+{{epic_structure}}
+
+### Requirements (from Planning Phase)
+{{requirements}}
+
+### Architecture Decisions (from Solutioning Phase)
+{{architecture_decisions}}
+
+---
+
+## Mission
+
+Expand the epic structure into **implementation-ready stories** with acceptance criteria. Each story should be sized for a single developer in 1-3 days.
+
+## Instructions
+
+1. **Write implementation-ready stories:**
+   - `key`: Short identifier like "1-1" or "2-3" (epic number - story number)
+   - `title`: Clear, action-oriented (e.g., "User registration with email verification")
+   - `description`: What the developer needs to build and why. Include enough context to start coding.
+   - `acceptance_criteria`: Specific, testable conditions. Minimum 1 per story. Use concrete language.
+   - `priority`: must (MVP-critical), should (high-value post-MVP), could (nice-to-have)
+
+2. **Ensure full FR coverage:**
+   - The epic structure from Step 1 maps FRs to epics — generate stories that fulfill each FR
+   - Cross-reference: every FR should be covered by at least one story's acceptance criteria
+
+3. **Respect architecture decisions:**
+   - Stories should reference the chosen tech stack and patterns
+   - If architecture specifies a project structure, Epic 1 Story 1 should be project scaffolding
+
+4. **Size stories appropriately:**
+   - Each story completable by one developer in 1-3 days
+   - If too large, split into multiple stories within the same epic
+   - If an epic has more than 8 stories, consider if the epic should be split
+
+## Output Contract
+
+Emit ONLY this YAML block as your final output — no other text.
+
+**CRITICAL YAML RULES**:
+- All string values MUST be quoted with double quotes.
+- Acceptance criteria must be plain English descriptions — NO code snippets, function calls, or special characters inside strings.
+- BAD: `- "convertMarkdown('# hello') returns '<h1>hello</h1>'"` (embedded quotes break YAML)
+- GOOD: `- "Converting a heading produces the correct HTML h1 tag"`
+
+```yaml
+result: success
+epics:
+  - title: "User Onboarding and Habit Management"
+    description: "Core habit tracking functionality that delivers immediate user value"
+    stories:
+      - key: "1-1"
+        title: "Project scaffolding and CLI setup"
+        description: "Initialize the project with TypeScript, Commander, and SQLite"
+        acceptance_criteria:
+          - "CLI binary runs and shows help text"
+          - "SQLite database is created on first run"
+        priority: must
+      - key: "1-2"
+        title: "Register and list habits"
+        description: "Users can create habits and view all tracked habits"
+        acceptance_criteria:
+          - "habit add command creates a new habit"
+          - "habit list command shows all habits with status"
+        priority: must
+```
+
+If you cannot produce valid output:
+
+```yaml
+result: failed
+```