rpi-kit 2.2.2 → 2.5.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 +3 -2
- package/.claude-plugin/plugin.json +1 -1
- package/.gemini/commands/opsx/apply.toml +149 -0
- package/.gemini/commands/opsx/archive.toml +154 -0
- package/.gemini/commands/opsx/bulk-archive.toml +239 -0
- package/.gemini/commands/opsx/continue.toml +111 -0
- package/.gemini/commands/opsx/explore.toml +170 -0
- package/.gemini/commands/opsx/ff.toml +94 -0
- package/.gemini/commands/opsx/new.toml +66 -0
- package/.gemini/commands/opsx/onboard.toml +547 -0
- package/.gemini/commands/opsx/propose.toml +103 -0
- package/.gemini/commands/opsx/sync.toml +131 -0
- package/.gemini/commands/opsx/verify.toml +161 -0
- package/.gemini/commands/rpi/archive.toml +140 -0
- package/.gemini/commands/rpi/docs-gen.toml +210 -0
- package/.gemini/commands/rpi/docs.toml +153 -0
- package/.gemini/commands/rpi/evolve.toml +411 -0
- package/.gemini/commands/rpi/fix.toml +290 -0
- package/.gemini/commands/rpi/implement.toml +272 -0
- package/.gemini/commands/rpi/init.toml +180 -0
- package/.gemini/commands/rpi/learn.toml +105 -0
- package/.gemini/commands/rpi/new.toml +158 -0
- package/.gemini/commands/rpi/onboarding.toml +236 -0
- package/.gemini/commands/rpi/party.toml +204 -0
- package/.gemini/commands/rpi/plan.toml +623 -0
- package/.gemini/commands/rpi/research.toml +265 -0
- package/.gemini/commands/rpi/review.toml +443 -0
- package/.gemini/commands/rpi/rpi.toml +114 -0
- package/.gemini/commands/rpi/simplify.toml +214 -0
- package/.gemini/commands/rpi/status.toml +194 -0
- package/.gemini/commands/rpi/update.toml +107 -0
- package/.gemini/skills/openspec-apply-change/SKILL.md +156 -0
- package/.gemini/skills/openspec-archive-change/SKILL.md +114 -0
- package/.gemini/skills/openspec-bulk-archive-change/SKILL.md +246 -0
- package/.gemini/skills/openspec-continue-change/SKILL.md +118 -0
- package/.gemini/skills/openspec-explore/SKILL.md +288 -0
- package/.gemini/skills/openspec-ff-change/SKILL.md +101 -0
- package/.gemini/skills/openspec-new-change/SKILL.md +74 -0
- package/.gemini/skills/openspec-onboard/SKILL.md +554 -0
- package/.gemini/skills/openspec-propose/SKILL.md +110 -0
- package/.gemini/skills/openspec-sync-specs/SKILL.md +138 -0
- package/.gemini/skills/openspec-verify-change/SKILL.md +168 -0
- package/CHANGELOG.md +15 -0
- package/README.md +6 -6
- package/agents/atlas.md +40 -0
- package/agents/clara.md +40 -0
- package/agents/forge.md +40 -0
- package/agents/hawk.md +40 -0
- package/agents/luna.md +40 -0
- package/agents/mestre.md +46 -0
- package/agents/nexus.md +52 -0
- package/agents/pixel.md +40 -0
- package/agents/quill.md +40 -0
- package/agents/razor.md +40 -0
- package/agents/sage.md +46 -0
- package/agents/scout.md +40 -0
- package/agents/shield.md +40 -0
- package/bin/cli.js +60 -18
- package/commands/rpi/docs.md +29 -1
- package/commands/rpi/fix.md +301 -0
- package/commands/rpi/implement.md +37 -0
- package/commands/rpi/plan.md +66 -1
- package/commands/rpi/research.md +48 -1
- package/commands/rpi/review.md +48 -1
- package/commands/rpi/rpi.md +1 -1
- package/commands/rpi/simplify.md +31 -1
- package/commands/rpi/status.md +69 -0
- package/marketplace.json +3 -2
- package/package.json +2 -1
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
description = "Auto-progress a feature to its next phase. Detects current state and runs the appropriate step."
|
|
2
|
+
|
|
3
|
+
prompt = """
|
|
4
|
+
# /rpi — Auto-Flow
|
|
5
|
+
|
|
6
|
+
Detects the current phase of a feature and runs the next step automatically.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Step 1: Load config and parse arguments
|
|
11
|
+
|
|
12
|
+
1. Read `.rpi.yaml` for config. Apply defaults if missing:
|
|
13
|
+
- `folder`: `rpi/features`
|
|
14
|
+
2. Parse `$ARGUMENTS` to extract:
|
|
15
|
+
- `{slug}` — the feature name (required)
|
|
16
|
+
- `--skip=phase` — skip a specific phase and detect the next one
|
|
17
|
+
- `--from=phase` — override detection, start from this phase
|
|
18
|
+
- `--force` — pass through to the delegated command
|
|
19
|
+
|
|
20
|
+
If `{slug}` is not provided, ask with AskUserQuestion: "Which feature? Provide the slug (e.g. 'oauth', 'dark-mode')."
|
|
21
|
+
|
|
22
|
+
## Step 2: Validate feature exists
|
|
23
|
+
|
|
24
|
+
Check if `rpi/features/{slug}/` exists and contains `REQUEST.md`.
|
|
25
|
+
|
|
26
|
+
If the directory does not exist:
|
|
27
|
+
```
|
|
28
|
+
Feature '{slug}' not found. Run /rpi:new {slug} to start.
|
|
29
|
+
```
|
|
30
|
+
Stop.
|
|
31
|
+
|
|
32
|
+
If the directory exists but `REQUEST.md` is missing:
|
|
33
|
+
```
|
|
34
|
+
Feature '{slug}' has no REQUEST.md. This shouldn't happen. Run /rpi:new {slug} to recreate it.
|
|
35
|
+
```
|
|
36
|
+
Stop.
|
|
37
|
+
|
|
38
|
+
## Step 3: Detect current phase
|
|
39
|
+
|
|
40
|
+
Check which artifacts exist to determine the next phase:
|
|
41
|
+
|
|
42
|
+
1. Has `REQUEST.md`, no `research/RESEARCH.md` AND no `plan/PLAN.md` → next = **research**
|
|
43
|
+
2. Has `research/RESEARCH.md`, no `plan/PLAN.md` → next = **plan**
|
|
44
|
+
3. Has `plan/PLAN.md`, no `implement/IMPLEMENT.md` → next = **implement**
|
|
45
|
+
4. Has `implement/IMPLEMENT.md` but NOT all tasks checked (`- [x]`) → next = **implement** (with `--resume`)
|
|
46
|
+
5. Has `implement/IMPLEMENT.md` with all tasks complete, no "## Simplify" section in IMPLEMENT.md → next = **simplify**
|
|
47
|
+
6. Has simplify done, no "## Review Verdict" section in IMPLEMENT.md → next = **review**
|
|
48
|
+
7. Has "## Review Verdict" with PASS, no `docs/` output generated → next = **docs**
|
|
49
|
+
8. Everything done → feature is complete
|
|
50
|
+
|
|
51
|
+
### Detection details
|
|
52
|
+
|
|
53
|
+
For step 4: Read `implement/IMPLEMENT.md` and check if any `- [ ]` (unchecked tasks) remain. If all tasks are `- [x]`, the implementation is complete.
|
|
54
|
+
|
|
55
|
+
For step 5: Check if IMPLEMENT.md contains a `## Simplify` section. If not, simplify has not been run yet.
|
|
56
|
+
|
|
57
|
+
For step 6: Check if IMPLEMENT.md contains a `## Review Verdict` section. If not, review has not been run yet.
|
|
58
|
+
|
|
59
|
+
For step 7: Check if IMPLEMENT.md contains a `## Review Verdict` section with "PASS". Then check if docs have been generated (look for mention of docs completion in IMPLEMENT.md or a generated docs artifact).
|
|
60
|
+
|
|
61
|
+
## Step 4: Apply --skip flag
|
|
62
|
+
|
|
63
|
+
If `--skip=phase` was provided:
|
|
64
|
+
- If the detected next phase matches the skipped phase, advance to the phase after it using the same detection logic.
|
|
65
|
+
- Valid phase names: `research`, `plan`, `implement`, `simplify`, `review`, `docs`.
|
|
66
|
+
- If the skip target is invalid, inform the user and stop.
|
|
67
|
+
|
|
68
|
+
## Step 5: Apply --from flag
|
|
69
|
+
|
|
70
|
+
If `--from=phase` was provided:
|
|
71
|
+
- Override the detected phase. Set next = the specified phase.
|
|
72
|
+
- Valid phase names: `research`, `plan`, `implement`, `simplify`, `review`, `docs`.
|
|
73
|
+
- If the from target is invalid, inform the user and stop.
|
|
74
|
+
- This is useful for re-running a phase (e.g., after fixing issues).
|
|
75
|
+
|
|
76
|
+
## Step 6: Handle completion
|
|
77
|
+
|
|
78
|
+
If no next phase was detected (everything is done):
|
|
79
|
+
```
|
|
80
|
+
{slug} is complete! All phases done.
|
|
81
|
+
|
|
82
|
+
To archive: /rpi:archive {slug}
|
|
83
|
+
To re-run a phase: /rpi {slug} --from=phase
|
|
84
|
+
```
|
|
85
|
+
Stop.
|
|
86
|
+
|
|
87
|
+
## Step 7: Announce and delegate
|
|
88
|
+
|
|
89
|
+
Output what is about to happen:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
{slug} -> next: {phase}
|
|
93
|
+
Starting {phase} phase...
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Then delegate to the appropriate command:
|
|
97
|
+
|
|
98
|
+
1. Read `commands/rpi/{phase}.md`
|
|
99
|
+
2. Follow its process section exactly, passing through the `{slug}` and any relevant flags (like `--force`, `--resume`)
|
|
100
|
+
|
|
101
|
+
The auto-flow command does NOT duplicate phase logic. It detects the state, announces the next step, and then executes the full process defined in the corresponding command file.
|
|
102
|
+
|
|
103
|
+
### Phase-to-command mapping
|
|
104
|
+
|
|
105
|
+
| Phase | Command file | Key artifacts |
|
|
106
|
+
|------------|-----------------------|----------------------------------|
|
|
107
|
+
| REQUEST | `commands/rpi/new.md` | `REQUEST.md` |
|
|
108
|
+
| RESEARCH | `commands/rpi/research.md` | `research/RESEARCH.md` |
|
|
109
|
+
| PLAN | `commands/rpi/plan.md` | `plan/PLAN.md` |
|
|
110
|
+
| IMPLEMENT | `commands/rpi/implement.md`| `implement/IMPLEMENT.md` |
|
|
111
|
+
| simplify | `commands/rpi/simplify.md` | Simplify section in IMPLEMENT.md |
|
|
112
|
+
| review | `commands/rpi/review.md` | Review Verdict in IMPLEMENT.md |
|
|
113
|
+
| docs | `commands/rpi/docs.md` | Generated documentation |
|
|
114
|
+
"""
|
|
@@ -0,0 +1,214 @@
|
|
|
1
|
+
description = "Razor analyzes the implementation for reuse, quality, and efficiency improvements."
|
|
2
|
+
|
|
3
|
+
prompt = """
|
|
4
|
+
# /rpi:simplify — Simplify Phase
|
|
5
|
+
|
|
6
|
+
Razor analyzes the full implementation diff across 3 dimensions — reuse, quality, and efficiency — and applies improvements directly. Tests must pass before and after.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Step 1: Load config and validate
|
|
11
|
+
|
|
12
|
+
1. Read `.rpi.yaml` for config. Apply defaults if missing:
|
|
13
|
+
- `folder`: `rpi/features`
|
|
14
|
+
- `context_file`: `rpi/context.md`
|
|
15
|
+
- `commit_style`: `conventional`
|
|
16
|
+
2. Parse `$ARGUMENTS` to extract `{slug}`.
|
|
17
|
+
3. Validate `rpi/features/{slug}/implement/IMPLEMENT.md` exists. If not:
|
|
18
|
+
```
|
|
19
|
+
IMPLEMENT.md not found for '{slug}'. Run /rpi:implement {slug} first.
|
|
20
|
+
```
|
|
21
|
+
Stop.
|
|
22
|
+
4. Read `rpi/features/{slug}/implement/IMPLEMENT.md`. Verify all tasks are marked `[x]` (done). If any task is `[ ]` (pending) or `BLOCKED`:
|
|
23
|
+
```
|
|
24
|
+
Implementation is not complete for '{slug}'. {N} tasks remaining.
|
|
25
|
+
Complete all tasks before simplifying: /rpi:implement {slug}
|
|
26
|
+
```
|
|
27
|
+
Stop.
|
|
28
|
+
|
|
29
|
+
## Step 2: Get implementation diff
|
|
30
|
+
|
|
31
|
+
1. Read `rpi/features/{slug}/implement/IMPLEMENT.md` — extract all commit hashes from the Execution Log.
|
|
32
|
+
2. Use git to get the combined diff of all implementation commits:
|
|
33
|
+
```bash
|
|
34
|
+
git diff {first_commit}^..{last_commit}
|
|
35
|
+
```
|
|
36
|
+
3. Store the diff as `$IMPL_DIFF`.
|
|
37
|
+
4. Collect the list of all files changed — store as `$CHANGED_FILES`.
|
|
38
|
+
|
|
39
|
+
## Step 3: Gather context
|
|
40
|
+
|
|
41
|
+
1. Read `rpi/features/{slug}/plan/eng.md` if it exists — store as `$ENG`.
|
|
42
|
+
2. Read `rpi/context.md` (project context) if it exists — store as `$CONTEXT`.
|
|
43
|
+
|
|
44
|
+
## Step 4: Run tests (baseline)
|
|
45
|
+
|
|
46
|
+
1. Run the project's test suite to establish baseline:
|
|
47
|
+
```bash
|
|
48
|
+
npm test # or whatever the project uses
|
|
49
|
+
```
|
|
50
|
+
2. If tests fail before simplification:
|
|
51
|
+
```
|
|
52
|
+
Tests are already failing before simplification. Fix failing tests first.
|
|
53
|
+
```
|
|
54
|
+
Stop.
|
|
55
|
+
3. Store the test output as `$BASELINE_TESTS`.
|
|
56
|
+
|
|
57
|
+
## Step 5: Launch Razor with 3 parallel sub-checks
|
|
58
|
+
|
|
59
|
+
Launch Razor agent with this prompt:
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
You are Razor. Simplify the implementation for feature: {slug}
|
|
63
|
+
|
|
64
|
+
## Implementation Diff
|
|
65
|
+
{$IMPL_DIFF}
|
|
66
|
+
|
|
67
|
+
## Changed Files
|
|
68
|
+
{$CHANGED_FILES}
|
|
69
|
+
|
|
70
|
+
## Engineering Spec
|
|
71
|
+
{$ENG}
|
|
72
|
+
|
|
73
|
+
## Project Context
|
|
74
|
+
{$CONTEXT}
|
|
75
|
+
|
|
76
|
+
Your task — analyze the implementation across 3 dimensions IN PARALLEL:
|
|
77
|
+
|
|
78
|
+
### 1. Reuse
|
|
79
|
+
- Scan for duplicated code within the changed files
|
|
80
|
+
- Scan for duplication against existing codebase utilities
|
|
81
|
+
- Identify extraction opportunities (shared functions, constants, types)
|
|
82
|
+
- Check for reimplemented functionality that already exists in the project
|
|
83
|
+
|
|
84
|
+
### 2. Quality
|
|
85
|
+
- Naming: unclear variable/function names, inconsistent conventions
|
|
86
|
+
- Complexity: functions doing too much, deep nesting, long parameter lists
|
|
87
|
+
- Code smells: magic numbers, dead code, commented-out code, unnecessary abstractions
|
|
88
|
+
- Consistency: does the new code match the patterns in context.md?
|
|
89
|
+
|
|
90
|
+
### 3. Efficiency
|
|
91
|
+
- Algorithm choices: O(n^2) where O(n) is possible, unnecessary iterations
|
|
92
|
+
- Database/API queries: N+1 problems, missing batching, redundant calls
|
|
93
|
+
- Imports: unused imports, heavy imports where lighter alternatives exist
|
|
94
|
+
- Memory: unnecessary copies, large objects held in scope too long
|
|
95
|
+
|
|
96
|
+
RULES:
|
|
97
|
+
1. Read ALL changed files before making any modifications
|
|
98
|
+
2. Apply fixes directly to the code — do not just list suggestions
|
|
99
|
+
3. Each fix must preserve existing behavior (no functional changes)
|
|
100
|
+
4. Match the project's existing style and patterns
|
|
101
|
+
5. Do NOT over-abstract — only extract if there are 3+ duplications
|
|
102
|
+
6. After all fixes, list what you changed and why
|
|
103
|
+
|
|
104
|
+
Output format:
|
|
105
|
+
## Changes Applied
|
|
106
|
+
- {file}: {what changed} — {why}
|
|
107
|
+
|
|
108
|
+
## Metrics
|
|
109
|
+
- Reuse: {N} fixes
|
|
110
|
+
- Quality: {N} fixes
|
|
111
|
+
- Efficiency: {N} fixes
|
|
112
|
+
- Lines removed: {N}
|
|
113
|
+
- Lines added: {N}
|
|
114
|
+
|
|
115
|
+
After simplification, append your activity to rpi/features/{slug}/ACTIVITY.md:
|
|
116
|
+
|
|
117
|
+
### {current_date} — Razor (Simplify)
|
|
118
|
+
- **Action:** Simplified implementation for {slug}
|
|
119
|
+
- **Key decisions:** {for each <decision> tag you emitted: "summary (rationale)", separated by semicolons. If none: "No decisions in this phase."}
|
|
120
|
+
- **Reuse fixes:** {count}
|
|
121
|
+
- **Quality fixes:** {count}
|
|
122
|
+
- **Efficiency fixes:** {count}
|
|
123
|
+
- **Lines removed:** {count}
|
|
124
|
+
- **Quality:** {your quality gate result}
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
Store Razor's output as `$RAZOR_OUTPUT`.
|
|
128
|
+
|
|
129
|
+
## Step 6: Run tests (verification)
|
|
130
|
+
|
|
131
|
+
1. Run the project's test suite again:
|
|
132
|
+
```bash
|
|
133
|
+
npm test
|
|
134
|
+
```
|
|
135
|
+
2. If tests fail after Razor's changes:
|
|
136
|
+
- Show the failing tests to the user.
|
|
137
|
+
- Revert Razor's changes: `git checkout -- .`
|
|
138
|
+
- Inform the user:
|
|
139
|
+
```
|
|
140
|
+
Razor's changes broke {N} tests. Changes have been reverted.
|
|
141
|
+
Review the failures and re-run: /rpi:simplify {slug}
|
|
142
|
+
```
|
|
143
|
+
- Stop.
|
|
144
|
+
3. If all tests pass: continue.
|
|
145
|
+
|
|
146
|
+
## Step 7: Commit simplification changes
|
|
147
|
+
|
|
148
|
+
1. Stage all modified files:
|
|
149
|
+
```bash
|
|
150
|
+
git add {list of files Razor modified}
|
|
151
|
+
```
|
|
152
|
+
2. Commit with a descriptive message following `commit_style` from config:
|
|
153
|
+
```bash
|
|
154
|
+
git commit -m "refactor({slug}): simplify implementation — Razor"
|
|
155
|
+
```
|
|
156
|
+
3. Store the commit hash as `$SIMPLIFY_COMMIT`.
|
|
157
|
+
|
|
158
|
+
## Step 8: Update IMPLEMENT.md
|
|
159
|
+
|
|
160
|
+
Append a simplification results section to `rpi/features/{slug}/implement/IMPLEMENT.md`:
|
|
161
|
+
|
|
162
|
+
```markdown
|
|
163
|
+
## Simplify
|
|
164
|
+
|
|
165
|
+
Agent: Razor
|
|
166
|
+
Date: {YYYY-MM-DD}
|
|
167
|
+
Commit: {$SIMPLIFY_COMMIT}
|
|
168
|
+
|
|
169
|
+
### Changes
|
|
170
|
+
{list of changes from $RAZOR_OUTPUT}
|
|
171
|
+
|
|
172
|
+
### Metrics
|
|
173
|
+
- Reuse fixes: {N}
|
|
174
|
+
- Quality fixes: {N}
|
|
175
|
+
- Efficiency fixes: {N}
|
|
176
|
+
- Net lines: {+/-N}
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
## Step 9: Consolidate decisions to DECISIONS.md
|
|
180
|
+
|
|
181
|
+
1. Read `rpi/features/{slug}/ACTIVITY.md`.
|
|
182
|
+
2. Extract all `<decision>` tags from entries belonging to the Simplify phase (Razor entries from this run).
|
|
183
|
+
3. If no decisions found, skip this step.
|
|
184
|
+
4. Read `rpi/features/{slug}/DECISIONS.md` if it exists (to get the last decision number for sequential numbering).
|
|
185
|
+
5. Append a new section to `rpi/features/{slug}/DECISIONS.md`:
|
|
186
|
+
|
|
187
|
+
```markdown
|
|
188
|
+
## Simplify Phase
|
|
189
|
+
_Generated: {current_date}_
|
|
190
|
+
|
|
191
|
+
| # | Type | Decision | Alternatives | Rationale | Impact |
|
|
192
|
+
|---|------|----------|-------------|-----------|--------|
|
|
193
|
+
| {N} | {type} | {summary} | {alternatives} | {rationale} | {impact} |
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
6. Number decisions sequentially, continuing from the last number in DECISIONS.md.
|
|
197
|
+
|
|
198
|
+
## Step 10: Output summary
|
|
199
|
+
|
|
200
|
+
```
|
|
201
|
+
Simplify complete: {slug}
|
|
202
|
+
|
|
203
|
+
Razor applied {total} fixes:
|
|
204
|
+
- Reuse: {N}
|
|
205
|
+
- Quality: {N}
|
|
206
|
+
- Efficiency: {N}
|
|
207
|
+
|
|
208
|
+
Tests: all passing
|
|
209
|
+
Commit: {$SIMPLIFY_COMMIT}
|
|
210
|
+
|
|
211
|
+
Next: /rpi {slug}
|
|
212
|
+
Or explicitly: /rpi:review {slug}
|
|
213
|
+
```
|
|
214
|
+
"""
|
|
@@ -0,0 +1,194 @@
|
|
|
1
|
+
description = "Show all features, their current phase, and progress."
|
|
2
|
+
|
|
3
|
+
prompt = """
|
|
4
|
+
# /rpi:status — Feature Status Dashboard
|
|
5
|
+
|
|
6
|
+
Show all active features with their current phase, verdict, and progress. Optionally show detailed view for a specific feature.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Step 1: Load config
|
|
11
|
+
|
|
12
|
+
Read `.rpi.yaml` for config. Apply defaults if missing:
|
|
13
|
+
- `folder`: `rpi/features`
|
|
14
|
+
|
|
15
|
+
Parse `$ARGUMENTS` to extract optional `{slug}` for detailed view.
|
|
16
|
+
|
|
17
|
+
## Step 2: Find all features
|
|
18
|
+
|
|
19
|
+
Glob `{folder}/*/REQUEST.md` to find all active features.
|
|
20
|
+
|
|
21
|
+
If no features found:
|
|
22
|
+
```
|
|
23
|
+
No features found. Run /rpi:new to start.
|
|
24
|
+
```
|
|
25
|
+
Stop.
|
|
26
|
+
|
|
27
|
+
## Step 3: Detect phase for each feature
|
|
28
|
+
|
|
29
|
+
For each feature directory found, determine the current phase by checking which artifacts exist:
|
|
30
|
+
|
|
31
|
+
1. Has `REQUEST.md`, no `research/RESEARCH.md` → phase = **request** (next: research)
|
|
32
|
+
2. Has `research/RESEARCH.md`, no `plan/PLAN.md` → phase = **research** (next: plan)
|
|
33
|
+
3. Has `plan/PLAN.md`, no `implement/IMPLEMENT.md` → phase = **plan** (next: implement)
|
|
34
|
+
4. Has `implement/IMPLEMENT.md` with unchecked tasks (`- [ ]`) → phase = **implement** (in progress)
|
|
35
|
+
5. Has `implement/IMPLEMENT.md` with all tasks checked, no "## Simplify" section → phase = **implement** (next: simplify)
|
|
36
|
+
6. Has "## Simplify" section, no "## Review Verdict" section → phase = **simplify** (next: review)
|
|
37
|
+
7. Has "## Review Verdict" with PASS → phase = **review** (next: docs)
|
|
38
|
+
8. Everything done → phase = **complete**
|
|
39
|
+
|
|
40
|
+
## Step 4: Gather metadata per feature
|
|
41
|
+
|
|
42
|
+
For each feature:
|
|
43
|
+
|
|
44
|
+
### Verdict
|
|
45
|
+
- Read `research/RESEARCH.md` if it exists. Look for `## Verdict` section. Extract: GO | GO with concerns | NO-GO.
|
|
46
|
+
- If no RESEARCH.md: verdict = "pending"
|
|
47
|
+
|
|
48
|
+
### Complexity
|
|
49
|
+
- Read `REQUEST.md`. Look for `## Complexity Estimate` section. Extract: S | M | L | XL.
|
|
50
|
+
- If not found: complexity = "unknown"
|
|
51
|
+
|
|
52
|
+
### Task progress (if plan/implement exists)
|
|
53
|
+
- Read `plan/PLAN.md` if it exists. Count total tasks (lines matching `- [ ]` or `- [x]` pattern).
|
|
54
|
+
- Read `implement/IMPLEMENT.md` if it exists. Count completed tasks (`- [x]`) vs total.
|
|
55
|
+
- Express as: `{completed}/{total} tasks`
|
|
56
|
+
|
|
57
|
+
### Activity Log
|
|
58
|
+
- Read `{feature_dir}/ACTIVITY.md` if it exists.
|
|
59
|
+
- Extract the last 3 activity entries.
|
|
60
|
+
- Extract quality scores from all entries — build a quality summary per phase:
|
|
61
|
+
- Research: {PASS|WEAK|FAIL|pending} (Atlas, Scout, Nexus scores)
|
|
62
|
+
- Plan: {PASS|WEAK|FAIL|pending} (Nexus interview, Mestre, Clara, adversarial scores)
|
|
63
|
+
- Implement: {PASS|WEAK|FAIL|pending} (Forge per-task scores)
|
|
64
|
+
- Simplify: {PASS|WEAK|FAIL|pending} (Razor score)
|
|
65
|
+
- Review: {PASS|WEAK|FAIL|pending} (Hawk, Shield, Sage, Nexus scores)
|
|
66
|
+
- Docs: {PASS|WEAK|FAIL|pending} (Quill score)
|
|
67
|
+
- Identify any WEAK or FAIL scores for alerts.
|
|
68
|
+
- Extract last activity timestamp for "last activity" display.
|
|
69
|
+
|
|
70
|
+
### Decisions
|
|
71
|
+
- Read `{feature_dir}/DECISIONS.md` if it exists.
|
|
72
|
+
- Count total decisions, count by impact (HIGH, MEDIUM, LOW).
|
|
73
|
+
- Extract the last 5 decisions (most recent = bottom of the file).
|
|
74
|
+
|
|
75
|
+
## Step 5: Display status
|
|
76
|
+
|
|
77
|
+
### If no specific feature requested (overview mode)
|
|
78
|
+
|
|
79
|
+
Output a status card per feature, sorted by phase (most advanced first):
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
# RPI Status
|
|
83
|
+
|
|
84
|
+
## {feature-slug}
|
|
85
|
+
Phase: {phase} {task_progress if applicable}
|
|
86
|
+
Verdict: {verdict}
|
|
87
|
+
Complexity: {complexity}
|
|
88
|
+
Last activity: {relative time, e.g. "2h ago" or "3 days ago"}
|
|
89
|
+
Quality: {phase_quality_summary, e.g. "Research PASS | Plan PASS | Implement 3/7"}
|
|
90
|
+
Decisions: {total} ({HIGH_count} HIGH, {MEDIUM_count} MEDIUM, {LOW_count} LOW)
|
|
91
|
+
|
|
92
|
+
## {feature-slug-2}
|
|
93
|
+
Phase: {phase}
|
|
94
|
+
Verdict: {verdict}
|
|
95
|
+
Complexity: {complexity}
|
|
96
|
+
Last activity: {relative time, e.g. "2h ago" or "3 days ago"}
|
|
97
|
+
Quality: {phase_quality_summary, e.g. "Research PASS | Plan PASS | Implement 3/7"}
|
|
98
|
+
Decisions: {total} ({HIGH_count} HIGH, {MEDIUM_count} MEDIUM, {LOW_count} LOW)
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
{total_count} feature(s) active
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### Quality Alerts
|
|
105
|
+
|
|
106
|
+
After the feature cards, if any feature has WEAK or FAIL quality scores:
|
|
107
|
+
|
|
108
|
+
```
|
|
109
|
+
## Alerts
|
|
110
|
+
|
|
111
|
+
- {feature}: {phase} quality WEAK — {agent} ({reason from activity log})
|
|
112
|
+
Suggestion: {actionable suggestion, e.g. "Re-run /rpi:research" or "Add context to REQUEST.md"}
|
|
113
|
+
|
|
114
|
+
- {feature}: {phase} quality FAIL — {agent} ({reason})
|
|
115
|
+
Suggestion: {actionable suggestion}
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
If no alerts: omit this section entirely.
|
|
119
|
+
|
|
120
|
+
Phase display format:
|
|
121
|
+
- `request` → "request (awaiting research)"
|
|
122
|
+
- `research` → "research (awaiting plan)"
|
|
123
|
+
- `plan` → "plan (awaiting implement)"
|
|
124
|
+
- `implement` → "implement ({completed}/{total} tasks)"
|
|
125
|
+
- `simplify` → "simplify (awaiting review)"
|
|
126
|
+
- `review` → "review (awaiting docs)"
|
|
127
|
+
- `complete` → "complete"
|
|
128
|
+
|
|
129
|
+
### If specific feature requested (detailed mode)
|
|
130
|
+
|
|
131
|
+
If `{slug}` was provided in arguments, show detailed view for that feature:
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
# RPI Status: {slug}
|
|
135
|
+
|
|
136
|
+
Phase: {phase} {task_progress}
|
|
137
|
+
Verdict: {verdict}
|
|
138
|
+
Complexity: {complexity}
|
|
139
|
+
|
|
140
|
+
## Artifacts
|
|
141
|
+
- REQUEST.md: {exists/missing}
|
|
142
|
+
- research/RESEARCH.md: {exists/missing}
|
|
143
|
+
- plan/PLAN.md: {exists/missing}
|
|
144
|
+
- plan/eng.md: {exists/missing}
|
|
145
|
+
- plan/pm.md: {exists/missing}
|
|
146
|
+
- plan/ux.md: {exists/missing}
|
|
147
|
+
- implement/IMPLEMENT.md: {exists/missing}
|
|
148
|
+
- DECISIONS.md: {exists/missing}
|
|
149
|
+
- delta/: {count of files in ADDED + MODIFIED + REMOVED}
|
|
150
|
+
|
|
151
|
+
## Tasks
|
|
152
|
+
{If PLAN.md exists, list all tasks with their status: [x] or [ ]}
|
|
153
|
+
|
|
154
|
+
## Review
|
|
155
|
+
{If Review Verdict exists in IMPLEMENT.md, show verdict and finding counts}
|
|
156
|
+
|
|
157
|
+
## Next
|
|
158
|
+
{Suggest the next command to run, e.g. "/rpi {slug}" or "/rpi:archive {slug}" if complete}
|
|
159
|
+
|
|
160
|
+
## Activity Log (last 5 entries)
|
|
161
|
+
{If ACTIVITY.md exists, show last 5 entries in reverse chronological order}
|
|
162
|
+
{If no ACTIVITY.md: "No activity log yet."}
|
|
163
|
+
|
|
164
|
+
## Key Decisions (last 5)
|
|
165
|
+
{If DECISIONS.md exists:}
|
|
166
|
+
| # | Phase | Decision | Impact |
|
|
167
|
+
|---|-------|----------|--------|
|
|
168
|
+
| {N} | {phase} | {summary} | {impact} |
|
|
169
|
+
|
|
170
|
+
Total: {N} decisions ({HIGH_count} HIGH, {MEDIUM_count} MEDIUM, {LOW_count} LOW)
|
|
171
|
+
Full log: rpi/features/{slug}/DECISIONS.md
|
|
172
|
+
|
|
173
|
+
{If no DECISIONS.md: "No decisions logged yet."}
|
|
174
|
+
|
|
175
|
+
## Quality Summary
|
|
176
|
+
{For each completed phase, show quality scores:}
|
|
177
|
+
- Research: Atlas {score} | Scout {score} | Nexus {score}
|
|
178
|
+
- Plan: Interview {score} | Mestre {score} | Clara {score} | Adversarial {score}
|
|
179
|
+
- Implement: {N}/{total} tasks, Forge avg quality {score}
|
|
180
|
+
- Simplify: Razor {score}
|
|
181
|
+
- Review: Hawk {score} | Shield {score} | Sage {score}
|
|
182
|
+
- Docs: Quill {score}
|
|
183
|
+
|
|
184
|
+
## Session Resume
|
|
185
|
+
Last activity: {timestamp and description of last logged action}
|
|
186
|
+
Next step: {suggest the next command based on current phase}
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
If the requested feature does not exist:
|
|
190
|
+
```
|
|
191
|
+
Feature '{slug}' not found. Available features:
|
|
192
|
+
- {list of existing feature slugs}
|
|
193
|
+
```
|
|
194
|
+
"""
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
description = "Update RPIKit plugin to the latest version from the remote repository."
|
|
2
|
+
|
|
3
|
+
prompt = """
|
|
4
|
+
# /rpi:update — Update RPIKit
|
|
5
|
+
|
|
6
|
+
Pull the latest version of RPIKit from the remote repository and clear the plugin cache.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Step 1: Find the installed plugin directory
|
|
11
|
+
|
|
12
|
+
Search for the RPIKit installation:
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
find ~/.claude/plugins -name "plugin.json" -path "*/rpi-kit/*" 2>/dev/null
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
From the results, determine the plugin root directory (the parent of `.claude-plugin/`).
|
|
19
|
+
|
|
20
|
+
If not found:
|
|
21
|
+
```
|
|
22
|
+
RPIKit installation not found in ~/.claude/plugins/.
|
|
23
|
+
Re-install from the marketplace or run:
|
|
24
|
+
claude plugin add git@github.com:dmend3z/rpi-kit.git
|
|
25
|
+
```
|
|
26
|
+
Stop.
|
|
27
|
+
|
|
28
|
+
Store the plugin root path as `$PLUGIN_DIR`.
|
|
29
|
+
|
|
30
|
+
## Step 2: Show current version
|
|
31
|
+
|
|
32
|
+
Read `$PLUGIN_DIR/.claude-plugin/plugin.json` and extract the current `version` field.
|
|
33
|
+
Store as `$CURRENT_VERSION`.
|
|
34
|
+
|
|
35
|
+
Also get the current git commit:
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
cd $PLUGIN_DIR && git rev-parse --short HEAD
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Store as `$CURRENT_COMMIT`.
|
|
42
|
+
|
|
43
|
+
## Step 3: Pull latest changes
|
|
44
|
+
|
|
45
|
+
Run git pull in the plugin directory:
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
cd $PLUGIN_DIR && git pull origin main 2>&1
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
If it fails:
|
|
52
|
+
- If "not a git repository": report the error and suggest re-installing.
|
|
53
|
+
- If merge conflict: report the error and suggest `cd $PLUGIN_DIR && git reset --hard origin/main` (ask user first — this discards local changes).
|
|
54
|
+
- If network error: report "Could not reach remote. Check your connection."
|
|
55
|
+
- Stop on any error.
|
|
56
|
+
|
|
57
|
+
If output says "Already up to date.":
|
|
58
|
+
```
|
|
59
|
+
RPIKit is already up to date (v{$CURRENT_VERSION}, {$CURRENT_COMMIT}).
|
|
60
|
+
```
|
|
61
|
+
Stop.
|
|
62
|
+
|
|
63
|
+
## Step 4: Show what changed
|
|
64
|
+
|
|
65
|
+
Get the new version:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
cd $PLUGIN_DIR && cat .claude-plugin/plugin.json | grep '"version"'
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
Store as `$NEW_VERSION`.
|
|
72
|
+
|
|
73
|
+
Get the new commit:
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
cd $PLUGIN_DIR && git rev-parse --short HEAD
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Store as `$NEW_COMMIT`.
|
|
80
|
+
|
|
81
|
+
Show the changelog between old and new commits:
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
cd $PLUGIN_DIR && git log --oneline $CURRENT_COMMIT..$NEW_COMMIT
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## Step 5: Clear plugin cache
|
|
88
|
+
|
|
89
|
+
Remove cached versions so Claude Code picks up the new files:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
rm -rf ~/.claude/plugins/cache/rpi-kit 2>/dev/null
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
## Step 6: Output summary
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
RPIKit updated!
|
|
99
|
+
|
|
100
|
+
{$CURRENT_VERSION} ({$CURRENT_COMMIT}) → {$NEW_VERSION} ({$NEW_COMMIT})
|
|
101
|
+
|
|
102
|
+
Changes:
|
|
103
|
+
{git log output from step 4}
|
|
104
|
+
|
|
105
|
+
Restart Claude Code to load the new version.
|
|
106
|
+
```
|
|
107
|
+
"""
|