rpi-kit 1.0.1 → 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/codex.md +69 -0
- package/package.json +4 -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/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`
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "rpi-kit",
|
|
3
|
-
"version": "1.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,10 +22,13 @@
|
|
|
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
|
],
|
|
@@ -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/`.
|