clevotics-claude-bootstrap 1.0.2 → 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/package.json +1 -1
- package/project-bootstrap/SKILL.md +96 -7
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "clevotics-claude-bootstrap",
|
|
3
|
-
"version": "1.0
|
|
3
|
+
"version": "1.1.0",
|
|
4
4
|
"description": "Claude Code skill that splits one Project Plan.md into PRD, ARCHITECTURE, DESIGN, a phased PLAN and a CLAUDE.md",
|
|
5
5
|
"bin": {
|
|
6
6
|
"clevotics-claude-bootstrap": "bin/cli.js"
|
|
@@ -21,10 +21,14 @@ CLAUDE.md short router + hard rules (written LAST)
|
|
|
21
21
|
docs/PRD.md product only: what and for whom, no tech
|
|
22
22
|
docs/ARCHITECTURE.md tech only: stack, data model, modules, APIs
|
|
23
23
|
docs/DESIGN.md UI only: tokens, components, copy rules (skip if no UI)
|
|
24
|
-
docs/PLAN.md phases, status, exit criteria
|
|
24
|
+
docs/PLAN.md phases, status, exit criteria (open phases only)
|
|
25
|
+
docs/plan-archive.md DONE phases moved here in full, with their Result paragraphs
|
|
26
|
+
docs/testing/ one manual test plan per phase: docs/testing/<phase-id>.md
|
|
25
27
|
docs/<source file> moved here unchanged as the original record
|
|
26
28
|
```
|
|
27
29
|
|
|
30
|
+
Create `docs/plan-archive.md` (header only) and `docs/testing/` (with a `.gitkeep`) at bootstrap time, so they exist before the first phase finishes
|
|
31
|
+
|
|
28
32
|
Add an extra doc only when the source has a large self-contained topic (an external API integration, a deployment runbook). Name it by topic (`docs/whatsapp-api.md`, `docs/DEPLOY.md`), never `notes.md` or `misc.md`
|
|
29
33
|
|
|
30
34
|
## Process
|
|
@@ -32,7 +36,7 @@ Add an extra doc only when the source has a large self-contained topic (an exter
|
|
|
32
36
|
1. **Read the whole source plan.** Sort every statement into one bucket: product (PRD), technical (ARCHITECTURE), UI (DESIGN), sequencing / tasks (PLAN), or rule (CLAUDE.md). Nothing gets dropped; nothing appears in two docs - other docs link to the owner instead
|
|
33
37
|
2. **Find the gaps.** List decisions the source leaves open that change the work materially (stack, auth method, hosting, multi-tenant or not). Ask them with the AskUserQuestion tool, max 4 per call, recommended option first. Do not ask about anything you can decide sensibly yourself - pick it and write it down as a decision
|
|
34
38
|
3. **Write PRD.md, ARCHITECTURE.md, DESIGN.md** using the templates below
|
|
35
|
-
4. **Write PLAN.md** - the most important file. Follow the phase rules strictly
|
|
39
|
+
4. **Write PLAN.md** - the most important file. Follow the phase rules strictly. Also create `docs/plan-archive.md` and `docs/testing/`
|
|
36
40
|
5. **Write CLAUDE.md last**, once the other docs exist, because it routes to them
|
|
37
41
|
6. **Move the source plan** into `docs/` unchanged (`git mv` if tracked)
|
|
38
42
|
7. Report: files created, phase count, decisions you made on the user's behalf, open questions left
|
|
@@ -46,7 +50,7 @@ Use this mode instead of steps 1 to 6 when the repo already has a `CLAUDE.md`, a
|
|
|
46
50
|
3. **Back up before rewriting.** Copy the current `CLAUDE.md` to `docs/CLAUDE.md.bak` (and any doc you will restructure, same pattern). The user deletes the backups once happy
|
|
47
51
|
4. **Keep every rule.** Each rule, command and convention in the old `CLAUDE.md` either stays in the new `CLAUDE.md` or moves to the doc that owns it with a link back. Product and architecture explanations move out; hard rules, commands and routing stay
|
|
48
52
|
5. **Keep existing docs that already fit.** If a doc already covers one bucket (e.g. an `API.md` that is the architecture), keep its name and route to it from `CLAUDE.md` instead of creating a duplicate
|
|
49
|
-
6. **Plan from where the code is, not from zero.** Work already in the code and git history becomes DONE phases at the top of `PLAN.md`, each with a short Result line ("existing before bootstrap"). Remaining work from the plan or the old docs becomes TODO phases following the phase rules below
|
|
53
|
+
6. **Plan from where the code is, not from zero.** Work already in the code and git history becomes DONE phases at the top of `PLAN.md`, each with a short Result line ("existing before bootstrap"). Remaining work from the plan or the old docs becomes TODO phases following the phase rules below. Existing DONE phases go straight into `docs/plan-archive.md`, leaving only their Overview row in `PLAN.md`. Create `docs/testing/` if missing, and add the Phase Completion Protocol to the new `CLAUDE.md` even if the old one had none
|
|
50
54
|
7. **Verify nothing was dropped.** Before reporting, list each heading of the old `CLAUDE.md` and where its content now lives. Any heading without a home is a bug - fix it before reporting
|
|
51
55
|
|
|
52
56
|
## Phase rules (PLAN.md)
|
|
@@ -59,7 +63,9 @@ A phase is the unit Claude finishes in one sitting, end to end
|
|
|
59
63
|
- **Each phase has:** Goal (one line), Tasks (checklist), Exit criteria (observable, testable - "GET /bookings returns 50 rows under 300 ms", never "bookings work"), Depends on
|
|
60
64
|
- **Status keys:** `TODO` `IN PROGRESS` `PARKED` `DONE`. One phase IN PROGRESS at a time
|
|
61
65
|
- **Production hardening** (security audit, load test, backups, monitoring) is its own final phase, PARKED until all features are DONE
|
|
62
|
-
- When a phase finishes, append a `Result (date)` paragraph: what was built, test results, deferred items with the reason
|
|
66
|
+
- When a phase finishes, append a `Result (date)` paragraph: what was built, test results, review outcome, link to its test plan, deferred items with the reason
|
|
67
|
+
- **Archive on DONE:** once the Result paragraph is written, move the whole phase section (Goal, Tasks, Exit criteria, Result) to the end of `docs/plan-archive.md`. In `PLAN.md` keep only its Overview row, set to DONE and linking to the archive entry. `PLAN.md` then holds only TODO, IN PROGRESS and PARKED phases
|
|
68
|
+
- **Test plan on DONE:** every finished phase gets `docs/testing/<phase-id>.md` (for example `docs/testing/B1.md`). It has setup once at the top (how to start, URL, login), then a numbered table of steps with do this / expect that, covering only what the phase changed and using real seed data. Mark the two or three steps where a bug would most likely hide
|
|
63
69
|
|
|
64
70
|
## Templates
|
|
65
71
|
|
|
@@ -121,7 +127,9 @@ One phase at a time. A phase starts only when the previous one meets its exit cr
|
|
|
121
127
|
| ... | ... | ... |
|
|
122
128
|
| B99 | Production hardening (last, before go-live) | PARKED |
|
|
123
129
|
|
|
124
|
-
|
|
130
|
+
DONE phases keep their row here and link to [plan-archive.md](plan-archive.md); their full sections live there
|
|
131
|
+
|
|
132
|
+
**Every phase exit also requires:** tests green, docs updated in the same change, the Phase Completion Protocol in CLAUDE.md, <project-wide checks>
|
|
125
133
|
|
|
126
134
|
---
|
|
127
135
|
|
|
@@ -136,7 +144,73 @@ One phase at a time. A phase starts only when the previous one meets its exit cr
|
|
|
136
144
|
**Exit criteria**
|
|
137
145
|
- <observable, testable>
|
|
138
146
|
|
|
139
|
-
**Result:** (filled in when DONE)
|
|
147
|
+
**Result:** (filled in when DONE, then the section moves to plan-archive.md)
|
|
148
|
+
Code review: <outcome>
|
|
149
|
+
Security review: <outcome>
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
## Review gate hook
|
|
153
|
+
|
|
154
|
+
Instructions alone can be skipped in a long session, so every bootstrap (new or existing project) also installs a hook that refuses to archive a phase whose Result does not record both reviews
|
|
155
|
+
|
|
156
|
+
1. Write `.claude/hooks/check-phase-reviews.js` with exactly this content:
|
|
157
|
+
|
|
158
|
+
```js
|
|
159
|
+
#!/usr/bin/env node
|
|
160
|
+
// Refuses to archive a phase whose Result does not record both reviews
|
|
161
|
+
const chunks = [];
|
|
162
|
+
process.stdin.on("data", (chunk) => chunks.push(chunk));
|
|
163
|
+
process.stdin.on("end", () => {
|
|
164
|
+
const input = JSON.parse(Buffer.concat(chunks).toString()).tool_input;
|
|
165
|
+
if (!input.file_path.replace(/\\/g, "/").endsWith("docs/plan-archive.md")) return;
|
|
166
|
+
const text = input.content ?? input.new_string ?? (input.edits ?? []).map((edit) => edit.new_string).join("\n");
|
|
167
|
+
if (!text.includes("**Result")) return;
|
|
168
|
+
const missing = ["Code review:", "Security review:"].filter((label) => !text.includes(label));
|
|
169
|
+
if (missing.length === 0) return;
|
|
170
|
+
process.stderr.write(`Blocked: the phase Result is missing ${missing.join(" and ")}. Run /code-review and /security-review, record each outcome in the Result, then archive the phase\n`);
|
|
171
|
+
process.exit(2);
|
|
172
|
+
});
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
2. Add this to `.claude/settings.json`, merging into any existing `hooks.PreToolUse` list instead of replacing it:
|
|
176
|
+
|
|
177
|
+
```json
|
|
178
|
+
{
|
|
179
|
+
"hooks": {
|
|
180
|
+
"PreToolUse": [
|
|
181
|
+
{
|
|
182
|
+
"matcher": "Edit|Write|MultiEdit",
|
|
183
|
+
"hooks": [{ "type": "command", "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-phase-reviews.js\"" }]
|
|
184
|
+
}
|
|
185
|
+
]
|
|
186
|
+
}
|
|
187
|
+
}
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
3. Mention in the report that both files should be committed so the gate applies to everyone on the repo
|
|
191
|
+
|
|
192
|
+
### docs/plan-archive.md
|
|
193
|
+
|
|
194
|
+
```markdown
|
|
195
|
+
# <Project> - Plan Archive
|
|
196
|
+
|
|
197
|
+
DONE phases, moved here from [PLAN.md](PLAN.md) in full, oldest first. Never edit an archived phase; new work goes in a new phase
|
|
198
|
+
|
|
199
|
+
---
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
### docs/testing/<phase-id>.md
|
|
203
|
+
|
|
204
|
+
```markdown
|
|
205
|
+
# <Phase id> - <Phase name>: Manual Test Plan
|
|
206
|
+
|
|
207
|
+
**Setup:** <how to start, URL, login, seed data>
|
|
208
|
+
|
|
209
|
+
| # | Do this | Expect |
|
|
210
|
+
|---|---|---|
|
|
211
|
+
| 1 | ... | ... |
|
|
212
|
+
|
|
213
|
+
**Sharp steps:** <step numbers and why a bug would hide there>
|
|
140
214
|
```
|
|
141
215
|
|
|
142
216
|
### CLAUDE.md (keep under ~120 lines)
|
|
@@ -154,6 +228,8 @@ One phase at a time. A phase starts only when the previous one meets its exit cr
|
|
|
154
228
|
| Data model, modules, APIs | `docs/ARCHITECTURE.md` |
|
|
155
229
|
| UI tokens, components, copy | `docs/DESIGN.md` |
|
|
156
230
|
| Current phase, exit criteria | `docs/PLAN.md` |
|
|
231
|
+
| Finished phases and their results | `docs/plan-archive.md` |
|
|
232
|
+
| Manual test plan for a phase | `docs/testing/<phase-id>.md` |
|
|
157
233
|
|
|
158
234
|
Update the relevant doc in the same change when a decision changes
|
|
159
235
|
|
|
@@ -166,7 +242,20 @@ Update the relevant doc in the same change when a decision changes
|
|
|
166
242
|
Status lives only in `docs/PLAN.md` (never log phases here)
|
|
167
243
|
|
|
168
244
|
- Follow `docs/PLAN.md` strictly: one phase at a time, meet exit criteria before the next
|
|
169
|
-
- When a phase passes its exit criteria
|
|
245
|
+
- When a phase passes its exit criteria, run the Phase Completion Protocol below before reporting
|
|
246
|
+
|
|
247
|
+
## Phase Completion Protocol (automatic, every phase)
|
|
248
|
+
|
|
249
|
+
When a phase's exit criteria pass, before reporting it done, run in order without being asked:
|
|
250
|
+
|
|
251
|
+
1. `code-review` skill on all changes of the phase
|
|
252
|
+
2. `security-review` skill on the same changes
|
|
253
|
+
3. Fix the findings, or record each accepted one with its reason. A phase is not DONE while a critical or high finding is open
|
|
254
|
+
4. Write the manual test plan to `docs/testing/<phase-id>.md`
|
|
255
|
+
5. Mark the phase DONE in `docs/PLAN.md` with its **Result (date)** paragraph: what was built, tests, test plan link, deferred items, plus one `Code review: <outcome>` line and one `Security review: <outcome>` line
|
|
256
|
+
6. Move the full phase section to `docs/plan-archive.md`, leaving only its DONE row in the PLAN.md Overview. A hook blocks this move if either review line is missing
|
|
257
|
+
|
|
258
|
+
Then report: exit criteria pass / fail, findings from each review ranked by severity, and the test plan steps
|
|
170
259
|
|
|
171
260
|
## Hard Rules
|
|
172
261
|
<architecture / security / performance rules pulled from the source plan - each one checkable in a diff>
|