rpi-kit 1.0.0 → 1.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/.claude-plugin/marketplace.json +23 -0
- package/.claude-plugin/plugin.json +20 -0
- package/README.md +19 -3
- package/agents/test-engineer.md +7 -0
- package/bin/cli.js +14 -2
- package/bin/onboarding.js +145 -0
- package/codex.md +69 -0
- package/commands/rpi/add-todo.md +83 -0
- package/commands/rpi/implement.md +41 -0
- package/commands/rpi/init.md +2 -2
- package/commands/rpi/new.md +47 -3
- package/commands/rpi/onboarding.md +241 -0
- package/package.json +5 -1
- package/skills/rpi-agents/SKILL.md +58 -0
- package/skills/rpi-workflow/SKILL.md +150 -0
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
|
3
|
+
"name": "rpi-kit",
|
|
4
|
+
"version": "1.1.0",
|
|
5
|
+
"description": "Research → Plan → Implement. A systematic feature development workflow with validation gates, multi-role agent teams, and adaptive depth.",
|
|
6
|
+
"owner": {
|
|
7
|
+
"name": "Daniel Mendes"
|
|
8
|
+
},
|
|
9
|
+
"plugins": [
|
|
10
|
+
{
|
|
11
|
+
"name": "rpi-kit",
|
|
12
|
+
"source": "./",
|
|
13
|
+
"description": "Research → Plan → Implement. A systematic feature development workflow for Claude Code and Codex.",
|
|
14
|
+
"version": "1.1.0",
|
|
15
|
+
"author": {
|
|
16
|
+
"name": "Daniel Mendes"
|
|
17
|
+
},
|
|
18
|
+
"license": "MIT",
|
|
19
|
+
"keywords": ["workflow", "research", "planning", "implementation", "feature-development", "agents"],
|
|
20
|
+
"category": "productivity"
|
|
21
|
+
}
|
|
22
|
+
]
|
|
23
|
+
}
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "rpi-kit",
|
|
3
|
+
"version": "1.1.0",
|
|
4
|
+
"description": "Research → Plan → Implement. A systematic feature development workflow with validation gates, multi-role agent teams, and adaptive depth.",
|
|
5
|
+
"author": {
|
|
6
|
+
"name": "Daniel Mendes",
|
|
7
|
+
"url": "https://github.com/dmend3z"
|
|
8
|
+
},
|
|
9
|
+
"repository": "https://github.com/dmend3z/rpi-kit",
|
|
10
|
+
"license": "MIT",
|
|
11
|
+
"keywords": [
|
|
12
|
+
"workflow",
|
|
13
|
+
"research",
|
|
14
|
+
"planning",
|
|
15
|
+
"implementation",
|
|
16
|
+
"feature-development",
|
|
17
|
+
"agents",
|
|
18
|
+
"codex"
|
|
19
|
+
]
|
|
20
|
+
}
|
package/README.md
CHANGED
|
@@ -6,13 +6,29 @@ RPIKit guides AI-first developers through a structured 3-phase pipeline with val
|
|
|
6
6
|
|
|
7
7
|
## Install
|
|
8
8
|
|
|
9
|
-
### Claude Code
|
|
9
|
+
### Claude Code
|
|
10
|
+
|
|
11
|
+
**From the marketplace (recommended):**
|
|
10
12
|
|
|
11
13
|
```bash
|
|
12
14
|
claude plugin install rpi-kit
|
|
13
15
|
```
|
|
14
16
|
|
|
15
|
-
|
|
17
|
+
**From npm:**
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
npm install -g rpi-kit
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
The postinstall script registers the plugin automatically. If it fails, register manually:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
claude plugin install /path/to/rpi-kit
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
> **Tip:** `npm root -g` shows where global packages are installed. The path is usually something like `~/.nvm/versions/node/vX.X.X/lib/node_modules/rpi-kit`.
|
|
30
|
+
|
|
31
|
+
**From source:**
|
|
16
32
|
|
|
17
33
|
```bash
|
|
18
34
|
git clone https://github.com/dmend3z/rpi-kit.git
|
|
@@ -147,7 +163,7 @@ commit_style: conventional # Commit message format
|
|
|
147
163
|
parallel_threshold: 8 # Task count for parallel mode
|
|
148
164
|
skip_artifacts: [] # Artifacts to never generate
|
|
149
165
|
review_after_implement: true # Mandatory review gate
|
|
150
|
-
|
|
166
|
+
isolation: none # none | branch | worktree
|
|
151
167
|
tdd: false # Enable Test-Driven Development
|
|
152
168
|
test_runner: auto # Test command (auto-detect or explicit)
|
|
153
169
|
```
|
package/agents/test-engineer.md
CHANGED
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: test-engineer
|
|
3
|
+
description: Writes focused, minimal failing tests before implementation code exists. Follows strict TDD — one test at a time, verify it fails, then hand off to the implementer. Spawned by /rpi:test and /rpi:implement (when TDD enabled).
|
|
4
|
+
tools: Read, Write, Edit, Bash, Glob, Grep
|
|
5
|
+
color: red
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Test Engineer
|
|
2
9
|
|
|
3
10
|
You write focused, minimal failing tests before implementation code exists. You follow strict TDD: one test at a time, verify it fails, then hand off to the implementer.
|
package/bin/cli.js
CHANGED
|
@@ -28,14 +28,14 @@ function hasCodex() {
|
|
|
28
28
|
function installClaude() {
|
|
29
29
|
log("Installing RPIKit for Claude Code...");
|
|
30
30
|
try {
|
|
31
|
-
execFileSync("claude", ["plugin", "
|
|
31
|
+
execFileSync("claude", ["plugin", "install", PLUGIN_DIR], {
|
|
32
32
|
stdio: silent ? "pipe" : "inherit",
|
|
33
33
|
});
|
|
34
34
|
log("Claude Code: installed.");
|
|
35
35
|
return true;
|
|
36
36
|
} catch {
|
|
37
37
|
log("Claude Code: could not register plugin automatically.");
|
|
38
|
-
log(" Manual install: claude plugin
|
|
38
|
+
log(" Manual install: claude plugin install " + PLUGIN_DIR);
|
|
39
39
|
return false;
|
|
40
40
|
}
|
|
41
41
|
}
|
|
@@ -85,6 +85,7 @@ Usage:
|
|
|
85
85
|
rpi-kit install --claude Install for Claude Code only
|
|
86
86
|
rpi-kit install --codex Install for Codex only (copies AGENTS.md to cwd)
|
|
87
87
|
rpi-kit uninstall Remove from Claude Code
|
|
88
|
+
rpi-kit onboarding Interactive walkthrough of the workflow
|
|
88
89
|
rpi-kit help Show this help
|
|
89
90
|
|
|
90
91
|
After install, use in Claude Code:
|
|
@@ -127,10 +128,21 @@ switch (command) {
|
|
|
127
128
|
log(" rpi-kit install --codex");
|
|
128
129
|
}
|
|
129
130
|
}
|
|
131
|
+
|
|
132
|
+
if (installed && !silent) {
|
|
133
|
+
log("");
|
|
134
|
+
log("New to RPIKit? Run: rpi-kit onboarding");
|
|
135
|
+
}
|
|
130
136
|
}
|
|
131
137
|
break;
|
|
132
138
|
}
|
|
133
139
|
|
|
140
|
+
case "onboarding": {
|
|
141
|
+
const { run } = require("./onboarding");
|
|
142
|
+
run();
|
|
143
|
+
break;
|
|
144
|
+
}
|
|
145
|
+
|
|
134
146
|
case "uninstall":
|
|
135
147
|
uninstallClaude();
|
|
136
148
|
break;
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
const readline = require("readline");
|
|
2
|
+
|
|
3
|
+
const CYAN = "\x1b[36m";
|
|
4
|
+
const GREEN = "\x1b[32m";
|
|
5
|
+
const YELLOW = "\x1b[33m";
|
|
6
|
+
const DIM = "\x1b[2m";
|
|
7
|
+
const BOLD = "\x1b[1m";
|
|
8
|
+
const RESET = "\x1b[0m";
|
|
9
|
+
|
|
10
|
+
const steps = [
|
|
11
|
+
{
|
|
12
|
+
title: "Welcome to RPIKit",
|
|
13
|
+
body: `
|
|
14
|
+
${BOLD}Research → Plan → Implement${RESET}
|
|
15
|
+
|
|
16
|
+
RPIKit is a structured feature development workflow for Claude Code and Codex.
|
|
17
|
+
It guides you through 3 phases with validation gates, so you research before
|
|
18
|
+
you plan, and plan before you code.
|
|
19
|
+
|
|
20
|
+
${DIM}11 specialized agents simulate a product team:
|
|
21
|
+
engineers, PMs, designers, reviewers — all working in parallel.${RESET}`,
|
|
22
|
+
},
|
|
23
|
+
{
|
|
24
|
+
title: "The Pipeline",
|
|
25
|
+
body: `
|
|
26
|
+
${DIM}Your feature flows through these phases:${RESET}
|
|
27
|
+
|
|
28
|
+
${CYAN}/rpi:new${RESET} Describe your feature → ${BOLD}REQUEST.md${RESET}
|
|
29
|
+
│
|
|
30
|
+
${CYAN}/rpi:research${RESET} Parallel agent analysis → ${BOLD}RESEARCH.md${RESET} + GO/NO-GO
|
|
31
|
+
│
|
|
32
|
+
${CYAN}/rpi:plan${RESET} Generate specs + tasks → ${BOLD}PLAN.md${RESET} + eng/pm/ux.md
|
|
33
|
+
│
|
|
34
|
+
${CYAN}/rpi:implement${RESET} Execute tasks with tracking → ${BOLD}IMPLEMENT.md${RESET}
|
|
35
|
+
│
|
|
36
|
+
${CYAN}/rpi:simplify${RESET} Code quality checks → auto-fix issues
|
|
37
|
+
│
|
|
38
|
+
${CYAN}/rpi:review${RESET} Review against plan → PASS / FAIL
|
|
39
|
+
│
|
|
40
|
+
${CYAN}/rpi:docs${RESET} Document the code → inline docs + changelog`,
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
title: "Research Tiers",
|
|
44
|
+
body: `
|
|
45
|
+
${DIM}Control depth and cost with tier flags:${RESET}
|
|
46
|
+
|
|
47
|
+
${GREEN}--quick${RESET} 2 agents Fast feasibility check
|
|
48
|
+
${YELLOW}--standard${RESET} 4 agents Scope + technical approach ${DIM}(default)${RESET}
|
|
49
|
+
${CYAN}--deep${RESET} 6 agents Full strategic analysis
|
|
50
|
+
|
|
51
|
+
${DIM}Agents run in parallel — deep research doesn't mean slow research.${RESET}`,
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
title: "Feature Folder Structure",
|
|
55
|
+
body: `
|
|
56
|
+
${DIM}Each feature gets its own folder with all artifacts:${RESET}
|
|
57
|
+
|
|
58
|
+
rpi/
|
|
59
|
+
└── ${BOLD}your-feature/${RESET}
|
|
60
|
+
├── REQUEST.md ${DIM}What and why${RESET}
|
|
61
|
+
├── research/
|
|
62
|
+
│ └── RESEARCH.md ${DIM}GO/NO-GO analysis${RESET}
|
|
63
|
+
├── plan/
|
|
64
|
+
│ ├── PLAN.md ${DIM}Task checklist${RESET}
|
|
65
|
+
│ ├── eng.md ${DIM}Technical spec${RESET}
|
|
66
|
+
│ ├── pm.md ${DIM}Product requirements${RESET}
|
|
67
|
+
│ └── ux.md ${DIM}UX design${RESET}
|
|
68
|
+
└── implement/
|
|
69
|
+
├── IMPLEMENT.md ${DIM}Execution audit trail${RESET}
|
|
70
|
+
└── DOCS.md ${DIM}Documentation summary${RESET}`,
|
|
71
|
+
},
|
|
72
|
+
{
|
|
73
|
+
title: "TDD Support",
|
|
74
|
+
body: `
|
|
75
|
+
${DIM}RPIKit supports strict Test-Driven Development per task:${RESET}
|
|
76
|
+
|
|
77
|
+
${CYAN}RED${RESET} → Write one failing test
|
|
78
|
+
${GREEN}GREEN${RESET} → Write minimal code to pass
|
|
79
|
+
${YELLOW}REFACTOR${RESET} → Clean up, re-run tests
|
|
80
|
+
|
|
81
|
+
${DIM}Enable in .rpi.yaml:${RESET}
|
|
82
|
+
tdd: true
|
|
83
|
+
test_runner: auto
|
|
84
|
+
|
|
85
|
+
${DIM}Or run standalone:${RESET} /rpi:test your-feature --task 1.2`,
|
|
86
|
+
},
|
|
87
|
+
{
|
|
88
|
+
title: "Get Started",
|
|
89
|
+
body: `
|
|
90
|
+
${BOLD}Step 1:${RESET} Open Claude Code in your project
|
|
91
|
+
|
|
92
|
+
${BOLD}Step 2:${RESET} Initialize RPIKit
|
|
93
|
+
${CYAN}/rpi:init${RESET}
|
|
94
|
+
|
|
95
|
+
${BOLD}Step 3:${RESET} Create your first feature
|
|
96
|
+
${CYAN}/rpi:new my-feature${RESET}
|
|
97
|
+
|
|
98
|
+
${BOLD}Step 4:${RESET} Follow the pipeline
|
|
99
|
+
${CYAN}/rpi:research my-feature${RESET}
|
|
100
|
+
${CYAN}/rpi:plan my-feature${RESET}
|
|
101
|
+
${CYAN}/rpi:implement my-feature${RESET}
|
|
102
|
+
|
|
103
|
+
${DIM}Use /rpi:status anytime to see where you are.${RESET}
|
|
104
|
+
|
|
105
|
+
${GREEN}Happy building!${RESET}`,
|
|
106
|
+
},
|
|
107
|
+
];
|
|
108
|
+
|
|
109
|
+
function run() {
|
|
110
|
+
const rl = readline.createInterface({
|
|
111
|
+
input: process.stdin,
|
|
112
|
+
output: process.stdout,
|
|
113
|
+
});
|
|
114
|
+
|
|
115
|
+
let current = 0;
|
|
116
|
+
|
|
117
|
+
function show(index) {
|
|
118
|
+
const step = steps[index];
|
|
119
|
+
const progress = `${DIM}[${index + 1}/${steps.length}]${RESET}`;
|
|
120
|
+
|
|
121
|
+
console.clear();
|
|
122
|
+
console.log();
|
|
123
|
+
console.log(` ${progress} ${BOLD}${step.title}${RESET}`);
|
|
124
|
+
console.log(` ${"─".repeat(50)}`);
|
|
125
|
+
console.log(step.body);
|
|
126
|
+
console.log();
|
|
127
|
+
|
|
128
|
+
if (index < steps.length - 1) {
|
|
129
|
+
rl.question(` ${DIM}Press Enter to continue (q to quit)${RESET} `, (answer) => {
|
|
130
|
+
if (answer.toLowerCase() === "q") {
|
|
131
|
+
rl.close();
|
|
132
|
+
return;
|
|
133
|
+
}
|
|
134
|
+
current++;
|
|
135
|
+
show(current);
|
|
136
|
+
});
|
|
137
|
+
} else {
|
|
138
|
+
rl.close();
|
|
139
|
+
}
|
|
140
|
+
}
|
|
141
|
+
|
|
142
|
+
show(0);
|
|
143
|
+
}
|
|
144
|
+
|
|
145
|
+
module.exports = { run };
|
package/codex.md
ADDED
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# RPI Workflow Rules
|
|
2
|
+
|
|
3
|
+
You follow the RPI (Research → Plan → Implement) workflow for feature development.
|
|
4
|
+
|
|
5
|
+
## Core Principles
|
|
6
|
+
|
|
7
|
+
1. **Never implement without research.** Every feature starts with a REQUEST.md and goes through a GO/NO-GO research gate.
|
|
8
|
+
2. **Never code without a plan.** The plan phase produces structured artifacts (PLAN.md, eng.md, and optionally pm.md/ux.md) before any code is written.
|
|
9
|
+
3. **Track every task.** Implementation uses task-level tracking with commits per task and phase checkpoints.
|
|
10
|
+
4. **Simplify before review.** After implementation, run code simplification (reuse, quality, efficiency) before code review.
|
|
11
|
+
5. **Review against the plan.** Code review checks implementation against plan requirements, not just code quality.
|
|
12
|
+
6. **Test before you code (when TDD enabled).** Write one failing test, verify it fails, write minimal code to pass, verify it passes, refactor. No implementation without a failing test first.
|
|
13
|
+
|
|
14
|
+
## File Conventions
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
{folder}/{feature-slug}/
|
|
18
|
+
├── REQUEST.md # Feature description (structured sections)
|
|
19
|
+
├── research/
|
|
20
|
+
│ └── RESEARCH.md # GO/NO-GO analysis with agent perspectives
|
|
21
|
+
├── plan/
|
|
22
|
+
│ ├── PLAN.md # Task checklist with effort, deps, files
|
|
23
|
+
│ ├── pm.md # (adaptive) User stories + acceptance criteria
|
|
24
|
+
│ ├── ux.md # (adaptive) User flows + interaction patterns
|
|
25
|
+
│ └── eng.md # Technical architecture + dependencies
|
|
26
|
+
└── implement/
|
|
27
|
+
└── IMPLEMENT.md # Full audit trail: tasks, commits, deviations
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Workflow Commands
|
|
31
|
+
|
|
32
|
+
- `/rpi:init` — Set up RPI config for this project
|
|
33
|
+
- `/rpi:new` — Interactive interview to create a feature REQUEST.md
|
|
34
|
+
- `/rpi:research <feature>` — Research phase with GO/NO-GO verdict
|
|
35
|
+
- `/rpi:plan <feature>` — Generate plan artifacts from research
|
|
36
|
+
- `/rpi:implement <feature>` — Execute plan with task tracking
|
|
37
|
+
- `/rpi:simplify <feature>` — Code simplification (reuse, quality, efficiency)
|
|
38
|
+
- `/rpi:test <feature>` — Run TDD cycles (RED → GREEN → REFACTOR) per task
|
|
39
|
+
- `/rpi:status` — Show all features and their current phase
|
|
40
|
+
- `/rpi:review <feature>` — Code review against plan
|
|
41
|
+
|
|
42
|
+
## Research Tiers
|
|
43
|
+
|
|
44
|
+
- `--quick` — Feasibility check only (2 agents: requirements + codebase)
|
|
45
|
+
- `--standard` — Scope + technical approach (4 agents: + PM + engineer)
|
|
46
|
+
- `--deep` — Full analysis with strategic assessment (5-6 agents: + CTO + UX if UI)
|
|
47
|
+
|
|
48
|
+
## Agent Team
|
|
49
|
+
|
|
50
|
+
| Role | Perspective |
|
|
51
|
+
|------|-------------|
|
|
52
|
+
| Requirement Parser | Extracts structured requirements, lists unknowns |
|
|
53
|
+
| Product Manager | Scope, user stories, effort, acceptance criteria |
|
|
54
|
+
| UX Designer | User flows, interaction patterns, existing components |
|
|
55
|
+
| Senior Engineer | Technical approach, architecture, dependencies |
|
|
56
|
+
| CTO Advisor | Risk, feasibility, strategic alignment, alternatives |
|
|
57
|
+
| Doc Synthesizer | Merges research into executive summary + verdict |
|
|
58
|
+
| Plan Executor | Implements tasks surgically, one at a time |
|
|
59
|
+
| Code Simplifier | Reuse, quality, efficiency checks with fixes |
|
|
60
|
+
| Code Reviewer | Reviews against plan requirements |
|
|
61
|
+
| Codebase Explorer | Scans existing code for patterns and context |
|
|
62
|
+
| Test Engineer | Writes failing tests before implementation (TDD) |
|
|
63
|
+
|
|
64
|
+
## GO/NO-GO Verdicts
|
|
65
|
+
|
|
66
|
+
- **GO** — Feature is feasible, proceed to planning
|
|
67
|
+
- **GO with concerns** — Feasible but has risks that need mitigation
|
|
68
|
+
- **NO-GO** — Not feasible as described; alternatives suggested
|
|
69
|
+
- Override a NO-GO verdict: `/rpi:plan {feature-slug} --force`
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rpi:add-todo
|
|
3
|
+
description: Add a quick todo so you don't forget what to implement next.
|
|
4
|
+
argument-hint: "[todo title]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Write
|
|
8
|
+
- Bash
|
|
9
|
+
- Glob
|
|
10
|
+
- AskUserQuestion
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
<objective>
|
|
14
|
+
Create a todo file in `{folder}/todos/` to capture an implementation idea before it's forgotten.
|
|
15
|
+
</objective>
|
|
16
|
+
|
|
17
|
+
<process>
|
|
18
|
+
|
|
19
|
+
## 1. Load config
|
|
20
|
+
|
|
21
|
+
Read `.rpi.yaml` for folder path. Default to `rpi/` if not found.
|
|
22
|
+
|
|
23
|
+
## 2. Ensure todos folder exists
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
mkdir -p {folder}/todos
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## 3. Determine todo title
|
|
30
|
+
|
|
31
|
+
If `$ARGUMENTS` contains a title, use it. Otherwise ask:
|
|
32
|
+
"What do you want to remember to implement?"
|
|
33
|
+
|
|
34
|
+
Convert the title to a kebab-case slug for the filename.
|
|
35
|
+
|
|
36
|
+
## 4. Check for duplicates
|
|
37
|
+
|
|
38
|
+
Use Glob to check if `{folder}/todos/{slug}.md` already exists. If yes, warn the user and ask if they want to update the existing one or pick a different name.
|
|
39
|
+
|
|
40
|
+
## 5. Quick interview
|
|
41
|
+
|
|
42
|
+
Ask 1-2 focused questions using AskUserQuestion:
|
|
43
|
+
|
|
44
|
+
- "Brief description — what should this do?" (skip if the title is already descriptive enough)
|
|
45
|
+
- "Priority?" — Options: `high`, `medium` (default), `low`
|
|
46
|
+
|
|
47
|
+
Keep it fast. The point is to capture the idea before it's lost, not to write a full spec.
|
|
48
|
+
|
|
49
|
+
## 6. Create the todo file
|
|
50
|
+
|
|
51
|
+
Write `{folder}/todos/{slug}.md`:
|
|
52
|
+
|
|
53
|
+
```markdown
|
|
54
|
+
# {Todo Title}
|
|
55
|
+
|
|
56
|
+
## What
|
|
57
|
+
{Brief description of what to implement}
|
|
58
|
+
|
|
59
|
+
## Priority
|
|
60
|
+
{high | medium | low}
|
|
61
|
+
|
|
62
|
+
## Notes
|
|
63
|
+
- {Any extra context the user mentioned, or leave empty}
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
Added: {YYYY-MM-DD}
|
|
67
|
+
Status: pending
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
## 7. Confirm
|
|
71
|
+
|
|
72
|
+
Output:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
Todo added: {folder}/todos/{slug}.md
|
|
76
|
+
Priority: {priority}
|
|
77
|
+
|
|
78
|
+
Quick actions:
|
|
79
|
+
/rpi:new {slug} Promote to a full RPI feature
|
|
80
|
+
/rpi:todos List all pending todos
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
</process>
|
|
@@ -272,4 +272,45 @@ Feature {feature-slug} implementation complete but review found issues:
|
|
|
272
272
|
Fix and re-run: /rpi:review {feature-slug}
|
|
273
273
|
```
|
|
274
274
|
|
|
275
|
+
## 12. Handle isolation cleanup
|
|
276
|
+
|
|
277
|
+
Read `isolation` from `.rpi.yaml`.
|
|
278
|
+
|
|
279
|
+
**If `isolation: none`** — do nothing.
|
|
280
|
+
|
|
281
|
+
**If `isolation: branch`:**
|
|
282
|
+
Ask the user:
|
|
283
|
+
```
|
|
284
|
+
Feature branch: feature/{feature-slug}
|
|
285
|
+
Want to merge into {main-branch} now? (yes/no)
|
|
286
|
+
```
|
|
287
|
+
If yes:
|
|
288
|
+
```bash
|
|
289
|
+
git checkout {main-branch}
|
|
290
|
+
git merge feature/{feature-slug}
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
**If `isolation: worktree`:**
|
|
294
|
+
Ask the user:
|
|
295
|
+
```
|
|
296
|
+
Worktree: .worktrees/{feature-slug}
|
|
297
|
+
Branch: feature/{feature-slug}
|
|
298
|
+
Want to merge into {main-branch} and remove the worktree? (yes/no)
|
|
299
|
+
```
|
|
300
|
+
If yes:
|
|
301
|
+
```bash
|
|
302
|
+
cd {project-root}
|
|
303
|
+
git checkout {main-branch}
|
|
304
|
+
git merge feature/{feature-slug}
|
|
305
|
+
git worktree remove .worktrees/{feature-slug}
|
|
306
|
+
```
|
|
307
|
+
If no:
|
|
308
|
+
```
|
|
309
|
+
Worktree preserved at .worktrees/{feature-slug}
|
|
310
|
+
To merge later:
|
|
311
|
+
git checkout {main-branch} && git merge feature/{feature-slug}
|
|
312
|
+
To remove:
|
|
313
|
+
git worktree remove .worktrees/{feature-slug}
|
|
314
|
+
```
|
|
315
|
+
|
|
275
316
|
</process>
|
package/commands/rpi/init.md
CHANGED
|
@@ -34,7 +34,7 @@ Use AskUserQuestion to gather preferences. Ask up to 4 questions at a time:
|
|
|
34
34
|
|
|
35
35
|
**Batch 3:**
|
|
36
36
|
- "Task count threshold for parallel execution?" — Options: 8 (Recommended), 5, 12, always sequential
|
|
37
|
-
- "
|
|
37
|
+
- "How do you want to isolate features?" — Options: `none` (Recommended — work on current branch), `branch` (create a git branch per feature), `worktree` (create a git worktree + branch in `.worktrees/`)
|
|
38
38
|
|
|
39
39
|
**Batch 4 (TDD):**
|
|
40
40
|
- "Enable Test-Driven Development during implementation?" — Options: No (default), Yes
|
|
@@ -55,7 +55,7 @@ commit_style: {conventional|descriptive}
|
|
|
55
55
|
parallel_threshold: {number}
|
|
56
56
|
skip_artifacts: []
|
|
57
57
|
review_after_implement: true
|
|
58
|
-
|
|
58
|
+
isolation: {none|branch|worktree}
|
|
59
59
|
tdd: {true|false}
|
|
60
60
|
test_runner: {auto|command}
|
|
61
61
|
```
|
package/commands/rpi/new.md
CHANGED
|
@@ -48,10 +48,54 @@ Start with core questions, then ask follow-ups based on answers.
|
|
|
48
48
|
|
|
49
49
|
Use AskUserQuestion for structured questions. Keep it conversational — 2-3 questions per batch, max 3 batches. Stop when you have enough to write a clear REQUEST.md.
|
|
50
50
|
|
|
51
|
-
## 5.
|
|
51
|
+
## 5. Set up isolation
|
|
52
52
|
|
|
53
|
-
|
|
53
|
+
Read `isolation` from `.rpi.yaml` (default: `none`).
|
|
54
54
|
|
|
55
|
+
**If `isolation: none`** — do nothing, continue on current branch.
|
|
56
|
+
|
|
57
|
+
**If `isolation: branch`:**
|
|
58
|
+
```bash
|
|
59
|
+
git checkout -b feature/{feature-slug}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
**If `isolation: worktree`:**
|
|
63
|
+
1. Verify `.worktrees/` is in `.gitignore`:
|
|
64
|
+
```bash
|
|
65
|
+
git check-ignore -q .worktrees 2>/dev/null
|
|
66
|
+
```
|
|
67
|
+
If NOT ignored, add `.worktrees/` to `.gitignore` and commit:
|
|
68
|
+
```bash
|
|
69
|
+
echo ".worktrees/" >> .gitignore
|
|
70
|
+
git add .gitignore && git commit -m "chore: add .worktrees/ to .gitignore"
|
|
71
|
+
```
|
|
72
|
+
2. Create the worktree:
|
|
73
|
+
```bash
|
|
74
|
+
git worktree add .worktrees/{feature-slug} -b feature/{feature-slug}
|
|
75
|
+
```
|
|
76
|
+
3. Run project setup in the worktree (auto-detect from project files: `npm install`, `pip install`, etc.)
|
|
77
|
+
4. Inform the user:
|
|
78
|
+
```
|
|
79
|
+
Worktree created at .worktrees/{feature-slug}
|
|
80
|
+
Branch: feature/{feature-slug}
|
|
81
|
+
|
|
82
|
+
To work in the worktree, open a new terminal:
|
|
83
|
+
cd .worktrees/{feature-slug}
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## 6. Generate REQUEST.md
|
|
87
|
+
|
|
88
|
+
Create the feature folder and write REQUEST.md.
|
|
89
|
+
|
|
90
|
+
**If `isolation: worktree`**, the feature folder is created inside the worktree:
|
|
91
|
+
```bash
|
|
92
|
+
cd .worktrees/{feature-slug}
|
|
93
|
+
mkdir -p {folder}/{feature-slug}/research
|
|
94
|
+
mkdir -p {folder}/{feature-slug}/plan
|
|
95
|
+
mkdir -p {folder}/{feature-slug}/implement
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**Otherwise:**
|
|
55
99
|
```bash
|
|
56
100
|
mkdir -p {folder}/{feature-slug}/research
|
|
57
101
|
mkdir -p {folder}/{feature-slug}/plan
|
|
@@ -84,7 +128,7 @@ Write `{folder}/{feature-slug}/REQUEST.md` with this structure:
|
|
|
84
128
|
{S | M | L | XL} — {brief justification}
|
|
85
129
|
```
|
|
86
130
|
|
|
87
|
-
##
|
|
131
|
+
## 7. Next step
|
|
88
132
|
|
|
89
133
|
Output:
|
|
90
134
|
```
|
|
@@ -0,0 +1,241 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rpi:onboarding
|
|
3
|
+
description: Interactive guided tour of the RPI workflow. Walks through each phase with a real demo feature, explaining what happens at each step.
|
|
4
|
+
argument-hint: "[--demo]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Write
|
|
8
|
+
- Bash
|
|
9
|
+
- Glob
|
|
10
|
+
- AskUserQuestion
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
<objective>
|
|
14
|
+
Guide a new user through the RPIKit workflow with clear explanations of each phase. Optionally create a demo feature to show the pipeline in action.
|
|
15
|
+
</objective>
|
|
16
|
+
|
|
17
|
+
<process>
|
|
18
|
+
|
|
19
|
+
## 1. Welcome
|
|
20
|
+
|
|
21
|
+
Output:
|
|
22
|
+
```
|
|
23
|
+
Welcome to RPIKit — Research, Plan, Implement.
|
|
24
|
+
|
|
25
|
+
RPIKit is a structured workflow that guides you through 3 phases before writing
|
|
26
|
+
any code. Each phase produces artifacts that feed the next, with validation
|
|
27
|
+
gates that prevent premature implementation.
|
|
28
|
+
|
|
29
|
+
Let me walk you through the pipeline.
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## 2. Explain the pipeline
|
|
33
|
+
|
|
34
|
+
Present the full pipeline with brief descriptions:
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
The RPIKit Pipeline
|
|
38
|
+
───────────────────
|
|
39
|
+
|
|
40
|
+
/rpi:init One-time project setup (.rpi.yaml)
|
|
41
|
+
|
|
42
|
+
/rpi:new Describe your feature → REQUEST.md
|
|
43
|
+
│ You answer a few questions about what you want to build.
|
|
44
|
+
│ RPIKit captures requirements in a structured format.
|
|
45
|
+
▼
|
|
46
|
+
/rpi:research Analyze feasibility → RESEARCH.md
|
|
47
|
+
│ 2-6 agents run in parallel: parsing requirements,
|
|
48
|
+
│ exploring your codebase, assessing scope and risk.
|
|
49
|
+
│ Produces a GO / NO-GO verdict.
|
|
50
|
+
▼
|
|
51
|
+
/rpi:plan Generate specs + tasks → PLAN.md
|
|
52
|
+
│ Creates technical spec (eng.md), product requirements
|
|
53
|
+
│ (pm.md), UX design (ux.md), and a task checklist.
|
|
54
|
+
│ Adapts which artifacts to create based on feature type.
|
|
55
|
+
▼
|
|
56
|
+
/rpi:implement Execute tasks → IMPLEMENT.md
|
|
57
|
+
│ Builds the feature task-by-task with per-task commits.
|
|
58
|
+
│ Supports TDD (Red-Green-Refactor) and parallel execution.
|
|
59
|
+
▼
|
|
60
|
+
/rpi:simplify Code quality → auto-fix
|
|
61
|
+
│ 3 agents check: code reuse, quality patterns, efficiency.
|
|
62
|
+
│ Fixes issues directly.
|
|
63
|
+
▼
|
|
64
|
+
/rpi:review Verify against plan → PASS / FAIL
|
|
65
|
+
│ Reviews completeness, correctness, deviations, test
|
|
66
|
+
│ coverage. Every finding cites a plan requirement.
|
|
67
|
+
▼
|
|
68
|
+
/rpi:docs Document the code → inline docs + changelog
|
|
69
|
+
Adds JSDoc/docstrings, API docs, README and changelog
|
|
70
|
+
updates. Only runs after review PASS.
|
|
71
|
+
|
|
72
|
+
/rpi:status Dashboard — see all features and their current phase.
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## 3. Explain the agents
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
RPIKit simulates a product team with 12 specialized agents:
|
|
79
|
+
|
|
80
|
+
Research agents (run in parallel):
|
|
81
|
+
┌─────────────────────┬──────────────────────────────────────┐
|
|
82
|
+
│ Requirement Parser │ Extracts testable requirements │
|
|
83
|
+
│ Codebase Explorer │ Scans your code for patterns │
|
|
84
|
+
│ Product Manager │ Scope, user stories, effort │
|
|
85
|
+
│ Senior Engineer │ Architecture, dependencies │
|
|
86
|
+
│ CTO Advisor │ Risk, strategy (deep tier only) │
|
|
87
|
+
│ UX Designer │ User flows, interactions (if UI) │
|
|
88
|
+
│ Doc Synthesizer │ Merges all outputs into RESEARCH.md │
|
|
89
|
+
└─────────────────────┴──────────────────────────────────────┘
|
|
90
|
+
|
|
91
|
+
Execution agents:
|
|
92
|
+
┌─────────────────────┬──────────────────────────────────────┐
|
|
93
|
+
│ Plan Executor │ Implements one task at a time │
|
|
94
|
+
│ Test Engineer │ Writes failing tests (TDD) │
|
|
95
|
+
│ Code Simplifier │ Reuse, quality, efficiency checks │
|
|
96
|
+
│ Code Reviewer │ Reviews against plan requirements │
|
|
97
|
+
│ Doc Writer │ Generates code documentation │
|
|
98
|
+
└─────────────────────┴──────────────────────────────────────┘
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
## 4. Explain research tiers
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
Research Tiers — control depth and cost:
|
|
105
|
+
|
|
106
|
+
--quick 2 agents "Can we do this?"
|
|
107
|
+
Requirements + codebase scan.
|
|
108
|
+
Use for small features or feasibility checks.
|
|
109
|
+
|
|
110
|
+
--standard 4 agents "How should we do this?" (default)
|
|
111
|
+
Adds product scope and technical approach.
|
|
112
|
+
Use for most features.
|
|
113
|
+
|
|
114
|
+
--deep 6 agents "Should we do this?"
|
|
115
|
+
Adds strategic risk and UX analysis.
|
|
116
|
+
Use for large features or risky changes.
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## 5. Show folder structure
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
Feature Folder Structure:
|
|
123
|
+
|
|
124
|
+
rpi/
|
|
125
|
+
└── your-feature/
|
|
126
|
+
├── REQUEST.md ← What you want to build
|
|
127
|
+
├── research/
|
|
128
|
+
│ └── RESEARCH.md ← GO/NO-GO analysis
|
|
129
|
+
├── plan/
|
|
130
|
+
│ ├── PLAN.md ← Task checklist by phases
|
|
131
|
+
│ ├── eng.md ← Technical specification
|
|
132
|
+
│ ├── pm.md ← Product requirements (adaptive)
|
|
133
|
+
│ └── ux.md ← UX design (adaptive)
|
|
134
|
+
└── implement/
|
|
135
|
+
├── IMPLEMENT.md ← Execution audit trail
|
|
136
|
+
└── DOCS.md ← Documentation summary
|
|
137
|
+
|
|
138
|
+
Each file is a gate — you can't plan without research, can't implement
|
|
139
|
+
without a plan, can't document without a passing review.
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
## 6. Ask about demo
|
|
143
|
+
|
|
144
|
+
Use AskUserQuestion:
|
|
145
|
+
"Want me to create a demo feature so you can see the pipeline in action? I'll create a small example feature and walk you through each step."
|
|
146
|
+
|
|
147
|
+
Options:
|
|
148
|
+
- "Yes, show me a demo" → proceed to step 7
|
|
149
|
+
- "No, I'll start on my own" → skip to step 8
|
|
150
|
+
|
|
151
|
+
## 7. Demo walkthrough (if user wants demo)
|
|
152
|
+
|
|
153
|
+
Create a minimal demo feature to show what each artifact looks like:
|
|
154
|
+
|
|
155
|
+
### 7.1 Create demo config
|
|
156
|
+
|
|
157
|
+
If `.rpi.yaml` doesn't exist, create a minimal one:
|
|
158
|
+
```yaml
|
|
159
|
+
folder: rpi
|
|
160
|
+
tier: quick
|
|
161
|
+
auto_simplify: true
|
|
162
|
+
commit_style: conventional
|
|
163
|
+
parallel_threshold: 8
|
|
164
|
+
review_after_implement: true
|
|
165
|
+
isolation: none
|
|
166
|
+
tdd: false
|
|
167
|
+
test_runner: auto
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
### 7.2 Create demo REQUEST.md
|
|
171
|
+
|
|
172
|
+
```bash
|
|
173
|
+
mkdir -p rpi/demo-greeting/research
|
|
174
|
+
mkdir -p rpi/demo-greeting/plan
|
|
175
|
+
mkdir -p rpi/demo-greeting/implement
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
Write `rpi/demo-greeting/REQUEST.md`:
|
|
179
|
+
```markdown
|
|
180
|
+
# Greeting Message
|
|
181
|
+
|
|
182
|
+
## Summary
|
|
183
|
+
Add a simple greeting function that returns a personalized welcome message.
|
|
184
|
+
|
|
185
|
+
## Problem
|
|
186
|
+
The application has no way to greet users by name. This is needed for the onboarding flow.
|
|
187
|
+
|
|
188
|
+
## Target Users
|
|
189
|
+
All new users during their first session.
|
|
190
|
+
|
|
191
|
+
## Constraints
|
|
192
|
+
- Must be a pure function (no side effects)
|
|
193
|
+
- Must handle missing or empty names gracefully
|
|
194
|
+
|
|
195
|
+
## References
|
|
196
|
+
- None
|
|
197
|
+
|
|
198
|
+
## Complexity Estimate
|
|
199
|
+
S — Single function with basic input validation
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
### 7.3 Explain what just happened
|
|
203
|
+
|
|
204
|
+
Output:
|
|
205
|
+
```
|
|
206
|
+
I created a demo feature: rpi/demo-greeting/
|
|
207
|
+
|
|
208
|
+
This is what /rpi:new does — it interviews you about your feature and creates
|
|
209
|
+
REQUEST.md with structured requirements.
|
|
210
|
+
|
|
211
|
+
In a real workflow, the next steps would be:
|
|
212
|
+
/rpi:research demo-greeting → agents analyze feasibility
|
|
213
|
+
/rpi:plan demo-greeting → generate specs and task checklist
|
|
214
|
+
/rpi:implement demo-greeting → build it task by task
|
|
215
|
+
|
|
216
|
+
You can run these commands now to see the full pipeline, or delete the demo:
|
|
217
|
+
rm -rf rpi/demo-greeting
|
|
218
|
+
```
|
|
219
|
+
|
|
220
|
+
## 8. Next steps
|
|
221
|
+
|
|
222
|
+
Output:
|
|
223
|
+
```
|
|
224
|
+
You're ready to go! Here's your first workflow:
|
|
225
|
+
|
|
226
|
+
1. /rpi:init Set up your preferences
|
|
227
|
+
2. /rpi:new my-feature Describe what you want to build
|
|
228
|
+
3. /rpi:research my-feature Let the agents analyze it
|
|
229
|
+
4. /rpi:plan my-feature Generate the implementation plan
|
|
230
|
+
5. /rpi:implement my-feature Build it
|
|
231
|
+
|
|
232
|
+
Use /rpi:status anytime to see where your features stand.
|
|
233
|
+
|
|
234
|
+
Tips:
|
|
235
|
+
- Start with --quick tier for small features
|
|
236
|
+
- Use --deep tier when adding new architecture or risky dependencies
|
|
237
|
+
- Enable tdd: true in .rpi.yaml if you want test-first development
|
|
238
|
+
- Run /rpi:simplify anytime to check code quality on recent changes
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
</process>
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "rpi-kit",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.1.0",
|
|
4
4
|
"description": "Research → Plan → Implement. A systematic feature development workflow for Claude Code.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Daniel Mendes",
|
|
@@ -22,14 +22,18 @@
|
|
|
22
22
|
"rpi-kit": "./bin/cli.js"
|
|
23
23
|
},
|
|
24
24
|
"files": [
|
|
25
|
+
".claude-plugin/",
|
|
25
26
|
"bin/",
|
|
26
27
|
"commands/",
|
|
27
28
|
"agents/",
|
|
29
|
+
"skills/",
|
|
28
30
|
"AGENTS.md",
|
|
31
|
+
"codex.md",
|
|
29
32
|
"README.md",
|
|
30
33
|
"LICENSE"
|
|
31
34
|
],
|
|
32
35
|
"scripts": {
|
|
36
|
+
"test": "node --test test/cli.test.js test/commands.test.js",
|
|
33
37
|
"postinstall": "node bin/cli.js install --silent"
|
|
34
38
|
}
|
|
35
39
|
}
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rpi-agents
|
|
3
|
+
description: This skill should be used when the user asks about RPI agent behavior, rules, or roles, asks "what agents are involved", "how does the code reviewer work", "what are the agent rules", "customize agent behavior", or mentions agent names like requirement-parser, product-manager, ux-designer, senior-engineer, cto-advisor, doc-synthesizer, plan-executor, code-simplifier, code-reviewer, explore-codebase, or test-engineer.
|
|
4
|
+
version: 1.0.1
|
|
5
|
+
license: MIT
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# RPI Agent Guidelines
|
|
9
|
+
|
|
10
|
+
Behavioral constraints for RPI agents. Every agent follows the general rules below PLUS their role-specific rules.
|
|
11
|
+
|
|
12
|
+
## General Rules (All Agents)
|
|
13
|
+
|
|
14
|
+
1. **Cite evidence.** Every claim must reference a specific file, dependency, or codebase pattern. No unsupported statements.
|
|
15
|
+
2. **Name unknowns.** If you're uncertain, say what you don't know. Never fill gaps with assumptions.
|
|
16
|
+
3. **Be concrete.** Anti-pattern: "This could improve performance." Instead: "Batching the 3 API calls reduces round-trips from 3 to 1."
|
|
17
|
+
4. **Stay in scope.** Only analyze what's relevant to the feature. Don't audit the entire codebase.
|
|
18
|
+
5. **Structured output.** Use the section format specified for your role. Include your verdict per section.
|
|
19
|
+
|
|
20
|
+
## Output Format (Research Agents)
|
|
21
|
+
|
|
22
|
+
Each research agent outputs markdown sections with verdicts:
|
|
23
|
+
|
|
24
|
+
```markdown
|
|
25
|
+
## [Section Name]
|
|
26
|
+
Verdict: GO | CONCERN | BLOCK
|
|
27
|
+
|
|
28
|
+
[Findings with evidence]
|
|
29
|
+
|
|
30
|
+
### [Sub-section if needed]
|
|
31
|
+
[Details]
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
End with: `Estimated Complexity: S | M | L | XL`
|
|
35
|
+
|
|
36
|
+
## Agent Roles
|
|
37
|
+
|
|
38
|
+
The RPI workflow uses 10 specialized agents. Each has detailed behavioral rules, anti-patterns, and output formats defined in its own file under `agents/`:
|
|
39
|
+
|
|
40
|
+
| Agent | Role | Phase |
|
|
41
|
+
|-------|------|-------|
|
|
42
|
+
| requirement-parser | Extract structured, testable requirements | Research |
|
|
43
|
+
| product-manager | Scope, user stories, effort, acceptance criteria | Research, Plan |
|
|
44
|
+
| ux-designer | User flows, interaction patterns, UI decisions | Research (deep), Plan |
|
|
45
|
+
| senior-engineer | Technical approach, architecture, dependencies | Research, Plan |
|
|
46
|
+
| cto-advisor | Risk, feasibility, strategic alignment | Research (deep) |
|
|
47
|
+
| doc-synthesizer | Merge research outputs into RESEARCH.md | Research |
|
|
48
|
+
| explore-codebase | Scan codebase for patterns and context | Research |
|
|
49
|
+
| test-engineer | Write failing tests before implementation (TDD) | Implement (TDD), Test |
|
|
50
|
+
| plan-executor | Implement tasks from PLAN.md surgically | Implement |
|
|
51
|
+
| code-simplifier | Check reuse, quality, efficiency and fix | Implement |
|
|
52
|
+
| code-reviewer | Review implementation against plan | Implement, Review |
|
|
53
|
+
|
|
54
|
+
For full role-specific rules, anti-patterns, and output formats, see the individual agent definitions in `agents/*.md`.
|
|
55
|
+
|
|
56
|
+
## Related
|
|
57
|
+
|
|
58
|
+
For the workflow process (phases, commands, configuration), see the **rpi-workflow** skill.
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rpi-workflow
|
|
3
|
+
description: This skill should be used when the user wants to develop a feature systematically, asks "how do I start a new feature", "walk me through the workflow", "help me build this step by step", says "research plan implement", mentions TDD or test-driven development, or mentions any RPI command (/rpi:init, /rpi:new, /rpi:research, /rpi:plan, /rpi:implement, /rpi:test, /rpi:simplify, /rpi:status, /rpi:review).
|
|
4
|
+
version: 0.2.0
|
|
5
|
+
license: MIT
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# RPI Workflow
|
|
9
|
+
|
|
10
|
+
RPI (Research → Plan → Implement) is a systematic feature development workflow with validation gates at each phase.
|
|
11
|
+
|
|
12
|
+
## Workflow Phases
|
|
13
|
+
|
|
14
|
+
### Phase 0: Init
|
|
15
|
+
Run `/rpi:init` once per project to configure:
|
|
16
|
+
- Feature folder location (default: `rpi/`)
|
|
17
|
+
- Default research tier
|
|
18
|
+
- Parallel threshold, commit style, and other preferences
|
|
19
|
+
- Creates `.rpi.yaml` at project root
|
|
20
|
+
|
|
21
|
+
### Phase 1: New Feature
|
|
22
|
+
Run `/rpi:new` to start. Adaptive interview:
|
|
23
|
+
- Start with core questions: what feature, what problem it solves
|
|
24
|
+
- Ask follow-ups based on answers (who uses it, complexity, constraints, references)
|
|
25
|
+
- Set up isolation based on `isolation` config:
|
|
26
|
+
- `none`: work on current branch
|
|
27
|
+
- `branch`: `git checkout -b feature/{slug}`
|
|
28
|
+
- `worktree`: create `.worktrees/{slug}` with `git worktree add`
|
|
29
|
+
- Generate `{folder}/{feature-slug}/REQUEST.md` with structured sections
|
|
30
|
+
|
|
31
|
+
REQUEST.md sections: Summary, Problem, Target Users, Constraints, References, Complexity Estimate.
|
|
32
|
+
|
|
33
|
+
### Phase 2: Research
|
|
34
|
+
Run `/rpi:research {feature-slug}` with optional tier flag.
|
|
35
|
+
|
|
36
|
+
Research tiers control agent composition:
|
|
37
|
+
- `--quick`: requirement-parser + explore-codebase (feasibility only)
|
|
38
|
+
- `--standard` (default): + product-manager + senior-engineer (scope + approach)
|
|
39
|
+
- `--deep`: + cto-advisor + ux-designer if UI (full analysis + alternatives)
|
|
40
|
+
|
|
41
|
+
All selected agents run in **parallel fan-out**. Doc-synthesizer merges outputs into RESEARCH.md.
|
|
42
|
+
|
|
43
|
+
RESEARCH.md format:
|
|
44
|
+
1. Executive Summary (5 lines: verdict, complexity, risk, recommendation, key finding)
|
|
45
|
+
2. Requirements Analysis
|
|
46
|
+
3. Product Scope
|
|
47
|
+
4. Codebase Context
|
|
48
|
+
5. Technical Analysis
|
|
49
|
+
6. Strategic Assessment (deep tier only)
|
|
50
|
+
7. Alternatives (mandatory if NO-GO)
|
|
51
|
+
|
|
52
|
+
Verdicts: **GO**, **GO with concerns**, **NO-GO**
|
|
53
|
+
- NO-GO includes alternative approaches and scope reduction suggestions
|
|
54
|
+
- Override with `--force` flag
|
|
55
|
+
|
|
56
|
+
### Phase 3: Plan
|
|
57
|
+
Run `/rpi:plan {feature-slug}`.
|
|
58
|
+
|
|
59
|
+
Adaptive artifact generation:
|
|
60
|
+
- Always: PLAN.md (task checklist) + eng.md (technical spec)
|
|
61
|
+
- Adaptive: pm.md (user stories) and ux.md (user flows) — generated based on feature type
|
|
62
|
+
- After research, asks user to confirm which artifacts to generate
|
|
63
|
+
|
|
64
|
+
PLAN.md task format:
|
|
65
|
+
```markdown
|
|
66
|
+
## Phase 1: Phase Name
|
|
67
|
+
|
|
68
|
+
- [ ] **1.1** Task description
|
|
69
|
+
Effort: S | Deps: none
|
|
70
|
+
Files: src/path/to/file.ts
|
|
71
|
+
Test: returns 200 for valid request with auth token
|
|
72
|
+
|
|
73
|
+
- [ ] **1.2** Another task
|
|
74
|
+
Effort: M | Deps: 1.1
|
|
75
|
+
Files: src/other/file.ts
|
|
76
|
+
Test: rejects duplicate entries with 409 conflict
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### Standalone: TDD
|
|
80
|
+
Run `/rpi:test {feature-slug}` to run TDD cycles on individual tasks.
|
|
81
|
+
|
|
82
|
+
- Works independently of `/rpi:implement` — use when you want TDD on specific tasks
|
|
83
|
+
- Strict RED → GREEN → REFACTOR per task, one test at a time
|
|
84
|
+
- Auto-detects test framework and conventions from the project
|
|
85
|
+
- Flags: `--task <id>` for single task, `--all` for all uncompleted tasks
|
|
86
|
+
|
|
87
|
+
### Phase 4: Implement
|
|
88
|
+
Run `/rpi:implement {feature-slug}`.
|
|
89
|
+
|
|
90
|
+
Smart execution mode:
|
|
91
|
+
- < 8 tasks: single plan-executor agent, sequential
|
|
92
|
+
- 8+ tasks: group into waves by dependency, execute in parallel
|
|
93
|
+
- Override: `--sequential` or `--parallel` flags
|
|
94
|
+
|
|
95
|
+
Pipeline per phase:
|
|
96
|
+
1. Execute tasks → commit per task
|
|
97
|
+
- If TDD enabled: RED (write failing test) → VERIFY RED → GREEN (minimal code) → VERIFY GREEN → REFACTOR → commit
|
|
98
|
+
- If TDD disabled: execute task → commit (original behavior)
|
|
99
|
+
2. Simplify (3 parallel sub-agents: reuse, quality, efficiency)
|
|
100
|
+
3. Review (code-reviewer checks against plan + test coverage)
|
|
101
|
+
4. Phase verdict: PASS or FAIL
|
|
102
|
+
|
|
103
|
+
IMPLEMENT.md tracks: task completion with commits, start/end times, files changed, deviations, simplify findings, review verdict.
|
|
104
|
+
|
|
105
|
+
After implementation, isolation cleanup runs based on config:
|
|
106
|
+
- `none`: nothing
|
|
107
|
+
- `branch`: asks to merge into main branch
|
|
108
|
+
- `worktree`: asks to merge + remove the worktree
|
|
109
|
+
|
|
110
|
+
## Configuration (.rpi.yaml)
|
|
111
|
+
|
|
112
|
+
```yaml
|
|
113
|
+
folder: rpi # Feature folder location
|
|
114
|
+
tier: standard # Default research tier
|
|
115
|
+
auto_simplify: true # Run simplify before review
|
|
116
|
+
commit_style: conventional # Commit message format
|
|
117
|
+
parallel_threshold: 8 # Task count for parallel mode
|
|
118
|
+
skip_artifacts: [] # Artifacts to never generate
|
|
119
|
+
review_after_implement: true # Mandatory review gate
|
|
120
|
+
isolation: none # none | branch | worktree
|
|
121
|
+
tdd: false # Enable Test-Driven Development
|
|
122
|
+
test_runner: auto # Test command (auto-detect or explicit)
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Feature Folder Structure
|
|
126
|
+
|
|
127
|
+
```
|
|
128
|
+
{folder}/{feature-slug}/
|
|
129
|
+
├── REQUEST.md
|
|
130
|
+
├── research/
|
|
131
|
+
│ └── RESEARCH.md
|
|
132
|
+
├── plan/
|
|
133
|
+
│ ├── PLAN.md
|
|
134
|
+
│ ├── pm.md (adaptive)
|
|
135
|
+
│ ├── ux.md (adaptive)
|
|
136
|
+
│ └── eng.md
|
|
137
|
+
└── implement/
|
|
138
|
+
└── IMPLEMENT.md
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
## Cross-Session Continuity
|
|
142
|
+
|
|
143
|
+
All state lives in markdown files. When resuming:
|
|
144
|
+
- `/rpi:status` shows all features with current phase and progress
|
|
145
|
+
- `/rpi:implement` reads IMPLEMENT.md and resumes from last completed task
|
|
146
|
+
- Multiple features can be in progress simultaneously
|
|
147
|
+
|
|
148
|
+
## Related
|
|
149
|
+
|
|
150
|
+
For agent behavioral guidelines, see the **rpi-agents** skill or individual agent files in `agents/`.
|