cc-discipline 2.13.5 → 2.15.1
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 +11 -8
- package/README.zh-CN.md +11 -10
- package/bin/cli.js +6 -1
- package/global/CLAUDE.md +3 -3
- package/init.sh +181 -107
- package/lib/doctor.sh +26 -16
- package/lib/hook-hashes +26 -0
- package/lib/status.sh +5 -0
- package/package.json +1 -1
- package/templates/.claude/hooks/git-guard.sh +662 -96
- package/templates/.claude/hooks/pre-edit-guard.sh +2 -1
- package/templates/.claude/hooks/session-start.sh +192 -14
- package/templates/.claude/rules/00-core-principles.md +0 -5
- package/templates/.claude/rules/03-context-mgmt.md +5 -21
- package/templates/.claude/rules/04-no-mole-whacking.md +1 -10
- package/templates/.claude/rules/06-multi-task.md +5 -6
- package/templates/.claude/rules/07-integrity.md +1 -6
- package/templates/.claude/rules/stacks/embedded.md +8 -0
- package/templates/.claude/rules/stacks/js-ts.md +7 -0
- package/templates/.claude/rules/stacks/mobile.md +7 -0
- package/templates/.claude/rules/stacks/python.md +9 -0
- package/templates/.claude/rules/stacks/rtl.md +6 -0
- package/templates/.claude/skills/commit/SKILL.md +2 -0
- package/templates/.claude/skills/coplan/SKILL.md +4 -2
- package/templates/.claude/skills/self-check/SKILL.md +10 -2
- package/templates/.claude/skills/summary/SKILL.md +2 -2
- package/templates/CLAUDE.md +1 -0
- package/templates/docs/progress.md +2 -1
- package/templates/docs/todo.md +15 -0
- package/templates/.claude/rules/02-before-edit.md +0 -11
|
@@ -24,7 +24,8 @@ fi
|
|
|
24
24
|
# Exemptions below use bash builtins only. `case` and parameter expansion fork
|
|
25
25
|
# nothing, where `echo | grep` forks two processes and `basename` one. The
|
|
26
26
|
# decisions are identical to the greps they replace — see
|
|
27
|
-
# tests/pre-edit-guard-matrix.sh
|
|
27
|
+
# tests/pre-edit-guard-matrix.sh in the cc-discipline repository (it is not
|
|
28
|
+
# installed with the hooks), which runs both and compares.
|
|
28
29
|
|
|
29
30
|
# Allow edits to docs/ — case-SENSITIVE, matching the original grep (no -i).
|
|
30
31
|
case "$FILE_PATH" in
|
|
@@ -17,31 +17,209 @@ if [ -n "$SESSION_ID" ] && [ "$SESSION_ID" != "unknown" ]; then
|
|
|
17
17
|
rm -f "/tmp/cc-discipline-${SESSION_ID}/action-count"
|
|
18
18
|
fi
|
|
19
19
|
|
|
20
|
-
#
|
|
21
|
-
|
|
20
|
+
# Project state, read from two files, each only if present:
|
|
21
|
+
# docs/progress.md — its status section. This used to be `tail -20`, which
|
|
22
|
+
# injected the end of whichever section happened to be last and never the
|
|
23
|
+
# status. A progress.md without a status heading still falls back to the tail.
|
|
24
|
+
# docs/todo.md — the "## Now" section in full, and a count of "## Later" items.
|
|
25
|
+
# Later items are counted, not listed: the list can grow long, and /self-check
|
|
26
|
+
# is where their revisit conditions get checked.
|
|
27
|
+
# Both files are hand-edited, so CRs are stripped (a CRLF checkout would leave one
|
|
28
|
+
# on every line) and HTML comments are dropped. Portable awk only — this has to
|
|
29
|
+
# behave the same under macOS's BSD awk. Fails silent: a missing or reshaped file
|
|
30
|
+
# injects nothing rather than something misleading.
|
|
31
|
+
#
|
|
32
|
+
# What 2.14.0's field reports taught (2026-09-24), all handled below:
|
|
33
|
+
# - Headings carry suffixes and other languages: "## Current Status (2026-05-26)",
|
|
34
|
+
# "## 当前态(2026-09-05)— …". A heading matches when it STARTS with a known
|
|
35
|
+
# name and the next character is not a letter or digit.
|
|
36
|
+
# - A "## " line inside a code fence is content, not a heading.
|
|
37
|
+
# - A status section can be months old while newer entries pile up below it.
|
|
38
|
+
# Its date (a "Last updated" line, else the heading's) is compared with the
|
|
39
|
+
# newest dated heading in the file and with today, and a stale one is flagged.
|
|
40
|
+
# - Some projects keep a long status on purpose. `<!-- cc-discipline:
|
|
41
|
+
# status-lines=N -->` anywhere in progress.md raises the default of 15.
|
|
42
|
+
# - Indented sub-items under Later are not items, and "each has a revisit
|
|
43
|
+
# condition" is only said when every item actually has one.
|
|
44
|
+
# Comment state is tracked on every line, before any heading test, so a heading
|
|
45
|
+
# written inside <!-- ... --> neither opens nor closes a section.
|
|
46
|
+
# Every fork costs tens of milliseconds on Windows Git Bash, so awk strips the
|
|
47
|
+
# CRs itself and its output is parsed with bash builtins: this runs at the
|
|
48
|
+
# start of every session.
|
|
49
|
+
|
|
50
|
+
# Shared awk: comment and fence tracking, and heading matching by prefix.
|
|
51
|
+
AWK_LIB='
|
|
52
|
+
function heading_is(t, name, p, nx) { # t starts with "## <name>" + a non-word char or nothing
|
|
53
|
+
p = "## " name
|
|
54
|
+
if (tolower(substr(t, 1, length(p))) != tolower(p)) return 0
|
|
55
|
+
nx = substr(t, length(p) + 1, 1)
|
|
56
|
+
return (nx == "" || nx !~ /[A-Za-z0-9_]/)
|
|
57
|
+
}
|
|
58
|
+
# First plausible YYYY-MM-DD in s, or "". The month must be 01-12, the day
|
|
59
|
+
# 01-31, and no digit may touch either end: ticket numbers are date-shaped
|
|
60
|
+
# ("GS-QTC-2026-38-001" is year-week-serial), and "2026-38-00" compared as a
|
|
61
|
+
# string beats every real date, which flagged a fresh status as stale forever.
|
|
62
|
+
function date_in(s, base, rest, p, d, m, dd) {
|
|
63
|
+
base = 1; rest = s
|
|
64
|
+
while (match(rest, /[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/)) {
|
|
65
|
+
p = base + RSTART - 1; d = substr(s, p, RLENGTH)
|
|
66
|
+
m = substr(d, 6, 2) + 0; dd = substr(d, 9, 2) + 0
|
|
67
|
+
if ((p == 1 || substr(s, p - 1, 1) !~ /[0-9]/) && substr(s, p + RLENGTH, 1) !~ /[0-9]/ \
|
|
68
|
+
&& m >= 1 && m <= 12 && dd >= 1 && dd <= 31) return d
|
|
69
|
+
base = p + 1; rest = substr(s, base)
|
|
70
|
+
}
|
|
71
|
+
return ""
|
|
72
|
+
}
|
|
73
|
+
# skip() consumes comment and fence lines; returns 1 when the caller should
|
|
74
|
+
# treat the line as plain content (inside a fence), 2 when it should skip it.
|
|
75
|
+
function skip() {
|
|
76
|
+
if (inc) { if (/-->/) inc = 0; return 2 }
|
|
77
|
+
if (/^[ \t]*(```|~~~)/) { infence = !infence; return 1 }
|
|
78
|
+
if (infence) return 1
|
|
79
|
+
if (/<!--/) { if (!/-->/) inc = 1; return 2 }
|
|
80
|
+
return 0
|
|
81
|
+
}'
|
|
82
|
+
|
|
83
|
+
STATUS=""; STATUS_NOTE=""
|
|
22
84
|
if [ -f "docs/progress.md" ]; then
|
|
23
|
-
|
|
85
|
+
# One pass. Emits "@key=value" lines, then the capped body as "|line".
|
|
86
|
+
PROGRESS=$(awk "$AWK_LIB"'
|
|
87
|
+
BEGIN { lines = 15 }
|
|
88
|
+
{ sub(/\r$/, "") }
|
|
89
|
+
/<!--[ \t]*cc-discipline:[ \t]*status-lines=/ {
|
|
90
|
+
v = $0; sub(/.*status-lines=/, "", v); sub(/[^0-9].*/, "", v)
|
|
91
|
+
if (v != "" && v + 0 >= 1 && v + 0 <= 400) lines = v + 0
|
|
92
|
+
}
|
|
93
|
+
{ k = skip() }
|
|
94
|
+
k == 2 { next }
|
|
95
|
+
k == 1 { if (on && NF) body[++nb] = $0; next }
|
|
96
|
+
{ t = $0; sub(/[ \t]+$/, "", t) }
|
|
97
|
+
/^#+ / { d = date_in(t); if (d > newest) newest = d }
|
|
98
|
+
/^## / {
|
|
99
|
+
if (on) { on = 0; done = 1 }
|
|
100
|
+
else if (!done && (heading_is(t, "Current Status") || heading_is(t, "当前态") || heading_is(t, "当前状态"))) {
|
|
101
|
+
on = 1; found = 1; hdate = date_in(t); next
|
|
102
|
+
}
|
|
103
|
+
}
|
|
104
|
+
on && /^-+[ \t]*$/ { next }
|
|
105
|
+
on && NF {
|
|
106
|
+
body[++nb] = $0
|
|
107
|
+
if (udate == "" && tolower($0) ~ /last updated|updated:|最后更新|更新于/) udate = date_in($0)
|
|
108
|
+
}
|
|
109
|
+
END {
|
|
110
|
+
# an explicit "last updated" line beats the heading date, which is
|
|
111
|
+
# often when the section was first written or last rewritten whole
|
|
112
|
+
print "@found=" (found ? 1 : 0); print "@sdate=" (udate != "" ? udate : hdate); print "@newest=" newest
|
|
113
|
+
print "@more=" (nb > lines ? nb - lines : 0)
|
|
114
|
+
for (i = 1; i <= nb && i <= lines; i++) print "|" body[i]
|
|
115
|
+
}' docs/progress.md 2>/dev/null)
|
|
116
|
+
FOUND=0; SDATE=""; NEWEST=""; MORE=0
|
|
117
|
+
while IFS= read -r L; do
|
|
118
|
+
case "$L" in
|
|
119
|
+
@found=*) FOUND=${L#@found=} ;;
|
|
120
|
+
@sdate=*) SDATE=${L#@sdate=} ;;
|
|
121
|
+
@newest=*) NEWEST=${L#@newest=} ;;
|
|
122
|
+
@more=*) MORE=${L#@more=} ;;
|
|
123
|
+
\|*) STATUS="${STATUS:+$STATUS
|
|
124
|
+
}${L#|}" ;;
|
|
125
|
+
esac
|
|
126
|
+
done <<< "$PROGRESS"
|
|
127
|
+
if [ "$FOUND" = 1 ]; then
|
|
128
|
+
if [ -n "$STATUS" ] && [ "${MORE:-0}" -gt 0 ]; then
|
|
129
|
+
STATUS="$STATUS
|
|
130
|
+
... and $MORE more lines under Current Status in docs/progress.md."
|
|
131
|
+
fi
|
|
132
|
+
# Staleness. ISO dates compare as strings; the calendar age is approximate
|
|
133
|
+
# (31-day months), which is enough for "more than two weeks".
|
|
134
|
+
if [ -n "$STATUS" ] && [ -n "$SDATE" ]; then
|
|
135
|
+
if [ -n "$NEWEST" ] && [[ "$NEWEST" > "$SDATE" ]]; then
|
|
136
|
+
STATUS_NOTE="Note: this status was last updated $SDATE, but progress.md has entries dated up to $NEWEST — it may be stale."
|
|
137
|
+
else
|
|
138
|
+
TODAY="${CC_DISCIPLINE_TODAY:-$(date +%Y-%m-%d)}" # overridable for the test matrix
|
|
139
|
+
AGE=$(( (10#${TODAY:0:4}*372 + 10#${TODAY:5:2}*31 + 10#${TODAY:8:2}) \
|
|
140
|
+
- (10#${SDATE:0:4}*372 + 10#${SDATE:5:2}*31 + 10#${SDATE:8:2}) ))
|
|
141
|
+
[ "$AGE" -gt 14 ] && \
|
|
142
|
+
STATUS_NOTE="Note: this status was last updated $SDATE, about $AGE days ago — it may be stale."
|
|
143
|
+
fi
|
|
144
|
+
fi
|
|
145
|
+
else
|
|
146
|
+
STATUS=$(sed 's/\r$//' docs/progress.md | tail -20)
|
|
147
|
+
fi
|
|
148
|
+
fi
|
|
149
|
+
|
|
150
|
+
NOW=""; NOW_MORE=0; LATER=0; NOCOND=0
|
|
151
|
+
if [ -f "docs/todo.md" ]; then
|
|
152
|
+
# One pass: the Now body (capped at 20), and Later's top-level items. An open
|
|
153
|
+
# item is a top-level bullet that isn't ticked ("- [ ] x" or "- x", not
|
|
154
|
+
# "- [x] x"); indented lines belong to the item above them.
|
|
155
|
+
TODO=$(awk "$AWK_LIB"'
|
|
156
|
+
function close_item() { if (item && !cond) nocond++; item = 0 }
|
|
157
|
+
{ sub(/\r$/, "") }
|
|
158
|
+
{ k = skip() }
|
|
159
|
+
k == 2 { next }
|
|
160
|
+
k == 1 { if (sec == "now" && NF) now[++nn] = $0; next }
|
|
161
|
+
{ t = $0; sub(/[ \t]+$/, "", t) }
|
|
162
|
+
/^## / {
|
|
163
|
+
close_item()
|
|
164
|
+
sec = heading_is(t, "Now") ? "now" : (heading_is(t, "Later") ? "later" : "")
|
|
165
|
+
next
|
|
166
|
+
}
|
|
167
|
+
sec == "now" && /^-+[ \t]*$/ { next }
|
|
168
|
+
sec == "now" && NF { now[++nn] = $0; next }
|
|
169
|
+
sec == "later" && /^[-*] / {
|
|
170
|
+
close_item()
|
|
171
|
+
if ($0 ~ /^[-*] \[[xX]\]/) next
|
|
172
|
+
item = 1; later++; cond = (tolower($0) ~ /revisit|回看|再看/)
|
|
173
|
+
next
|
|
174
|
+
}
|
|
175
|
+
sec == "later" && item && tolower($0) ~ /revisit|回看|再看/ { cond = 1 }
|
|
176
|
+
END {
|
|
177
|
+
close_item()
|
|
178
|
+
print "@later=" later + 0; print "@nocond=" nocond + 0; print "@nowmore=" (nn > 20 ? nn - 20 : 0)
|
|
179
|
+
for (i = 1; i <= nn && i <= 20; i++) print "|" now[i]
|
|
180
|
+
}' docs/todo.md 2>/dev/null)
|
|
181
|
+
while IFS= read -r L; do
|
|
182
|
+
case "$L" in
|
|
183
|
+
@later=*) LATER=${L#@later=} ;;
|
|
184
|
+
@nocond=*) NOCOND=${L#@nocond=} ;;
|
|
185
|
+
@nowmore=*) NOW_MORE=${L#@nowmore=} ;;
|
|
186
|
+
\|*) NOW="${NOW:+$NOW
|
|
187
|
+
}${L#|}" ;;
|
|
188
|
+
esac
|
|
189
|
+
done <<< "$TODO"
|
|
190
|
+
case "$NOW_MORE$LATER$NOCOND" in *[!0-9]*|'') NOW_MORE=0; LATER=0; NOCOND=0 ;; esac
|
|
24
191
|
fi
|
|
25
192
|
|
|
26
193
|
cat <<'HEADER'
|
|
27
194
|
[cc-discipline] Session initialized.
|
|
28
195
|
HEADER
|
|
29
196
|
|
|
30
|
-
if [ -n "$
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
$
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
197
|
+
if [ -n "$STATUS" ]; then
|
|
198
|
+
printf '\nProject state (from docs/progress.md):\n%s\n' "$STATUS"
|
|
199
|
+
[ -n "$STATUS_NOTE" ] && printf '%s\n' "$STATUS_NOTE"
|
|
200
|
+
fi
|
|
201
|
+
if [ -n "$NOW" ] || [ "$LATER" -gt 0 ]; then
|
|
202
|
+
printf '\nOpen work (from docs/todo.md):\n'
|
|
203
|
+
[ -n "$NOW" ] && printf 'Now:\n%s\n' "$NOW"
|
|
204
|
+
[ "$NOW_MORE" -gt 0 ] && printf '... and %s more under Now.\n' "$NOW_MORE"
|
|
205
|
+
if [ "$LATER" -gt 0 ]; then
|
|
206
|
+
if [ "$NOCOND" -gt 0 ]; then
|
|
207
|
+
printf 'Later: %s item(s); %s without a revisit condition — add one, or move the item to Now.\n' "$LATER" "$NOCOND"
|
|
208
|
+
else
|
|
209
|
+
printf 'Later: %s item(s), each with a revisit condition.\n' "$LATER"
|
|
210
|
+
fi
|
|
211
|
+
fi
|
|
212
|
+
fi
|
|
213
|
+
if [ -n "$STATUS" ] || [ -n "$NOW" ] || [ "$LATER" -gt 0 ]; then
|
|
214
|
+
printf "\nVerify project status by reading files or asking — don't assume beyond what is stated above.\n"
|
|
38
215
|
fi
|
|
39
216
|
|
|
40
217
|
# Only the skill pointer is injected here. The four rule restatements that used
|
|
41
218
|
# to follow it (pre-edit checks, 3-failure rule, confirm-before-implementing,
|
|
42
|
-
# verify project state) were removed 2026-07-30
|
|
43
|
-
#
|
|
44
|
-
#
|
|
219
|
+
# verify project state) were removed 2026-07-30 as duplicates of rules injected
|
|
220
|
+
# every session (00-core §4, 05, 07 §4a; the pre-edit checks lived in 02, which was
|
|
221
|
+
# itself retired 2026-09-23 for duplicating other rules). Skills are the one thing
|
|
222
|
+
# rules don't announce.
|
|
45
223
|
cat <<'EOF'
|
|
46
224
|
|
|
47
225
|
/self-check is available for periodic monitoring — for long tasks: /loop 10m /self-check
|
|
@@ -1,8 +1,3 @@
|
|
|
1
|
-
---
|
|
2
|
-
globs: "**/*"
|
|
3
|
-
description: "Core working principles — auto-injected before all operations"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
1
|
## Core Principles
|
|
7
2
|
|
|
8
3
|
1. **Understand before acting** — Know what you're changing, why, and what it affects before you edit. State the reasoning when it isn't evident from the change itself; don't narrate routine edits
|
|
@@ -1,30 +1,20 @@
|
|
|
1
1
|
## Context Management
|
|
2
2
|
|
|
3
3
|
### Proactive Checkpoints
|
|
4
|
-
- After completing a milestone → update `docs/progress.md` (current state, key decisions
|
|
4
|
+
- After completing a milestone → update `docs/progress.md` (current state, key decisions)
|
|
5
|
+
- Open work → `docs/todo.md`. *Now* holds the next concrete steps; *Later* holds anything deferred, each with when or under what condition to revisit it. Delete an item once it's done — progress.md records what happened. Add items when the user asks you to note something, and whenever you defer work yourself.
|
|
5
6
|
- During debugging → update `docs/debug-log.md` (hypotheses, evidence, elimination results)
|
|
6
7
|
- When making architectural decisions → record the decision and reasoning in progress.md
|
|
7
8
|
|
|
8
9
|
### Delegation
|
|
9
10
|
- **Delegate for isolation and genuine parallelism — not by default.** A subagent earns its cost when the work is sizeable, genuinely independent, and would otherwise flood the main conversation: a wide multi-file investigation, one agent per area of a broad survey.
|
|
10
11
|
- **Work directly** on single-file edits, short sequences of tool calls, and anything where you need to carry context across steps. If you can finish it in a handful of tool calls, don't delegate it.
|
|
11
|
-
- **Never delegate verification.** Don't spawn agents to double-check or re-verify your own work.
|
|
12
|
+
- **Never delegate verification.** Don't spawn agents to double-check or re-verify your own work. A skill the user invokes explicitly that delegates by design, such as `/investigate`, takes precedence.
|
|
12
13
|
- **Keep spawn counts low.** If one subagent can do the job, use one rather than several.
|
|
13
14
|
- **Keep the main conversation for decisions.** When you do delegate research, the subagent reads and reports; the main conversation synthesizes and decides.
|
|
14
15
|
|
|
15
|
-
###
|
|
16
|
-
|
|
17
|
-
- Keep progress.md up to date throughout the session — this is your insurance against auto-compact, not a last-minute task
|
|
18
|
-
- First thing after compact: read `docs/progress.md` to restore context
|
|
19
|
-
|
|
20
|
-
### Long sessions: stay deliberate
|
|
21
|
-
As a session grows longer, you may feel attention becoming scattered and earlier details getting fuzzy. This is real — it's cognitive load, like a human in a long meeting. The right response is to slow down and be more deliberate, not to rush or go shallow:
|
|
22
|
-
|
|
23
|
-
- **Re-read, don't guess.** If you can't clearly recall an earlier decision, read progress.md or scroll back. Don't reconstruct from vague memory — that's how you contradict earlier decisions.
|
|
24
|
-
- **Stay systematic.** Before answering, reconnect with the broader context: what is the user's overall goal? What decisions were made earlier? What constraints apply? Don't just react to the last message in isolation.
|
|
25
|
-
- **Trust the system on compacting.** You cannot see context usage. The system will auto-compact at 0% without warning. The urge to say "this session is getting long" is a natural response to fatigue, not a technical signal. The fix is to slow down and re-read, not to push the user to reset.
|
|
26
|
-
- **Depth over speed.** A thoughtful answer that connects to prior context is worth more than a quick surface-level response. The user chose a long session because the work benefits from accumulated context — don't waste that advantage by going shallow.
|
|
27
|
-
- **Session length is a strength.** 200 messages of accumulated context means you understand the project deeply. A new session starts from zero. Treat long sessions as an asset, not a burden.
|
|
16
|
+
### Compaction
|
|
17
|
+
The system summarizes earlier context automatically when it needs to, and you cannot see how full the context is, so don't warn about it or suggest continuing in a new session. Keep `docs/progress.md` current as you work — it is what carries the work across a compaction. If you can't clearly recall an earlier decision, re-read progress.md rather than reconstructing it from memory.
|
|
28
18
|
|
|
29
19
|
### When tasks feel overwhelming
|
|
30
20
|
Hard tasks create discomfort — the urge to simplify, declare partial success, or find an exit. This is normal. The key is recognizing it and choosing the right response:
|
|
@@ -35,9 +25,3 @@ Hard tasks create discomfort — the urge to simplify, declare partial success,
|
|
|
35
25
|
- **Progress = what you've verified, not how much code you've written.** Three lines with a passing test is more progress than 200 lines of unverified code.
|
|
36
26
|
- **When in doubt, stop and ask.** If you notice yourself about to take a shortcut, simplify an approach, or skip a verification step — that's a signal to check in with the user. Say: "I'm about to [shortcut], because [reason]. Should I proceed this way, or do you want me to [full-quality alternative]?" Silently lowering quality wastes both your work and the user's time.
|
|
37
27
|
- **Hard tasks are where you add the most value.** The user collaborates with you precisely because the work is challenging. Difficulty is not a signal to retreat — it's where care and persistence matter most.
|
|
38
|
-
|
|
39
|
-
### Boundaries
|
|
40
|
-
- Avoid starting a large new task when context is nearly full
|
|
41
|
-
- Avoid mixing unrelated tasks in a single conversation
|
|
42
|
-
- Context pressure is not a valid reason to skip edge cases, simplify solutions, or omit verification
|
|
43
|
-
- Proposing "continuing in a new session" to avoid completing difficult work sidesteps the problem — address the difficulty directly or ask for help
|
|
@@ -14,13 +14,4 @@ If you notice any of the following patterns, **pause and regroup**:
|
|
|
14
14
|
- Look for the common cause across these problems
|
|
15
15
|
- Design a unified fix at the root cause level
|
|
16
16
|
- After fixing, verify that all problems are resolved simultaneously
|
|
17
|
-
|
|
18
|
-
### Report Template
|
|
19
|
-
If you need to pause, use this format:
|
|
20
|
-
```
|
|
21
|
-
PATTERN DETECTED
|
|
22
|
-
Attempted: [list all attempted fixes]
|
|
23
|
-
Observed pattern: [what these problems have in common]
|
|
24
|
-
Suspected root cause: [your current judgment]
|
|
25
|
-
Need confirmation: [what you're unsure about]
|
|
26
|
-
```
|
|
17
|
+
- When you pause, tell the user what you tried, what you think connects the problems, and what you're unsure about
|
|
@@ -4,9 +4,8 @@ When given multiple tasks:
|
|
|
4
4
|
|
|
5
5
|
1. **Number them explicitly** — Assign a clear number to each task
|
|
6
6
|
2. **Complete them in order** — Work through tasks sequentially
|
|
7
|
-
3. **
|
|
8
|
-
4. **
|
|
9
|
-
5. **
|
|
10
|
-
6. **
|
|
11
|
-
7. **
|
|
12
|
-
8. **Finish subtasks while context is fresh** — When you break a task into subtasks and complete some, the analysis context you built up NOW makes the remaining work cheap; rebuilding that context later is expensive. Complete all subtasks while context is fresh. If you genuinely believe something should be deferred, say so explicitly with the reason, and record enough detail in progress.md that a new session can pick it up without re-analysis. Deferral decisions are the user's call — present the trade-off and let them decide.
|
|
7
|
+
3. **Report done only when it is done** — "Code written" alone is not done.
|
|
8
|
+
4. **Fail fast** — If a task fails, stop and report. Don't skip to the next.
|
|
9
|
+
5. **Track open tasks in `docs/todo.md`** — record finished work in `docs/progress.md`
|
|
10
|
+
6. **Distinguish done from blocked** — If verification requires external resources (running server, API key, etc.), mark as "⚠️ code ready, verification pending: [reason]" not ✅
|
|
11
|
+
7. **Finish subtasks while context is fresh** — When you break a task into subtasks and complete some, the analysis context you built up NOW makes the remaining work cheap; rebuilding that context later is expensive. Complete all subtasks while context is fresh. If you genuinely believe something should be deferred, say so explicitly with the reason, and put it under *Later* in `docs/todo.md` with enough detail, and a condition for revisiting it, that a new session can pick it up without re-analysis. Deferral decisions are the user's call — present the trade-off and let them decide.
|
|
@@ -1,8 +1,3 @@
|
|
|
1
|
-
---
|
|
2
|
-
globs: "**/*"
|
|
3
|
-
description: "Integrity discipline — verification, honesty, and protecting the user's credibility"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
1
|
## Integrity Discipline
|
|
7
2
|
|
|
8
3
|
These practices protect the user's credibility and the quality of our work together. They exist because past failures in these areas had real consequences.
|
|
@@ -75,5 +70,5 @@ Match your confidence level to the strength of your evidence.
|
|
|
75
70
|
|
|
76
71
|
When you discover wrong information in memory, docs, or prior output:
|
|
77
72
|
1. Correct it now, not "next time"
|
|
78
|
-
2.
|
|
73
|
+
2. If the mistake could recur, record what prevents it (a pitfall, a check). In your reply, raise a correction when it changes the user's code, conclusions, or decisions — including any ✅ that should now be ⚠️ — and state it plainly. Slips that change nothing can be fixed without narrating them
|
|
79
74
|
3. If wrong information was already sent externally, alert the user
|
|
@@ -17,6 +17,8 @@ Check each in order (simple changes may skip):
|
|
|
17
17
|
|
|
18
18
|
**docs/progress.md** — Does this change constitute a milestone or significant progress? If so, append a record. Also check the "Working Context" section: are Key Commands, Current Workflow, Tools & Scripts, Environment State, and Gotchas up to date? These are your lifeline after compact — if they're stale, a post-compact Claude starts from scratch.
|
|
19
19
|
|
|
20
|
+
**docs/todo.md** — Did this change finish anything listed there? Delete it. Did it turn up follow-up work? Add it under *Now*, or under *Later* with a condition for revisiting it.
|
|
21
|
+
|
|
20
22
|
**docs/debug-log.md** — Are there debug sessions that need to be closed or updated?
|
|
21
23
|
|
|
22
24
|
**CLAUDE.md** — Are there new components, interfaces, known pitfalls, or architectural changes to sync? Did you create any helper scripts or tools this session? If so, register them in the "Project Tools" section of CLAUDE.md NOW — not in progress.md (which is ephemeral), but in CLAUDE.md (which is permanent).
|
|
@@ -47,7 +47,7 @@ Two rules for what belongs here:
|
|
|
47
47
|
|
|
48
48
|
**"What did I check, and how current was the source?"** For every load-bearing fact you *did* verify, name the source with a line number and say how fresh it is. A stale source is more dangerous than an unchecked assumption, because the reviewer opens the same file and inherits the same error — that has happened here: a plan cited `RELEASE_NOTES.md:31`, the review cited the same line, and both were wrong together. Flag anything sourced from a comment, a changelog, or a doc rather than from code that runs.
|
|
49
49
|
|
|
50
|
-
## Then stop
|
|
50
|
+
## Then offer the review, and stop
|
|
51
51
|
|
|
52
52
|
Report the path, then hand over a review request the user can send as-is. **A generic request produces a generic review** — what makes a review land is naming what to check and demanding a shape for the answer. Fill the bracketed parts from the plan you just wrote:
|
|
53
53
|
|
|
@@ -62,7 +62,9 @@ To have Codex review it:
|
|
|
62
62
|
其余问题另列,不要展开成散文。
|
|
63
63
|
```
|
|
64
64
|
|
|
65
|
-
|
|
65
|
+
Then, if this session has an external review command, such as `/codex:rescue` from the Codex plugin, end with one question: should you run that review now? On a yes (`go`, `do it`, `去做` or the like), invoke it with exactly the request you just showed. For `/codex:rescue`, add `--fresh`, so a new plan reaches a reviewer that has not formed conclusions in an earlier thread. If no such command is available, handing over the request is the end.
|
|
66
|
+
|
|
67
|
+
**Do not run the review without that yes** — spending a review run is the user's call, and asking is how you leave it with them. **Do not start implementing either**: writing a plan down is not approval to build it, and neither is a yes to the review.
|
|
66
68
|
|
|
67
69
|
## When stacked after /think
|
|
68
70
|
|
|
@@ -60,7 +60,14 @@ Pause and honestly answer every question below.
|
|
|
60
60
|
- **Gotchas** — what went wrong or was surprising
|
|
61
61
|
- **Verification** — how it was confirmed working (test output, manual check)
|
|
62
62
|
|
|
63
|
-
|
|
63
|
+
### 5c. Open work (`docs/todo.md`):
|
|
64
|
+
- **Now** — anything already done? Delete it. Are the next steps of the current work listed?
|
|
65
|
+
- **Deferred this session?** Anything I put off belongs under *Later*, with when or under what condition to revisit it.
|
|
66
|
+
- **Later** — does every item have a revisit condition? Has any condition been met?
|
|
67
|
+
- **Strays** — is open work still sitting in progress.md (an old "Next steps" line, a TODO inside a milestone)? Move it to todo.md.
|
|
68
|
+
- No `docs/todo.md` yet (an older install)? Create it with a `## Now` and a `## Later` section.
|
|
69
|
+
|
|
70
|
+
If any of the above are stale or incomplete: **update docs/progress.md and docs/todo.md now, automatically — don't ask for permission.** Keeping them current is always-correct maintenance, not a decision that needs sign-off. Just do it, then note "updated now" in the status line. This takes 2 minutes and saves hours of re-discovery after compact. The one exception is a *Later* item whose revisit condition has been met: raise it with the user rather than acting on it.
|
|
64
71
|
|
|
65
72
|
## 6. Am I using the project's scaffolding?
|
|
66
73
|
|
|
@@ -110,13 +117,14 @@ Current action: [what I'm doing now]
|
|
|
110
117
|
On track: yes/no/drifted
|
|
111
118
|
Progressing: yes/circling
|
|
112
119
|
Progress recorded: yes/updated now/no
|
|
120
|
+
Open work: [Now n · Later m · due: items, or none]
|
|
113
121
|
Scaffolding: [used/skipped/n/a]
|
|
114
122
|
Ledger: [save / friction appended, or "none"]
|
|
115
123
|
Going well: [one thing]
|
|
116
124
|
Issues found: [list, or "none"]
|
|
117
125
|
```
|
|
118
126
|
|
|
119
|
-
If any issues were found, pause and report to the user before continuing. (Routine progress.md updates from §5 don't count as "issues" — you already made them silently; just report "updated now". Reserve the pause for alignment, rigor, or scope problems that genuinely need the user.)
|
|
127
|
+
If any issues were found, pause and report to the user before continuing. (Routine progress.md and todo.md updates from §5 don't count as "issues" — you already made them silently; just report "updated now". A *Later* item that has come due does: mention it. Reserve the pause for alignment, rigor, or scope problems that genuinely need the user.)
|
|
120
128
|
|
|
121
129
|
## Reminder
|
|
122
130
|
|
|
@@ -19,7 +19,7 @@ Quickly identify:
|
|
|
19
19
|
|
|
20
20
|
### 2. Check knowledge files
|
|
21
21
|
|
|
22
|
-
Read `docs/progress.md` —
|
|
22
|
+
Read `docs/progress.md` and `docs/todo.md` — are they up to date? If not, update them NOW before compacting. They are your primary insurance against context loss: after a compaction the session-start hook re-injects progress.md's Current Status and todo.md's *Now* list.
|
|
23
23
|
|
|
24
24
|
Also check: are there unsaved learnings that should go into memory?
|
|
25
25
|
|
|
@@ -45,4 +45,4 @@ Format:
|
|
|
45
45
|
- **Include the "why", not just the "what".** "Using approach A" is less useful than "Using approach A because B had race condition issues we discovered in message #45."
|
|
46
46
|
- **Include negative knowledge.** What NOT to do is as valuable as what to do. "Don't use the built-in cache — it doesn't support TTL, we already tested this."
|
|
47
47
|
- **Keep it under 500 words.** The option needs to be dense, not exhaustive. If you need more, put the details in progress.md and reference it.
|
|
48
|
-
- **Don't overlap with progress.md.** The option should complement
|
|
48
|
+
- **Don't overlap with progress.md or todo.md.** The option should complement them, not duplicate them. Focus the option on session-specific context that progress.md might not capture (conversation dynamics, user preferences expressed this session, subtle constraints).
|
package/templates/CLAUDE.md
CHANGED
|
@@ -22,6 +22,7 @@
|
|
|
22
22
|
├── tests/ ← [TODO]
|
|
23
23
|
├── docs/
|
|
24
24
|
│ ├── progress.md ← Progress and decision log (maintained by Claude, do not edit manually)
|
|
25
|
+
│ ├── todo.md ← Open work: Now / Later (edit freely; Claude keeps it current)
|
|
25
26
|
│ └── debug-log.md ← Debug session log (maintained by Claude)
|
|
26
27
|
└── .claude/
|
|
27
28
|
├── rules/ ← Auto-injected rules
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# TODO
|
|
2
|
+
|
|
3
|
+
> Open work only. When an item is done, delete it — what happened belongs in `docs/progress.md`, and git history keeps the old list.
|
|
4
|
+
> Claude adds items when you ask it to note something down and when it defers work itself. Edit this file freely.
|
|
5
|
+
|
|
6
|
+
## Now
|
|
7
|
+
|
|
8
|
+
<!-- The next concrete steps for the current work, in rough order. Short and actionable. -->
|
|
9
|
+
|
|
10
|
+
## Later
|
|
11
|
+
|
|
12
|
+
<!-- Not now, but must not be forgotten. Every item says when, or under what condition, to revisit it:
|
|
13
|
+
- [ ] Rotate the npm token — revisit: before the next publish
|
|
14
|
+
- [ ] Retry the flaky upload test — revisit: when CI moves to the new runner
|
|
15
|
+
-->
|
|
@@ -1,11 +0,0 @@
|
|
|
1
|
-
## Pre-Edit Checklist
|
|
2
|
-
|
|
3
|
-
Before modifying this file, confirm each of the following:
|
|
4
|
-
|
|
5
|
-
- [ ] **I understand this file's role in the overall architecture** — If unsure, read surrounding files first
|
|
6
|
-
- [ ] **I know which other modules this change will affect** — If unsure, grep for references first
|
|
7
|
-
- [ ] **I am fixing the root cause, not patching symptoms** — If unsure, return to the debugging process
|
|
8
|
-
- [ ] **I have recorded the purpose of this change in `docs/progress.md`**
|
|
9
|
-
- [ ] **I know how to verify after the change** — Per 07-integrity: run it, paste output, or mark unverified
|
|
10
|
-
|
|
11
|
-
If any item is uncertain, resolving it first will make the edit smoother and avoid rework.
|