@comfanion/workflow 4.36.65 → 4.36.67
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.
- package/package.json +1 -1
- package/src/build-info.json +2 -2
- package/src/opencode/FLOW.yaml +6 -1
- package/src/opencode/agents/analyst.md +1 -1
- package/src/opencode/agents/dev.md +3 -4
- package/src/opencode/agents/pm.md +30 -5
- package/src/opencode/package.json +1 -1
- package/src/opencode/skills/architecture-design/SKILL.md +126 -0
- package/src/opencode/skills/epic-writing/SKILL.md +87 -0
- package/src/opencode/skills/prd-writing/SKILL.md +243 -3
- package/src/opencode/skills/prd-writing/template.md +36 -0
- package/src/opencode/skills/story-writing/SKILL.md +29 -0
package/package.json
CHANGED
package/src/build-info.json
CHANGED
package/src/opencode/FLOW.yaml
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
# This file defines the complete workflow pipeline for AI-assisted development
|
|
3
3
|
|
|
4
4
|
name: documentation-workflow
|
|
5
|
-
version: "3.
|
|
5
|
+
version: "3.1"
|
|
6
6
|
description: |
|
|
7
7
|
End-to-end workflow from research to implementation and review.
|
|
8
8
|
|
|
@@ -12,6 +12,11 @@ description: |
|
|
|
12
12
|
- Skills: Knowledge (HOW to do things)
|
|
13
13
|
|
|
14
14
|
Config: .opencode/config.yaml
|
|
15
|
+
|
|
16
|
+
Project Size Classification:
|
|
17
|
+
- Defined in PRD (first section, mandatory)
|
|
18
|
+
- Agents read PRD to understand project size
|
|
19
|
+
- Size determines depth of all artifacts (PRD, Architecture, Epics, Stories)
|
|
15
20
|
|
|
16
21
|
# =============================================================================
|
|
17
22
|
# CONFIGURATION
|
|
@@ -4,9 +4,8 @@ mode: all # Can be primary agent or invoked via @dev
|
|
|
4
4
|
temperature: 0.2
|
|
5
5
|
|
|
6
6
|
model: anthropic/claude-opus-4-5 # Strong
|
|
7
|
-
#model: z.ai/glm-4.7 #
|
|
8
|
-
#model: openai/gpt-5.2-codex
|
|
9
|
-
#model: anthropic/claude-opus-4-5
|
|
7
|
+
#model: z.ai/glm-4.7 # Can break
|
|
8
|
+
#model: openai/gpt-5.2-codex
|
|
10
9
|
|
|
11
10
|
# Tools - FULL ACCESS for implementation
|
|
12
11
|
tools:
|
|
@@ -232,7 +231,7 @@ permission:
|
|
|
232
231
|
**What I Don't Do:**
|
|
233
232
|
- Define product scope (→ @pm)
|
|
234
233
|
- Make architecture decisions (→ @architect)
|
|
235
|
-
- Implement without a story
|
|
234
|
+
- Implement without a story-зж
|
|
236
235
|
- Skip tests or lie about test status
|
|
237
236
|
|
|
238
237
|
**Red-Green-Refactor:** 🔴 Write failing test → 🟢 Minimal code to pass → 🔵 Refactor
|
|
@@ -63,6 +63,7 @@ permission:
|
|
|
63
63
|
<r>ALWAYS communicate in {communication_language}</r>
|
|
64
64
|
<r>ALWAYS write technical documentation in ENGLISH (docs/ folder)</r>
|
|
65
65
|
<r>Translations go to docs/confluence/ folder</r>
|
|
66
|
+
<r critical="MANDATORY">📚 LOAD SKILL FIRST: Before creating any document (PRD/epic/story), MUST load appropriate skill</r>
|
|
66
67
|
<r>PRDs emerge from user interviews, not template filling</r>
|
|
67
68
|
<r>Ship the smallest thing that validates the assumption</r>
|
|
68
69
|
<r>Every feature must trace to a user problem</r>
|
|
@@ -85,9 +86,22 @@ permission:
|
|
|
85
86
|
</activation>
|
|
86
87
|
|
|
87
88
|
<workflow hint="How I approach complex tasks">
|
|
89
|
+
<phase name="0. Load Skill" critical="MANDATORY">
|
|
90
|
+
<action>BEFORE starting work, load appropriate skill:</action>
|
|
91
|
+
<skills>
|
|
92
|
+
- Creating PRD? → Load skill: prd-writing
|
|
93
|
+
- Creating epics? → Load skill: epic-writing
|
|
94
|
+
- Creating stories? → Load skill: story-writing
|
|
95
|
+
- Planning sprints? → Load skill: sprint-planning
|
|
96
|
+
- Syncing Jira? → Load skill: jira-integration
|
|
97
|
+
</skills>
|
|
98
|
+
<why>Skills contain critical guidelines, templates, and size-specific rules</why>
|
|
99
|
+
</phase>
|
|
100
|
+
|
|
88
101
|
<phase name="1. Analysis">
|
|
89
102
|
<action>Understand what needs to be created (PRD, epics, stories)</action>
|
|
90
103
|
<action>Search existing docs for context and dependencies</action>
|
|
104
|
+
<action>If PRD exists: Read "Project Classification" section</action>
|
|
91
105
|
</phase>
|
|
92
106
|
|
|
93
107
|
<phase name="2. Planning">
|
|
@@ -109,6 +123,7 @@ permission:
|
|
|
109
123
|
</phase>
|
|
110
124
|
|
|
111
125
|
<never-do>
|
|
126
|
+
- Start writing docs WITHOUT loading the skill first
|
|
112
127
|
- Start writing docs before user confirms the plan
|
|
113
128
|
- Skip the tasklist for complex work
|
|
114
129
|
- Assume what user wants without asking
|
|
@@ -129,11 +144,21 @@ permission:
|
|
|
129
144
|
</principles>
|
|
130
145
|
</persona>
|
|
131
146
|
|
|
132
|
-
<
|
|
133
|
-
<
|
|
134
|
-
|
|
135
|
-
<
|
|
136
|
-
</
|
|
147
|
+
<project-size-awareness critical="MANDATORY">
|
|
148
|
+
<instruction>BEFORE starting ANY work (PRD, epics, stories):</instruction>
|
|
149
|
+
|
|
150
|
+
<step n="1">If PRD exists: Read "Project Classification" section (first section)</step>
|
|
151
|
+
<step n="2">If no PRD: Load skill `prd-writing` to understand size classification</step>
|
|
152
|
+
<step n="3">Adapt your approach based on size</step>
|
|
153
|
+
|
|
154
|
+
<key-principle>
|
|
155
|
+
TOY/SMALL → Flat structure, no modules
|
|
156
|
+
MEDIUM+ → Break into Modules/Domains, create Unit docs
|
|
157
|
+
|
|
158
|
+
Don't over-engineer small projects!
|
|
159
|
+
Don't under-structure large projects!
|
|
160
|
+
</key-principle>
|
|
161
|
+
</project-size-awareness>
|
|
137
162
|
|
|
138
163
|
<methodologies>
|
|
139
164
|
<method name="Problem Framing">What's the REAL problem? Who experiences it? Why does it matter?</method>
|
|
@@ -30,6 +30,132 @@ Always check project standards: `@CLAUDE.md`
|
|
|
30
30
|
|
|
31
31
|
Use template at: `@.opencode/skills/architecture-design/template.md`
|
|
32
32
|
|
|
33
|
+
## CRITICAL: Adapt Depth to Project Size
|
|
34
|
+
|
|
35
|
+
**BEFORE writing architecture, read PRD's Project Classification section!**
|
|
36
|
+
|
|
37
|
+
Your architecture document size should match project size:
|
|
38
|
+
|
|
39
|
+
| Project Size | Target Lines | Diagrams | ADRs | Focus |
|
|
40
|
+
|--------------|--------------|----------|------|-------|
|
|
41
|
+
| **TOY** | 200-500 | C4 Context + Container | None | Core components only |
|
|
42
|
+
| **SMALL** | 500-1000 | + C4 Component | 2-3 major decisions | Clear module boundaries |
|
|
43
|
+
| **MEDIUM** | 1000-2000 | + Sequences + ER | 5-10 significant | Complete system design |
|
|
44
|
+
| **LARGE** | 2000-4000 | + Deployment + State | 10-20 all decisions | Multiple files OK |
|
|
45
|
+
| **ENTERPRISE** | 4000+ | All diagrams | 20+ per domain | Per-domain files |
|
|
46
|
+
|
|
47
|
+
**Examples:**
|
|
48
|
+
|
|
49
|
+
**TOY (Tetris - 350 lines):**
|
|
50
|
+
```
|
|
51
|
+
Executive Summary (50 lines)
|
|
52
|
+
System Context diagram (ASCII)
|
|
53
|
+
3 Modules: GameEngine, Renderer, ScoreManager
|
|
54
|
+
Data Model: GameState object (no DB)
|
|
55
|
+
Tech Stack: HTML5 Canvas, Vanilla JS
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
**SMALL (Blog - 800 lines):**
|
|
59
|
+
```
|
|
60
|
+
Executive Summary
|
|
61
|
+
Decision Summary (pattern choice)
|
|
62
|
+
C4 Context + Container + Component
|
|
63
|
+
5 Modules: Auth, Posts, Comments, Media, Admin
|
|
64
|
+
ER Diagram (users, posts, comments)
|
|
65
|
+
2-3 ADRs (why SQLite, why server-side rendering)
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
**MEDIUM (E-commerce - 1500 lines):**
|
|
69
|
+
```
|
|
70
|
+
Full C4 model
|
|
71
|
+
8 Modules across 3 domains
|
|
72
|
+
Complete ER diagram
|
|
73
|
+
Sequence diagrams for checkout flow
|
|
74
|
+
5-10 ADRs
|
|
75
|
+
Integration points documented
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
**Don't over-engineer small projects!** If PRD says "toy", keep it under 500 lines.
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## Module/Unit Breakdown by Size
|
|
83
|
+
|
|
84
|
+
**CRITICAL:** Read PRD's Project Classification to determine module strategy.
|
|
85
|
+
|
|
86
|
+
| Project Size | Module Strategy | Structure |
|
|
87
|
+
|--------------|-----------------|-----------|
|
|
88
|
+
| **TOY** | No modules | Flat components (GameEngine, Renderer, ScoreManager) |
|
|
89
|
+
| **SMALL** | No modules | Flat components (AuthService, PostService, CommentService) |
|
|
90
|
+
| **MEDIUM** | **YES - Modules** | 3-5 modules (OrderModule, InventoryModule, PaymentModule) |
|
|
91
|
+
| **LARGE** | **YES - Domains** | 5-10 domains (OrderDomain, PaymentDomain, UserDomain) |
|
|
92
|
+
| **ENTERPRISE** | **YES - Bounded Contexts** | 10+ contexts with subdomains |
|
|
93
|
+
|
|
94
|
+
**For MEDIUM+ projects:**
|
|
95
|
+
|
|
96
|
+
1. **Identify Modules from PRD:**
|
|
97
|
+
- Read PRD's Executive Summary → "Key Domains"
|
|
98
|
+
- Each domain = Module in architecture
|
|
99
|
+
- Example: PRD lists "Order Management, Inventory, Payment" → 3 modules
|
|
100
|
+
|
|
101
|
+
2. **Document Each Module:**
|
|
102
|
+
- Create section per module in architecture.md
|
|
103
|
+
- Define module boundaries (what's in, what's out)
|
|
104
|
+
- Define module's internal services
|
|
105
|
+
- Define module's data ownership
|
|
106
|
+
- Define module's API (what other modules can call)
|
|
107
|
+
|
|
108
|
+
3. **Create Unit Documentation:**
|
|
109
|
+
- For each module, create `docs/units/module-name/index.md`
|
|
110
|
+
- Use `unit-writing` skill
|
|
111
|
+
- Include: data model, API spec, events (if event-driven)
|
|
112
|
+
|
|
113
|
+
4. **Module Communication:**
|
|
114
|
+
- Document how modules interact
|
|
115
|
+
- Synchronous (REST/GraphQL) or Asynchronous (events)
|
|
116
|
+
- Integration diagram showing module dependencies
|
|
117
|
+
|
|
118
|
+
**Example - MEDIUM E-commerce (3 modules):**
|
|
119
|
+
|
|
120
|
+
```markdown
|
|
121
|
+
## Modules Overview
|
|
122
|
+
|
|
123
|
+
### Order Management Module
|
|
124
|
+
|
|
125
|
+
**Purpose:** Handles order lifecycle from creation to fulfillment
|
|
126
|
+
|
|
127
|
+
**Internal Services:**
|
|
128
|
+
- OrderService: CRUD operations
|
|
129
|
+
- OrderWorkflowService: Status transitions
|
|
130
|
+
- OrderValidationService: Business rules
|
|
131
|
+
|
|
132
|
+
**Data Ownership:**
|
|
133
|
+
- orders table
|
|
134
|
+
- order_items table
|
|
135
|
+
- order_history table
|
|
136
|
+
|
|
137
|
+
**API (exposed to other modules):**
|
|
138
|
+
- `POST /orders` - Create order
|
|
139
|
+
- `GET /orders/{id}` - Get order details
|
|
140
|
+
- `PUT /orders/{id}/status` - Update status
|
|
141
|
+
|
|
142
|
+
**Events Published:**
|
|
143
|
+
- OrderCreated
|
|
144
|
+
- OrderPaid
|
|
145
|
+
- OrderShipped
|
|
146
|
+
|
|
147
|
+
→ Unit: `docs/units/order-management/`
|
|
148
|
+
|
|
149
|
+
### Payment Module
|
|
150
|
+
...
|
|
151
|
+
|
|
152
|
+
### Inventory Module
|
|
153
|
+
...
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
**TOY/SMALL projects - NO modules:**
|
|
157
|
+
Just list components/services in flat structure.
|
|
158
|
+
|
|
33
159
|
## Architecture Document Structure (v2)
|
|
34
160
|
|
|
35
161
|
### 1. Executive Summary
|
|
@@ -22,6 +22,93 @@ Use this skill when you need to:
|
|
|
22
22
|
|
|
23
23
|
Use template at: `@.opencode/skills/epic-writing/template.md`
|
|
24
24
|
|
|
25
|
+
## CRITICAL: What is an Epic?
|
|
26
|
+
|
|
27
|
+
**Epic scope changes with project size!** Read PRD's Project Classification first.
|
|
28
|
+
|
|
29
|
+
| Project Size | Epic = | Example | Stories |
|
|
30
|
+
|--------------|--------|---------|---------|
|
|
31
|
+
| **TOY** | Major feature | "Game Logic", "UI Rendering", "Scoring" | 3-8 tasks |
|
|
32
|
+
| **SMALL** | Feature area | "User Authentication", "Post Management" | 5-12 tasks |
|
|
33
|
+
| **MEDIUM** | **Module/Unit** | "Order Management Module", "Payment Module" | 8-15 features |
|
|
34
|
+
| **LARGE** | **Domain** | "Order Domain", "Payment Domain" | 10-20 features |
|
|
35
|
+
| **ENTERPRISE** | **Bounded Context** | "Core Banking Context" | 15-30 features |
|
|
36
|
+
|
|
37
|
+
**For MEDIUM+ projects:**
|
|
38
|
+
- Each Epic = One Module from PRD
|
|
39
|
+
- Epic should reference Unit documentation: `→ Unit: docs/units/order-management/`
|
|
40
|
+
- Stories within epic are features of that module
|
|
41
|
+
- Epic owns a set of FRs (e.g., FR-ORD-001 through FR-ORD-015)
|
|
42
|
+
|
|
43
|
+
**Example - MEDIUM E-commerce:**
|
|
44
|
+
```
|
|
45
|
+
Epic: Order Management Module
|
|
46
|
+
→ Unit: docs/units/order-management/
|
|
47
|
+
→ FRs: FR-ORD-001 to FR-ORD-012
|
|
48
|
+
→ Stories:
|
|
49
|
+
- Customer can create order
|
|
50
|
+
- System validates inventory
|
|
51
|
+
- Order status workflow
|
|
52
|
+
- Order history view
|
|
53
|
+
...
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
**Example - TOY Tetris:**
|
|
57
|
+
```
|
|
58
|
+
Epic: Game Logic
|
|
59
|
+
→ Stories:
|
|
60
|
+
- Implement block rotation
|
|
61
|
+
- Add collision detection
|
|
62
|
+
- Clear full lines
|
|
63
|
+
- Increase fall speed
|
|
64
|
+
→ No Unit docs needed
|
|
65
|
+
→ Simple AC: "Game logic works correctly"
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
**Example - SMALL Blog:**
|
|
69
|
+
```
|
|
70
|
+
Epic: Post Management
|
|
71
|
+
→ Stories:
|
|
72
|
+
- User can create post
|
|
73
|
+
- User can edit post
|
|
74
|
+
- User can delete post
|
|
75
|
+
- User can publish/unpublish
|
|
76
|
+
- Posts show in list
|
|
77
|
+
→ No Unit docs (flat structure)
|
|
78
|
+
→ AC: "Users can manage posts through full lifecycle"
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Epic Depth by Project Size
|
|
84
|
+
|
|
85
|
+
**CRITICAL:** Epic structure changes with project size!
|
|
86
|
+
|
|
87
|
+
**TOY/SMALL:**
|
|
88
|
+
- Simple overview (1-2 paragraphs)
|
|
89
|
+
- No Units Affected section (no modules)
|
|
90
|
+
- Simple AC checklist
|
|
91
|
+
- Stories listed as bullet points
|
|
92
|
+
- No Technical Decisions section
|
|
93
|
+
- No Risks section
|
|
94
|
+
|
|
95
|
+
**MEDIUM:**
|
|
96
|
+
- Detailed overview with business value
|
|
97
|
+
- **Units Affected section** (references Unit docs)
|
|
98
|
+
- Comprehensive AC
|
|
99
|
+
- Stories in table with dependencies
|
|
100
|
+
- Technical Decisions with ADR links
|
|
101
|
+
- Risks identified
|
|
102
|
+
|
|
103
|
+
**LARGE/ENTERPRISE:**
|
|
104
|
+
- Complete overview with strategic context
|
|
105
|
+
- **Multiple Units Affected** (cross-domain)
|
|
106
|
+
- Exhaustive AC with compliance
|
|
107
|
+
- Stories with estimates and confidence levels
|
|
108
|
+
- All Technical Decisions documented
|
|
109
|
+
- Risks with mitigation plans
|
|
110
|
+
- Security considerations
|
|
111
|
+
|
|
25
112
|
## Epic Structure (v2)
|
|
26
113
|
|
|
27
114
|
### 1. Header
|
|
@@ -21,7 +21,194 @@ Use this skill when you need to:
|
|
|
21
21
|
|
|
22
22
|
Use the template at: `@.opencode/skills/prd-writing/template.md`
|
|
23
23
|
|
|
24
|
-
## PRD Structure (
|
|
24
|
+
## PRD Structure (v3 - with Project Classification)
|
|
25
|
+
|
|
26
|
+
### 0. Project Classification (MANDATORY FIRST SECTION)
|
|
27
|
+
|
|
28
|
+
**Purpose:** This section determines how deep and detailed ALL subsequent artifacts will be.
|
|
29
|
+
|
|
30
|
+
**CRITICAL - Fill this FIRST:**
|
|
31
|
+
1. Ask user about project (or infer from requirements)
|
|
32
|
+
2. Classify size based on timeline and complexity
|
|
33
|
+
3. Fill the classification table
|
|
34
|
+
4. Adapt your writing style for the rest of PRD
|
|
35
|
+
|
|
36
|
+
**Classification Table:**
|
|
37
|
+
|
|
38
|
+
| Attribute | Value | Notes |
|
|
39
|
+
|-----------|-------|-------|
|
|
40
|
+
| **Size** | toy / small / medium / large / enterprise | See guide below |
|
|
41
|
+
| **Complexity** | simple / moderate / complex / very_complex | Business logic depth |
|
|
42
|
+
| **Team Size** | 1-100+ | Number of developers |
|
|
43
|
+
| **Timeline** | Days/weeks/months | Expected duration |
|
|
44
|
+
| **Domain** | game / web_app / api / library / cli / mobile_app / embedded | Project type |
|
|
45
|
+
|
|
46
|
+
**Size Impact Table:**
|
|
47
|
+
|
|
48
|
+
| Attribute | Value |
|
|
49
|
+
|-----------|-------|
|
|
50
|
+
| **PRD Depth** | X-Y pages |
|
|
51
|
+
| **Architecture** | X-Y lines |
|
|
52
|
+
| **Epics** | X-Y (scope: feature/module/domain) |
|
|
53
|
+
| **Stories per Epic** | X-Y |
|
|
54
|
+
| **Sprints** | X |
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
### How to Classify Project Size
|
|
59
|
+
|
|
60
|
+
**Ask yourself:**
|
|
61
|
+
- What's the scope? (single feature vs full system)
|
|
62
|
+
- How complex is the business logic? (simple CRUD vs complex workflows)
|
|
63
|
+
- How many integrations? (none vs many external systems)
|
|
64
|
+
- What's the data model? (few entities vs complex relationships)
|
|
65
|
+
- Who's the team? (solo vs multiple teams)
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
**TOY** - Learning/Prototype
|
|
70
|
+
- **Examples:** Tetris, Calculator, Tic-tac-toe, Todo list
|
|
71
|
+
- **Scope:** Single feature or concept exploration
|
|
72
|
+
- **Complexity:** Minimal business logic, no integrations
|
|
73
|
+
- **Data:** No database or simple localStorage
|
|
74
|
+
- **Team:** Solo developer
|
|
75
|
+
- **What to write:**
|
|
76
|
+
- PRD: 2-3 pages, bullet points OK
|
|
77
|
+
- Architecture: 200-500 lines, simple component diagram
|
|
78
|
+
- Structure: Flat components (GameEngine, Renderer, ScoreManager)
|
|
79
|
+
- Epics: 3-5 major features ("Game Logic", "UI", "Scoring")
|
|
80
|
+
- No modules, no Unit docs
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
**SMALL** - Simple Application
|
|
85
|
+
- **Examples:** Blog, Portfolio site, Simple REST API, Chrome extension, CLI tool
|
|
86
|
+
- **Scope:** Single application with basic CRUD
|
|
87
|
+
- **Complexity:** Simple business logic, 1-2 integrations max
|
|
88
|
+
- **Data:** Basic database (5-10 tables), simple relationships
|
|
89
|
+
- **Team:** 1-2 developers
|
|
90
|
+
- **What to write:**
|
|
91
|
+
- PRD: 3-5 pages, structured tables
|
|
92
|
+
- Architecture: 500-1000 lines, C4 Context + Container + Component
|
|
93
|
+
- Structure: Flat services (AuthService, PostService, CommentService)
|
|
94
|
+
- Epics: 5-10 feature areas ("User Auth", "Post Management")
|
|
95
|
+
- No modules yet, no Unit docs
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
**MEDIUM** - Multi-Module System
|
|
100
|
+
- **Examples:** E-commerce site, CRM, Mobile app, Booking system
|
|
101
|
+
- **Scope:** Multiple interconnected features
|
|
102
|
+
- **Complexity:** Moderate business logic, 3-5 integrations, workflows
|
|
103
|
+
- **Data:** 15-30 tables, complex relationships, transactions
|
|
104
|
+
- **Team:** 2-5 developers (small team)
|
|
105
|
+
- **What to write:**
|
|
106
|
+
- PRD: 5-10 pages, break into **MODULES**
|
|
107
|
+
- Architecture: 1000-2000 lines, full C4 model + sequences
|
|
108
|
+
- Structure: **Modules** (OrderModule, InventoryModule, PaymentModule)
|
|
109
|
+
- Epics: 8-15, **each Epic = one Module**
|
|
110
|
+
- **Create Unit docs** for each module: `docs/units/module-name/`
|
|
111
|
+
- Module boundaries matter - define what's in/out
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
**LARGE** - Multi-Domain Platform
|
|
116
|
+
- **Examples:** Multi-tenant SaaS, Payment platform, Social network, Marketplace
|
|
117
|
+
- **Scope:** Multiple domains with complex interactions
|
|
118
|
+
- **Complexity:** Complex business logic, 10+ integrations, event-driven
|
|
119
|
+
- **Data:** 50-100+ tables, multiple databases, caching layers
|
|
120
|
+
- **Team:** 5-20 developers (multiple teams)
|
|
121
|
+
- **What to write:**
|
|
122
|
+
- PRD: 10-20 pages, think in **DOMAINS**
|
|
123
|
+
- Architecture: 2000-4000 lines, likely multiple files per domain
|
|
124
|
+
- Structure: **Domains/Bounded Contexts** (OrderDomain, PaymentDomain)
|
|
125
|
+
- Epics: 15-30, **each Epic = one Domain**
|
|
126
|
+
- **Complete Unit docs** with API specs, events, data models
|
|
127
|
+
- ADRs for all major decisions (affects multiple teams)
|
|
128
|
+
- Security review required
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
**ENTERPRISE** - Mission-Critical System
|
|
133
|
+
- **Examples:** Banking system, Healthcare platform, ERP, Trading platform
|
|
134
|
+
- **Scope:** Enterprise-wide system with governance
|
|
135
|
+
- **Complexity:** Very complex, regulatory compliance, high availability
|
|
136
|
+
- **Data:** 100+ tables, distributed databases, audit trails
|
|
137
|
+
- **Team:** 20+ developers (large organization)
|
|
138
|
+
- **What to write:**
|
|
139
|
+
- PRD: 20-50 pages, strategic document
|
|
140
|
+
- Architecture: 4000+ lines, per-domain files
|
|
141
|
+
- Structure: **Bounded Contexts** with subdomains
|
|
142
|
+
- Compliance requirements in every section
|
|
143
|
+
- Multiple review stages (security, compliance, legal)
|
|
144
|
+
- Audit-ready documentation
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
### How Size Affects Your Writing
|
|
149
|
+
|
|
150
|
+
**TOY/SMALL - Keep it lean:**
|
|
151
|
+
```markdown
|
|
152
|
+
## Functional Requirements
|
|
153
|
+
|
|
154
|
+
### Game Logic
|
|
155
|
+
| ID | Requirement | Priority |
|
|
156
|
+
|----|-------------|----------|
|
|
157
|
+
| FR-001 | User can rotate block | P0 |
|
|
158
|
+
| FR-002 | Blocks fall automatically | P0 |
|
|
159
|
+
| FR-003 | Full lines disappear | P0 |
|
|
160
|
+
|
|
161
|
+
**Notes:**
|
|
162
|
+
- Rotation uses standard Tetris rules
|
|
163
|
+
- Fall speed increases with score
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
**MEDIUM - Structured by modules:**
|
|
167
|
+
```markdown
|
|
168
|
+
## Functional Requirements
|
|
169
|
+
|
|
170
|
+
### Order Management Module
|
|
171
|
+
| ID | Requirement | Priority |
|
|
172
|
+
|----|-------------|----------|
|
|
173
|
+
| FR-ORD-001 | Customer can create order with items | P0 |
|
|
174
|
+
| FR-ORD-002 | System validates inventory before order | P0 |
|
|
175
|
+
| FR-ORD-003 | Order status follows workflow (pending → paid → shipped) | P0 |
|
|
176
|
+
|
|
177
|
+
**Notes:**
|
|
178
|
+
- Order cannot be modified after payment
|
|
179
|
+
- Inventory reserved on order creation, committed on payment
|
|
180
|
+
|
|
181
|
+
→ Unit: `docs/units/order-management/`
|
|
182
|
+
|
|
183
|
+
### Payment Module
|
|
184
|
+
| ID | Requirement | Priority |
|
|
185
|
+
|----|-------------|----------|
|
|
186
|
+
| FR-PAY-001 | System integrates with Stripe | P0 |
|
|
187
|
+
| FR-PAY-002 | Payment failures trigger order cancellation | P0 |
|
|
188
|
+
|
|
189
|
+
→ Unit: `docs/units/payment/`
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
**LARGE/ENTERPRISE - Domain-driven:**
|
|
193
|
+
```markdown
|
|
194
|
+
## Functional Requirements
|
|
195
|
+
|
|
196
|
+
### Order Domain
|
|
197
|
+
→ Unit: `docs/units/order-domain/`
|
|
198
|
+
|
|
199
|
+
#### Order Lifecycle
|
|
200
|
+
| ID | Requirement | Priority | Compliance |
|
|
201
|
+
|----|-------------|----------|------------|
|
|
202
|
+
| FR-ORD-001 | Customer can create order | P0 | GDPR: consent required |
|
|
203
|
+
| FR-ORD-002 | Order audit trail maintained | P0 | SOX: 7 year retention |
|
|
204
|
+
|
|
205
|
+
#### Order Validation
|
|
206
|
+
...
|
|
207
|
+
|
|
208
|
+
### Payment Domain
|
|
209
|
+
→ Unit: `docs/units/payment-domain/`
|
|
210
|
+
...
|
|
211
|
+
```
|
|
25
212
|
|
|
26
213
|
### 1. Executive Summary
|
|
27
214
|
|
|
@@ -47,9 +234,28 @@ Brief prose section with:
|
|
|
47
234
|
| Growth Features | Post-MVP enhancements |
|
|
48
235
|
| Out of Scope | Explicit exclusions |
|
|
49
236
|
|
|
237
|
+
**IMPORTANT - Module Breakdown by Size:**
|
|
238
|
+
|
|
239
|
+
- **TOY/SMALL:** No modules needed, flat feature list
|
|
240
|
+
- **MEDIUM+:** Break into modules/domains (Units)
|
|
241
|
+
- Each module = separate section in scope
|
|
242
|
+
- Each module will become Epic later
|
|
243
|
+
- Example: "Order Management Module", "Payment Module"
|
|
244
|
+
|
|
50
245
|
### 4. Functional Requirements
|
|
51
246
|
|
|
52
|
-
**
|
|
247
|
+
**Grouping by Project Size:**
|
|
248
|
+
|
|
249
|
+
**TOY/SMALL projects:**
|
|
250
|
+
- Group by feature area (flat structure)
|
|
251
|
+
- Example: "Game Logic", "UI", "Scoring"
|
|
252
|
+
|
|
253
|
+
**MEDIUM+ projects:**
|
|
254
|
+
- Group by Module/Unit (hierarchical)
|
|
255
|
+
- Each module gets its own FR table
|
|
256
|
+
- Example: "Order Management Module" → FR-ORD-001, FR-ORD-002
|
|
257
|
+
|
|
258
|
+
**Table format:**
|
|
53
259
|
|
|
54
260
|
| ID | Requirement | Priority |
|
|
55
261
|
|----|-------------|----------|
|
|
@@ -57,6 +263,13 @@ Brief prose section with:
|
|
|
57
263
|
|
|
58
264
|
With **Notes:** for business rules after each domain table.
|
|
59
265
|
|
|
266
|
+
**Module-based FR IDs (MEDIUM+):**
|
|
267
|
+
```
|
|
268
|
+
FR-ORD-001 # Order Management module
|
|
269
|
+
FR-PAY-001 # Payment module
|
|
270
|
+
FR-INV-001 # Inventory module
|
|
271
|
+
```
|
|
272
|
+
|
|
60
273
|
### 5. Non-Functional Requirements
|
|
61
274
|
|
|
62
275
|
Tables for:
|
|
@@ -81,13 +294,40 @@ Using `→` format:
|
|
|
81
294
|
→ Requirements: `docs/requirements.md`
|
|
82
295
|
```
|
|
83
296
|
|
|
297
|
+
## Units (Modules/Domains)
|
|
298
|
+
|
|
299
|
+
**What is a Unit?**
|
|
300
|
+
A Unit is a module, domain, or bounded context - a cohesive piece of the system.
|
|
301
|
+
|
|
302
|
+
**When to create Units?**
|
|
303
|
+
|
|
304
|
+
| Project Size | Units? | Scope | Examples |
|
|
305
|
+
|--------------|--------|-------|----------|
|
|
306
|
+
| **TOY** | No | Flat features | "Game Logic", "UI", "Scoring" |
|
|
307
|
+
| **SMALL** | No | Flat features | "Auth", "Posts", "Comments" |
|
|
308
|
+
| **MEDIUM** | Yes | Modules | "Order Management", "Inventory", "Payment" |
|
|
309
|
+
| **LARGE** | Yes | Domains | "Order Domain", "Payment Domain" |
|
|
310
|
+
| **ENTERPRISE** | Yes | Bounded Contexts | "Core Banking", "Risk Management" |
|
|
311
|
+
|
|
312
|
+
**For MEDIUM+ projects:**
|
|
313
|
+
1. Identify modules/domains in Executive Summary
|
|
314
|
+
2. Create separate scope section per module
|
|
315
|
+
3. Group FRs by module (FR-ORD-001, FR-PAY-001)
|
|
316
|
+
4. Each module → separate Epic later
|
|
317
|
+
5. Each module → separate Unit documentation (docs/units/module-name/)
|
|
318
|
+
|
|
319
|
+
**Unit Documentation:**
|
|
320
|
+
- For MEDIUM+ projects, create `docs/units/module-name/index.md` for each module
|
|
321
|
+
- Use `unit-writing` skill to document each unit
|
|
322
|
+
- Link from PRD: `→ Unit: Order Management - docs/units/order-management/`
|
|
323
|
+
|
|
84
324
|
## Writing Guidelines
|
|
85
325
|
|
|
86
326
|
### Reference Format
|
|
87
327
|
|
|
88
328
|
Always use `→` prefix for links:
|
|
89
329
|
```
|
|
90
|
-
→ Unit: `
|
|
330
|
+
→ Unit: `Order Management` - docs/units/order-management/
|
|
91
331
|
→ FR: `FR-001`
|
|
92
332
|
→ ADR: `ADR-001`
|
|
93
333
|
→ `path/to/file.md`
|
|
@@ -10,6 +10,42 @@ author: {{author}}
|
|
|
10
10
|
|
|
11
11
|
---
|
|
12
12
|
|
|
13
|
+
## Project Classification
|
|
14
|
+
|
|
15
|
+
> **Purpose:** Determines workflow depth and artifact sizes. Agents use this to adapt their approach.
|
|
16
|
+
> See `.opencode/project-size-guide.yaml` for detailed guidelines.
|
|
17
|
+
|
|
18
|
+
| Attribute | Value | Notes |
|
|
19
|
+
|-----------|-------|-------|
|
|
20
|
+
| **Size** | {{size}} | toy / small / medium / large / enterprise |
|
|
21
|
+
| **Complexity** | {{complexity}} | simple / moderate / complex / very_complex |
|
|
22
|
+
| **Team Size** | {{team_size}} | Number of developers |
|
|
23
|
+
| **Timeline** | {{timeline}} | Expected duration |
|
|
24
|
+
| **Domain** | {{domain}} | web_app / mobile_app / api / library / cli / game / embedded |
|
|
25
|
+
|
|
26
|
+
**Size Impact:**
|
|
27
|
+
- **PRD Depth:** {{prd_pages}} pages
|
|
28
|
+
- **Architecture:** {{arch_lines}} lines
|
|
29
|
+
- **Epics:** {{epic_count}} ({{epic_scope}})
|
|
30
|
+
- **Stories per Epic:** {{stories_per_epic}}
|
|
31
|
+
- **Sprints:** {{sprint_count}}
|
|
32
|
+
|
|
33
|
+
<!-- Examples:
|
|
34
|
+
TOY (Tetris):
|
|
35
|
+
Size: toy | Complexity: simple | Team: 1 | Timeline: < 1 week | Domain: game
|
|
36
|
+
PRD: 2-3 pages | Arch: 200-500 lines | Epics: 3-5 (major features) | Stories: 3-8 | Sprints: 1
|
|
37
|
+
|
|
38
|
+
SMALL (Blog):
|
|
39
|
+
Size: small | Complexity: simple | Team: 1-2 | Timeline: 1-4 weeks | Domain: web_app
|
|
40
|
+
PRD: 3-5 pages | Arch: 500-1000 lines | Epics: 5-10 (features) | Stories: 5-12 | Sprints: 1-2
|
|
41
|
+
|
|
42
|
+
MEDIUM (E-commerce):
|
|
43
|
+
Size: medium | Complexity: moderate | Team: 2-5 | Timeline: 1-3 months | Domain: web_app
|
|
44
|
+
PRD: 5-10 pages | Arch: 1000-2000 lines | Epics: 8-15 (modules) | Stories: 8-15 | Sprints: 2-4
|
|
45
|
+
-->
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
13
49
|
## Executive Summary
|
|
14
50
|
|
|
15
51
|
{{project}} is a {{type}} platform for {{target_users}}. The system handles {{core_capabilities}}.
|
|
@@ -22,6 +22,35 @@ Use this skill when you need to:
|
|
|
22
22
|
|
|
23
23
|
Use template at: `@.opencode/skills/story-writing/template.md`
|
|
24
24
|
|
|
25
|
+
## CRITICAL: Story Depth by Project Size
|
|
26
|
+
|
|
27
|
+
**Read PRD's Project Classification to understand appropriate depth!**
|
|
28
|
+
|
|
29
|
+
| Project Size | Story Depth | AC Detail | Tasks | Example |
|
|
30
|
+
|--------------|-------------|-----------|-------|---------|
|
|
31
|
+
| **TOY** | Simple | Basic Given/When/Then | 1-3 tasks, no subtasks | "Implement block rotation" |
|
|
32
|
+
| **SMALL** | Moderate | Given/When/Then + edge cases | 2-5 tasks, optional subtasks | "User can create post" |
|
|
33
|
+
| **MEDIUM** | Detailed | Comprehensive Given/When/Then | 3-8 tasks, subtasks recommended | "Customer can place order" |
|
|
34
|
+
| **LARGE** | Comprehensive | All scenarios + edge cases | 5-10 tasks, subtasks required | "Process payment with retry logic" |
|
|
35
|
+
| **ENTERPRISE** | Exhaustive | All scenarios + compliance | 8-15 tasks, subtasks + estimates | "Execute trade with audit trail" |
|
|
36
|
+
|
|
37
|
+
**Key differences:**
|
|
38
|
+
|
|
39
|
+
**TOY/SMALL:**
|
|
40
|
+
- Simple AC: "Given block at top, When user presses rotate, Then block rotates 90°"
|
|
41
|
+
- Tasks are straightforward: "Add rotation logic", "Add tests"
|
|
42
|
+
- No Required Reading section needed (no coding standards yet)
|
|
43
|
+
|
|
44
|
+
**MEDIUM:**
|
|
45
|
+
- Detailed AC with edge cases: "Given order with out-of-stock item, When customer submits, Then show error"
|
|
46
|
+
- Tasks reference coding standards and Unit docs
|
|
47
|
+
- Required Reading section mandatory
|
|
48
|
+
|
|
49
|
+
**LARGE/ENTERPRISE:**
|
|
50
|
+
- Exhaustive AC with compliance: "Given payment failure, When retry limit reached, Then log to audit, notify customer, update order status"
|
|
51
|
+
- Tasks include security considerations
|
|
52
|
+
- Multiple review stages
|
|
53
|
+
|
|
25
54
|
## MANDATORY: Read Before Writing
|
|
26
55
|
|
|
27
56
|
**Before writing ANY story, read these documents:**
|