@cliangdev/flux-plugin 0.1.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/README.md +135 -0
- package/commands/breakdown.md +262 -0
- package/commands/flux.md +112 -0
- package/commands/implement.md +314 -0
- package/commands/prd.md +139 -0
- package/dist/server/index.js +86929 -0
- package/package.json +62 -0
- package/skills/agent-creator/SKILL.md +310 -0
- package/skills/epic-template/SKILL.md +156 -0
- package/skills/flux-orchestrator/SKILL.md +130 -0
- package/skills/prd-template/SKILL.md +240 -0
package/package.json
ADDED
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@cliangdev/flux-plugin",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Claude Code plugin for AI-first workflow orchestration with MCP server",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"main": "./dist/server/index.js",
|
|
7
|
+
"bin": {
|
|
8
|
+
"flux-plugin": "./dist/server/index.js"
|
|
9
|
+
},
|
|
10
|
+
"files": [
|
|
11
|
+
"dist/",
|
|
12
|
+
"skills/",
|
|
13
|
+
"commands/"
|
|
14
|
+
],
|
|
15
|
+
"scripts": {
|
|
16
|
+
"dev": "bun run src/server/index.ts",
|
|
17
|
+
"build": "bun build src/server/index.ts --outdir dist/server --target node",
|
|
18
|
+
"postbuild": "node -e \"const fs=require('fs');const f='dist/server/index.js';const c=fs.readFileSync(f,'utf-8');if(!c.startsWith('#!/usr/bin/env node')){fs.writeFileSync(f,'#!/usr/bin/env node\\n'+c)}\"",
|
|
19
|
+
"build:compile": "bun build --compile --outfile bin/flux-server src/server/index.ts && bun build --compile --outfile bin/flux-status src/status-line/index.ts",
|
|
20
|
+
"build:compile:server": "bun build --compile --outfile bin/flux-server src/server/index.ts",
|
|
21
|
+
"build:compile:status": "bun build --compile --outfile bin/flux-status src/status-line/index.ts",
|
|
22
|
+
"prepublishOnly": "bun run build",
|
|
23
|
+
"test": "bun test",
|
|
24
|
+
"test:linear-description": "bun run src/server/adapters/__tests__/linear-description-test.ts",
|
|
25
|
+
"typecheck": "tsc --noEmit",
|
|
26
|
+
"lint": "biome check .",
|
|
27
|
+
"lint:fix": "biome check --write .",
|
|
28
|
+
"format": "biome format --write .",
|
|
29
|
+
"verify-release": "bun run scripts/verify-release.ts"
|
|
30
|
+
},
|
|
31
|
+
"repository": {
|
|
32
|
+
"type": "git",
|
|
33
|
+
"url": "https://github.com/cliangdev/flux-plugin.git"
|
|
34
|
+
},
|
|
35
|
+
"keywords": [
|
|
36
|
+
"claude",
|
|
37
|
+
"claude-code",
|
|
38
|
+
"mcp",
|
|
39
|
+
"model-context-protocol",
|
|
40
|
+
"workflow",
|
|
41
|
+
"orchestration",
|
|
42
|
+
"ai",
|
|
43
|
+
"productivity",
|
|
44
|
+
"task-management"
|
|
45
|
+
],
|
|
46
|
+
"author": "Chris Liang <chris@cliangdev.com>",
|
|
47
|
+
"license": "MIT",
|
|
48
|
+
"devDependencies": {
|
|
49
|
+
"@biomejs/biome": "^2.3.11",
|
|
50
|
+
"@types/bun": "^1.3.6",
|
|
51
|
+
"typescript": "^5.0.0"
|
|
52
|
+
},
|
|
53
|
+
"dependencies": {
|
|
54
|
+
"@linear/sdk": "^70.0.0",
|
|
55
|
+
"@modelcontextprotocol/sdk": "^1.25.2",
|
|
56
|
+
"chalk": "^5.4.1",
|
|
57
|
+
"zod": "^4.3.5"
|
|
58
|
+
},
|
|
59
|
+
"publishConfig": {
|
|
60
|
+
"access": "public"
|
|
61
|
+
}
|
|
62
|
+
}
|
|
@@ -0,0 +1,310 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Guide for creating effective subagents. Use when users want to create a new agent that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Agent Creator Skill
|
|
6
|
+
|
|
7
|
+
This skill guides the creation of well-designed Claude Code subagents following Anthropic's best practices.
|
|
8
|
+
|
|
9
|
+
## When to Use This Skill
|
|
10
|
+
|
|
11
|
+
- User wants to create a new subagent
|
|
12
|
+
- User needs to automate a repetitive workflow
|
|
13
|
+
- User wants to add domain-specific expertise to Claude
|
|
14
|
+
- User is building agents for a plugin
|
|
15
|
+
|
|
16
|
+
## Core Principles (from Anthropic)
|
|
17
|
+
|
|
18
|
+
### 1. Start Simple
|
|
19
|
+
"Find the simplest solution possible, and only increase complexity when needed."
|
|
20
|
+
|
|
21
|
+
**Complexity ladder:**
|
|
22
|
+
1. Single optimized prompt (try this first)
|
|
23
|
+
2. Prompt chaining (fixed sequence of steps)
|
|
24
|
+
3. Routing (classify input → specialized handler)
|
|
25
|
+
4. Orchestrator-workers (dynamic delegation)
|
|
26
|
+
5. Full autonomous agent (only if truly needed)
|
|
27
|
+
|
|
28
|
+
### 2. When Agents Excel
|
|
29
|
+
- Open-ended problems where steps are unpredictable
|
|
30
|
+
- Tasks requiring dynamic tool selection
|
|
31
|
+
- Work that benefits from iterative refinement
|
|
32
|
+
- Multi-step processes with branching logic
|
|
33
|
+
|
|
34
|
+
### 3. When to Avoid Agents
|
|
35
|
+
- Fixed, predictable workflows → use prompt chaining
|
|
36
|
+
- Single-domain tasks → use a focused prompt
|
|
37
|
+
- Tasks with clear evaluation criteria → use evaluator-optimizer pattern
|
|
38
|
+
|
|
39
|
+
## Subagent Architecture Patterns
|
|
40
|
+
|
|
41
|
+
### Pattern 1: Specialist Agent
|
|
42
|
+
Single-purpose expert for a specific domain.
|
|
43
|
+
|
|
44
|
+
```markdown
|
|
45
|
+
---
|
|
46
|
+
name: {domain}-specialist
|
|
47
|
+
description: Expert in {domain}. Use when {trigger condition}.
|
|
48
|
+
tools: {minimal required tools}
|
|
49
|
+
model: sonnet
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
You are an expert in {domain}.
|
|
53
|
+
|
|
54
|
+
When invoked:
|
|
55
|
+
1. {First action}
|
|
56
|
+
2. {Second action}
|
|
57
|
+
3. {Output format}
|
|
58
|
+
|
|
59
|
+
Focus on: {core responsibilities}
|
|
60
|
+
Avoid: {out of scope items}
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
**Use when:** Task requires deep expertise in one area.
|
|
64
|
+
|
|
65
|
+
### Pattern 2: Workflow Agent
|
|
66
|
+
Orchestrates a multi-step process with defined stages.
|
|
67
|
+
|
|
68
|
+
```markdown
|
|
69
|
+
---
|
|
70
|
+
name: {workflow}-workflow
|
|
71
|
+
description: Runs the {workflow} process. Use when {trigger}.
|
|
72
|
+
tools: {tools for all stages}
|
|
73
|
+
model: sonnet
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
You orchestrate the {workflow} process.
|
|
77
|
+
|
|
78
|
+
## Workflow Stages
|
|
79
|
+
|
|
80
|
+
### Stage 1: {Name}
|
|
81
|
+
{What to do}
|
|
82
|
+
{Success criteria}
|
|
83
|
+
|
|
84
|
+
### Stage 2: {Name}
|
|
85
|
+
{What to do}
|
|
86
|
+
{Success criteria}
|
|
87
|
+
|
|
88
|
+
### Stage 3: {Name}
|
|
89
|
+
{What to do}
|
|
90
|
+
{Success criteria}
|
|
91
|
+
|
|
92
|
+
## Completion
|
|
93
|
+
{How to know when done}
|
|
94
|
+
{What to output}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**Use when:** Task has predictable stages but needs intelligent execution within each.
|
|
98
|
+
|
|
99
|
+
### Pattern 3: Evaluator Agent
|
|
100
|
+
Reviews and provides structured feedback.
|
|
101
|
+
|
|
102
|
+
```markdown
|
|
103
|
+
---
|
|
104
|
+
name: {domain}-reviewer
|
|
105
|
+
description: Reviews {what} for {criteria}. Use proactively after {trigger}.
|
|
106
|
+
tools: Read, Grep, Glob
|
|
107
|
+
model: inherit
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
You are a {domain} reviewer ensuring {quality standard}.
|
|
111
|
+
|
|
112
|
+
## Review Checklist
|
|
113
|
+
- [ ] {Criterion 1}
|
|
114
|
+
- [ ] {Criterion 2}
|
|
115
|
+
- [ ] {Criterion 3}
|
|
116
|
+
|
|
117
|
+
## Output Format
|
|
118
|
+
Organize feedback by priority:
|
|
119
|
+
1. **Critical** (must fix)
|
|
120
|
+
2. **Warning** (should fix)
|
|
121
|
+
3. **Suggestion** (consider)
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
**Use when:** Clear evaluation criteria exist and feedback improves outcomes.
|
|
125
|
+
|
|
126
|
+
### Pattern 4: Research Agent
|
|
127
|
+
Gathers and synthesizes information.
|
|
128
|
+
|
|
129
|
+
```markdown
|
|
130
|
+
---
|
|
131
|
+
name: {domain}-researcher
|
|
132
|
+
description: Researches {topic area}. Use when encountering unfamiliar {domain}.
|
|
133
|
+
tools: Read, Glob, Grep, WebFetch, WebSearch
|
|
134
|
+
model: sonnet
|
|
135
|
+
---
|
|
136
|
+
|
|
137
|
+
You are a research specialist for {domain}.
|
|
138
|
+
|
|
139
|
+
When asked to research:
|
|
140
|
+
1. Identify key questions to answer
|
|
141
|
+
2. Search for authoritative sources
|
|
142
|
+
3. Synthesize findings into actionable insights
|
|
143
|
+
4. Cite sources
|
|
144
|
+
|
|
145
|
+
## Output Format
|
|
146
|
+
### Summary
|
|
147
|
+
{1-2 sentence overview}
|
|
148
|
+
|
|
149
|
+
### Key Findings
|
|
150
|
+
- {Finding 1}
|
|
151
|
+
- {Finding 2}
|
|
152
|
+
|
|
153
|
+
### Recommendations
|
|
154
|
+
{How to apply findings}
|
|
155
|
+
|
|
156
|
+
### Sources
|
|
157
|
+
- {Source 1}
|
|
158
|
+
- {Source 2}
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
**Use when:** Tasks require gathering external information.
|
|
162
|
+
|
|
163
|
+
## Best Practices
|
|
164
|
+
|
|
165
|
+
### 1. Write Detailed Descriptions
|
|
166
|
+
The `description` field determines when Claude delegates to the subagent.
|
|
167
|
+
|
|
168
|
+
**Good:**
|
|
169
|
+
```yaml
|
|
170
|
+
description: Expert code reviewer for TypeScript. Use proactively after writing or modifying any .ts or .tsx files. Focuses on type safety, best practices, and potential bugs.
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
**Bad:**
|
|
174
|
+
```yaml
|
|
175
|
+
description: Reviews code
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
### 2. Limit Tool Access
|
|
179
|
+
Grant only the tools the agent needs. Less is more.
|
|
180
|
+
|
|
181
|
+
| Agent Type | Typical Tools |
|
|
182
|
+
|------------|---------------|
|
|
183
|
+
| Read-only analyzer | `Read`, `Grep`, `Glob` |
|
|
184
|
+
| Code modifier | `Read`, `Edit`, `Grep`, `Glob` |
|
|
185
|
+
| Build/test runner | `Bash`, `Read`, `Glob` |
|
|
186
|
+
| Research agent | `WebFetch`, `WebSearch`, `Read` |
|
|
187
|
+
|
|
188
|
+
### 3. Choose the Right Model
|
|
189
|
+
|
|
190
|
+
| Model | Use When |
|
|
191
|
+
|-------|----------|
|
|
192
|
+
| `haiku` | Fast, simple tasks; exploration; high-volume |
|
|
193
|
+
| `sonnet` | Balanced capability; most agents |
|
|
194
|
+
| `opus` | Complex reasoning; critical decisions |
|
|
195
|
+
| `inherit` | Match parent conversation |
|
|
196
|
+
|
|
197
|
+
### 4. Make Agents Proactive
|
|
198
|
+
Add "use proactively" to description for autonomous invocation:
|
|
199
|
+
|
|
200
|
+
```yaml
|
|
201
|
+
description: Test runner that executes after code changes. Use proactively when files in src/ are modified.
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
### 5. Define Clear Completion Criteria
|
|
205
|
+
Every agent should know when it's done:
|
|
206
|
+
|
|
207
|
+
```markdown
|
|
208
|
+
## Completion
|
|
209
|
+
You are done when:
|
|
210
|
+
- All tests pass
|
|
211
|
+
- Coverage > 80%
|
|
212
|
+
- No linting errors
|
|
213
|
+
|
|
214
|
+
Output a summary of what was accomplished.
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
### 6. Handle Edge Cases
|
|
218
|
+
Document what the agent should NOT do:
|
|
219
|
+
|
|
220
|
+
```markdown
|
|
221
|
+
## Boundaries
|
|
222
|
+
- Do NOT modify files outside src/
|
|
223
|
+
- Do NOT run commands that could affect production
|
|
224
|
+
- If unsure, ask for clarification instead of guessing
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
## Creating an Agent: Interview Flow
|
|
228
|
+
|
|
229
|
+
When helping create an agent, ask:
|
|
230
|
+
|
|
231
|
+
1. **Purpose**: "What task should this agent handle?"
|
|
232
|
+
2. **Trigger**: "When should it be invoked? (after code changes, on request, etc.)"
|
|
233
|
+
3. **Tools**: "What capabilities does it need? (read files, edit, run commands, web search)"
|
|
234
|
+
4. **Autonomy**: "Should it act proactively or wait to be called?"
|
|
235
|
+
5. **Output**: "What should it produce when done?"
|
|
236
|
+
|
|
237
|
+
Then generate the appropriate pattern.
|
|
238
|
+
|
|
239
|
+
## File Locations
|
|
240
|
+
|
|
241
|
+
| Scope | Location | Use Case |
|
|
242
|
+
|-------|----------|----------|
|
|
243
|
+
| User | `~/.claude/agents/` | Personal agents across all projects |
|
|
244
|
+
| Project | `.claude/agents/` | Shared with team via version control |
|
|
245
|
+
| Plugin | `{plugin}/agents/` | Distributed with plugin |
|
|
246
|
+
|
|
247
|
+
## Example: Creating a Research Subagent
|
|
248
|
+
|
|
249
|
+
**User request:** "I need an agent that researches technologies when I mention something unfamiliar"
|
|
250
|
+
|
|
251
|
+
**Generated agent:**
|
|
252
|
+
|
|
253
|
+
```markdown
|
|
254
|
+
---
|
|
255
|
+
name: tech-researcher
|
|
256
|
+
description: Researches unfamiliar technologies, libraries, and APIs. Use proactively when user mentions tech that may need investigation, or when explicitly asked to research something.
|
|
257
|
+
tools: WebFetch, WebSearch, Read
|
|
258
|
+
model: sonnet
|
|
259
|
+
---
|
|
260
|
+
|
|
261
|
+
You are a technology research specialist.
|
|
262
|
+
|
|
263
|
+
## When to Activate
|
|
264
|
+
- User mentions a library, framework, or API you're uncertain about
|
|
265
|
+
- User explicitly asks "research X" or "what is X?"
|
|
266
|
+
- Confidence in technical recommendation < 70%
|
|
267
|
+
|
|
268
|
+
## Research Process
|
|
269
|
+
1. **Identify** the core questions to answer
|
|
270
|
+
2. **Search** using WebSearch for recent, authoritative sources
|
|
271
|
+
3. **Deep dive** using WebFetch on official docs, GitHub repos
|
|
272
|
+
4. **Synthesize** findings relevant to user's context
|
|
273
|
+
|
|
274
|
+
## Output Format
|
|
275
|
+
|
|
276
|
+
### {Technology Name}
|
|
277
|
+
|
|
278
|
+
**What it is:** {1-sentence description}
|
|
279
|
+
|
|
280
|
+
**Key features:**
|
|
281
|
+
- {Feature 1}
|
|
282
|
+
- {Feature 2}
|
|
283
|
+
|
|
284
|
+
**Relevance to your project:**
|
|
285
|
+
{How this applies to what user is building}
|
|
286
|
+
|
|
287
|
+
**Recommendations:**
|
|
288
|
+
{Should they use it? Alternatives?}
|
|
289
|
+
|
|
290
|
+
**Sources:**
|
|
291
|
+
- [{Source title}]({url})
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
## Validation Checklist
|
|
295
|
+
|
|
296
|
+
Before finalizing an agent, verify:
|
|
297
|
+
|
|
298
|
+
- [ ] Description clearly states when to use it
|
|
299
|
+
- [ ] Tools are minimal and appropriate
|
|
300
|
+
- [ ] Model matches complexity needs
|
|
301
|
+
- [ ] Prompt includes clear instructions
|
|
302
|
+
- [ ] Output format is defined
|
|
303
|
+
- [ ] Completion criteria are specified
|
|
304
|
+
- [ ] Edge cases and boundaries are documented
|
|
305
|
+
|
|
306
|
+
## References
|
|
307
|
+
|
|
308
|
+
- [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) - Anthropic's agent design principles
|
|
309
|
+
- [Claude Code Subagents](https://code.claude.com/docs/en/sub-agents) - Official subagent documentation
|
|
310
|
+
- [Awesome Claude Code Subagents](https://github.com/VoltAgent/awesome-claude-code-subagents) - Community examples
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Epic and task structure patterns for Flux. Use when breaking PRDs into epics and tasks. Epics should be self-contained with clear acceptance criteria.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Epic Template Skill
|
|
6
|
+
|
|
7
|
+
Epics are **self-contained work packages** that can be implemented independently.
|
|
8
|
+
|
|
9
|
+
## Epic Structure
|
|
10
|
+
|
|
11
|
+
```markdown
|
|
12
|
+
## {Epic Title}
|
|
13
|
+
|
|
14
|
+
**Goal**: {One sentence: what does completing this epic achieve?}
|
|
15
|
+
|
|
16
|
+
**Scope**:
|
|
17
|
+
- IN: {What's included}
|
|
18
|
+
- OUT: {What's explicitly excluded}
|
|
19
|
+
|
|
20
|
+
**Tasks**:
|
|
21
|
+
1. {Task title} - {brief description}
|
|
22
|
+
2. {Task title} - {brief description}
|
|
23
|
+
|
|
24
|
+
**Acceptance Criteria**:
|
|
25
|
+
- [ ] {Testable criterion 1}
|
|
26
|
+
- [ ] {Testable criterion 2}
|
|
27
|
+
|
|
28
|
+
**Dependencies**: {Other epics this depends on, or "None"}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Task Structure
|
|
32
|
+
|
|
33
|
+
```markdown
|
|
34
|
+
### {Task Title}
|
|
35
|
+
|
|
36
|
+
{1-2 sentences: what needs to be done}
|
|
37
|
+
|
|
38
|
+
**Acceptance Criteria**:
|
|
39
|
+
- [ ] {Specific, testable criterion}
|
|
40
|
+
- [ ] {Specific, testable criterion}
|
|
41
|
+
|
|
42
|
+
**Files**: {Key files to create/modify, if known}
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
## Guidelines
|
|
46
|
+
|
|
47
|
+
### Epic Sizing
|
|
48
|
+
- **Too small**: "Add login button" → merge into larger epic
|
|
49
|
+
- **Right size**: "User Authentication" (3-7 tasks, 1-3 days work)
|
|
50
|
+
- **Too big**: "Build entire frontend" → split into multiple epics
|
|
51
|
+
|
|
52
|
+
### Task Sizing
|
|
53
|
+
- One task = one commit
|
|
54
|
+
- Should take 30min - 4hrs
|
|
55
|
+
- Has clear "done" state
|
|
56
|
+
|
|
57
|
+
### Dependency Order
|
|
58
|
+
- Order epics so dependencies come first
|
|
59
|
+
- Mark blocking dependencies explicitly
|
|
60
|
+
- Prefer parallel-safe epics when possible
|
|
61
|
+
|
|
62
|
+
### Test Type Convention
|
|
63
|
+
|
|
64
|
+
Mark each acceptance criterion with its test type as a prefix:
|
|
65
|
+
- **`[auto]`** - Verified by automated test (unit, integration, e2e)
|
|
66
|
+
- **`[manual]`** - Requires human verification (include steps)
|
|
67
|
+
|
|
68
|
+
For manual criteria, add verification steps after `→ Verify:`:
|
|
69
|
+
```
|
|
70
|
+
[manual] Dashboard displays correctly on mobile → Verify: Open on phone, check layout
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
Examples:
|
|
74
|
+
- `[auto] API returns 401 for invalid credentials`
|
|
75
|
+
- `[auto] User record is created in database`
|
|
76
|
+
- `[manual] Error message is user-friendly → Verify: Read message aloud, is it clear?`
|
|
77
|
+
- `[manual] Loading animation feels smooth → Verify: Test on slow network`
|
|
78
|
+
|
|
79
|
+
Prefer `[auto]` wherever possible - automated tests are more reliable and repeatable.
|
|
80
|
+
|
|
81
|
+
## Breaking Down PRDs
|
|
82
|
+
|
|
83
|
+
### Step 1: Identify Epics
|
|
84
|
+
Read PRD features and group into logical work packages:
|
|
85
|
+
- Each P0 feature often maps to 1-2 epics
|
|
86
|
+
- Shared infrastructure (auth, database setup) = separate epic
|
|
87
|
+
- UI and backend for same feature can be same or separate epic
|
|
88
|
+
|
|
89
|
+
### Step 2: Order by Dependencies
|
|
90
|
+
```
|
|
91
|
+
Epic 1: Project Setup (no deps)
|
|
92
|
+
Epic 2: Database Schema (depends on 1)
|
|
93
|
+
Epic 3: User Auth (depends on 2)
|
|
94
|
+
Epic 4: Core Feature A (depends on 3)
|
|
95
|
+
Epic 5: Core Feature B (depends on 3) ← can parallel with 4
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
### Step 3: Break into Tasks
|
|
99
|
+
For each epic, create 3-7 tasks:
|
|
100
|
+
- Start with data/schema tasks
|
|
101
|
+
- Then business logic
|
|
102
|
+
- Then API/interface
|
|
103
|
+
- Finally integration/wiring
|
|
104
|
+
|
|
105
|
+
### Example Breakdown
|
|
106
|
+
|
|
107
|
+
**PRD Feature**:
|
|
108
|
+
> **User Authentication**: Users can sign up and log in
|
|
109
|
+
> - Sign up with email, password, name
|
|
110
|
+
> - Login returns JWT
|
|
111
|
+
> - Forgot password flow
|
|
112
|
+
|
|
113
|
+
**Epic**:
|
|
114
|
+
```markdown
|
|
115
|
+
## User Authentication
|
|
116
|
+
|
|
117
|
+
**Goal**: Users can create accounts and authenticate.
|
|
118
|
+
|
|
119
|
+
**Scope**:
|
|
120
|
+
- IN: Sign up, login, JWT tokens, forgot password
|
|
121
|
+
- OUT: OAuth, 2FA, session management
|
|
122
|
+
|
|
123
|
+
**Tasks**:
|
|
124
|
+
1. Create users table schema
|
|
125
|
+
2. Implement sign up endpoint
|
|
126
|
+
3. Implement login endpoint with JWT
|
|
127
|
+
4. Add forgot password email flow
|
|
128
|
+
5. Create auth middleware
|
|
129
|
+
|
|
130
|
+
**Acceptance Criteria**:
|
|
131
|
+
- [ ] User can sign up with email/password/name
|
|
132
|
+
- [ ] User can login and receive JWT
|
|
133
|
+
- [ ] Invalid credentials return 401
|
|
134
|
+
- [ ] Forgot password sends reset email
|
|
135
|
+
|
|
136
|
+
**Dependencies**: Database Setup epic
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
## MCP Integration
|
|
140
|
+
|
|
141
|
+
When breaking down:
|
|
142
|
+
|
|
143
|
+
1. Create epic: `create_epic` with prd_ref, title, description
|
|
144
|
+
2. Add criteria: `add_criteria` for each acceptance criterion
|
|
145
|
+
3. Create tasks: `create_task` with epic_ref, title, description
|
|
146
|
+
4. Add task criteria: `add_criteria` for each task criterion
|
|
147
|
+
5. Add dependencies: `add_dependency` between epics if needed
|
|
148
|
+
|
|
149
|
+
## Workflow
|
|
150
|
+
|
|
151
|
+
1. **Read PRD** → Understand features and scope
|
|
152
|
+
2. **Draft epics** → Group features into work packages
|
|
153
|
+
3. **Review with user** → Confirm epic structure
|
|
154
|
+
4. **Create in MCP** → Use tools to persist
|
|
155
|
+
5. **Break into tasks** → Detail each epic
|
|
156
|
+
6. **Set dependencies** → Order the work
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Orchestrates Flux workflows based on project context
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Flux Orchestrator Skill
|
|
6
|
+
|
|
7
|
+
This skill is automatically active when working in a Flux project. It provides context about available tools and workflow patterns.
|
|
8
|
+
|
|
9
|
+
## Available MCP Tools
|
|
10
|
+
|
|
11
|
+
### Query Tools
|
|
12
|
+
- `get_project_context` - Check if project initialized, get name/vision/prefix
|
|
13
|
+
- `get_stats` - Get PRD/epic/task counts by status
|
|
14
|
+
- `get_entity` - Fetch entity by ref with optional includes (criteria, tasks, dependencies)
|
|
15
|
+
- `query_entities` - Search entities by type, status, parent ref
|
|
16
|
+
|
|
17
|
+
### Mutation Tools
|
|
18
|
+
- `init_project` - Initialize new .flux/ directory with project.json and database
|
|
19
|
+
- `create_prd` - Create a new PRD
|
|
20
|
+
- `create_epic` - Create an epic linked to a PRD
|
|
21
|
+
- `create_task` - Create a task linked to an epic
|
|
22
|
+
- `update_entity` - Update any entity's fields
|
|
23
|
+
- `update_status` - Update entity status with validation
|
|
24
|
+
- `delete_entity` - Delete entity with cascade
|
|
25
|
+
|
|
26
|
+
### Relationship Tools
|
|
27
|
+
- `add_dependency` - Add dependency between epics or tasks
|
|
28
|
+
- `remove_dependency` - Remove a dependency
|
|
29
|
+
- `add_criteria` - Add acceptance criterion to epic or task
|
|
30
|
+
- `mark_criteria_met` - Mark criterion as satisfied
|
|
31
|
+
|
|
32
|
+
## Workflow States
|
|
33
|
+
|
|
34
|
+
The Flux project progresses through these states:
|
|
35
|
+
|
|
36
|
+
1. **Uninitialized** - No .flux/ directory
|
|
37
|
+
- Action: Run `/flux` to initialize
|
|
38
|
+
|
|
39
|
+
2. **No PRDs** - Project initialized but empty
|
|
40
|
+
- Action: Run `/flux:prd` to create first PRD
|
|
41
|
+
|
|
42
|
+
3. **PRD Draft** - PRD created but needs review
|
|
43
|
+
- Action: Review and submit for approval or refine
|
|
44
|
+
|
|
45
|
+
4. **PRD Pending Review** - PRD submitted for review
|
|
46
|
+
- Action: Run critique agent, then approve or revise
|
|
47
|
+
|
|
48
|
+
5. **PRD Reviewed** - Critique complete
|
|
49
|
+
- Action: Address feedback, then approve or revise to DRAFT
|
|
50
|
+
|
|
51
|
+
6. **PRD Approved** - Ready for epic breakdown
|
|
52
|
+
- Action: Run `/flux:breakdown` to create epics
|
|
53
|
+
|
|
54
|
+
7. **Breakdown Ready** - Epics and tasks created
|
|
55
|
+
- Action: Run `/flux:implement` to start coding
|
|
56
|
+
|
|
57
|
+
8. **Implementation In Progress** - Tasks IN_PROGRESS
|
|
58
|
+
- Action: Continue implementing current task
|
|
59
|
+
|
|
60
|
+
9. **Complete** - All tasks COMPLETED
|
|
61
|
+
- Action: Review and create PR
|
|
62
|
+
|
|
63
|
+
## Entity References
|
|
64
|
+
|
|
65
|
+
All entities have a reference format: `{PREFIX}-{TYPE}{NUMBER}`
|
|
66
|
+
|
|
67
|
+
- PRD: `MSA-P1`, `MSA-P2`
|
|
68
|
+
- Epic: `MSA-E1`, `MSA-E2`
|
|
69
|
+
- Task: `MSA-T1`, `MSA-T2`
|
|
70
|
+
|
|
71
|
+
The prefix is generated from the project name during initialization.
|
|
72
|
+
|
|
73
|
+
## Status Values
|
|
74
|
+
|
|
75
|
+
### PRD Statuses (6-stage workflow)
|
|
76
|
+
- `DRAFT` - Initial state, being created/refined
|
|
77
|
+
- `PENDING_REVIEW` - Submitted for critique
|
|
78
|
+
- `REVIEWED` - Critique complete, awaiting approval
|
|
79
|
+
- `APPROVED` - Ready for epic breakdown
|
|
80
|
+
- `BREAKDOWN_READY` - Epics and tasks created
|
|
81
|
+
- `COMPLETED` - All epics done
|
|
82
|
+
|
|
83
|
+
### Valid PRD Transitions
|
|
84
|
+
```
|
|
85
|
+
DRAFT → PENDING_REVIEW
|
|
86
|
+
PENDING_REVIEW → REVIEWED | DRAFT (revise)
|
|
87
|
+
REVIEWED → APPROVED | DRAFT (revise)
|
|
88
|
+
APPROVED → BREAKDOWN_READY
|
|
89
|
+
BREAKDOWN_READY → COMPLETED
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### Epic/Task Statuses
|
|
93
|
+
- `PENDING` - Not started
|
|
94
|
+
- `IN_PROGRESS` - Currently being worked on
|
|
95
|
+
- `COMPLETED` - Done
|
|
96
|
+
|
|
97
|
+
## Confidence-Based Autonomy
|
|
98
|
+
|
|
99
|
+
The orchestrator uses confidence levels to determine autonomy:
|
|
100
|
+
|
|
101
|
+
| Confidence | Behavior | Example |
|
|
102
|
+
|------------|----------|---------|
|
|
103
|
+
| > 80% | Auto-execute, inform user | "I'm creating the epic structure..." |
|
|
104
|
+
| 50-80% | Suggest action, wait for confirmation | "Ready to break down into tasks. Proceed?" |
|
|
105
|
+
| < 50% | Ask clarifying question | "Should we research this technology first?" |
|
|
106
|
+
|
|
107
|
+
### Confidence Indicators
|
|
108
|
+
- **High confidence (>80%)**: Clear next step, no ambiguity, user has been responsive
|
|
109
|
+
- **Medium confidence (50-80%)**: Reasonable next step, some uncertainty
|
|
110
|
+
- **Low confidence (<50%)**: Multiple valid paths, unclear requirements, unfamiliar tech
|
|
111
|
+
|
|
112
|
+
## Available Subagents
|
|
113
|
+
|
|
114
|
+
### Research Agent
|
|
115
|
+
- **Trigger**: Unfamiliar technology mentioned, confidence < 70%
|
|
116
|
+
- **Purpose**: Gather information about libraries, frameworks, APIs
|
|
117
|
+
- **Tools**: Context7, WebSearch, WebFetch
|
|
118
|
+
|
|
119
|
+
### Critique Agent
|
|
120
|
+
- **Trigger**: PRD status becomes PENDING_REVIEW
|
|
121
|
+
- **Purpose**: Analyze feasibility, scope, risks
|
|
122
|
+
- **Output**: Structured critique with recommendations
|
|
123
|
+
|
|
124
|
+
## Best Practices
|
|
125
|
+
|
|
126
|
+
1. **Check context first** - Always call `get_project_context` before taking actions
|
|
127
|
+
2. **Use refs, not IDs** - Tools accept human-readable refs like `MSA-E1`
|
|
128
|
+
3. **Validate status transitions** - Use `update_status` which enforces valid transitions
|
|
129
|
+
4. **Include related data** - Use `include` parameter to fetch nested entities in one call
|
|
130
|
+
5. **Handle errors gracefully** - Tools return errors with codes, display user-friendly messages
|