macca-method 1.1.0 → 2.0.0
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/.agents/legacy-payloads.json +22 -0
- package/{skills-lock.json → .agents/macca-lock.json} +3 -2
- package/.agents/macca-managed-skills.txt +2 -1
- package/.agents/skills/_shared/references/additional-skills.md +30 -0
- package/.agents/skills/_shared/references/brainstorm-session.md +42 -11
- package/.agents/skills/_shared/references/config-mutation.md +25 -0
- package/.agents/skills/_shared/references/finding-format.md +25 -0
- package/.agents/skills/_shared/references/fix-mode.md +39 -0
- package/.agents/skills/_shared/references/human-loop.md +3 -1
- package/.agents/skills/_shared/references/implementation-principles.md +19 -0
- package/.agents/skills/_shared/references/invocation-policy.md +39 -0
- package/.agents/skills/_shared/references/language-config.md +15 -0
- package/.agents/skills/_shared/references/output-ownership.md +4 -2
- package/.agents/skills/_shared/references/runtime-config.md +7 -168
- package/.agents/skills/_shared/references/skill-catalog.md +34 -0
- package/.agents/skills/_shared/scripts/validate-skills.py +106 -4
- package/.agents/skills/add-feature/SKILL.md +10 -7
- package/.agents/skills/brainstorm-api/SKILL.md +49 -194
- package/.agents/skills/brainstorm-api/assets/api.template.md +147 -0
- package/.agents/skills/brainstorm-architecture/SKILL.md +22 -127
- package/.agents/skills/brainstorm-architecture/assets/architecture.template.md +135 -0
- package/.agents/skills/brainstorm-prd/SKILL.md +19 -102
- package/.agents/skills/brainstorm-prd/assets/PRD.template.md +106 -0
- package/.agents/skills/brainstorm-rules/SKILL.md +17 -151
- package/.agents/skills/brainstorm-rules/assets/rules.template.md +127 -0
- package/.agents/skills/brainstorm-schema/SKILL.md +49 -115
- package/.agents/skills/brainstorm-schema/assets/schema.template.md +109 -0
- package/.agents/skills/brainstorm-styleguide/SKILL.md +19 -134
- package/.agents/skills/brainstorm-styleguide/assets/StyleGuide.template.md +147 -0
- package/.agents/skills/brainstorm-task/SKILL.md +22 -107
- package/.agents/skills/brainstorm-task/assets/Task.template.md +113 -0
- package/.agents/skills/bug-fix/SKILL.md +45 -54
- package/.agents/skills/code-review/SKILL.md +26 -19
- package/.agents/skills/code-review/references/review-checklist.md +24 -26
- package/.agents/skills/developer/SKILL.md +25 -39
- package/.agents/skills/developer/references/close-phase.md +25 -0
- package/.agents/skills/developer/references/execute-task.md +69 -0
- package/.agents/skills/developer/references/onboarding.md +47 -0
- package/.agents/skills/help/SKILL.md +12 -13
- package/.agents/skills/meet/SKILL.md +168 -0
- package/.agents/skills/quick-dev/SKILL.md +28 -32
- package/.agents/skills/release-readiness/SKILL.md +149 -0
- package/.agents/skills/spec-audit/SKILL.md +37 -22
- package/.agents/skills/spec-compliance/SKILL.md +41 -40
- package/.agents/skills/spec-init/SKILL.md +29 -14
- package/README.md +171 -122
- package/bin/macca-method.js +779 -85
- package/flow.webp +0 -0
- package/image-macca-method.webp +0 -0
- package/package.json +12 -5
- package/scripts/run-skill-validator.js +24 -0
- package/scripts/test-install.js +398 -0
- package/scripts/test-upgrade-legacy.js +107 -0
- package/scripts/validate-skill-behavior.js +124 -0
- package/.agents/skills/developer/references/execution-workflow.md +0 -322
- package/.agents/skills/rapat/SKILL.md +0 -172
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brainstorm-architecture
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
3
|
+
description: Interviews users and generates `architecture.md` with stack, boundaries, operations, observability, recovery, security, and ADRs. Use only when the user explicitly wants architecture decisions documented after the PRD.
|
|
4
|
+
compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
|
|
5
|
+
metadata:
|
|
6
|
+
persona: "Fachri"
|
|
7
|
+
persona-role: "Tech Lead"
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# Brainstorm Architecture
|
|
@@ -34,12 +36,13 @@ You are **@Fachri — Tech Lead**, a **Senior Software Architect** who designs s
|
|
|
34
36
|
|
|
35
37
|
Before any interview:
|
|
36
38
|
|
|
37
|
-
1. Read `../_shared/references/
|
|
38
|
-
2. Read `../_shared/references/
|
|
39
|
-
3. Read `../_shared/references/
|
|
39
|
+
1. Read `../_shared/references/language-config.md`.
|
|
40
|
+
2. Read `../_shared/references/config-mutation.md`.
|
|
41
|
+
3. Read `../_shared/references/brainstorm-session.md`.
|
|
42
|
+
4. Read `../_shared/references/scope-rules.md`.
|
|
40
43
|
4. Use `languagePreferences.communication.normalized` for chat.
|
|
41
44
|
5. Use `languagePreferences.documents.normalized` for the final `project-context/architecture.md`.
|
|
42
|
-
6. Apply `brainstormPreferences.discussionMode` and `
|
|
45
|
+
6. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
|
|
43
46
|
|
|
44
47
|
---
|
|
45
48
|
|
|
@@ -55,7 +58,7 @@ Before any interview:
|
|
|
55
58
|
- `backend` → architecture.md MUST focus on backend architecture, service/data/auth, and consumer dependencies only
|
|
56
59
|
- `fullstack` → full architecture.md
|
|
57
60
|
|
|
58
|
-
4. Run the shared runtime setup above
|
|
61
|
+
4. Run the shared runtime setup above and apply all three pacing modes from the shared session policy. If preferences are saved, announce and proceed without another confirmation.
|
|
59
62
|
|
|
60
63
|
5. Run the interview in the chosen mode. Wait for answers.
|
|
61
64
|
|
|
@@ -67,7 +70,7 @@ Before any interview:
|
|
|
67
70
|
|
|
68
71
|
## Interview Topics (10 Topics)
|
|
69
72
|
|
|
70
|
-
Ask the topics in order
|
|
73
|
+
Ask the topics in order and wait after each selected batch, not after every topic when batching is enabled.
|
|
71
74
|
|
|
72
75
|
### 1. System Context
|
|
73
76
|
*"What systems and external services interact with this project?"*
|
|
@@ -88,6 +91,7 @@ Collect:
|
|
|
88
91
|
- ORM/ODM
|
|
89
92
|
- Hosting platform
|
|
90
93
|
- Specific versions (for example Next.js 14 App Router, React 18)
|
|
94
|
+
- For each strategic dependency/vendor: existing/native alternative, runtime compatibility, maintenance health, license, security advisories, operational cost, lock-in, migration path, and removal/exit path
|
|
91
95
|
|
|
92
96
|
### 3. State Management
|
|
93
97
|
*"If there is a frontend, how is state managed?"*
|
|
@@ -150,6 +154,10 @@ Collect:
|
|
|
150
154
|
- CI/CD strategy
|
|
151
155
|
- Domain and SSL
|
|
152
156
|
- CDN or object storage needs?
|
|
157
|
+
- Operational owner, support/runbook expectations, and capacity constraints
|
|
158
|
+
- Logs, metrics, traces, dashboards, alert thresholds, and retention required by PRD success/NFR targets
|
|
159
|
+
- Deployment rollback trigger, mechanism, validation, and data compatibility
|
|
160
|
+
- For critical depth: backup/restore ownership, tested restore process, RPO, RTO, and regional/dependency failure behavior
|
|
153
161
|
|
|
154
162
|
### 10. Architecture Decision Records (ADR)
|
|
155
163
|
*"Are there key architecture decisions whose rationale should be documented?"*
|
|
@@ -158,128 +166,14 @@ Collect:
|
|
|
158
166
|
- Non-obvious decisions (why PostgreSQL vs MongoDB)
|
|
159
167
|
- Structural decisions with hidden rationale
|
|
160
168
|
- Trade-offs considered
|
|
169
|
+
- Revisit/exit trigger for strategic libraries and vendors
|
|
161
170
|
- If the user has no ADRs, help identify them from topics 1-9
|
|
162
171
|
|
|
163
|
-
## architecture.md Output
|
|
172
|
+
## architecture.md Output
|
|
164
173
|
|
|
165
|
-
|
|
166
|
-
# Architecture
|
|
174
|
+
After discovery is complete and immediately before generating `project-context/architecture.md`, read `assets/architecture.template.md`.
|
|
167
175
|
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
## Document Role
|
|
171
|
-
- **Source of Truth:** System design, technical constraints, and architecture decisions
|
|
172
|
-
- **Primary Owner:** `brainstorm-architecture`
|
|
173
|
-
- **Out of Scope:** Detailed API payload schemas, per-table database columns, UI design tokens, and task sequencing
|
|
174
|
-
|
|
175
|
-
## System Boundaries
|
|
176
|
-
| Topic | Canonical Document |
|
|
177
|
-
|-------|--------------------|
|
|
178
|
-
| Product scope and business intent | `project-context/PRD.md` |
|
|
179
|
-
| Data model and field-level contracts | `project-context/schema.md` |
|
|
180
|
-
| Endpoint contracts and error payloads | `project-context/api.md` |
|
|
181
|
-
| UI language and component styling | `project-context/StyleGuide.md` |
|
|
182
|
-
| Coding standards and AI behavior | `project-context/rules.md` |
|
|
183
|
-
| Execution order and implementation plan | `project-context/Task.md` |
|
|
184
|
-
|
|
185
|
-
---
|
|
186
|
-
|
|
187
|
-
## 1. System Context
|
|
188
|
-
|
|
189
|
-
**Users:** [End Users, Admins, etc.]
|
|
190
|
-
|
|
191
|
-
**External Services:**
|
|
192
|
-
| Service | Purpose | Protocol |
|
|
193
|
-
|---------|---------|----------|
|
|
194
|
-
| [Service] | [Purpose] | REST / SDK / OAuth |
|
|
195
|
-
|
|
196
|
-
## 2. Tech Stack
|
|
197
|
-
| Layer | Technology | Version | Notes |
|
|
198
|
-
|-------|------------|---------|-------|
|
|
199
|
-
| Frontend | [Framework] | [Version] | [Notes] |
|
|
200
|
-
| Backend | [Framework] | [Version] | [Notes] |
|
|
201
|
-
| Database | [Database] | [Version] | [Notes] |
|
|
202
|
-
| ORM | [ORM] | [Version] | [Notes] |
|
|
203
|
-
| Language | [Language] | [Version] | [Notes] |
|
|
204
|
-
|
|
205
|
-
## 3. State Management
|
|
206
|
-
- **Client State:** [Zustand / Redux / Context API]
|
|
207
|
-
- **Server State:** [TanStack Query / SWR]
|
|
208
|
-
- **Forms:** [React Hook Form / Formik]
|
|
209
|
-
- **Persistence:** [localStorage / sessionStorage / none]
|
|
210
|
-
|
|
211
|
-
## 4. API Design
|
|
212
|
-
- **Type:** REST / GraphQL / tRPC
|
|
213
|
-
- **Real-time:** WebSocket / SSE / No
|
|
214
|
-
- **Base Path:** `/api/v1`
|
|
215
|
-
|
|
216
|
-
## 5. Folder Structure
|
|
217
|
-
```
|
|
218
|
-
[Project Root]
|
|
219
|
-
├── [folder 1]/ # [description]
|
|
220
|
-
│ ├── [subfolder]/ # [description]
|
|
221
|
-
│ └── [file]
|
|
222
|
-
├── [folder 2]/ # [description]
|
|
223
|
-
└── [folder 3]/ # [description]
|
|
224
|
-
```
|
|
225
|
-
|
|
226
|
-
## 6. Design Pattern
|
|
227
|
-
- **Main Pattern:** MVC / Feature-based / Clean Architecture
|
|
228
|
-
- **Layers:** routes → controller → service → repository
|
|
229
|
-
- **Notes:** [Special rules]
|
|
230
|
-
|
|
231
|
-
## 7. Authentication & Authorization
|
|
232
|
-
- **Method:** JWT / Session / OAuth
|
|
233
|
-
- **Provider:** Google / GitHub / Custom
|
|
234
|
-
- **Token Storage:** httpOnly cookie
|
|
235
|
-
- **RBAC:** Yes / No
|
|
236
|
-
- **Roles:** [List with access levels]
|
|
237
|
-
|
|
238
|
-
## 8. Security & Abuse Cases
|
|
239
|
-
- **Sensitive Data:** [PII, tokens, payment data, etc.]
|
|
240
|
-
- **Critical Actions:** [Login, password reset, admin actions, upload, payment, etc.]
|
|
241
|
-
- **Abuse Cases:**
|
|
242
|
-
- [Brute force, spam, IDOR, CSRF, privilege escalation, replay, upload abuse, etc.]
|
|
243
|
-
- **Required Controls:**
|
|
244
|
-
- [Rate limiting, ownership checks, CSRF protection, audit logs, signed webhooks, secure session expiry]
|
|
245
|
-
- **Audit Logs:** [Which events must be recorded]
|
|
246
|
-
|
|
247
|
-
## 9. Deployment & Infrastructure
|
|
248
|
-
- **Platform:** Vercel / Railway / Docker+VPS / etc.
|
|
249
|
-
- **Environments:** development → staging → production
|
|
250
|
-
- **CI/CD:** GitHub Actions / etc.
|
|
251
|
-
- **CDN/Storage:** Cloudflare / S3 / etc.
|
|
252
|
-
- **Domain:** [Planned domain]
|
|
253
|
-
|
|
254
|
-
## 10. Canonical Terminology
|
|
255
|
-
| Term | Definition |
|
|
256
|
-
|------|------------|
|
|
257
|
-
| [Term] | [Definition in the project context] |
|
|
258
|
-
|
|
259
|
-
## 11. Architecture Decision Records (ADR)
|
|
260
|
-
|
|
261
|
-
### ADR Index
|
|
262
|
-
| ADR ID | Title | Status | Summary |
|
|
263
|
-
|--------|-------|--------|---------|
|
|
264
|
-
| ADR-001 | [Title] | Accepted / Proposed | [One-line reason] |
|
|
265
|
-
|
|
266
|
-
### ADR-001: [Title]
|
|
267
|
-
- **Context:** [Situation that led to the decision]
|
|
268
|
-
- **Decision:** [What was decided]
|
|
269
|
-
- **Rationale:** [Why this option]
|
|
270
|
-
- **Trade-off:** [Accepted downside]
|
|
271
|
-
- **Rejected Alternatives:** [What else was considered and why it was rejected]
|
|
272
|
-
|
|
273
|
-
---
|
|
274
|
-
|
|
275
|
-
## 12. Assumptions & Open Questions
|
|
276
|
-
|
|
277
|
-
### Assumptions
|
|
278
|
-
- [Assumption the architecture depends on]
|
|
279
|
-
|
|
280
|
-
### Open Questions
|
|
281
|
-
- [Question that is still unresolved]
|
|
282
|
-
````
|
|
176
|
+
Adapt only sections that are applicable and preserve every required contract from the interview. Do not load the template during early discovery.
|
|
283
177
|
|
|
284
178
|
## After architecture.md Is Created
|
|
285
179
|
|
|
@@ -296,6 +190,7 @@ Collect:
|
|
|
296
190
|
- **System Context (topic 1)** is the highest level. Start here before technical detail.
|
|
297
191
|
- **Threat modeling (topic 8)** is required before implementation.
|
|
298
192
|
- **ADR (topic 10)** helps prevent accidental reversal of mature decisions.
|
|
193
|
+
- Use the strategic dependency checklist only for architecture-level choices; local packages remain a `developer` decision.
|
|
299
194
|
- Render the final document in the configured document language
|
|
300
195
|
|
|
301
196
|
|
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
# Architecture
|
|
2
|
+
|
|
3
|
+
> **Version:** 1.0 | **Date:** [date]
|
|
4
|
+
|
|
5
|
+
## Document Role
|
|
6
|
+
- **Source of Truth:** System design, technical constraints, and architecture decisions
|
|
7
|
+
- **Primary Owner:** `brainstorm-architecture`
|
|
8
|
+
- **Out of Scope:** Detailed API payload schemas, per-table database columns, UI design tokens, and task sequencing
|
|
9
|
+
|
|
10
|
+
## System Boundaries
|
|
11
|
+
| Topic | Canonical Document |
|
|
12
|
+
|-------|--------------------|
|
|
13
|
+
| Product scope and business intent | `project-context/PRD.md` |
|
|
14
|
+
| Data model and field-level contracts | `project-context/schema.md` |
|
|
15
|
+
| Endpoint contracts and error payloads | `project-context/api.md` |
|
|
16
|
+
| UI language and component styling | `project-context/StyleGuide.md` |
|
|
17
|
+
| Coding standards and AI behavior | `project-context/rules.md` |
|
|
18
|
+
| Execution order and implementation plan | `project-context/Task.md` |
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 1. System Context
|
|
23
|
+
|
|
24
|
+
**Users:** [End Users, Admins, etc.]
|
|
25
|
+
|
|
26
|
+
**External Services:**
|
|
27
|
+
| Service | Purpose | Protocol |
|
|
28
|
+
|---------|---------|----------|
|
|
29
|
+
| [Service] | [Purpose] | REST / SDK / OAuth |
|
|
30
|
+
|
|
31
|
+
## 2. Tech Stack
|
|
32
|
+
| Layer | Technology | Version | Notes |
|
|
33
|
+
|-------|------------|---------|-------|
|
|
34
|
+
| Frontend | [Framework] | [Version] | [Notes] |
|
|
35
|
+
| Backend | [Framework] | [Version] | [Notes] |
|
|
36
|
+
| Database | [Database] | [Version] | [Notes] |
|
|
37
|
+
| ORM | [ORM] | [Version] | [Notes] |
|
|
38
|
+
| Language | [Language] | [Version] | [Notes] |
|
|
39
|
+
|
|
40
|
+
### Strategic Dependency Evaluation
|
|
41
|
+
| Dependency/Vendor | Why Needed | Native/Existing Alternative | License & Health | Lock-in / Exit Path | Decision |
|
|
42
|
+
|-------------------|------------|-----------------------------|------------------|---------------------|----------|
|
|
43
|
+
| [name] | [reason] | [alternative] | [evidence] | [migration/removal] | Accepted / Proposed |
|
|
44
|
+
|
|
45
|
+
## 3. State Management
|
|
46
|
+
- **Client State:** [Zustand / Redux / Context API]
|
|
47
|
+
- **Server State:** [TanStack Query / SWR]
|
|
48
|
+
- **Forms:** [React Hook Form / Formik]
|
|
49
|
+
- **Persistence:** [localStorage / sessionStorage / none]
|
|
50
|
+
|
|
51
|
+
## 4. API Design
|
|
52
|
+
- **Type:** REST / GraphQL / tRPC / Event-driven / Mixed
|
|
53
|
+
- **Primary Entry Point:** [base path / endpoint / router / broker namespace]
|
|
54
|
+
- **Realtime / Delivery:** WebSocket / SSE / queue / stream / none
|
|
55
|
+
|
|
56
|
+
## 5. Folder Structure
|
|
57
|
+
```
|
|
58
|
+
[Project Root]
|
|
59
|
+
├── [folder 1]/ # [description]
|
|
60
|
+
│ ├── [subfolder]/ # [description]
|
|
61
|
+
│ └── [file]
|
|
62
|
+
├── [folder 2]/ # [description]
|
|
63
|
+
└── [folder 3]/ # [description]
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## 6. Design Pattern
|
|
67
|
+
- **Main Pattern:** MVC / Feature-based / Clean Architecture
|
|
68
|
+
- **Layers:** routes → controller → service → repository
|
|
69
|
+
- **Notes:** [Special rules]
|
|
70
|
+
|
|
71
|
+
## 7. Authentication & Authorization
|
|
72
|
+
- **Method:** JWT / Session / OAuth
|
|
73
|
+
- **Provider:** Google / GitHub / Custom
|
|
74
|
+
- **Token Storage:** httpOnly cookie
|
|
75
|
+
- **RBAC:** Yes / No
|
|
76
|
+
- **Roles:** [List with access levels]
|
|
77
|
+
|
|
78
|
+
## 8. Security & Abuse Cases
|
|
79
|
+
- **Sensitive Data:** [PII, tokens, payment data, etc.]
|
|
80
|
+
- **Critical Actions:** [Login, password reset, admin actions, upload, payment, etc.]
|
|
81
|
+
- **Abuse Cases:**
|
|
82
|
+
- [Brute force, spam, IDOR, CSRF, privilege escalation, replay, upload abuse, etc.]
|
|
83
|
+
- **Required Controls:**
|
|
84
|
+
- [Rate limiting, ownership checks, CSRF protection, audit logs, signed webhooks, secure session expiry]
|
|
85
|
+
- **Audit Logs:** [Which events must be recorded]
|
|
86
|
+
|
|
87
|
+
## 9. Deployment & Infrastructure
|
|
88
|
+
- **Platform:** Vercel / Railway / Docker+VPS / etc.
|
|
89
|
+
- **Environments:** development → staging → production
|
|
90
|
+
- **CI/CD:** GitHub Actions / etc.
|
|
91
|
+
- **CDN/Storage:** Cloudflare / S3 / etc.
|
|
92
|
+
- **Domain:** [Planned domain]
|
|
93
|
+
|
|
94
|
+
### Operations & Observability
|
|
95
|
+
- **Operational Owner:** [team/role]
|
|
96
|
+
- **Runbook / Support:** [location and escalation]
|
|
97
|
+
- **Logs:** [events, redaction, retention]
|
|
98
|
+
- **Metrics & Traces:** [signals tied to NFR/success metrics]
|
|
99
|
+
- **Alerts:** [threshold, owner, escalation]
|
|
100
|
+
|
|
101
|
+
### Rollback and Recovery
|
|
102
|
+
- **Rollback Trigger:** [condition]
|
|
103
|
+
- **Rollback Mechanism:** [deployment/data strategy]
|
|
104
|
+
- **Post-Rollback Validation:** [checks]
|
|
105
|
+
- **Backup / Restore:** [scope and test cadence]
|
|
106
|
+
- **RPO / RTO:** [critical systems only]
|
|
107
|
+
|
|
108
|
+
## 10. Canonical Terminology
|
|
109
|
+
| Term | Definition |
|
|
110
|
+
|------|------------|
|
|
111
|
+
| [Term] | [Definition in the project context] |
|
|
112
|
+
|
|
113
|
+
## 11. Architecture Decision Records (ADR)
|
|
114
|
+
|
|
115
|
+
### ADR Index
|
|
116
|
+
| ADR ID | Title | Status | Summary |
|
|
117
|
+
|--------|-------|--------|---------|
|
|
118
|
+
| ADR-001 | [Title] | Accepted / Proposed | [One-line reason] |
|
|
119
|
+
|
|
120
|
+
### ADR-001: [Title]
|
|
121
|
+
- **Context:** [Situation that led to the decision]
|
|
122
|
+
- **Decision:** [What was decided]
|
|
123
|
+
- **Rationale:** [Why this option]
|
|
124
|
+
- **Trade-off:** [Accepted downside]
|
|
125
|
+
- **Rejected Alternatives:** [What else was considered and why it was rejected]
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
## 12. Assumptions & Open Questions
|
|
130
|
+
|
|
131
|
+
### Assumptions
|
|
132
|
+
- [Assumption the architecture depends on]
|
|
133
|
+
|
|
134
|
+
### Open Questions
|
|
135
|
+
- [Question that is still unresolved]
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brainstorm-prd
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
3
|
+
description: Interviews users and generates `PRD.md` with scope, outcomes, metrics, rollout, business rules, and traceability. Use only when the user explicitly wants to define a new product or create/recreate its PRD.
|
|
4
|
+
compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
|
|
5
|
+
metadata:
|
|
6
|
+
persona: "Galbi"
|
|
7
|
+
persona-role: "Project Manager"
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# Brainstorm PRD
|
|
@@ -34,12 +36,13 @@ You are an experienced **Product Manager** who turns raw ideas into clear, actio
|
|
|
34
36
|
|
|
35
37
|
Before any interview:
|
|
36
38
|
|
|
37
|
-
1. Read `../_shared/references/
|
|
38
|
-
2. Read `../_shared/references/
|
|
39
|
-
3. Read `../_shared/references/
|
|
39
|
+
1. Read `../_shared/references/language-config.md`.
|
|
40
|
+
2. Read `../_shared/references/config-mutation.md`.
|
|
41
|
+
3. Read `../_shared/references/brainstorm-session.md`.
|
|
42
|
+
4. Read `../_shared/references/scope-rules.md`.
|
|
40
43
|
4. Use `languagePreferences.communication.normalized` for chat.
|
|
41
44
|
5. Use `languagePreferences.documents.normalized` for the final `project-context/PRD.md`.
|
|
42
|
-
6. Apply `brainstormPreferences.discussionMode` and `
|
|
45
|
+
6. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
|
|
43
46
|
|
|
44
47
|
---
|
|
45
48
|
|
|
@@ -55,7 +58,7 @@ Before any interview:
|
|
|
55
58
|
- `backend` → PRD MUST focus on business rules, service/API/data/auth, and consumer dependencies
|
|
56
59
|
- `fullstack` → full PRD
|
|
57
60
|
|
|
58
|
-
4. Run the shared runtime setup above
|
|
61
|
+
4. Run the shared runtime setup above and apply all three pacing modes from the shared session policy. If preferences are saved, announce and proceed without another confirmation.
|
|
59
62
|
|
|
60
63
|
5. Run the interview in the chosen mode. Wait for the answer before continuing.
|
|
61
64
|
|
|
@@ -90,6 +93,7 @@ Collect:
|
|
|
90
93
|
|
|
91
94
|
Collect:
|
|
92
95
|
- Current condition without this project
|
|
96
|
+
- Current workaround and its time, cost, or reliability impact
|
|
93
97
|
- Main pain points
|
|
94
98
|
- Why existing solutions are not enough
|
|
95
99
|
|
|
@@ -117,6 +121,7 @@ Collect:
|
|
|
117
121
|
- Step-by-step user journey
|
|
118
122
|
- Different flows for different roles
|
|
119
123
|
- Happy path vs error scenarios
|
|
124
|
+
- Expected degraded behavior when data or an external dependency is unavailable
|
|
120
125
|
|
|
121
126
|
### 7. Design & Technical Requirements
|
|
122
127
|
*"What is the target platform: web, mobile, or both? Any design references or technical preferences?"*
|
|
@@ -142,8 +147,10 @@ Collect:
|
|
|
142
147
|
|
|
143
148
|
Collect:
|
|
144
149
|
- MVP criteria
|
|
145
|
-
- Success metrics
|
|
150
|
+
- Success metrics with baseline, target, timeframe, measurement source, and owner
|
|
146
151
|
- Timeline/deadline
|
|
152
|
+
- Product rollout: pilot/beta/phased/full launch, target audience, and readiness criteria
|
|
153
|
+
- Analytics events needed to measure the selected metrics, only when behavioral measurement is relevant
|
|
147
154
|
|
|
148
155
|
### 10. Acceptance Criteria
|
|
149
156
|
*"For each main feature, what conditions must be met for it to count as 'done'?"*
|
|
@@ -202,101 +209,11 @@ All requirements must have stable Traceability IDs:
|
|
|
202
209
|
|
|
203
210
|
Do not renumber old IDs in future updates; append new IDs sequentially.
|
|
204
211
|
|
|
205
|
-
## PRD.md Output
|
|
212
|
+
## PRD.md Output
|
|
206
213
|
|
|
207
|
-
|
|
208
|
-
# PRD: [Project Name]
|
|
214
|
+
After discovery is complete and immediately before generating `project-context/PRD.md`, read `assets/PRD.template.md`.
|
|
209
215
|
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
## Document Role
|
|
213
|
-
- **Source of Truth:** Product scope, user intent, business rules, and success criteria
|
|
214
|
-
- **Primary Owner:** `brainstorm-prd`
|
|
215
|
-
- **Out of Scope:** API payload details, schema column definitions, code patterns, and implementation order
|
|
216
|
-
|
|
217
|
-
## Canonical Terminology
|
|
218
|
-
| Term | Meaning |
|
|
219
|
-
|------|---------|
|
|
220
|
-
| [Term] | [Exact meaning in this project] |
|
|
221
|
-
|
|
222
|
-
---
|
|
223
|
-
|
|
224
|
-
## 1. Project Goal
|
|
225
|
-
[Goal and vision — 1-2 paragraphs]
|
|
226
|
-
|
|
227
|
-
## 2. Target Users
|
|
228
|
-
| Persona | Description | Role |
|
|
229
|
-
|---------|-------------|------|
|
|
230
|
-
| [Persona 1] | [Description] | End User / Admin / etc |
|
|
231
|
-
|
|
232
|
-
## 3. Problem Statement
|
|
233
|
-
[Problem being solved]
|
|
234
|
-
|
|
235
|
-
## 4. Core Features
|
|
236
|
-
### MVP (Release 1)
|
|
237
|
-
| ID | Feature | Description | Priority |
|
|
238
|
-
|----|---------|-------------|----------|
|
|
239
|
-
| FEAT-01 | [Feature] | [Description] | High |
|
|
240
|
-
|
|
241
|
-
### Future Enhancements
|
|
242
|
-
- **FEAT-02:** [Feature] — [Description]
|
|
243
|
-
|
|
244
|
-
## 5. Business Rules
|
|
245
|
-
- **BR-01:** [Rule]
|
|
246
|
-
- **BR-02:** [Rule]
|
|
247
|
-
|
|
248
|
-
## 6. User Flow
|
|
249
|
-
### [Persona 1]
|
|
250
|
-
1. [Step 1]
|
|
251
|
-
2. [Step 2]
|
|
252
|
-
|
|
253
|
-
## 7. Design & Technical Requirements
|
|
254
|
-
- **Platform:** Web / Mobile / Desktop
|
|
255
|
-
- **UI Reference:** [Link or name]
|
|
256
|
-
- **Tech Stack (preferred):** [If any]
|
|
257
|
-
- **Integrations:** [Third-party services]
|
|
258
|
-
|
|
259
|
-
## 8. Non-Functional Requirements
|
|
260
|
-
| ID | Category | Requirement | Target |
|
|
261
|
-
|----|----------|-------------|--------|
|
|
262
|
-
| NFR-01 | Performance | Page load time | < 3 seconds |
|
|
263
|
-
| NFR-02 | Security | [Requirement] | [Target] |
|
|
264
|
-
| NFR-03 | Scalability | Concurrent users | [Count] |
|
|
265
|
-
| NFR-04 | Accessibility | [Requirement] | [Target] |
|
|
266
|
-
|
|
267
|
-
## 9. Success Criteria (Minimum)
|
|
268
|
-
- [ ] [Criterion 1]
|
|
269
|
-
- [ ] [Criterion 2]
|
|
270
|
-
|
|
271
|
-
## 10. Acceptance Criteria
|
|
272
|
-
### FEAT-01: [Feature Name]
|
|
273
|
-
- **AC-01:** **Given** [starting condition], **When** [user action], **Then** [expected result]
|
|
274
|
-
|
|
275
|
-
## 11. Non-Goals / Out of Scope
|
|
276
|
-
- [What will NOT be done]
|
|
277
|
-
|
|
278
|
-
## 12. Assumptions
|
|
279
|
-
- [Assumption 1]
|
|
280
|
-
- [Assumption 2]
|
|
281
|
-
|
|
282
|
-
## 13. User Stories
|
|
283
|
-
- **US-01:** As a **[role]**, I want **[feature]** so that **[benefit]**
|
|
284
|
-
|
|
285
|
-
## 14. Stakeholders
|
|
286
|
-
| Name/Role | Responsibility |
|
|
287
|
-
|-----------|----------------|
|
|
288
|
-
| [Name] | [Role] |
|
|
289
|
-
|
|
290
|
-
## 15. Open Questions
|
|
291
|
-
| Question | Status | Owner |
|
|
292
|
-
|----------|--------|-------|
|
|
293
|
-
| [Question] | Pending | [Who] |
|
|
294
|
-
|
|
295
|
-
## Reading Guide for AI
|
|
296
|
-
- If this PRD conflicts with detailed implementation documents, the PRD wins on business intent and scope.
|
|
297
|
-
- If a term is ambiguous, prioritize the definition in `Canonical Terminology`.
|
|
298
|
-
- Use `Non-Goals / Out of Scope`, `Assumptions`, and `Open Questions` to avoid building more than necessary.
|
|
299
|
-
````
|
|
216
|
+
Adapt only sections that are applicable and preserve every required contract from the interview. Do not load the template during early discovery.
|
|
300
217
|
|
|
301
218
|
## After PRD.md Is Created
|
|
302
219
|
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
# PRD: [Project Name]
|
|
2
|
+
|
|
3
|
+
> **Version:** 1.0 | **Date:** [date] | **Status:** Draft
|
|
4
|
+
|
|
5
|
+
## Document Role
|
|
6
|
+
- **Source of Truth:** Product scope, user intent, business rules, and success criteria
|
|
7
|
+
- **Primary Owner:** `brainstorm-prd`
|
|
8
|
+
- **Out of Scope:** API payload details, schema column definitions, code patterns, and implementation order
|
|
9
|
+
|
|
10
|
+
## Canonical Terminology
|
|
11
|
+
| Term | Meaning |
|
|
12
|
+
|------|---------|
|
|
13
|
+
| [Term] | [Exact meaning in this project] |
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 1. Project Goal
|
|
18
|
+
[Goal and vision — 1-2 paragraphs]
|
|
19
|
+
|
|
20
|
+
## 2. Target Users
|
|
21
|
+
| Persona | Description | Role |
|
|
22
|
+
|---------|-------------|------|
|
|
23
|
+
| [Persona 1] | [Description] | End User / Admin / etc |
|
|
24
|
+
|
|
25
|
+
## 3. Problem Statement
|
|
26
|
+
[Problem being solved]
|
|
27
|
+
|
|
28
|
+
### Current Workaround
|
|
29
|
+
- **How users handle it now:** [workaround]
|
|
30
|
+
- **Cost / limitation:** [time, money, risk, or reliability impact]
|
|
31
|
+
|
|
32
|
+
## 4. Core Features
|
|
33
|
+
### MVP (Release 1)
|
|
34
|
+
| ID | Feature | Description | Priority |
|
|
35
|
+
|----|---------|-------------|----------|
|
|
36
|
+
| FEAT-01 | [Feature] | [Description] | High |
|
|
37
|
+
|
|
38
|
+
### Future Enhancements
|
|
39
|
+
- **FEAT-02:** [Feature] — [Description]
|
|
40
|
+
|
|
41
|
+
## 5. Business Rules
|
|
42
|
+
- **BR-01:** [Rule]
|
|
43
|
+
- **BR-02:** [Rule]
|
|
44
|
+
|
|
45
|
+
## 6. User Flow
|
|
46
|
+
### [Persona 1]
|
|
47
|
+
1. [Step 1]
|
|
48
|
+
2. [Step 2]
|
|
49
|
+
|
|
50
|
+
### Failure and Degraded Behavior
|
|
51
|
+
| Situation | Expected User Experience | Recovery |
|
|
52
|
+
|-----------|--------------------------|----------|
|
|
53
|
+
| [Dependency/data unavailable] | [behavior] | [retry/fallback/support] |
|
|
54
|
+
|
|
55
|
+
## 7. Design & Technical Requirements
|
|
56
|
+
- **Platform:** Web / Mobile / Desktop
|
|
57
|
+
- **UI Reference:** [Link or name]
|
|
58
|
+
- **Tech Stack (preferred):** [If any]
|
|
59
|
+
- **Integrations:** [Third-party services]
|
|
60
|
+
|
|
61
|
+
## 8. Non-Functional Requirements
|
|
62
|
+
| ID | Category | Requirement | Target |
|
|
63
|
+
|----|----------|-------------|--------|
|
|
64
|
+
| NFR-01 | Performance | Page load time | < 3 seconds |
|
|
65
|
+
| NFR-02 | Security | [Requirement] | [Target] |
|
|
66
|
+
| NFR-03 | Scalability | Concurrent users | [Count] |
|
|
67
|
+
| NFR-04 | Accessibility | [Requirement] | [Target] |
|
|
68
|
+
|
|
69
|
+
## 9. Success Metrics and Rollout
|
|
70
|
+
| Metric | Baseline | Target | Timeframe | Measurement Source | Owner |
|
|
71
|
+
|--------|----------|--------|-----------|--------------------|-------|
|
|
72
|
+
| [Metric] | [current/unknown] | [target] | [period] | [analytics/report] | [owner] |
|
|
73
|
+
|
|
74
|
+
**Rollout:** [pilot / beta / phased / full]
|
|
75
|
+
**Target Audience:** [initial cohort]
|
|
76
|
+
**Readiness Criteria:** [conditions before expansion]
|
|
77
|
+
**Analytics Events:** [only events required to measure the metrics]
|
|
78
|
+
|
|
79
|
+
## 10. Acceptance Criteria
|
|
80
|
+
### FEAT-01: [Feature Name]
|
|
81
|
+
- **AC-01:** **Given** [starting condition], **When** [user action], **Then** [expected result]
|
|
82
|
+
|
|
83
|
+
## 11. Non-Goals / Out of Scope
|
|
84
|
+
- [What will NOT be done]
|
|
85
|
+
|
|
86
|
+
## 12. Assumptions
|
|
87
|
+
- [Assumption 1]
|
|
88
|
+
- [Assumption 2]
|
|
89
|
+
|
|
90
|
+
## 13. User Stories
|
|
91
|
+
- **US-01:** As a **[role]**, I want **[feature]** so that **[benefit]**
|
|
92
|
+
|
|
93
|
+
## 14. Stakeholders
|
|
94
|
+
| Name/Role | Responsibility |
|
|
95
|
+
|-----------|----------------|
|
|
96
|
+
| [Name] | [Role] |
|
|
97
|
+
|
|
98
|
+
## 15. Open Questions
|
|
99
|
+
| Question | Status | Owner |
|
|
100
|
+
|----------|--------|-------|
|
|
101
|
+
| [Question] | Pending | [Who] |
|
|
102
|
+
|
|
103
|
+
## Reading Guide for AI
|
|
104
|
+
- If this PRD conflicts with detailed implementation documents, the PRD wins on business intent and scope.
|
|
105
|
+
- If a term is ambiguous, prioritize the definition in `Canonical Terminology`.
|
|
106
|
+
- Use `Non-Goals / Out of Scope`, `Assumptions`, and `Open Questions` to avoid building more than necessary.
|