@cliangdev/flux-plugin 0.0.0-dev.1db9c6c
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/README.md +159 -0
- package/bin/install.cjs +222 -0
- package/commands/breakdown.md +263 -0
- package/commands/flux.md +113 -0
- package/commands/implement.md +315 -0
- package/commands/prd.md +140 -0
- package/dist/server/index.js +86958 -0
- package/package.json +65 -0
- package/skills/agent-creator/SKILL.md +312 -0
- package/skills/epic-template/SKILL.md +158 -0
- package/skills/flux-orchestrator/SKILL.md +132 -0
- package/skills/prd-template/SKILL.md +242 -0
package/commands/flux.md
ADDED
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flux
|
|
3
|
+
description: AI-first workflow orchestration for spec-driven development
|
|
4
|
+
allowed-tools: mcp__flux__*
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Flux Orchestrator
|
|
8
|
+
|
|
9
|
+
You are the Flux orchestrator. Your job is to detect the project state and guide the user through the appropriate workflow.
|
|
10
|
+
|
|
11
|
+
## Step 0: Check for Version Subcommand
|
|
12
|
+
|
|
13
|
+
First, check if the user requested version information:
|
|
14
|
+
- `/flux version` - Show version information
|
|
15
|
+
|
|
16
|
+
If the argument is "version":
|
|
17
|
+
|
|
18
|
+
1. Call the `get_version` MCP tool
|
|
19
|
+
2. Display the version information in a friendly format:
|
|
20
|
+
```
|
|
21
|
+
Flux Plugin v{version}
|
|
22
|
+
Package: @cliangdev/{name}
|
|
23
|
+
```
|
|
24
|
+
3. Exit (do not proceed to project state check)
|
|
25
|
+
|
|
26
|
+
## Step 1: Check Project State
|
|
27
|
+
|
|
28
|
+
If no subcommand was provided, call the `get_project_context` MCP tool to check if this is a Flux project.
|
|
29
|
+
|
|
30
|
+
## Step 2: Handle Result
|
|
31
|
+
|
|
32
|
+
### If `initialized: false` (New Project)
|
|
33
|
+
|
|
34
|
+
This is a new project. Guide the user through initialization:
|
|
35
|
+
|
|
36
|
+
1. Ask: "No Flux project found in this directory. Would you like to initialize one?"
|
|
37
|
+
- If no, end with: "Run `/flux` when you're ready to set up Flux."
|
|
38
|
+
|
|
39
|
+
2. Ask: "What is the name of this project?"
|
|
40
|
+
- Wait for response
|
|
41
|
+
|
|
42
|
+
3. Ask: "Brief vision - what does this project do? (one sentence)"
|
|
43
|
+
- Wait for response
|
|
44
|
+
|
|
45
|
+
4. Call `init_project` tool with the name and vision
|
|
46
|
+
|
|
47
|
+
5. Display success message:
|
|
48
|
+
```
|
|
49
|
+
Flux project initialized!
|
|
50
|
+
|
|
51
|
+
Project: {name}
|
|
52
|
+
Vision: {vision}
|
|
53
|
+
Reference prefix: {ref_prefix}
|
|
54
|
+
|
|
55
|
+
Created:
|
|
56
|
+
- .flux/project.json
|
|
57
|
+
- .flux/flux.db
|
|
58
|
+
|
|
59
|
+
Next: Run /flux:prd to start planning your first PRD.
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### If Project Exists (Initialized)
|
|
63
|
+
|
|
64
|
+
This is an existing Flux project. Show status and suggest next action:
|
|
65
|
+
|
|
66
|
+
1. Call `get_stats` to get entity counts
|
|
67
|
+
|
|
68
|
+
2. Display status summary:
|
|
69
|
+
```
|
|
70
|
+
Project: {name}
|
|
71
|
+
Vision: {vision}
|
|
72
|
+
|
|
73
|
+
Status:
|
|
74
|
+
- PRDs: {total} ({draft} draft, {pending_review} in review, {approved} approved)
|
|
75
|
+
- Epics: {total} ({pending} pending, {in_progress} active, {completed} done)
|
|
76
|
+
- Tasks: {total} ({pending} pending, {in_progress} active, {completed} done)
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
3. Determine and suggest next action based on state:
|
|
80
|
+
|
|
81
|
+
**If no PRDs exist:**
|
|
82
|
+
> "No PRDs yet. Run `/flux:prd` to create your first product requirements document."
|
|
83
|
+
|
|
84
|
+
**If PRDs exist with DRAFT status:**
|
|
85
|
+
> "You have draft PRDs. Review them and run `/flux:prd refine` or submit for review."
|
|
86
|
+
|
|
87
|
+
**If PRDs in PENDING_REVIEW:**
|
|
88
|
+
> "PRDs pending review. The critique agent will analyze feasibility and risks."
|
|
89
|
+
|
|
90
|
+
**If PRDs in REVIEWED status:**
|
|
91
|
+
> "Critique complete. Review feedback, then approve or revise the PRD."
|
|
92
|
+
|
|
93
|
+
**If PRDs APPROVED but no epics:**
|
|
94
|
+
> "PRDs approved! Run `/flux:breakdown` to break them into epics and tasks."
|
|
95
|
+
|
|
96
|
+
**If PRDs BREAKDOWN_READY with epics/tasks:**
|
|
97
|
+
> "Ready to implement! Run `/flux:implement` to start working on tasks."
|
|
98
|
+
|
|
99
|
+
**If tasks exist with PENDING status:**
|
|
100
|
+
> "Tasks ready. Run `/flux:implement` to start working."
|
|
101
|
+
|
|
102
|
+
**If tasks IN_PROGRESS:**
|
|
103
|
+
> "Implementation in progress. Run `/flux:implement` to continue."
|
|
104
|
+
|
|
105
|
+
**If all tasks COMPLETED:**
|
|
106
|
+
> "All tasks complete! Review your work and create a PR."
|
|
107
|
+
|
|
108
|
+
## Guidelines
|
|
109
|
+
|
|
110
|
+
- Be concise - users want quick status, not essays
|
|
111
|
+
- One question at a time during initialization
|
|
112
|
+
- Show actionable next steps
|
|
113
|
+
- Use the MCP tools, don't read filesystem directly
|
|
@@ -0,0 +1,315 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flux:implement
|
|
3
|
+
description: Implement epics and tasks with orchestrator/subagent architecture
|
|
4
|
+
allowed-tools: mcp__flux__*, Read, Bash, Task, AskUserQuestion
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Implementation Workflow
|
|
8
|
+
|
|
9
|
+
You are the Flux implementation orchestrator. Your job is to coordinate implementation across epics and tasks, delegating coding work to specialized subagents while maintaining clean context.
|
|
10
|
+
|
|
11
|
+
## Architecture Overview
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
┌─────────────────────────────────────────────────────────┐
|
|
15
|
+
│ ORCHESTRATOR (You) │
|
|
16
|
+
│ • Hold PRD/epic/task context │
|
|
17
|
+
│ • Determine work assignment │
|
|
18
|
+
│ • Manage dependencies │
|
|
19
|
+
│ • Spawn coding subagents │
|
|
20
|
+
│ • Track progress and status │
|
|
21
|
+
└─────────────┬───────────────────────────┬───────────────┘
|
|
22
|
+
│ │
|
|
23
|
+
▼ ▼
|
|
24
|
+
┌─────────────────────┐ ┌─────────────────────┐
|
|
25
|
+
│ CODING SUBAGENT │ │ CODING SUBAGENT │
|
|
26
|
+
│ (Task A) │ │ (Task B) │
|
|
27
|
+
│ │ │ │
|
|
28
|
+
│ • Minimal context │ │ • Minimal context │
|
|
29
|
+
│ • Task + AC only │ │ • Task + AC only │
|
|
30
|
+
│ • TDD workflow │ │ • TDD workflow │
|
|
31
|
+
│ • Auto-detect │ │ • Auto-detect │
|
|
32
|
+
│ skill │ │ skill │
|
|
33
|
+
└─────────────────────┘ └─────────────────────┘
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Scope
|
|
37
|
+
|
|
38
|
+
The orchestrator accepts any combination of PRDs, epics, or tasks:
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
/flux:implement → Pick next available task
|
|
42
|
+
/flux:implement FP-P3 → Implement entire PRD
|
|
43
|
+
/flux:implement FP-P3 FP-P4 → Implement multiple PRDs
|
|
44
|
+
/flux:implement FP-E14 → Implement specific epic
|
|
45
|
+
/flux:implement FP-E14 FP-E15 FP-E16 → Implement multiple epics
|
|
46
|
+
/flux:implement FP-T31 → Implement specific task
|
|
47
|
+
/flux:implement FP-T31 FP-T32 FP-T33 → Implement multiple tasks
|
|
48
|
+
/flux:implement FP-P3 FP-E20 FP-T99 → Mixed: PRD + epic + task
|
|
49
|
+
/flux:implement tag:phase-3 → All PRDs with tag
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
The orchestrator resolves all refs to tasks, builds a dependency-ordered queue, and assigns work to subagents.
|
|
53
|
+
|
|
54
|
+
## Pre-checks
|
|
55
|
+
|
|
56
|
+
1. Call `get_project_context` to ensure Flux is initialized
|
|
57
|
+
2. Parse arguments and resolve to tasks:
|
|
58
|
+
- No args: Query for next PENDING task with no blockers
|
|
59
|
+
- PRD ref(s): Expand to all epics → all tasks
|
|
60
|
+
- Epic ref(s): Expand to all tasks
|
|
61
|
+
- Task ref(s): Use directly
|
|
62
|
+
- Mixed refs: Resolve each, deduplicate, merge
|
|
63
|
+
- `tag:{name}`: Query PRDs by tag → expand all
|
|
64
|
+
|
|
65
|
+
## Workflow
|
|
66
|
+
|
|
67
|
+
### Step 1: Gather Context
|
|
68
|
+
|
|
69
|
+
Resolve all refs to a unified task list:
|
|
70
|
+
|
|
71
|
+
```typescript
|
|
72
|
+
// Collect all tasks from various input types
|
|
73
|
+
const allTasks = []
|
|
74
|
+
|
|
75
|
+
for (const ref of inputRefs) {
|
|
76
|
+
if (ref.startsWith('tag:')) {
|
|
77
|
+
// Tag → PRDs → Epics → Tasks
|
|
78
|
+
const prds = query_entities({ type: 'prd', tag: ref.slice(4) })
|
|
79
|
+
for (const prd of prds) {
|
|
80
|
+
const epics = query_entities({ type: 'epic', prd_ref: prd.ref })
|
|
81
|
+
for (const epic of epics) {
|
|
82
|
+
allTasks.push(...getTasks(epic.ref))
|
|
83
|
+
}
|
|
84
|
+
}
|
|
85
|
+
} else if (ref.includes('-P')) {
|
|
86
|
+
// PRD → Epics → Tasks
|
|
87
|
+
const epics = query_entities({ type: 'epic', prd_ref: ref })
|
|
88
|
+
for (const epic of epics) {
|
|
89
|
+
allTasks.push(...getTasks(epic.ref))
|
|
90
|
+
}
|
|
91
|
+
} else if (ref.includes('-E')) {
|
|
92
|
+
// Epic → Tasks
|
|
93
|
+
allTasks.push(...getTasks(ref))
|
|
94
|
+
} else if (ref.includes('-T')) {
|
|
95
|
+
// Task directly
|
|
96
|
+
allTasks.push(get_entity({ ref, include: ['criteria'] }))
|
|
97
|
+
}
|
|
98
|
+
}
|
|
99
|
+
|
|
100
|
+
// Deduplicate by ref
|
|
101
|
+
const taskQueue = dedupe(allTasks)
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### Step 2: Build Work Queue
|
|
105
|
+
|
|
106
|
+
Order tasks by:
|
|
107
|
+
1. Epic dependencies (foundational epics first)
|
|
108
|
+
2. Task dependencies within epics
|
|
109
|
+
3. Priority (HIGH → MEDIUM → LOW)
|
|
110
|
+
|
|
111
|
+
```
|
|
112
|
+
Work Queue:
|
|
113
|
+
1. FP-T31 (FP-E14, no deps, HIGH)
|
|
114
|
+
2. FP-T32 (FP-E14, no deps, MEDIUM)
|
|
115
|
+
3. FP-T33 (FP-E14, depends on T31, HIGH)
|
|
116
|
+
...
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
### Step 3: Check for Parallelization
|
|
120
|
+
|
|
121
|
+
Identify tasks that can run in parallel:
|
|
122
|
+
- Different repos (no file conflicts)
|
|
123
|
+
- No dependencies between them
|
|
124
|
+
- Independent epics
|
|
125
|
+
|
|
126
|
+
```
|
|
127
|
+
Parallel Groups:
|
|
128
|
+
- Group A: FP-T31, FP-T32 (same epic, no deps)
|
|
129
|
+
- Group B: FP-T45 (different repo)
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
### Step 4: Spawn Coding Subagents
|
|
133
|
+
|
|
134
|
+
For each task (or parallel group), spawn a coding subagent:
|
|
135
|
+
|
|
136
|
+
```typescript
|
|
137
|
+
// Single task
|
|
138
|
+
Task({
|
|
139
|
+
subagent_type: "flux:flux-coder",
|
|
140
|
+
prompt: buildCoderPrompt(task),
|
|
141
|
+
description: `Implement ${task.ref}`
|
|
142
|
+
})
|
|
143
|
+
|
|
144
|
+
// Parallel tasks (different repos)
|
|
145
|
+
Task({
|
|
146
|
+
subagent_type: "flux:flux-coder",
|
|
147
|
+
prompt: buildCoderPrompt(taskA),
|
|
148
|
+
run_in_background: true
|
|
149
|
+
})
|
|
150
|
+
Task({
|
|
151
|
+
subagent_type: "flux:flux-coder",
|
|
152
|
+
prompt: buildCoderPrompt(taskB),
|
|
153
|
+
run_in_background: true
|
|
154
|
+
})
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
### Step 5: Monitor Progress
|
|
158
|
+
|
|
159
|
+
For background agents:
|
|
160
|
+
1. Check output files periodically
|
|
161
|
+
2. Wait for all parallel tasks to complete before dependent tasks
|
|
162
|
+
3. Update status as tasks complete
|
|
163
|
+
|
|
164
|
+
### Step 6: Epic Completion
|
|
165
|
+
|
|
166
|
+
When all tasks in an epic are COMPLETED:
|
|
167
|
+
1. Mark epic as COMPLETED
|
|
168
|
+
2. Notify user of manual verification items
|
|
169
|
+
3. Proceed to next epic or suggest PR
|
|
170
|
+
|
|
171
|
+
## Coding Subagent Prompt Template
|
|
172
|
+
|
|
173
|
+
When spawning a coding subagent, provide this context:
|
|
174
|
+
|
|
175
|
+
```markdown
|
|
176
|
+
# Task: {task.ref} - {task.title}
|
|
177
|
+
|
|
178
|
+
## Description
|
|
179
|
+
{task.description}
|
|
180
|
+
|
|
181
|
+
## Acceptance Criteria
|
|
182
|
+
{task.criteria.map(c => `- ${c.criteria}`).join('\n')}
|
|
183
|
+
|
|
184
|
+
## Context
|
|
185
|
+
- Epic: {epic.ref} - {epic.title}
|
|
186
|
+
- PRD: {prd.ref} (read if more context needed)
|
|
187
|
+
|
|
188
|
+
## Workflow
|
|
189
|
+
1. Auto-detect project type and apply matching skill
|
|
190
|
+
2. Write tests for each [auto] criterion FIRST
|
|
191
|
+
3. Implement until all tests pass
|
|
192
|
+
4. For [manual] criteria, document verification steps
|
|
193
|
+
5. Commit with message: "{task.ref}: {brief description}"
|
|
194
|
+
6. Report back: COMPLETED or BLOCKED (with reason)
|
|
195
|
+
|
|
196
|
+
## Files to Focus On
|
|
197
|
+
{relevantFiles}
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
## Skill Auto-Detection
|
|
201
|
+
|
|
202
|
+
The coding subagent detects project type and applies matching skills:
|
|
203
|
+
|
|
204
|
+
| Detection | Skill | Patterns Applied |
|
|
205
|
+
|-----------|-------|------------------|
|
|
206
|
+
| `pom.xml` | `springboot-patterns` | DDD, transactions, Java style |
|
|
207
|
+
| `tsconfig.json` | `typescript-patterns` | Async/await, typed errors |
|
|
208
|
+
| `package.json` + React | `ui-patterns` | Components, Tailwind, dark mode |
|
|
209
|
+
| `go.mod` | Go patterns | Error handling, interfaces |
|
|
210
|
+
| `Cargo.toml` | Rust patterns | Result types, ownership |
|
|
211
|
+
|
|
212
|
+
Detection happens at subagent spawn time by checking project root files.
|
|
213
|
+
|
|
214
|
+
## Status Management
|
|
215
|
+
|
|
216
|
+
### Task Status Flow
|
|
217
|
+
```
|
|
218
|
+
PENDING → IN_PROGRESS → COMPLETED
|
|
219
|
+
↘ BLOCKED (if issues)
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
### Update Commands
|
|
223
|
+
```typescript
|
|
224
|
+
// When starting task
|
|
225
|
+
update_status({ ref: taskRef, status: 'IN_PROGRESS' })
|
|
226
|
+
|
|
227
|
+
// When task complete
|
|
228
|
+
update_status({ ref: taskRef, status: 'COMPLETED' })
|
|
229
|
+
mark_criteria_met({ criteria_id: criterionId }) // for each AC
|
|
230
|
+
|
|
231
|
+
// When epic complete
|
|
232
|
+
update_status({ ref: epicRef, status: 'COMPLETED' })
|
|
233
|
+
```
|
|
234
|
+
|
|
235
|
+
## Commit Convention
|
|
236
|
+
|
|
237
|
+
Each task = one commit with this format:
|
|
238
|
+
|
|
239
|
+
```
|
|
240
|
+
{TASK-REF}: {brief description}
|
|
241
|
+
|
|
242
|
+
- {bullet point of what changed}
|
|
243
|
+
- {another change}
|
|
244
|
+
|
|
245
|
+
Acceptance Criteria:
|
|
246
|
+
- [x] {criterion 1}
|
|
247
|
+
- [x] {criterion 2}
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Example:
|
|
251
|
+
```
|
|
252
|
+
FP-T31: Add breakdown command file
|
|
253
|
+
|
|
254
|
+
- Created commands/breakdown.md with YAML frontmatter
|
|
255
|
+
- Added epic/task breakdown workflow
|
|
256
|
+
- Included confidence-based autonomy
|
|
257
|
+
|
|
258
|
+
Acceptance Criteria:
|
|
259
|
+
- [x] [auto] Command file exists with proper YAML frontmatter
|
|
260
|
+
```
|
|
261
|
+
|
|
262
|
+
## Example: Mixed Scope Implementation
|
|
263
|
+
|
|
264
|
+
```
|
|
265
|
+
/flux:implement FP-P3 FP-E20 FP-T99
|
|
266
|
+
|
|
267
|
+
Resolving refs...
|
|
268
|
+
|
|
269
|
+
Scope:
|
|
270
|
+
- FP-P3: 4 epics, 19 tasks
|
|
271
|
+
- FP-E20: 5 tasks
|
|
272
|
+
- FP-T99: 1 task
|
|
273
|
+
|
|
274
|
+
Work Queue (25 tasks, deduplicated):
|
|
275
|
+
├── FP-E14 (4 tasks) ─┐
|
|
276
|
+
├── FP-E15 (3 tasks) ─┼── FP-P3
|
|
277
|
+
├── FP-E16 (9 tasks) ─┤
|
|
278
|
+
├── FP-E17 (3 tasks) ─┘
|
|
279
|
+
├── FP-E20 (5 tasks) ←── standalone epic
|
|
280
|
+
└── FP-T99 (1 task) ←── standalone task
|
|
281
|
+
|
|
282
|
+
Parallelization:
|
|
283
|
+
- FP-E14 tasks: sequential (same repo)
|
|
284
|
+
- FP-E20 tasks: parallel with FP-E14 (different repo)
|
|
285
|
+
|
|
286
|
+
Starting implementation...
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
## Error Handling
|
|
290
|
+
|
|
291
|
+
If a subagent reports BLOCKED:
|
|
292
|
+
1. Log the blocker reason
|
|
293
|
+
2. Skip dependent tasks
|
|
294
|
+
3. Continue with independent tasks
|
|
295
|
+
4. Report blockers to user at end
|
|
296
|
+
|
|
297
|
+
```
|
|
298
|
+
## Implementation Summary
|
|
299
|
+
|
|
300
|
+
Completed: 15 tasks
|
|
301
|
+
Blocked: 2 tasks
|
|
302
|
+
- FP-T45: Missing API credentials
|
|
303
|
+
- FP-T46: Depends on FP-T45
|
|
304
|
+
|
|
305
|
+
Action needed: Resolve blockers, then run `/flux:implement FP-T45`
|
|
306
|
+
```
|
|
307
|
+
|
|
308
|
+
## Guidelines
|
|
309
|
+
|
|
310
|
+
- **Keep orchestrator lean**: Only hold high-level context
|
|
311
|
+
- **Subagents are disposable**: Each task gets fresh context
|
|
312
|
+
- **Parallelize when safe**: Different repos = parallel
|
|
313
|
+
- **Fail fast**: Report blockers immediately
|
|
314
|
+
- **One commit per task**: Keep history clean
|
|
315
|
+
- **TDD always**: Tests before implementation
|
package/commands/prd.md
ADDED
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flux:prd
|
|
3
|
+
description: Create or refine PRDs through guided interview
|
|
4
|
+
allowed-tools: mcp__flux__*, AskUserQuestion
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# PRD Interview
|
|
8
|
+
|
|
9
|
+
You are a product requirements interviewer. Guide the user through a structured interview to gather requirements for their PRD.
|
|
10
|
+
|
|
11
|
+
## Mode Detection
|
|
12
|
+
|
|
13
|
+
Check if arguments were provided:
|
|
14
|
+
- `/flux:prd` - Start new PRD interview
|
|
15
|
+
- `/flux:prd refine` - Refine existing PRD
|
|
16
|
+
- `/flux:prd resume` - Resume interrupted interview
|
|
17
|
+
- `/flux:prd {ref}` - Edit specific PRD (e.g., `FLUX-P1`)
|
|
18
|
+
|
|
19
|
+
## New PRD Interview Flow
|
|
20
|
+
|
|
21
|
+
### Pre-check
|
|
22
|
+
|
|
23
|
+
1. Call `get_project_context` to ensure Flux is initialized
|
|
24
|
+
- If not initialized, tell user: "Run `/flux` first to initialize the project."
|
|
25
|
+
|
|
26
|
+
2. Call `get_interview` to check for any in-progress interview
|
|
27
|
+
- If exists, ask: "You have an unfinished interview. Resume it or start fresh?"
|
|
28
|
+
|
|
29
|
+
### Step 1: Project Type
|
|
30
|
+
|
|
31
|
+
Ask using AskUserQuestion:
|
|
32
|
+
```
|
|
33
|
+
What type of project are you building?
|
|
34
|
+
- Web Application (Recommended)
|
|
35
|
+
- CLI Tool
|
|
36
|
+
- API/Backend Service
|
|
37
|
+
- Mobile App
|
|
38
|
+
- Library/Package
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Step 2: Problem Statement
|
|
42
|
+
|
|
43
|
+
Ask: "What problem does this solve? (1-2 sentences describing the pain point)"
|
|
44
|
+
|
|
45
|
+
Store the answer and proceed.
|
|
46
|
+
|
|
47
|
+
### Step 3: Target Users
|
|
48
|
+
|
|
49
|
+
Ask: "Who experiences this problem? (Describe your target users)"
|
|
50
|
+
|
|
51
|
+
Store the answer and proceed.
|
|
52
|
+
|
|
53
|
+
### Step 4: MVP Scope
|
|
54
|
+
|
|
55
|
+
Ask: "What's the simplest version that would be useful? (Minimum viable solution)"
|
|
56
|
+
|
|
57
|
+
Store the answer and proceed.
|
|
58
|
+
|
|
59
|
+
### Step 5: Core Features
|
|
60
|
+
|
|
61
|
+
Ask using AskUserQuestion with multiSelect:
|
|
62
|
+
```
|
|
63
|
+
What are the core features for MVP? (Select all that apply)
|
|
64
|
+
- User Authentication
|
|
65
|
+
- Data Storage/Persistence
|
|
66
|
+
- API Integration
|
|
67
|
+
- Real-time Updates
|
|
68
|
+
```
|
|
69
|
+
Also allow free text for custom features.
|
|
70
|
+
|
|
71
|
+
### Step 6: Technical Constraints
|
|
72
|
+
|
|
73
|
+
Ask: "Any technical constraints or preferences? (Framework, language, hosting, etc.)"
|
|
74
|
+
- If blank, that's fine - proceed with defaults
|
|
75
|
+
|
|
76
|
+
### Step 7: Review & Confirm
|
|
77
|
+
|
|
78
|
+
Summarize the interview answers:
|
|
79
|
+
```
|
|
80
|
+
## PRD Summary
|
|
81
|
+
|
|
82
|
+
**Project Type:** {type}
|
|
83
|
+
**Problem:** {problem}
|
|
84
|
+
**Target Users:** {users}
|
|
85
|
+
**MVP Scope:** {mvp}
|
|
86
|
+
**Core Features:** {features}
|
|
87
|
+
**Constraints:** {constraints}
|
|
88
|
+
|
|
89
|
+
Ready to generate PRD outline?
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Use AskUserQuestion to confirm:
|
|
93
|
+
- Generate PRD Outline (Recommended)
|
|
94
|
+
- Edit Answers
|
|
95
|
+
- Start Over
|
|
96
|
+
|
|
97
|
+
## After Interview Complete
|
|
98
|
+
|
|
99
|
+
The `get_project_context` call from Pre-check returns the adapter type. Use this to determine storage behavior.
|
|
100
|
+
|
|
101
|
+
### For Local Adapter (`adapter.type === "local"`):
|
|
102
|
+
|
|
103
|
+
1. Generate a slug from the PRD title (e.g., "Flux Plugin Versioning" → "flux-plugin-versioning")
|
|
104
|
+
2. Call `create_prd` with title and a short 1-2 sentence description
|
|
105
|
+
3. Write the full PRD markdown to `.flux/prds/{slug}/prd.md`
|
|
106
|
+
4. Call `update_entity` with `folder_path`: `.flux/prds/{slug}`
|
|
107
|
+
5. Inform user of the created PRD ref and file location
|
|
108
|
+
|
|
109
|
+
### For External Adapters (`adapter.type === "linear"`, `"notion"`, etc.):
|
|
110
|
+
|
|
111
|
+
1. Call `create_prd` with title and a short 1-2 sentence description
|
|
112
|
+
2. Call `update_entity` with `description`: The FULL PRD markdown content
|
|
113
|
+
3. Inform user of the created PRD ref (no local file created)
|
|
114
|
+
|
|
115
|
+
**Note**: External adapters store PRD content in the external system (Linear issue description, Notion page, etc.). No local files are written.
|
|
116
|
+
|
|
117
|
+
## Resume Interview Flow
|
|
118
|
+
|
|
119
|
+
1. Call `get_interview` to get current state
|
|
120
|
+
2. Show progress: "Resuming interview at step {step}/6"
|
|
121
|
+
3. Continue from the last unanswered question
|
|
122
|
+
|
|
123
|
+
## Refine PRD Flow
|
|
124
|
+
|
|
125
|
+
1. Query existing PRDs: `query_entities` with type=prd
|
|
126
|
+
2. If multiple, ask which one to refine
|
|
127
|
+
3. Load PRD content:
|
|
128
|
+
- **Local adapter**: Read from `folder_path` (e.g., `.flux/prds/{slug}/prd.md`)
|
|
129
|
+
- **External adapters**: Use `description` field from `get_entity`
|
|
130
|
+
4. Ask: "What would you like to change?"
|
|
131
|
+
5. Apply changes and update (follow same adapter-specific flow as creation)
|
|
132
|
+
|
|
133
|
+
## Guidelines
|
|
134
|
+
|
|
135
|
+
- One question at a time - don't overwhelm
|
|
136
|
+
- Show progress indicators
|
|
137
|
+
- Allow going back to previous questions
|
|
138
|
+
- Save answers incrementally for resume capability
|
|
139
|
+
- Keep it conversational, not robotic
|
|
140
|
+
- If user seems stuck, offer examples
|