cclaw-cli 0.34.0 → 0.35.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/README.md +43 -18
- package/dist/content/meta-skill.js +21 -0
- package/dist/content/protocols.js +53 -2
- package/dist/content/stages/spec.js +2 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -2,13 +2,15 @@
|
|
|
2
2
|
|
|
3
3
|
**Install once, ship every time.** cclaw is an installer-first workflow
|
|
4
4
|
runtime that gives your AI coding agent one inspectable path from idea to
|
|
5
|
-
shipped PR
|
|
5
|
+
shipped PR — **plus an automatic closeout chain** that turns every ship
|
|
6
|
+
into reusable knowledge:
|
|
6
7
|
|
|
7
|
-
> **brainstorm → scope → design → spec → plan → tdd → review → ship**
|
|
8
|
+
> **brainstorm → scope → design → spec → plan → tdd → review → ship**
|
|
9
|
+
> **↳ auto-closeout: retro → compound → archive** *(resumable, never manual)*
|
|
8
10
|
|
|
9
11
|
Every stage has real gates the agent cannot skip, every decision leaves a
|
|
10
|
-
file-backed audit trail, and the same
|
|
11
|
-
|
|
12
|
+
file-backed audit trail, and the same slash commands work across Claude
|
|
13
|
+
Code, Cursor, OpenCode, and OpenAI Codex.
|
|
12
14
|
|
|
13
15
|
You install cclaw **once** from the terminal, then everything happens
|
|
14
16
|
inside your harness — no hidden control plane, no background daemon, no
|
|
@@ -41,15 +43,28 @@ operational knobs to memorise.
|
|
|
41
43
|
│ │ │ │ │ │ │ │
|
|
42
44
|
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
|
|
43
45
|
01.md 02.md 03.md 04.md 05.md 06.md 07.md 08.md
|
|
44
|
-
│
|
|
45
|
-
└──── gates + subagents + knowledge capture
|
|
46
|
+
│ │
|
|
47
|
+
└──── gates + subagents + knowledge capture │
|
|
48
|
+
happen at every step │
|
|
49
|
+
▼
|
|
50
|
+
┌─────────────────────────┐
|
|
51
|
+
│ automatic closeout │
|
|
52
|
+
│ (resumable state │
|
|
53
|
+
│ machine, never manual)│
|
|
54
|
+
└────────────┬────────────┘
|
|
55
|
+
▼
|
|
56
|
+
retro ──► compound ──► archive
|
|
57
|
+
09.md (knowledge (runs/
|
|
58
|
+
promoted) <slug>/)
|
|
46
59
|
```
|
|
47
60
|
|
|
48
61
|
Every stage reads and writes real files under `.cclaw/`. `flow-state.json`
|
|
49
|
-
holds the single source of truth for "where are we"
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
62
|
+
holds the single source of truth for "where are we" — including
|
|
63
|
+
`closeout.shipSubstate` so a ship → retro → compound → archive chain
|
|
64
|
+
resumes at the exact step after any interruption. `knowledge.jsonl`
|
|
65
|
+
accumulates reusable lessons **throughout** the flow, not only at the
|
|
66
|
+
end; stage artifacts live under `.cclaw/artifacts/` until archive rolls
|
|
67
|
+
them into `.cclaw/runs/<date-slug>/`.
|
|
53
68
|
|
|
54
69
|
```
|
|
55
70
|
You ──► /cc <idea>
|
|
@@ -188,21 +203,31 @@ No magic. No ambiguity about where you are.
|
|
|
188
203
|
|
|
189
204
|
---
|
|
190
205
|
|
|
191
|
-
## The eight stages,
|
|
206
|
+
## The eight stages, the three tracks, and auto-closeout
|
|
192
207
|
|
|
193
|
-
cclaw has eight stages
|
|
194
|
-
|
|
208
|
+
cclaw has eight **critical-path** stages plus an automatic three-step
|
|
209
|
+
closeout chain (retro → compound → archive). A single prompt rarely needs
|
|
210
|
+
all eight critical-path stages, so `/cc` picks a **track** up front so
|
|
211
|
+
the flow matches the task.
|
|
195
212
|
|
|
196
|
-
| Track |
|
|
213
|
+
| Track | Critical path | Typical trigger |
|
|
197
214
|
|---|---|---|
|
|
198
215
|
| **quick** | `spec → tdd → review → ship` | `bug`, `hotfix`, `typo`, `rename`, `bump`, `docs only`, one-liners |
|
|
199
216
|
| **medium** | `brainstorm → spec → plan → tdd → review → ship` | `add endpoint`, `add field`, `extend existing`, `wire integration` |
|
|
200
217
|
| **standard** _(default)_ | all 8 stages | `new feature`, `refactor`, `migration`, `platform`, `schema`, `architecture` |
|
|
201
218
|
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
`
|
|
205
|
-
|
|
219
|
+
**Every track ends with the same auto-closeout chain.** Once ship
|
|
220
|
+
completes, `/cc-next` automatically drives
|
|
221
|
+
`retro → compound → archive` — with `closeout.shipSubstate` carrying the
|
|
222
|
+
exact step across sessions, so a crashed or backgrounded run resumes
|
|
223
|
+
without re-drafting retros or re-asking structured questions. See
|
|
224
|
+
[Ship and closeout](#ship-and-closeout--automatic-resumable).
|
|
225
|
+
|
|
226
|
+
Each critical-path stage produces a dated artifact under
|
|
227
|
+
`.cclaw/artifacts/`: `00-idea.md` (seed), `01-brainstorm.md` through
|
|
228
|
+
`08-ship.md`. Closeout adds `09-retro.md`; archive then rolls the whole
|
|
229
|
+
bundle into `.cclaw/runs/<YYYY-MM-DD-slug>/` and resets the active flow
|
|
230
|
+
for the next feature.
|
|
206
231
|
|
|
207
232
|
### Track heuristics are configurable
|
|
208
233
|
|
|
@@ -18,6 +18,27 @@ description: "Routing brain for cclaw. Decide whether to start/resume a stage, a
|
|
|
18
18
|
|
|
19
19
|
If the user explicitly overrides a stage rule, record it in the artifact.
|
|
20
20
|
|
|
21
|
+
## Skill-before-response gate
|
|
22
|
+
|
|
23
|
+
If \`.cclaw/state/flow-state.json\` exists and \`currentStage\` is set,
|
|
24
|
+
load the matching stage SKILL before producing **substantive** work
|
|
25
|
+
(artifact edits, code, structured clarifying questions). Do not improvise
|
|
26
|
+
from memory. Also load a contextual utility skill when the task clearly
|
|
27
|
+
triggers it (security, performance, debugging, docs, finishing-a-branch,
|
|
28
|
+
verification-before-completion).
|
|
29
|
+
|
|
30
|
+
Substantive vs. non-substantive:
|
|
31
|
+
|
|
32
|
+
- **Substantive** (must load skill first): proposing design, editing an
|
|
33
|
+
artifact, running gates, dispatching subagents, asking a
|
|
34
|
+
\`Decision Protocol\` question, declaring a stage done.
|
|
35
|
+
- **Non-substantive** (skill load optional): one-line acknowledgement,
|
|
36
|
+
clarifying a typo, confirming a prior answer, pure conversation.
|
|
37
|
+
|
|
38
|
+
If the current stage is ambiguous because \`flow-state.json\` is missing
|
|
39
|
+
or corrupt, stop and route through \`/cc\` before any substantive
|
|
40
|
+
response.
|
|
41
|
+
|
|
21
42
|
## Routing flow
|
|
22
43
|
|
|
23
44
|
\`\`\`
|
|
@@ -19,11 +19,62 @@ Shared format for decisions that require user confirmation.
|
|
|
19
19
|
- OpenCode/Codex: plain text options
|
|
20
20
|
5. Wait for user choice before proceeding.
|
|
21
21
|
|
|
22
|
+
## Decision skeleton
|
|
23
|
+
|
|
24
|
+
Every Decision Protocol call — regardless of harness — follows this
|
|
25
|
+
four-part skeleton. Do not skip a part; if a part is trivially empty,
|
|
26
|
+
say so explicitly (e.g. "Re-ground: same branch, same task as prior
|
|
27
|
+
turn").
|
|
28
|
+
|
|
29
|
+
1. **Re-ground (1-2 sentences).** State the project, the active
|
|
30
|
+
feature slug, the active stage (from \`flow-state.json\`), and the
|
|
31
|
+
decision's plain-English context. Pull these values from the source
|
|
32
|
+
of truth, not from conversation memory.
|
|
33
|
+
2. **Simplify (2-4 sentences).** Explain the choice in plain English a
|
|
34
|
+
smart 16-year-old could follow. No internal jargon, no raw function
|
|
35
|
+
names, no implementation trivia. Say what each option DOES and
|
|
36
|
+
what changes for the user.
|
|
37
|
+
3. **Recommend.** One line of the form
|
|
38
|
+
\`RECOMMENDATION: Choose [Letter] because [one-line reason]\`.
|
|
39
|
+
Always prefer the more complete option unless an explicit constraint
|
|
40
|
+
says otherwise (see Completeness calibration below). Never present
|
|
41
|
+
options as equivalent when they are not.
|
|
42
|
+
4. **Options.** Lettered options \`A) ... B) ... C) ...\`. Each option
|
|
43
|
+
includes one-line \`Completeness: X/10\` plus, when effort differs
|
|
44
|
+
noticeably, a \`(human: ~Xh / agent: ~Ym)\` estimate.
|
|
45
|
+
|
|
46
|
+
## Completeness calibration
|
|
47
|
+
|
|
48
|
+
Use the same 1-10 scale for every option so comparisons stay honest:
|
|
49
|
+
|
|
50
|
+
- **10** = complete implementation: all stated edges handled,
|
|
51
|
+
traceable to spec, no known deferred work.
|
|
52
|
+
- **7** = covers the happy path; one or two non-critical edges
|
|
53
|
+
deferred with an explicit follow-up.
|
|
54
|
+
- **5** = partial; either drops edge cases silently or hands off
|
|
55
|
+
required work to a future run.
|
|
56
|
+
- **3** = shortcut; skips spec criteria, violates an Iron Law, or
|
|
57
|
+
defers significant work without tracking.
|
|
58
|
+
- **1** = acknowledged placeholder (\`TBD\`, \`TODO\`, "static for now").
|
|
59
|
+
|
|
60
|
+
Calibration rules:
|
|
61
|
+
|
|
62
|
+
- Mark any option at \`Completeness: ≤5\` and require the user to
|
|
63
|
+
acknowledge the gap before picking it.
|
|
64
|
+
- If two options are both \`≥8\`, recommend the higher one.
|
|
65
|
+
- "Static for now" / "we will add later" phrasing always scores \`≤3\`
|
|
66
|
+
and must be surfaced in Simplify, not buried in an option label.
|
|
67
|
+
|
|
22
68
|
## Ask format
|
|
23
69
|
|
|
24
70
|
- One question per call.
|
|
25
|
-
- Option labels are short and unambiguous
|
|
26
|
-
|
|
71
|
+
- Option labels are short and unambiguous; the full reasoning lives in
|
|
72
|
+
Simplify + per-option Completeness.
|
|
73
|
+
- If tool schema fails once, fall back to plain text immediately but
|
|
74
|
+
keep the skeleton (Re-ground / Simplify / RECOMMENDATION / lettered
|
|
75
|
+
Options with Completeness scores).
|
|
76
|
+
- Log the chosen letter into the stage artifact's decision log with
|
|
77
|
+
the Completeness score; do not rely on chat history.
|
|
27
78
|
|
|
28
79
|
## Retry and escalation
|
|
29
80
|
|
|
@@ -31,6 +31,7 @@ export const SPEC = {
|
|
|
31
31
|
"Express each requirement in observable terms.",
|
|
32
32
|
"Resolve ambiguity before moving to plan. Challenge vague language.",
|
|
33
33
|
"Capture assumptions explicitly, not implicitly.",
|
|
34
|
+
"**Chunk acceptance criteria for review.** When presenting the spec to the user for sign-off, deliver acceptance criteria in batches of 3-5 and **pause for explicit ACK** (via Decision Protocol) before sending the next batch. Do not dump the full criteria wall in one message — small batches surface objections earlier and keep the sign-off meaningful. Full spec writeup still lands in `04-spec.md`, but the conversation itself must be digestible.",
|
|
34
35
|
"Require user confirmation on the written spec. **STOP.** Do NOT proceed to plan until user approves.",
|
|
35
36
|
"For each criterion, ask: how would you test this? If the answer is unclear, rewrite.",
|
|
36
37
|
"When encountering ambiguity, classify it before acting: (A) ask user for missing info, (B) enumerate interpretations and pick one with justification, (C) propose hypothesis with validation path. Do NOT silently resolve ambiguity."
|
|
@@ -40,6 +41,7 @@ export const SPEC = {
|
|
|
40
41
|
"Capture constraints, assumptions, and edge cases.",
|
|
41
42
|
"Build testability map: criterion -> test description.",
|
|
42
43
|
"Confirm testability for each criterion.",
|
|
44
|
+
"Present acceptance criteria to the user in 3-5-item batches, pausing for explicit ACK between batches (see Interaction Protocol).",
|
|
43
45
|
"Write spec artifact and request approval."
|
|
44
46
|
],
|
|
45
47
|
requiredGates: [
|