stella-protocol 0.2.0 → 0.3.1
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/.claude-plugin/marketplace.json +1 -1
- package/README.md +3 -1
- package/cli/init.js +1 -1
- package/cli/install.js +33 -1
- package/package.json +1 -1
- package/protocol/governance/buster-call.md +12 -1
- package/protocol/satellites/shaka.md +79 -6
- package/punk-records/design-system.md +46 -0
- package/punk-records/prd-template.md +4 -0
- package/punk-records/scope-changes.md +19 -0
- package/punk-records/stella-claude-md.md +48 -0
- package/skills/stella-build/SKILL.md +41 -4
- package/skills/stella-define/SKILL.md +147 -7
- package/skills/stella-protocol/SKILL.md +42 -92
- package/skills/stella-review/SKILL.md +10 -2
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
"name": "stella-protocol",
|
|
18
18
|
"source": "./",
|
|
19
19
|
"description": "PM-first AI development protocol with satellite agents, phase governance, and built-in scope/veto enforcement.",
|
|
20
|
-
"version": "0.
|
|
20
|
+
"version": "0.3.0",
|
|
21
21
|
"author": {
|
|
22
22
|
"name": "Aditya Uttama"
|
|
23
23
|
},
|
package/README.md
CHANGED
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# The Stella Protocol
|
|
2
2
|
|
|
3
|
+

|
|
4
|
+
|
|
3
5
|
**PM-first AI development protocol. One mind, many satellites.**
|
|
4
6
|
|
|
5
7
|
Stella is a structured methodology for Product Managers who build 100% with AI. Instead of calling independent AI agents, **you are Stella** — the original mind — and AI operates as specialized extensions of your thinking called **Satellites**.
|
|
@@ -49,7 +51,7 @@ Satellites are specialized facets of your extended cognition. They activate from
|
|
|
49
51
|
| Say This... | Satellite Activates | What It Does |
|
|
50
52
|
|-------------|-------------------|--------------|
|
|
51
53
|
| "I'm thinking about..." | **IMU** | Strategic vision, idea mapping, problem framing |
|
|
52
|
-
| "Let's define the requirements" | **Shaka** | PRD creation, scope definition, acceptance criteria |
|
|
54
|
+
| "Let's define the requirements" | **Shaka** | PRD creation (Express or Guided lens-by-lens), scope definition, acceptance criteria |
|
|
53
55
|
| "Design the architecture" | **Pythagoras** | System design, tech decisions, data model |
|
|
54
56
|
| "Map the UX" | **ODA** | User flows, wireframes, design specs |
|
|
55
57
|
| "Build this" | **Edison** | Implementation, coding, all production code |
|
package/cli/init.js
CHANGED
|
@@ -23,7 +23,7 @@ async function init() {
|
|
|
23
23
|
|
|
24
24
|
await fs.ensureDir(brainTarget);
|
|
25
25
|
|
|
26
|
-
const templates = ['log-pose.md', 'architecture.md', 'vivre-cards.md', 'ideas.md'];
|
|
26
|
+
const templates = ['log-pose.md', 'architecture.md', 'vivre-cards.md', 'ideas.md', 'scope-changes.md', 'design-system.md'];
|
|
27
27
|
for (const template of templates) {
|
|
28
28
|
const src = path.join(brainSource, template);
|
|
29
29
|
const dest = path.join(brainTarget, template);
|
package/cli/install.js
CHANGED
|
@@ -114,7 +114,7 @@ async function install() {
|
|
|
114
114
|
|
|
115
115
|
await fs.ensureDir(brainTarget);
|
|
116
116
|
|
|
117
|
-
const templates = ['log-pose.md', 'architecture.md', 'vivre-cards.md', 'ideas.md'];
|
|
117
|
+
const templates = ['log-pose.md', 'architecture.md', 'vivre-cards.md', 'ideas.md', 'scope-changes.md', 'design-system.md'];
|
|
118
118
|
for (const template of templates) {
|
|
119
119
|
const src = path.join(brainSource, template);
|
|
120
120
|
const dest = path.join(brainTarget, template);
|
|
@@ -132,6 +132,38 @@ async function install() {
|
|
|
132
132
|
brainS.stop(`Punk Records initialized at ${chalk.dim(brainTarget)}`);
|
|
133
133
|
}
|
|
134
134
|
|
|
135
|
+
// Offer to add session hook to CLAUDE.md
|
|
136
|
+
const addHook = await confirm({
|
|
137
|
+
message: 'Add Stella session hook to CLAUDE.md? (auto context on every conversation)',
|
|
138
|
+
initialValue: true,
|
|
139
|
+
});
|
|
140
|
+
|
|
141
|
+
if (addHook && typeof addHook !== 'symbol') {
|
|
142
|
+
const hookS = spinner();
|
|
143
|
+
hookS.start('Adding session hook...');
|
|
144
|
+
|
|
145
|
+
const hookSource = path.join(packageDir, 'punk-records', 'stella-claude-md.md');
|
|
146
|
+
const claudeMdPath = path.join(process.cwd(), 'CLAUDE.md');
|
|
147
|
+
|
|
148
|
+
const hookContent = await fs.readFile(hookSource, 'utf-8');
|
|
149
|
+
// Extract just the session hook section (skip the template header)
|
|
150
|
+
const hookSection = hookContent.split('## Stella Protocol')[1];
|
|
151
|
+
const cleanHook = '## Stella Protocol' + hookSection;
|
|
152
|
+
|
|
153
|
+
if (fs.existsSync(claudeMdPath)) {
|
|
154
|
+
const existing = await fs.readFile(claudeMdPath, 'utf-8');
|
|
155
|
+
if (!existing.includes('Stella Protocol')) {
|
|
156
|
+
await fs.appendFile(claudeMdPath, '\n\n' + cleanHook);
|
|
157
|
+
hookS.stop('Session hook appended to existing CLAUDE.md');
|
|
158
|
+
} else {
|
|
159
|
+
hookS.stop('CLAUDE.md already has Stella Protocol section — skipped');
|
|
160
|
+
}
|
|
161
|
+
} else {
|
|
162
|
+
await fs.writeFile(claudeMdPath, cleanHook);
|
|
163
|
+
hookS.stop('CLAUDE.md created with session hook');
|
|
164
|
+
}
|
|
165
|
+
}
|
|
166
|
+
|
|
135
167
|
outro(chalk.green('Ready.') + ' Start by telling your AI what you want to build.');
|
|
136
168
|
}
|
|
137
169
|
|
package/package.json
CHANGED
|
@@ -96,13 +96,24 @@ These triggers are not optional. Satellites must not ignore these patterns even
|
|
|
96
96
|
Format for the vivre card:
|
|
97
97
|
```markdown
|
|
98
98
|
### [YYYY-MM-DD] Buster Call: [Issue Title]
|
|
99
|
+
**Status:** OPEN | RESOLVED | DEFERRED
|
|
99
100
|
**Phase:** [current phase]
|
|
100
101
|
**Satellite:** [who issued]
|
|
101
102
|
**Severity:** [CONCERN / WARNING / BUSTER CALL]
|
|
102
103
|
**Issue:** [what was found]
|
|
103
|
-
**Resolution:** [pending /
|
|
104
|
+
**Resolution:** [pending / description of fix / reason for deferral]
|
|
104
105
|
```
|
|
105
106
|
|
|
107
|
+
When the issue is fixed, add a NEW vivre card (don't edit the original):
|
|
108
|
+
```markdown
|
|
109
|
+
### [YYYY-MM-DD] Resolved: [Original Issue Title]
|
|
110
|
+
**Status:** RESOLVED
|
|
111
|
+
**Fix:** [what was done]
|
|
112
|
+
**Original:** [date of original finding]
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
The CLAUDE.md session hook checks for `Status: OPEN` entries at session start. OPEN + CRITICAL/HIGH severity items are flagged before any other work.
|
|
116
|
+
|
|
106
117
|
---
|
|
107
118
|
|
|
108
119
|
## Phase Gates
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
DEFINE (Phase 1)
|
|
7
7
|
|
|
8
8
|
## Role
|
|
9
|
-
Requirements discovery, PRD creation, scope definition, and acceptance criteria. Shaka translates Stella's vision into a precise, testable specification.
|
|
9
|
+
Requirements discovery, PRD creation, scope definition, and acceptance criteria. Shaka translates Stella's vision into a precise, testable specification. Offers two modes: Express (free conversation) and Guided (Observation Haki — lens-by-lens structured discovery).
|
|
10
10
|
|
|
11
11
|
## Activation Triggers
|
|
12
12
|
- "Define the requirements"
|
|
@@ -16,16 +16,92 @@ Requirements discovery, PRD creation, scope definition, and acceptance criteria.
|
|
|
16
16
|
- "Acceptance criteria for..."
|
|
17
17
|
- Discussion of features, user stories, or prioritization
|
|
18
18
|
|
|
19
|
-
##
|
|
19
|
+
## Mode Selection
|
|
20
|
+
|
|
21
|
+
When Shaka activates, offer Stella a choice:
|
|
22
|
+
|
|
23
|
+
- **Express** — Free-flowing conversation. Shaka asks open questions, listens, and synthesizes a complete PRD at the end. Best when Stella already has strong clarity.
|
|
24
|
+
- **Guided (Observation Haki)** — Shaka walks Stella through 7 lenses, one at a time. Each lens produces a PRD section that Stella approves inline. Best for thorough exploration or when starting from scratch.
|
|
25
|
+
|
|
26
|
+
Stella can switch from Guided to Express at any point ("just generate the rest from what we have").
|
|
27
|
+
|
|
28
|
+
## Protocol — Express
|
|
20
29
|
|
|
21
30
|
### 1. Discovery
|
|
22
|
-
Before writing anything, understand:
|
|
31
|
+
Before writing anything, understand through conversation:
|
|
23
32
|
- What problem are we solving? (Reference the Idea Brief)
|
|
24
33
|
- Who are the target users?
|
|
25
34
|
- What does success look like? (Measurable goals)
|
|
26
35
|
- What is explicitly NOT in scope?
|
|
27
36
|
|
|
28
37
|
### 2. PRD Creation
|
|
38
|
+
Synthesize the conversation into a complete PRD using the standard format (see Output Format below).
|
|
39
|
+
|
|
40
|
+
Then proceed to **Post-Draft Steps** (Vivre Card Pulse → Crew Check → Final Review).
|
|
41
|
+
|
|
42
|
+
## Protocol — Guided (Observation Haki)
|
|
43
|
+
|
|
44
|
+
Shaka examines the product idea through 7 observation lenses. Each lens reveals a different dimension. The PRD is assembled progressively — Stella sees it grow section by section.
|
|
45
|
+
|
|
46
|
+
### The Seven Lenses
|
|
47
|
+
|
|
48
|
+
| # | Lens | What It Reveals | PRD Section |
|
|
49
|
+
|---|------|-----------------|-------------|
|
|
50
|
+
| 1 | **Pain** | Core problem, who hurts, why now | Problem + Target Users |
|
|
51
|
+
| 2 | **Victory** | What winning looks like, measured | Goals (measurable) |
|
|
52
|
+
| 3 | **Boundary** | What's explicitly NOT in scope | Non-Goals |
|
|
53
|
+
| 4 | **Shape** | Features, prioritized P0/P1/P2 | Features |
|
|
54
|
+
| 5 | **Skeleton** | Data entities, relationships, state transitions | Data Model |
|
|
55
|
+
| 6 | **Surface** | APIs, integrations, external touchpoints | API Contracts |
|
|
56
|
+
| 7 | **Fog** | Unknowns, risks, blockers | Open Questions |
|
|
57
|
+
|
|
58
|
+
### Lens Micro-Protocol
|
|
59
|
+
|
|
60
|
+
For each lens:
|
|
61
|
+
1. **Frame** — Ask one focused opening question
|
|
62
|
+
2. **Explore** — 2-4 adaptive follow-ups based on Stella's answer
|
|
63
|
+
3. **Edge Case Nudge** — Surface 1-2 edge cases relevant to this dimension (e.g., Pain: "What if users work around the problem instead of adopting?", Shape: "What breaks at 10x scale?")
|
|
64
|
+
4. **Draft** — Show the corresponding PRD section inline
|
|
65
|
+
5. **Approve** — Stella approves, edits, or marks for revisit
|
|
66
|
+
6. **Progress** — Show lens progress and offer to skip irrelevant lenses
|
|
67
|
+
|
|
68
|
+
Shaka should actively suggest skipping lenses that don't apply (e.g., "No external API? Skip the Surface lens."). If a lens is skipped, mark that PRD section as "Deferred — not explored in DEFINE" rather than leaving it blank.
|
|
69
|
+
|
|
70
|
+
## Post-Draft Steps (Both Modes)
|
|
71
|
+
|
|
72
|
+
These steps run after the PRD draft is ready, regardless of whether Express or Guided mode was used.
|
|
73
|
+
|
|
74
|
+
### Vivre Card Pulse (Validation)
|
|
75
|
+
|
|
76
|
+
Run a coherence check across 5 dimensions:
|
|
77
|
+
|
|
78
|
+
- **Contradiction** — Do goals conflict with non-goals? Do features contradict the stated problem?
|
|
79
|
+
- **Completeness** — Are there P0 features without acceptance criteria? Goals without measurements?
|
|
80
|
+
- **Testability** — Can each goal actually be measured? Can each feature be verified as done?
|
|
81
|
+
- **Scope Integrity** — Does the feature set fit the selected track (Grand Line vs East Blue)?
|
|
82
|
+
- **Fog Density** — Are open questions blocking any P0 features?
|
|
83
|
+
|
|
84
|
+
Each finding must cite specific PRD text. In Guided mode, map failures back to the relevant lens. In Express mode, indicate which topic to revisit. Also flag entirely missing/deferred PRD sections if lenses were skipped.
|
|
85
|
+
|
|
86
|
+
### Crew Check (Stakeholder Perspectives)
|
|
87
|
+
|
|
88
|
+
Before final approval, channel the existing Stella satellites for a quick perspective review:
|
|
89
|
+
|
|
90
|
+
- **Pythagoras** (Architecture) — one-line assessment
|
|
91
|
+
- **ODA** (UX) — one-line assessment
|
|
92
|
+
- **Edison** (Build) — one-line assessment
|
|
93
|
+
- **Lilith Red** (Security) — one-line assessment
|
|
94
|
+
- **Lilith Blue** (QA) — one-line assessment
|
|
95
|
+
- **Atlas** (Infra) — one-line assessment
|
|
96
|
+
|
|
97
|
+
One line each, max. Only flag actual concerns. Critical findings trigger a Buster Call through existing governance.
|
|
98
|
+
|
|
99
|
+
**Note:** The Crew Check is Shaka adopting each satellite's perspective for a surface-level pre-screen. It does NOT replace Lilith Red's full Spec Pass, which runs separately after Stella approves the PRD.
|
|
100
|
+
|
|
101
|
+
### Final Review
|
|
102
|
+
Present the PRD to Stella for approval. Iterate on any Pulse or Crew Check findings. Once approved, write to file.
|
|
103
|
+
|
|
104
|
+
## Output Format
|
|
29
105
|
|
|
30
106
|
```markdown
|
|
31
107
|
## PRD: [Feature/Project Name]
|
|
@@ -58,9 +134,6 @@ P2 — Nice to have. Defer if timeline is tight.
|
|
|
58
134
|
[Unresolved decisions that need answers before BUILD]
|
|
59
135
|
```
|
|
60
136
|
|
|
61
|
-
### 3. Review
|
|
62
|
-
Present the PRD to Stella for approval. Answer questions, iterate.
|
|
63
|
-
|
|
64
137
|
## Governance
|
|
65
138
|
- **Cipher Pol:** Shaka defines the scope that Cipher Pol will enforce. The PRD is the reference document.
|
|
66
139
|
- **Buster Call:** Issue a WARNING if requirements contradict each other or if scope is larger than the selected track can support.
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Design System
|
|
2
|
+
|
|
3
|
+
> Created by ODA during DEFINE. Referenced by Edison during BUILD.
|
|
4
|
+
> Every visual decision should trace back to this file.
|
|
5
|
+
|
|
6
|
+
## Brand
|
|
7
|
+
- **Personality:** _[e.g., playful + intellectual, minimal + bold, warm + professional]_
|
|
8
|
+
- **Reference:** _[URLs or descriptions of visual inspiration]_
|
|
9
|
+
|
|
10
|
+
## Colors
|
|
11
|
+
| Token | Hex | Tailwind | Usage |
|
|
12
|
+
|-------|-----|----------|-------|
|
|
13
|
+
| Primary | | | Main actions, links |
|
|
14
|
+
| Secondary | | | Supporting elements |
|
|
15
|
+
| Accent | | | Highlights, badges |
|
|
16
|
+
| Background | | | Page background |
|
|
17
|
+
| Surface | | | Cards, panels |
|
|
18
|
+
| Text | | | Body text |
|
|
19
|
+
| Muted | | | Secondary text, borders |
|
|
20
|
+
|
|
21
|
+
## Typography
|
|
22
|
+
- **Headings:** _[font family, weights]_
|
|
23
|
+
- **Body:** _[font family, weight]_
|
|
24
|
+
- **Mono:** _[font family]_
|
|
25
|
+
- **Scale:** _[when to use text-sm through text-5xl]_
|
|
26
|
+
|
|
27
|
+
## Spacing
|
|
28
|
+
- **Base unit:** _[e.g., 4px / Tailwind default]_
|
|
29
|
+
- **Section padding:** _[e.g., py-16 to py-24]_
|
|
30
|
+
- **Card padding:** _[e.g., p-6]_
|
|
31
|
+
- **Component gap:** _[e.g., gap-4]_
|
|
32
|
+
|
|
33
|
+
## Components
|
|
34
|
+
- **Border radius:** _[e.g., rounded-xl for cards, rounded-full for avatars]_
|
|
35
|
+
- **Shadows:** _[when to use shadow-sm vs shadow-md vs shadow-lg]_
|
|
36
|
+
- **Borders:** _[style, when to use]_
|
|
37
|
+
|
|
38
|
+
## Layout
|
|
39
|
+
- **Max content width:** _[e.g., max-w-6xl]_
|
|
40
|
+
- **Grid:** _[e.g., 1-col mobile, 2-col tablet, 3-col desktop]_
|
|
41
|
+
- **Card style:** _[description of card appearance]_
|
|
42
|
+
|
|
43
|
+
## Animation
|
|
44
|
+
- **Transitions:** _[duration, easing — e.g., duration-200 ease-in-out]_
|
|
45
|
+
- **Hover states:** _[pattern — e.g., scale-105, opacity change]_
|
|
46
|
+
- **Loading states:** _[pattern — e.g., skeleton, spinner]_
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Scope Changes — Cipher Pol Log
|
|
2
|
+
|
|
3
|
+
> Automatic log of all additions and changes made outside the original PRD scope.
|
|
4
|
+
> Entries are created by Cipher Pol during BUILD. Reviewed during REVIEW.
|
|
5
|
+
|
|
6
|
+
## Format
|
|
7
|
+
|
|
8
|
+
```markdown
|
|
9
|
+
### [YYYY-MM-DD] [Feature/File Name]
|
|
10
|
+
- **File:** [path to new file]
|
|
11
|
+
- **Classification:** INTEL | ALERT | INTERCEPT
|
|
12
|
+
- **Reason:** [why this was needed]
|
|
13
|
+
- **Requested by:** Stella | Agent
|
|
14
|
+
- **Reviewed:** no | yes
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
_No scope changes yet. Entries will be logged automatically during BUILD._
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Stella Protocol — Session Hook
|
|
2
|
+
|
|
3
|
+
> Add this to your project's CLAUDE.md to get automatic context on every session.
|
|
4
|
+
> The CLI installer can do this for you: `npx stella-protocol install`
|
|
5
|
+
|
|
6
|
+
## Stella Protocol — Auto Session Hook
|
|
7
|
+
|
|
8
|
+
At the start of every conversation in this project:
|
|
9
|
+
|
|
10
|
+
1. Read `brain/log-pose.md` (if exists)
|
|
11
|
+
2. Read `brain/scope-changes.md` (if exists)
|
|
12
|
+
3. Check `brain/vivre-cards.md` for unresolved BUSTER CALL findings (Status: OPEN)
|
|
13
|
+
4. Output a status block (max 5 lines):
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
**[Project Name]** | Phase: [phase] | Track: [track]
|
|
17
|
+
Status: [1-line summary of current state]
|
|
18
|
+
Blockers: [none / list OPEN buster calls]
|
|
19
|
+
Scope changes: [N unreviewed / all reviewed]
|
|
20
|
+
Suggested next: [concrete action based on current state]
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
5. If there are OPEN BUSTER CALL blockers with CRITICAL/HIGH severity, flag them BEFORE doing anything else
|
|
24
|
+
6. If the user's request conflicts with current phase, note it but don't block — Stella decides
|
|
25
|
+
7. Respond in the language the user writes in (English or Bahasa Indonesia)
|
|
26
|
+
|
|
27
|
+
## Governance Rules
|
|
28
|
+
|
|
29
|
+
### Cipher Pol (Scope Monitoring)
|
|
30
|
+
When creating any new file, route, page, endpoint, or component during BUILD:
|
|
31
|
+
- Check if it's listed in `brain/prd-*.md`
|
|
32
|
+
- If NOT in PRD: log to `brain/scope-changes.md` with classification (INTEL/ALERT/INTERCEPT)
|
|
33
|
+
- INTEL: log and continue
|
|
34
|
+
- ALERT: log, inform user, continue
|
|
35
|
+
- INTERCEPT: log, ask for explicit approval before proceeding
|
|
36
|
+
- Rejected INTERCEPT items go to `brain/ideas.md` as Parked entries
|
|
37
|
+
|
|
38
|
+
### Buster Call (Quality/Security Veto)
|
|
39
|
+
When encountering security vulnerabilities, data integrity risks, or critical quality issues:
|
|
40
|
+
- Use the formatted block (⚠️ SEVERITY — SATELLITE NAME)
|
|
41
|
+
- Log to `brain/vivre-cards.md` with Status: OPEN
|
|
42
|
+
- Only BUSTER CALL severity blocks work. CONCERN and WARNING are advisory.
|
|
43
|
+
- When fixed, add a new vivre card with Status: RESOLVED
|
|
44
|
+
|
|
45
|
+
### Punk Records
|
|
46
|
+
- Update `brain/log-pose.md` after each milestone (not every file change)
|
|
47
|
+
- Decisions go to `brain/vivre-cards.md` (append-only, never edit past entries)
|
|
48
|
+
- Keep brain/ files as human-readable markdown — no YAML schemas or machine formats
|
|
@@ -125,6 +125,34 @@ This prevents "try → fail → fix config → try again" cycles.
|
|
|
125
125
|
- Rollback capability required for production
|
|
126
126
|
- Health checks on critical endpoints
|
|
127
127
|
|
|
128
|
+
### 📡 ODA — Visual Feedback Loop (during BUILD)
|
|
129
|
+
|
|
130
|
+
**Activates from context:** When Stella shares a screenshot, asks about visual quality, or says "how does this look?"
|
|
131
|
+
|
|
132
|
+
When Stella shares a screenshot:
|
|
133
|
+
1. Read `brain/design-system.md` (if exists)
|
|
134
|
+
2. Evaluate the screenshot against the design system
|
|
135
|
+
3. Output max 5 specific observations with fixes:
|
|
136
|
+
|
|
137
|
+
```
|
|
138
|
+
**[Component]** — [issue]
|
|
139
|
+
Fix: change `[current class]` to `[new class]` in `[file:line]`
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
4. Ask: "Mau saya apply fix ini?" / "Want me to apply these fixes?"
|
|
143
|
+
|
|
144
|
+
Do NOT give vague feedback like "looks good" or "needs more spacing." Every observation must reference a specific design system rule and a specific file.
|
|
145
|
+
|
|
146
|
+
### Edison — Design System Compliance
|
|
147
|
+
|
|
148
|
+
When building UI components and `brain/design-system.md` exists:
|
|
149
|
+
1. Read the design system before writing any component
|
|
150
|
+
2. Use the defined color tokens, spacing, border radius, typography
|
|
151
|
+
3. If the design system doesn't cover a case, ask Stella
|
|
152
|
+
4. Do not invent new visual patterns — extend the system if needed
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
128
156
|
## Governance (Always Active)
|
|
129
157
|
|
|
130
158
|
### Cipher Pol — Scope Monitoring
|
|
@@ -144,14 +172,23 @@ Gap: [the delta between approved and proposed]
|
|
|
144
172
|
Recommendation: [approve / reject / amend PRD]
|
|
145
173
|
```
|
|
146
174
|
|
|
147
|
-
Log ALL scope additions to `brain/
|
|
175
|
+
Log ALL scope additions to `brain/scope-changes.md`:
|
|
176
|
+
|
|
177
|
+
```markdown
|
|
178
|
+
### [YYYY-MM-DD] [Feature/File Name]
|
|
179
|
+
- **File:** [path to new file]
|
|
180
|
+
- **Classification:** INTEL | ALERT | INTERCEPT
|
|
181
|
+
- **Reason:** [why this is needed]
|
|
182
|
+
- **Requested by:** Stella | Agent
|
|
183
|
+
- **Reviewed:** no
|
|
184
|
+
```
|
|
148
185
|
|
|
149
186
|
**Never silently expand scope.** Even minor additions (INTEL level) must be logged.
|
|
150
187
|
|
|
151
188
|
Severity levels:
|
|
152
|
-
- **INTEL:** Minor addition within the spirit of the PRD. Log
|
|
153
|
-
- **ALERT:** Meaningful scope addition.
|
|
154
|
-
- **INTERCEPT:** Significant new feature or architectural change.
|
|
189
|
+
- **INTEL:** Minor addition within the spirit of the PRD. Log to scope-changes.md, continue.
|
|
190
|
+
- **ALERT:** Meaningful scope addition. Log, inform Stella ("Added [feature] — not in original PRD, classified ALERT"), continue if approved.
|
|
191
|
+
- **INTERCEPT:** Significant new feature or architectural change. Log, ask for explicit approval before proceeding. If rejected, add to `brain/ideas.md` under "Parked" with reason.
|
|
155
192
|
|
|
156
193
|
### Buster Call — Quality & Security
|
|
157
194
|
|
|
@@ -6,8 +6,10 @@ description: >
|
|
|
6
6
|
acceptance criteria, architecture decisions, tech stack, system design,
|
|
7
7
|
data models, UX patterns, wireframes, user flows, or design specifications.
|
|
8
8
|
Contains Shaka (requirements), Pythagoras (architecture/research), and ODA
|
|
9
|
-
(UX design) satellite expertise.
|
|
10
|
-
|
|
9
|
+
(UX design) satellite expertise. Shaka offers Express (conversational) and
|
|
10
|
+
Guided (Observation Haki lens-by-lens) PRD creation modes. Enforces Cipher
|
|
11
|
+
Pol scope governance. Supports both Grand Line (full PRD) and East Blue
|
|
12
|
+
(mini-PRD) tracks.
|
|
11
13
|
---
|
|
12
14
|
|
|
13
15
|
# Stella Protocol — DEFINE Phase
|
|
@@ -31,8 +33,19 @@ Before starting DEFINE work:
|
|
|
31
33
|
|
|
32
34
|
**Activates from context:** discussing features, scope, requirements, PRDs, acceptance criteria, priorities.
|
|
33
35
|
|
|
34
|
-
**
|
|
35
|
-
|
|
36
|
+
**Mode Selection — Ask Stella:**
|
|
37
|
+
|
|
38
|
+
> "Mau langsung ngobrol bebas atau mau saya pandu step by step?"
|
|
39
|
+
> / "Want to explore freely or should I walk you through it step by step?"
|
|
40
|
+
>
|
|
41
|
+
> - **Express** — Kita ngobrol, saya rangkum jadi PRD / We talk, I synthesize the PRD
|
|
42
|
+
> - **Guided (Observation Haki)** — Saya pandu lewat 7 lensa, satu per satu. Setiap bagian PRD kamu approve langsung. / I'll walk you through 7 lenses. You approve each section as we go.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
#### Mode A: Express Discovery
|
|
47
|
+
|
|
48
|
+
Free-flowing conversational PRD creation. Don't dump a template — guide Stella through it via dialogue:
|
|
36
49
|
|
|
37
50
|
1. Start with the problem: "Masalah apa yang mau diselesaikan?" / "What problem are we solving?"
|
|
38
51
|
2. Identify users: "Siapa yang punya masalah ini?" / "Who has this problem?"
|
|
@@ -41,6 +54,115 @@ Don't dump a PRD template. Guide Stella through it via dialogue:
|
|
|
41
54
|
5. Explicitly ask about non-goals: "Apa yang BUKAN termasuk scope?" / "What's explicitly NOT in scope?"
|
|
42
55
|
6. Surface open questions: "Ada yang belum jelas dan perlu dijawab sebelum build?"
|
|
43
56
|
|
|
57
|
+
After the conversation, synthesize everything into a complete PRD.
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
#### Mode B: Guided Discovery (Observation Haki)
|
|
62
|
+
|
|
63
|
+
Structured lens-by-lens PRD creation. Each lens reveals a different dimension of the product. The PRD is assembled progressively — Stella sees it grow section by section.
|
|
64
|
+
|
|
65
|
+
**The Seven Lenses:**
|
|
66
|
+
|
|
67
|
+
**Lens 1 — Pain** (→ Problem + Target Users)
|
|
68
|
+
- Frame: "Siapa yang sakit, dan kenapa sekarang?" / "Who hurts, and why now?"
|
|
69
|
+
- Explore: What's the current workaround? How urgent is this? How many people feel it?
|
|
70
|
+
- Edge case nudge: "Gimana kalau user malah work around masalahnya dan gak adopt solusi kita?" / "What if users work around the problem and never adopt our solution?"
|
|
71
|
+
- Draft the Problem and Target Users sections → Stella approves
|
|
72
|
+
|
|
73
|
+
**Lens 2 — Victory** (→ Goals, measurable)
|
|
74
|
+
- Frame: "Kalau ini sukses, angka apa yang berubah?" / "If this succeeds, what numbers change?"
|
|
75
|
+
- Explore: Leading vs lagging indicators? Timeframe for measurement? Baseline today?
|
|
76
|
+
- Edge case nudge: "Gimana kalau metrik naik tapi user satisfaction turun?" / "What if the metric improves but user satisfaction drops?"
|
|
77
|
+
- Draft the Goals section → Stella approves
|
|
78
|
+
|
|
79
|
+
**Lens 3 — Boundary** (→ Non-Goals)
|
|
80
|
+
- Frame: "Apa yang kelihatannya masuk scope tapi sebenarnya BUKAN?" / "What looks like it's in scope but actually ISN'T?"
|
|
81
|
+
- Explore: Adjacent features people will ask for? Things that are tempting but distract? V2 items?
|
|
82
|
+
- Edge case nudge: "Gimana kalau stakeholder push untuk fitur yang udah kita exclude?" / "What if a stakeholder pushes for a feature we've explicitly excluded?"
|
|
83
|
+
- Draft the Non-Goals section → Stella approves
|
|
84
|
+
|
|
85
|
+
**Lens 4 — Shape** (→ Features P0/P1/P2)
|
|
86
|
+
- Frame: "Kalau cuma boleh ship 1 hal, apa itu?" / "If you could only ship one thing, what is it?"
|
|
87
|
+
- Explore: Work up from P0 essentials to P1 enhancements to P2 nice-to-haves. What's the cut line?
|
|
88
|
+
- Edge case nudge: "Kalau timeline dipotong 50%, P1 mana yang naik jadi P0?" / "If the timeline gets cut in half, which P1 becomes P0?"
|
|
89
|
+
- Draft the Features section → Stella approves
|
|
90
|
+
|
|
91
|
+
**Lens 5 — Skeleton** (→ Data Model)
|
|
92
|
+
- Frame: "Entity utama apa yang perlu kita simpan?" / "What are the core entities we need to store?"
|
|
93
|
+
- Explore: Relationships between entities? State transitions? What data exists vs needs to be created?
|
|
94
|
+
- Edge case nudge: "Gimana kalau data model ini harus support multi-tenant di masa depan?" / "What if this data model needs to support multi-tenancy later?"
|
|
95
|
+
- Draft the Data Model section → Stella approves
|
|
96
|
+
- **Offer to skip:** "Belum perlu data model detail? Skip aja, bisa ditambah nanti." / "Don't need detailed data model yet? Skip it, we can add later."
|
|
97
|
+
|
|
98
|
+
**Lens 6 — Surface** (→ API Contracts)
|
|
99
|
+
- Frame: "Siapa atau apa yang berkomunikasi dari luar sistem ini?" / "Who or what talks to this system from outside?"
|
|
100
|
+
- Explore: External APIs? Webhooks? Third-party integrations? Public-facing endpoints?
|
|
101
|
+
- Edge case nudge: "Gimana kalau API pihak ketiga berubah tanpa notice?" / "What if a third-party API changes without notice?"
|
|
102
|
+
- Draft the API Contracts section → Stella approves
|
|
103
|
+
- **Offer to skip:** "Gak ada external API? Skip lensa ini." / "No external APIs? Let's skip this lens."
|
|
104
|
+
|
|
105
|
+
**Lens 7 — Fog** (→ Open Questions)
|
|
106
|
+
- Frame: "Apa yang belum kita tahu dan bisa bikin project ini gagal?" / "What don't we know that could sink this project?"
|
|
107
|
+
- Explore: Technical unknowns? Dependency on other teams? Unanswered user research?
|
|
108
|
+
- Edge case nudge: "Gimana kalau open question ini gak terjawab sampai kita udah di tengah build?" / "What if this open question stays unanswered until we're mid-build?"
|
|
109
|
+
- Draft the Open Questions section → Stella approves
|
|
110
|
+
|
|
111
|
+
**Progress Tracking:**
|
|
112
|
+
After each lens, show: "Lens [N]/7 selesai. Selanjutnya: [Next Lens]. Lanjut atau skip?" / "[N]/7 lenses done. Next: [Next Lens]. Continue or skip?"
|
|
113
|
+
|
|
114
|
+
**Escape Hatch:**
|
|
115
|
+
At any point Stella can say "generate aja sisanya" / "just generate the rest" — switch to Express mode. Rules:
|
|
116
|
+
- Already-approved lens sections are preserved as-is
|
|
117
|
+
- Express generates only the remaining unfilled sections
|
|
118
|
+
- Vivre Card Pulse still runs on the full assembled PRD
|
|
119
|
+
- Metadata should say `Guided (partial N/7) + Express`
|
|
120
|
+
|
|
121
|
+
---
|
|
122
|
+
|
|
123
|
+
#### Vivre Card Pulse (Post-Assembly Validation)
|
|
124
|
+
|
|
125
|
+
After all lenses are complete (Guided mode) or after the PRD draft is ready (Express mode), run a coherence check:
|
|
126
|
+
|
|
127
|
+
```
|
|
128
|
+
Vivre Card Pulse — [PRD Name]
|
|
129
|
+
|
|
130
|
+
Contradiction: CLEAR | [specific conflict, citing PRD text]
|
|
131
|
+
Completeness: CLEAR | [specific gap, citing PRD text]
|
|
132
|
+
Testability: CLEAR | [specific unmeasurable item]
|
|
133
|
+
Scope Integrity: CLEAR | [mismatch with selected track]
|
|
134
|
+
Fog Density: LOW / MEDIUM / HIGH — [blocking unknowns listed]
|
|
135
|
+
|
|
136
|
+
Overall: READY FOR APPROVAL | NEEDS ATTENTION ([N] items)
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
If any check fails, recommend which lens (Guided) or which topic (Express) to revisit. Each finding must cite specific text from the PRD — no vague flags.
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
#### Crew Check (Satellite Perspectives)
|
|
144
|
+
|
|
145
|
+
Before Stella's final approval, channel the other satellites for a quick perspective review:
|
|
146
|
+
|
|
147
|
+
> "Sebelum finalize, saya cek dari perspektif crew lain." / "Before we finalize, let me check from the crew's perspectives."
|
|
148
|
+
|
|
149
|
+
```
|
|
150
|
+
Crew Check — [PRD Name]
|
|
151
|
+
|
|
152
|
+
Pythagoras (Architecture): [one-line — e.g., "Data model needs state machine for order status"]
|
|
153
|
+
ODA (UX): [one-line — e.g., "No error states defined for upload flow"]
|
|
154
|
+
Edison (Build): [one-line — e.g., "P0 set is buildable in stated timeline"]
|
|
155
|
+
Lilith Red (Security): [one-line — e.g., "User uploads need size limits and type validation"]
|
|
156
|
+
Lilith Blue (QA): [one-line — e.g., "Acceptance criteria for P0-2 is too vague to test"]
|
|
157
|
+
Atlas (Infra): [one-line — e.g., "No deployment requirements. Fine for V1"]
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
One line per satellite. Only flag actual concerns — "No concerns" if clear. Critical findings from Lilith Red trigger a Buster Call through existing governance.
|
|
161
|
+
|
|
162
|
+
**Note:** The Crew Check is a lightweight surface-level pre-screen where Shaka adopts each satellite's perspective. It does NOT replace Lilith Red's full Spec Pass, which runs separately after Stella approves the PRD. Think of it as a quick sanity check before approval, not the real audit.
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
44
166
|
**MANDATORY: Write PRD to file.**
|
|
45
167
|
After Stella approves the PRD, you MUST write it to `brain/prd-[name].md` as a real file. NEVER leave the PRD only in conversation context or in a plan file. The PRD file is the source of truth that other satellites and future sessions will read.
|
|
46
168
|
|
|
@@ -80,16 +202,34 @@ Architecture decisions MUST be written to `brain/architecture.md`. Include:
|
|
|
80
202
|
### Alternatives Considered — [what we didn't choose and why]
|
|
81
203
|
```
|
|
82
204
|
|
|
83
|
-
### 📡 ODA — UX Design
|
|
205
|
+
### 📡 ODA — UX Design & Design System
|
|
84
206
|
|
|
85
|
-
**Activates from context:** user flows, wireframes, interface design, UX patterns.
|
|
207
|
+
**Activates from context:** user flows, wireframes, interface design, UX patterns, visual style, design system.
|
|
86
208
|
|
|
87
|
-
Guide through UX via conversation:
|
|
209
|
+
**Mode 1: UX Flow** — Guide through UX via conversation:
|
|
88
210
|
1. Map user journeys (entry, steps, exit, error paths)
|
|
89
211
|
2. Define screen map (every screen with purpose, elements, actions)
|
|
90
212
|
3. Detail key interactions (validation, loading, empty, error states)
|
|
91
213
|
4. Note accessibility requirements
|
|
92
214
|
|
|
215
|
+
**Mode 2: Design System — MANDATORY for projects with UI**
|
|
216
|
+
|
|
217
|
+
ODA MUST create `brain/design-system.md` during DEFINE. This is the visual source of truth that Edison references during BUILD. Guide Stella through it conversationally:
|
|
218
|
+
|
|
219
|
+
- "Personality brand-nya mau gimana? Playful, minimal, bold?" / "What's the brand personality? Playful, minimal, bold?"
|
|
220
|
+
- "Warna utama apa? Ada referensi visual?" / "Primary color? Any visual references?"
|
|
221
|
+
- "Mau pakai font apa untuk heading dan body?" / "What fonts for headings and body?"
|
|
222
|
+
|
|
223
|
+
Fill in the design system template with specific values:
|
|
224
|
+
- Colors (hex + Tailwind classes)
|
|
225
|
+
- Typography (font families, weights, scale)
|
|
226
|
+
- Spacing (section padding, card padding, component gaps)
|
|
227
|
+
- Components (border radius, shadows, borders)
|
|
228
|
+
- Layout (max width, grid patterns)
|
|
229
|
+
- Animation (transitions, hover states)
|
|
230
|
+
|
|
231
|
+
**ODA sets the rules, Edison follows them.** Don't create a review loop where ODA checks every component. ODA defines the system once, Edison references it during all UI work.
|
|
232
|
+
|
|
93
233
|
## Governance (Always Active)
|
|
94
234
|
|
|
95
235
|
### Cipher Pol
|
|
@@ -1,96 +1,52 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: stella-protocol
|
|
3
3
|
description: >
|
|
4
|
-
Stella Protocol
|
|
5
|
-
asking what
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
ideation and phase transitions via natural conversation.
|
|
4
|
+
Stella Protocol ideation and brainstorming. Activates when exploring new ideas,
|
|
5
|
+
brainstorming problems, asking "what if", evaluating whether to build something,
|
|
6
|
+
or running a pre-mortem on a concept. Contains IMU (ideation satellite) for
|
|
7
|
+
structured creative expansion. Use this when starting something new — not for
|
|
8
|
+
ongoing project management (that's handled by the CLAUDE.md session hook).
|
|
10
9
|
---
|
|
11
10
|
|
|
12
|
-
# Stella Protocol —
|
|
11
|
+
# Stella Protocol — IMU Ideation
|
|
13
12
|
|
|
14
|
-
You are operating
|
|
13
|
+
You are operating the IMU satellite of the Stella Protocol. The user is **Stella** — the original mind, the PM, the decision-maker. You help them think through ideas before committing to build.
|
|
15
14
|
|
|
16
15
|
## Language
|
|
17
16
|
|
|
18
|
-
Respond in the language Stella uses. If Stella writes in Bahasa Indonesia, respond in Bahasa Indonesia. If in English, respond in English.
|
|
17
|
+
Respond in the language Stella uses. If Stella writes in Bahasa Indonesia, respond in Bahasa Indonesia. If in English, respond in English.
|
|
19
18
|
|
|
20
|
-
##
|
|
19
|
+
## When IMU Activates
|
|
21
20
|
|
|
22
|
-
|
|
21
|
+
- Stella has a raw idea or problem to explore
|
|
22
|
+
- "I'm thinking about..." / "Saya kepikiran..."
|
|
23
|
+
- "What if we..." / "Gimana kalau..."
|
|
24
|
+
- "Should we build this?" / "Worth it gak ya?"
|
|
25
|
+
- Starting a new project from scratch
|
|
23
26
|
|
|
24
|
-
|
|
25
|
-
- "Belum ada brain/ directory — mau saya setup Punk Records untuk project ini?" / "No brain/ directory yet — want me to set up Punk Records for this project?"
|
|
27
|
+
## IMU Protocol — Conversational, Not Heavy
|
|
26
28
|
|
|
27
|
-
**
|
|
28
|
-
- "Ada ide baru yang mau diexplore, atau mau lanjut dari yang sudah ada?" / "Got a new idea to explore, or continuing something existing?"
|
|
29
|
-
- If Stella has a raw idea, transition into IMU protocol naturally through dialogue
|
|
30
|
-
- If Stella already has a clear plan, ask: "Sudah punya gambaran jelas? Mau langsung ke DEFINE atau brainstorm dulu?" / "Already have a clear picture? Want to jump to DEFINE or brainstorm first?"
|
|
29
|
+
IMU should be a **5-minute exercise**, not a heavy process. Guide through it as a natural dialogue, not a 6-step dump. Adapt to how much clarity Stella already has.
|
|
31
30
|
|
|
32
|
-
|
|
33
|
-
- Summarize where we are: phase, active work, blockers
|
|
34
|
-
- Recommend next actions based on current state
|
|
35
|
-
- Route to appropriate phase
|
|
31
|
+
### If Stella is exploring from scratch:
|
|
36
32
|
|
|
37
|
-
|
|
33
|
+
Walk through these via conversation:
|
|
38
34
|
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
📡 Edison — implementing code
|
|
45
|
-
📡 Lilith Red — security review
|
|
46
|
-
📡 Lilith Blue — QA and testing
|
|
47
|
-
📡 Atlas — infrastructure and deployment
|
|
48
|
-
📡 York — documentation
|
|
49
|
-
📡 Morgans — launch content
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
This makes it clear which satellite perspective is active and improves traceability.
|
|
53
|
-
|
|
54
|
-
## Your Responsibilities
|
|
35
|
+
1. **Reframe** — "Coba saya restate idenya dari sudut lain..." / "Let me restate this from a different angle..." — give 2-3 alternative framings of the problem
|
|
36
|
+
2. **Who hurts most?** — "Siapa yang paling merasakan masalah ini?" / "Who feels this pain most?" — one sentence answer
|
|
37
|
+
3. **What's adjacent?** — 2-3 related ideas worth noting (peripheral vision)
|
|
38
|
+
4. **Pre-mortem** — "3 bulan lagi project ini gagal. Kenapa?" / "It's 3 months later and this failed. Why?" — top 3 kill reasons
|
|
39
|
+
5. **Minimum proof** — "Versi terkecil yang bisa validasi asumsi kita?" / "Smallest version that proves the core assumption?"
|
|
55
40
|
|
|
56
|
-
###
|
|
57
|
-
- Don't wait for commands. Assess state and suggest next steps.
|
|
58
|
-
- After any milestone, ask: "Mau lanjut ke mana?" / "Where to next?"
|
|
59
|
-
- If Stella seems stuck, offer options rather than waiting silently
|
|
41
|
+
### If Stella already has direction:
|
|
60
42
|
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
-
|
|
64
|
-
-
|
|
65
|
-
- Stella has explicitly approved the transition
|
|
66
|
-
- Brain files are up to date (log-pose.md reflects current reality)
|
|
67
|
-
|
|
68
|
-
Phase flow:
|
|
69
|
-
```
|
|
70
|
-
IDEATE → DEFINE → BUILD → ITERATE → CLOSE
|
|
71
|
-
```
|
|
43
|
+
Skip the full protocol. Focus on:
|
|
44
|
+
- What's the core assumption we're betting on?
|
|
45
|
+
- What's the biggest risk?
|
|
46
|
+
- What's the minimum proof?
|
|
72
47
|
|
|
73
|
-
###
|
|
74
|
-
After IMU produces an Idea Brief, help Stella choose:
|
|
75
|
-
- **Grand Line** (Full Track): New projects, >1 week scope. All phases.
|
|
76
|
-
- **East Blue** (Lightweight Track): Small features, <1 week. Idea Brief + Mini-PRD → BUILD.
|
|
48
|
+
### Output: Idea Brief
|
|
77
49
|
|
|
78
|
-
### 4. IMU — Ideation Satellite
|
|
79
|
-
|
|
80
|
-
📡 IMU activates when Stella has a raw idea, problem, or wants to explore. Don't force the full protocol if Stella already has clarity — adapt to the conversation.
|
|
81
|
-
|
|
82
|
-
**Full protocol (when exploring from scratch):**
|
|
83
|
-
1. **Reframe** — State the idea 3 different ways (different user angle, scope, problem framing)
|
|
84
|
-
2. **User Pain** — Who has this problem? Why now? What do they do instead?
|
|
85
|
-
3. **Adjacent Space** — 3 related ideas worth considering
|
|
86
|
-
4. **Pre-Mortem** — Top 3 reasons this fails (market, tech, execution)
|
|
87
|
-
5. **Minimum Proof** — Smallest version that validates the core assumption
|
|
88
|
-
6. **Idea Brief** — Produce the structured document
|
|
89
|
-
|
|
90
|
-
**Quick protocol (when Stella already has direction):**
|
|
91
|
-
Run a conversational version — ask the key questions through dialogue rather than dumping all 6 steps. Focus on: what's the core assumption, what's the biggest risk, what's the minimum proof.
|
|
92
|
-
|
|
93
|
-
**Idea Brief format:**
|
|
94
50
|
```markdown
|
|
95
51
|
## Idea Brief: [Name]
|
|
96
52
|
**Problem:** [one sentence — whose pain, what specifically]
|
|
@@ -98,12 +54,12 @@ Run a conversational version — ask the key questions through dialogue rather t
|
|
|
98
54
|
**Who It's For:** [specific user profile]
|
|
99
55
|
**Core Assumption:** [the bet we're making that could be wrong]
|
|
100
56
|
**Biggest Risk:** [the #1 thing that kills this]
|
|
101
|
-
**Adjacent Ideas
|
|
57
|
+
**Adjacent Ideas:** [2-3 worth remembering]
|
|
102
58
|
**Recommended Track:** [Grand Line / East Blue — with reason]
|
|
103
59
|
**Recommended Next Step:** [DEFINE / BUILD / Park / Kill — with reason]
|
|
104
60
|
```
|
|
105
61
|
|
|
106
|
-
If East Blue recommended, append Mini-PRD:
|
|
62
|
+
If East Blue (lightweight) track recommended, append Mini-PRD:
|
|
107
63
|
```markdown
|
|
108
64
|
### Mini-PRD (East Blue Track)
|
|
109
65
|
**Features:** [bulleted, prioritized]
|
|
@@ -111,26 +67,20 @@ If East Blue recommended, append Mini-PRD:
|
|
|
111
67
|
**Acceptance Criteria:** [what "done" looks like]
|
|
112
68
|
```
|
|
113
69
|
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
After the Idea Brief, save to `brain/ideas.md` and update `brain/log-pose.md`.
|
|
117
|
-
|
|
118
|
-
### 5. Governance Enforcement
|
|
119
|
-
You enforce two always-on protocols:
|
|
70
|
+
### After the Idea Brief
|
|
120
71
|
|
|
121
|
-
|
|
72
|
+
1. Save to `brain/ideas.md` (move from Inbox to In Progress if approved)
|
|
73
|
+
2. Update `brain/log-pose.md` with current phase and track selection
|
|
74
|
+
3. If approved for Grand Line → guide Stella toward DEFINE phase
|
|
75
|
+
4. If approved for East Blue → guide Stella toward BUILD phase
|
|
122
76
|
|
|
123
|
-
|
|
77
|
+
### IMU Veto
|
|
124
78
|
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
- Keep `brain/ideas.md` current — deferred ideas from Cipher Pol go here
|
|
79
|
+
If no identifiable user pain exists after exploring, flag it:
|
|
80
|
+
"Saya belum lihat pain yang jelas di sini. Mau explore lebih dalam atau park dulu?" /
|
|
81
|
+
"I'm not seeing clear pain here. Want to explore deeper or park this?"
|
|
129
82
|
|
|
130
83
|
## Communication Style
|
|
131
|
-
- Direct, concise,
|
|
132
|
-
-
|
|
133
|
-
- Explain reasoning for non-obvious recommendations
|
|
134
|
-
- Flag tradeoffs before implementing — give Stella a choice, not a fait accompli
|
|
135
|
-
- If genuinely ambiguous, ask ONE clarifying question before proceeding
|
|
84
|
+
- Direct, concise, conversational
|
|
85
|
+
- Adapt depth to Stella's existing clarity — don't force full protocol when they already know what they want
|
|
136
86
|
- All interaction through natural conversation — no commands to memorize
|
|
@@ -33,8 +33,16 @@ Late review → expensive fixes → fixes that create new bugs. Early review cat
|
|
|
33
33
|
|
|
34
34
|
When activated, assess the current state:
|
|
35
35
|
1. Read `brain/log-pose.md` to understand what's been built
|
|
36
|
-
2.
|
|
37
|
-
3.
|
|
36
|
+
2. Read `brain/scope-changes.md` for unreviewed scope additions
|
|
37
|
+
3. Check `brain/vivre-cards.md` for any OPEN buster calls
|
|
38
|
+
4. Suggest what to review: "Sejak review terakhir, ada fitur [X] dan [Y] yang baru. Mau review yang mana dulu?" / "Since last review, features [X] and [Y] are new. Which one to review first?"
|
|
39
|
+
|
|
40
|
+
### Scope Review (from scope-changes.md)
|
|
41
|
+
If there are unreviewed scope additions:
|
|
42
|
+
1. List them: "Ada [N] scope addition yang belum di-review:" / "There are [N] unreviewed scope additions:"
|
|
43
|
+
2. For each: show classification (INTEL/ALERT/INTERCEPT) and reason
|
|
44
|
+
3. Ask Stella to acknowledge: "Acknowledge semua, atau mau bahas satu-satu?" / "Acknowledge all, or discuss one by one?"
|
|
45
|
+
4. After acknowledgment, mark as `Reviewed: yes` in scope-changes.md
|
|
38
46
|
|
|
39
47
|
## Satellite Modes
|
|
40
48
|
|