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.
@@ -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 (plugin)
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
- Or clone and install locally:
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
- branch_per_feature: false # Git branch per feature
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
  ```
@@ -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", "add", PLUGIN_DIR], {
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 add " + PLUGIN_DIR);
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>
@@ -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
- - "Create a git branch per feature?" — Options: No (Recommended), Yes
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
- branch_per_feature: {true|false}
58
+ isolation: {none|branch|worktree}
59
59
  tdd: {true|false}
60
60
  test_runner: {auto|command}
61
61
  ```
@@ -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. Generate REQUEST.md
51
+ ## 5. Set up isolation
52
52
 
53
- Create the feature folder and write REQUEST.md:
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
- ## 6. Next step
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.0.0",
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/`.