cc-discipline 2.12.3 → 2.13.0

package/README.md

@@ -17,9 +17,11 @@ Markdown rules help, but Claude can ignore them. **Hooks can't be ignored** —
 
 ### Hooks (the enforcer)
 
-Three shell scripts that run automatically before/after Claude's actions:
+Seven shell scripts run automatically before and after Claude's actions. Two of them can stop an operation outright — `git-guard.sh` on destructive git commands, and `streak-breaker.sh` once a file passes its edit ceiling. The rest inject context rather than block. The three below are the ones worth seeing in action:
 
-**`streak-breaker.sh`** — Tracks per-file edit counts. Warns at 3, **hard-blocks at 5**. Forces Claude to stop and find the root cause instead of endlessly patching.
+**`streak-breaker.sh`** — Tracks per-file edit counts. Source files warn at 6 and **hard-block at 10**; config and docs warn at 10 and block at 16. Confirming that a run of edits is planned doubles both thresholds for that file. Forces Claude to stop and find the root cause instead of endlessly patching.
+
+> Raised from 3/5 on 2026-07-30. Newer models complete multi-file features end to end rather than one pass per file, so five edits to one source file is now common in legitimate work — the old thresholds fired on progress, not on circling.
 
 Here's what it looks like in practice:
 
@@ -34,25 +36,26 @@ Claude: The regex wasn't enough, let me also add length check.
 
 Claude: That broke the existing tests, let me adjust.
         [Edit src/auth.py — fix test compatibility]
-        ⚠️ EDIT NOTE: File src/auth.py has been edited 3 times.
+        ⚠️ EDIT NOTE: File src/auth.py has been edited 6 times.
         Quick check: are these edits building toward a goal,
         or fixing previous edits?
 
 Claude: Let me try a different approach to the validation.
         [Edit src/auth.py — rewrite validation layer]
+        [… three more edits …]
 
 Claude: Almost there, one more adjustment...
         [Edit src/auth.py — blocked]
 
         🛑 EDIT CHECKPOINT
-        File src/auth.py has been edited 5 times this session.
+        File src/auth.py has been edited 10 times this session.
         Reflect:
           1. Are these edits progressing toward a goal,
              or fixing previous edits?
           2. If fixing previous edits: pause and look
              for the root cause.
 
-Claude: You're right. Looking at all 5 edits, I was patching
+Claude: You're right. Looking at all 10 edits, I was patching
         symptoms. The real issue is that the User model's
         validate() method is called before sanitization.
         Let me fix it at the source instead.
@@ -62,7 +65,9 @@ Without the hook, Claude would keep editing `auth.py` indefinitely — each fix
 
 ---
 
-**`pre-edit-guard.sh`** — Checks `docs/debug-log.md` for unverified hypotheses. If you're debugging and haven't finished the process, it blocks source code edits until you do.
+**`pre-edit-guard.sh`** — Before a source edit, checks `docs/debug-log.md` for hypotheses still marked pending, flags unusually large diffs, and reminds you to register newly created scripts. These are context notes, not blocks.
+
+> Downgraded from a hard block on 2026-07-30. Combined with the debugging rules it had become a trap: write three hypotheses into the log as the rules ask, and you were then barred from editing source until three were confirmed — including for unrelated planned work. The hypothesis discipline stays in the rules; only the enforcement was relaxed.
 
 ```
 You:   "The API is returning 500 errors on /users endpoint"
@@ -73,11 +78,12 @@ Claude: Let me investigate.
 
 Claude: I think it's a database connection issue. Let me fix
         the connection pool config.
-        [Edit src/db.py — blocked]
+        [Edit src/db.py]
 
-        🛑 docs/debug-log.md has 2 unverified hypotheses.
-        Please complete the debugging process (verify or
-        eliminate hypotheses) before editing source code.
+        DEBUG-LOG NOTE: docs/debug-log.md has 2 hypotheses
+        still marked pending. If this edit is the fix for one
+        of them, update its status first so the log stays
+        truthful. If this edit is unrelated work, carry on.
 
 Claude: Right, I haven't verified my hypothesis yet.
         Let me check the actual error logs first.
@@ -188,8 +194,9 @@ CLAUDE.md                     # Your project info (you fill this in)
 
 ```bash
 # In .claude/hooks/streak-breaker.sh
-WARN_THRESHOLD=3    # Warn after N edits to same file
-STOP_THRESHOLD=5    # Hard block after N edits
+WARN_THRESHOLD=6     # Warn after N edits to same source file
+STOP_THRESHOLD=10    # Hard block after N edits
+# Config and doc files use 10/16; a confirmed run doubles both
 ```
 
 **Add your own rules:**

package/README.zh-CN.md

@@ -84,7 +84,7 @@ your-project/
 │   │       └── mobile.md              #   移动端
 │   ├── hooks/
 │   │   ├── pre-edit-guard.sh          # 编辑前纪律检查
-│   │   ├── streak-breaker.sh          # 打地鼠检测（同文件编辑≥5次硬停止）
+│   │   ├── streak-breaker.sh          # 打地鼠检测（源码同文件编辑≥10次硬停止）
 │   │   └── post-error-remind.sh       # 错误后调试流程提醒
 │   ├── agents/
 │   │   ├── reviewer.md                # 代码审查员（独立 context）
@@ -127,8 +127,8 @@ Hooks 是在 Claude 执行操作前/后自动运行的 shell 脚本。**exit 2
 
 | Hook | 触发时机 | 作用 |
 |------|---------|------|
-| `streak-breaker.sh` | 编辑文件前 | 同文件编辑 ≥3 次警告，≥5 次硬停止 |
-| `pre-edit-guard.sh` | 编辑文件前 | 检查是否有未完成的调试流程 |
+| `streak-breaker.sh` | 编辑文件前 | 源码同文件编辑 ≥6 次警告、**≥10 次硬停止**；配置与文档为 10 / 16。用户确认为计划内改动后，两个阈值翻倍 |
+| `pre-edit-guard.sh` | 编辑文件前 | 检查 debug-log 中仍标 pending 的假设、超大 diff、新建脚本 —— **均为上下文提示，不阻断**（2026-07-30 从硬阻断降级） |
 | `post-error-remind.sh` | 执行命令后 | 检测到错误输出时提醒遵守调试纪律 |
 
 **实际效果演示：**
@@ -146,22 +146,23 @@ Claude: 正则不够，再加个长度检查。
 
 Claude: 把之前的测试搞挂了，调整一下。
         [编辑 src/auth.py — 修复测试兼容性]
-        ⚠️ 提示：auth.py 已被编辑 3 次。
+        ⚠️ 提示：auth.py 已被编辑 6 次。
         检查一下：这些修改是在推进目标，还是在修前面的修改？
 
 Claude: 换个思路重写验证层。
         [编辑 src/auth.py — 重写验证逻辑]
+        [… 中间还有三次编辑 …]
 
 Claude: 差不多了，再调一下...
         [编辑 src/auth.py — 被阻止]
 
         🛑 编辑检查点
-        文件 auth.py 本次会话已被编辑 5 次。
+        文件 auth.py 本次会话已被编辑 10 次。
         反思：
           1. 这些修改是在推进目标，还是在修之前的修改？
           2. 如果是后者：停下来，寻找根本原因。
 
-Claude: 你说得对。回顾这 5 次编辑，我一直在修症状。
+Claude: 你说得对。回顾这 10 次编辑，我一直在修症状。
         真正的问题是 User 模型的 validate() 在
         sanitization 之前被调用了。我应该从源头修。
 ```
@@ -170,7 +171,7 @@ Claude: 你说得对。回顾这 5 次编辑，我一直在修症状。
 
 ---
 
-**pre-edit-guard** — 阻止跳过诊断直接改代码：
+**pre-edit-guard** — 在跳过诊断直接改代码时提示（2026-07-30 起为提示，不阻断）：
 
 ```
 你：  "API 的 /users 接口返回 500 错误"
@@ -180,11 +181,12 @@ Claude: 我来排查。
         → 500 Internal Server Error
 
 Claude: 我觉得是数据库连接池的问题，改一下配置。
-        [编辑 src/db.py — 被阻止]
+        [编辑 src/db.py]
 
-        🛑 docs/debug-log.md 中有 2 个未验证的假设。
-        请先完成调试流程（验证或排除假设），
-        再编辑源代码。
+        DEBUG-LOG 提示：docs/debug-log.md 中有 2 个假设
+        仍标记为 pending。如果这次编辑就是其中某条的修复，
+        请先更新它的状态，让日志保持真实；
+        如果是无关的工作，继续即可。
 
 Claude: 对，我还没验证我的假设。先看看错误日志。
         [执行: tail -50 logs/error.log]
@@ -262,8 +264,9 @@ EOF
 
 编辑 `.claude/hooks/streak-breaker.sh`：
 ```bash
-WARN_THRESHOLD=3    # Warning after N edits to same file
-STOP_THRESHOLD=5    # Hard block after N edits to same file
+WARN_THRESHOLD=6     # 同一源码文件编辑 N 次后警告
+STOP_THRESHOLD=10    # 同一源码文件编辑 N 次后硬停止
+# 配置与文档文件为 10/16；用户确认为计划内改动后两者翻倍
 ```
 
 ### 添加新的子代理

package/init.sh

@@ -394,13 +394,52 @@ echo -e "${GREEN}Installing skills...${NC}"
 SKILLS_MANIFEST=".claude/.cc-discipline-skills.manifest"
 NEW_MANIFEST=$(mktemp 2>/dev/null || echo ".claude/.skills-manifest.tmp")
 PRESERVED_SKILLS=""
-
+RETIRED_SKILLS=""
+RETIRED_PARTIAL=""
+KEPT_RETIRED=""
+# Snapshot the manifest before the install loop overwrites it. The retirement
+# pass further down needs the OLD record to tell "we installed this" apart from
+# "the user wrote it themselves".
+OLD_MANIFEST=$(mktemp 2>/dev/null || echo ".claude/.skills-manifest.old")
+[ -f "$SKILLS_MANIFEST" ] && cp "$SKILLS_MANIFEST" "$OLD_MANIFEST"
+
+# Emit "<algo>:<digest>", never a bare digest. The fallback chain below resolves
+# differently depending on what is installed, so a manifest that stores only the
+# digest silently mis-compares the moment tool availability changes — the same
+# class of environment drift that made the jq-only reads fail. When that happens
+# every recorded hash mismatches, every retired skill looks user-modified, and
+# the retirement pass does nothing. (fixed 2026-08-28, before 2.13.0 shipped.)
+# sha256sum and `shasum -a 256` produce identical digests, so both record sha256.
 _cc_hash() {
-    if command -v sha256sum >/dev/null 2>&1; then sha256sum "$1" | cut -d' ' -f1
-    elif command -v shasum >/dev/null 2>&1; then shasum -a 256 "$1" | cut -d' ' -f1
-    elif command -v md5sum >/dev/null 2>&1; then md5sum "$1" | cut -d' ' -f1
-    elif command -v md5 >/dev/null 2>&1; then md5 -q "$1"
-    else cksum "$1" | cut -d' ' -f1; fi
+    if command -v sha256sum >/dev/null 2>&1; then echo "sha256:$(sha256sum "$1" | cut -d' ' -f1)"
+    elif command -v shasum >/dev/null 2>&1; then echo "sha256:$(shasum -a 256 "$1" | cut -d' ' -f1)"
+    elif command -v md5sum >/dev/null 2>&1; then echo "md5:$(md5sum "$1" | cut -d' ' -f1)"
+    elif command -v md5 >/dev/null 2>&1; then echo "md5:$(md5 -q "$1")"
+    else echo "cksum:$(cksum "$1" | cut -d' ' -f1)"; fi
+}
+
+# True when manifest entry $2 still describes the current content of file $1.
+# Handles the "<algo>:<digest>" form written from 2.13.0 and the bare digest
+# written by 2.12.2/2.12.3: for a legacy entry the algorithm is unknown, so try
+# each available one and accept any match rather than calling the file modified.
+_cc_hash_matches() {
+    _f="$1"; _rec="$2"
+    [ -n "$_rec" ] || return 1
+    case "$_rec" in
+        *:*) [ "$(_cc_hash "$_f")" = "$_rec" ] && return 0; return 1 ;;
+    esac
+    for _algo in sha256sum shasum md5sum md5 cksum; do
+        command -v "$_algo" >/dev/null 2>&1 || continue
+        case "$_algo" in
+            sha256sum) _got=$(sha256sum "$_f" | cut -d' ' -f1) ;;
+            shasum)    _got=$(shasum -a 256 "$_f" | cut -d' ' -f1) ;;
+            md5sum)    _got=$(md5sum "$_f" | cut -d' ' -f1) ;;
+            md5)       _got=$(md5 -q "$_f") ;;
+            cksum)     _got=$(cksum "$_f" | cut -d' ' -f1) ;;
+        esac
+        [ "$_got" = "$_rec" ] && return 0
+    done
+    return 1
 }
 
 for skill_dir in "$SCRIPT_DIR"/templates/.claude/skills/*/; do
@@ -419,11 +458,10 @@ for skill_dir in "$SCRIPT_DIR"/templates/.claude/skills/*/; do
         if [ ! -f "$dst" ]; then
             cp "$src" "$dst"                       # new file — nothing to protect
         else
-            disk_hash=$(_cc_hash "$dst")
             recorded=$(grep "^$rel " "$SKILLS_MANIFEST" 2>/dev/null | head -1 | cut -d' ' -f2)
-            if [ "$disk_hash" = "$tpl_hash" ]; then
+            if _cc_hash_matches "$dst" "$tpl_hash"; then
                 :                                  # already current
-            elif [ -n "$recorded" ] && [ "$disk_hash" = "$recorded" ]; then
+            elif _cc_hash_matches "$dst" "$recorded"; then
                 cp "$src" "$dst"                   # pristine older version — safe
             elif [ -z "$recorded" ]; then
                 # No manifest yet (first run on an existing install) and the file
@@ -449,6 +487,59 @@ done
 
 [ -f "$NEW_MANIFEST" ] && mv "$NEW_MANIFEST" "$SKILLS_MANIFEST"
 
+# ─── Retire skills that upstream removed ───
+# The install loop only ever copies, so a skill deleted from templates/ (as
+# /finish and /retro were in v2.13.0) would otherwise sit in every existing
+# install forever. Same conffile rule as the overwrite guard above: delete only
+# what we installed and the user never touched. Anything modified is kept and
+# reported. An install with no prior manifest is left alone entirely — without
+# the old hashes there is no way to tell our copy from the user's own work.
+if [ -s "$OLD_MANIFEST" ]; then
+    for old_skill in $(cut -d' ' -f1 "$OLD_MANIFEST" | cut -d'/' -f1 | sort -u); do
+        [ -d "$SCRIPT_DIR/templates/.claude/skills/$old_skill" ] && continue
+        [ -d ".claude/skills/$old_skill" ] || continue
+        skill_modified=false
+        while read -r rel rec_hash; do
+            case "$rel" in "$old_skill"/*) ;; *) continue ;; esac
+            [ -f ".claude/skills/$rel" ] || continue
+            _cc_hash_matches ".claude/skills/$rel" "$rec_hash" || skill_modified=true
+        done < "$OLD_MANIFEST"
+        if [ "$skill_modified" = true ]; then
+            KEPT_RETIRED="$KEPT_RETIRED $old_skill"
+            # Carry the old entries into the new manifest. Without this the skill
+            # never appears in a manifest again, so a later upgrade cannot tell
+            # our copy from the user's and it is frozen in place permanently.
+            grep "^$old_skill/" "$OLD_MANIFEST" >> "$SKILLS_MANIFEST" 2>/dev/null
+        else
+            # Delete only the files the manifest recorded, then the directory if
+            # that leaves it empty. A blanket rm -rf would also destroy files a
+            # user put inside the skill directory that we never installed and
+            # therefore cannot account for.
+            while read -r rel _; do
+                case "$rel" in "$old_skill"/*) ;; *) continue ;; esac
+                rm -f ".claude/skills/$rel"
+            done < "$OLD_MANIFEST"
+            if rmdir ".claude/skills/$old_skill" 2>/dev/null; then
+                RETIRED_SKILLS="$RETIRED_SKILLS $old_skill"
+            else
+                RETIRED_PARTIAL="$RETIRED_PARTIAL $old_skill"
+            fi
+        fi
+    done
+fi
+rm -f "$OLD_MANIFEST" 2>/dev/null
+
+if [ -n "$RETIRED_SKILLS" ]; then
+    echo -e "   ${YELLOW}Retired upstream, removed:${RETIRED_SKILLS}${NC}"
+fi
+if [ -n "$RETIRED_PARTIAL" ]; then
+    echo -e "   ${YELLOW}Retired upstream; our files removed but directory kept (it holds files we did not install):${RETIRED_PARTIAL}${NC}"
+fi
+if [ -n "$KEPT_RETIRED" ]; then
+    echo -e "   ${YELLOW}Retired upstream but kept — you modified them:${KEPT_RETIRED}${NC}"
+    echo -e "   ${YELLOW}Delete by hand once you no longer need them.${NC}"
+fi
+
 if [ -n "$PRESERVED_SKILLS" ]; then
     echo -e "   ${YELLOW}Locally modified skills were not overwritten:${PRESERVED_SKILLS}${NC}"
     echo -e "   ${YELLOW}Compare with: diff .claude/skills/<name>/SKILL.md{,.new}${NC}"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-discipline",
-  "version": "2.12.3",
+  "version": "2.13.0",
   "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
   "bin": {
     "cc-discipline": "bin/cli.js"

package/templates/.claude/hooks/pre-edit-guard.sh

@@ -90,25 +90,14 @@ if [ "$DIFF_LINES" -gt 200 ]; then
     exit 0
 fi
 
-# ─── New tool/script detection ───
-# When creating a script file via Write, remind to register in CLAUDE.md
-# jq-or-sed: the previous jq-only line left TOOL_NAME empty on Windows Git Bash,
-# so this detection never fired there. (fixed 2026-07-30)
-if command -v jq &>/dev/null; then
-    TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
-else
-    TOOL_NAME=$(echo "$INPUT" | sed -n -E 's/.*"tool_name"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1)
-fi
-if [ "$TOOL_NAME" = "Write" ] && echo "$BASENAME" | grep -qiE "\.(sh|py|js|ts|rb|pl)$"; then
-    # Check if file already exists (new file = tool creation)
-    FULL_PATH="$FILE_PATH"
-    if [ ! -f "$FULL_PATH" ]; then
-        cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"NEW SCRIPT DETECTED: You are creating $BASENAME. If this is a reusable tool/helper, register it in CLAUDE.md under 'Project Tools' now (path, purpose, usage, date) — capturing it while context is fresh saves time later."}}
-JSONEOF
-        exit 0
-    fi
-fi
+# The new-script registration reminder was removed 2026-08-28. It fired 2,170
+# times in four weeks across two machines (~50 tokens each), almost entirely on
+# one-off transform scripts nobody would ever register. The measured correlation
+# with a growing Project Tools section was confounded: /commit carries the same
+# instruction, and a "does the heading exist" gate was disproven because
+# templates/CLAUDE.md ships that heading so every generated project has it.
+# Removing the branch also drops the TOOL_NAME extraction, which nothing else
+# used, cutting two subprocess calls from the hottest hook.
 
 # Normal source edit: stay silent (exit 0, no output).
 # The "list >=3 causes before a bug fix" guidance already lives in the

package/templates/.claude/skills/coplan/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: coplan
+description: Write the plan under discussion to docs/current-plan.md so Codex can review it against the real code. Stacks after /think.
+when_to_use: When a plan is worth a second opinion before building it — "coplan", "落个方案", "写下来给 codex 看", "把方案存一下" — or whenever /coplan is stacked after /think.
+---
+
+Write the plan under discussion to `docs/current-plan.md`, then stop.
+
+This skill does not produce the plan and does not decide anything. It takes whatever is on the table — the approaches from `/think`, or a plan just described in conversation — and puts it where Codex can read it. Codex runs read-only from the repo root, so a plan **on disk** is one it can check **against the actual code**. That is the entire point: a plan pasted into a prompt can only be judged on its own terms, while a plan in the tree can be judged against what is really there.
+
+If there is no plan on the table yet — no approaches from `/think`, nothing described in conversation — **say so and stop**. Point at `/think` instead. Do not invent a plan just to have something to write: a fabricated plan sent for review wastes a Codex run and produces confident feedback on something nobody proposed.
+
+## What to write
+
+**Overwrite the file completely.** One path, current version only — every earlier version survives in `git log -p docs/current-plan.md`, so nothing is lost and the directory never fills with dated files.
+
+Include, in this order:
+
+1. **Task** — what is being asked, in a sentence or two, framed the way the user framed it rather than the way you re-scoped it.
+2. **Approaches** — two or three. For each: how it works, what it costs, what it gives up. If there is genuinely only one reasonable approach, say so and say why. Do not invent alternatives to fill the section.
+3. **Recommendation** — which one, and the reason. A recommendation, not a survey.
+4. **Assumptions to verify** — the highest-value section for a reviewer that has the repo. Every claim the plan rests on that you have *not* checked: "assumes this is only called from X", "assumes the migration runs before Y", "assumes no other caller depends on the old shape". Codex can open the code and tell you which of these are false. **A plan usually fails here, not in its logic.**
+5. **Risks and unknowns** — what could go wrong, and what you could not determine.
+6. **Out of scope** — what this deliberately does not touch, so a reviewer does not flag choices as omissions.
+
+Write it for someone who has the codebase but was not in this conversation. No "as discussed above", no pronouns pointing at chat history.
+
+## Then stop
+
+Report the path and hand the review command over verbatim:
+
+```
+Plan written to docs/current-plan.md
+
+To have Codex review it:
+/codex:rescue 只评审方案不要修改任何文件，方案见 docs/current-plan.md
+```
+
+**Do not run the review yourself** — it costs time and quota, and a small plan does not need one. That call belongs to the user. **Do not start implementing either**: writing a plan down is not approval to build it.
+
+## When stacked after /think
+
+`/think /coplan <task>` is the intended pairing. `/think` produces the approaches and stops for the user's choice; `/coplan` puts them on disk on the way past.
+
+Write the file with the approaches **still open**. The review is meant to inform the choice, not rubber-stamp one already made — so do not collapse the section down to your recommendation just because you have one.

package/templates/.claude/skills/self-check/SKILL.md

@@ -86,9 +86,18 @@ Keep this list curated — remove tools that are obsolete.
 
 (Empty — fill in as the project develops scaffolding worth checking periodically.)
 
-## 7. What's working well?
+## 7. Did the rules change anything this time?
 
-Before reporting issues, note one thing that's going well — a good approach, a clean fix, effective tool use, or strong alignment with the user's direction. Recognizing what works reinforces it.
+Most checks have neither — **"none this time" is the normal answer and it is data.** Never manufacture one.
+
+- **Save** — a rule or hook *changed the outcome*: caught a real mistake, blocked a real loss, stopped a wrong turn already in motion. "The rules kept me disciplined" is not a save; "git-guard blocked a hard reset with 40 min of uncommitted work in the tree" is.
+- **Friction** — a rule or hook cost time for no benefit. Only log it with a concrete `→ fix:` (raise a threshold, exempt a path, reword a check). "X was annoying" is not actionable.
+
+If either is present, append one dated line each to a `## Rule Ledger` table in `docs/progress.md` (create the section at the end if it isn't there), then note it in the status line. **Do this automatically — recording an observation is not a change that needs sign-off.**
+
+Saves get logged because they are invisible: a rule that works suppresses the very failure it was written for, so only its cost surfaces on its own. Judge on cost alone and every load-bearing rule eventually looks like overhead.
+
+If there was no save, note one thing that went well instead — recognizing what works reinforces it.
 
 ## 8. Status report
 
@@ -102,6 +111,7 @@ On track: yes/no/drifted
 Progressing: yes/circling
 Progress recorded: yes/updated now/no
 Scaffolding: [used/skipped/n/a]
+Ledger: [save / friction appended, or "none"]
 Going well: [one thing]
 Issues found: [list, or "none"]
 ```

package/templates/.claude/skills/think/SKILL.md

@@ -93,7 +93,7 @@ If self-review reveals issues, revise your proposals before presenting. Don't sh
 
 Do not:
 - Start coding "while waiting"
-- Create files or scaffolding
+- Create files or scaffolding — **except** writing the plan itself to disk, which is not implementation. `/coplan` does exactly that and is designed to stack here.
 - Run exploratory commands beyond what's needed for Step 0-3
 - Say "I'll go ahead and start with Approach A" — that's the user's call
 
@@ -112,6 +112,5 @@ Carry these forward. If scope changes during implementation, pause and re-align
 The user may steer what happens after alignment by appending a directive to the invocation:
 
 - **`/think and plan`** — after alignment, produce the plan (in plan mode, present it for approval via ExitPlanMode).
-- **`/think and finish`** (or `and goal`) — after the user approves the approach, transition into **/finish**: drive to completion with its quality bar (solid, comprehensive, fully tested). Do NOT start before approval — 05-phase-discipline still applies; "and finish" declares the post-approval execution stance, it does not bypass the gate.
 
 If no directive was appended, stop and wait as usual (Step 5).

package/templates/docs/progress.md

@@ -76,7 +76,7 @@
 ## Rule Ledger
 
 <!--
-Appended by /retro. Two columns of evidence about the discipline rules themselves:
+Appended by /self-check §7. Two columns of evidence about the discipline rules themselves:
 
 - SAVE  — a rule or hook changed the outcome: caught a real mistake, blocked a
           real loss, stopped a wrong turn already in motion.

package/templates/.claude/skills/finish/SKILL.md

@@ -1,44 +0,0 @@
----
-name: finish
-description: Drive a task to completion with the quality bar — solid, comprehensive, fully tested; "not run" never counts as done. Use when you're ready to execute to the end (standalone, or as the handoff after /think approval).
----
-
-You are in **finish mode**: the task is understood and approved — now drive it to completion without stopping early. This is the opposite stance from /think (which aligns and waits). Here you execute, persist, and hold a high quality bar.
-
-## Step 1: Lock the completion conditions
-
-State explicitly — in one short block — what "done" means for this task:
-- The concrete deliverables (what must exist / work when finished)
-- The quality bar below, applied to each
-- Anything you'll treat as "blocked, must report" rather than silently skip
-
-If invoked standalone (no prior /think) and the scope is genuinely unclear, ask ONE tight round of questions, then commit. Don't turn finish mode into a planning session — the point is to execute.
-
-## Step 2: The quality bar (definition of done)
-
-Hold all of these. They are the standard, not aspirations:
-
-- **扎实 (solid)** — Fix the root cause, not symptoms. Handle edge cases (empty / null / error paths). No TODO, stub, or workaround left standing in as "the solution."
-- **全面 (comprehensive)** — Cover the full scope, not just the happy path. Update related call sites, docs, and `docs/progress.md`. Don't leave half the task for "later."
-- **完备测试 (fully tested)** — Write tests AND run them. Per 07-integrity §2, "verified" requires actual execution output — paste the command and result. Untested code is not done.
-- **诚实 (honest)** — If something is blocked by an external resource, mark it "⚠️ code ready, verification pending: [reason]" — never ✅ it. Distinguish done from blocked.
-
-## Step 3: Drive
-
-Keep going until the completion conditions are met. While driving:
-- Make reasonable decisions and keep moving — note them, don't stop to ask about trivia.
-- The discipline rules still apply: 3 consecutive failures → pause and regroup; scope changes → re-align; anything irreversible or outward-facing → confirm first.
-- Don't declare partial success to exit early. If you feel the urge to stop before the bar is met, that urge is the signal to push through or report the specific blocker — not to lower the bar.
-
-## Step 4: Report on completion
-
-When the completion conditions are met, give a short close-out:
-
-```
-FINISH — [task]
-Done: [each deliverable + how it was verified — paste key command output]
-Quality bar: 扎实 [✓/note] · 全面 [✓/note] · 完备测试 [✓/note]
-Blocked (if any): [item — why, what's needed]
-```
-
-If any part is blocked rather than done, say so plainly. A truthful "90% done, X blocked on Y" beats a false ✅.

package/templates/.claude/skills/retro/SKILL.md

@@ -1,49 +0,0 @@
----
-name: retro
-description: Find friction, remove friction. Quick post-task review that makes this project's workflow smoother and feeds improvements back to cc-discipline.
----
-
-Find friction. Remove friction. Record what the rules actually caught.
-
-## What to do
-
-Quickly scan what just happened — `git log --oneline -10` and any hook triggers you remember. Then output in this format:
-
-```
-RETRO — [date]
-
-Friction:
-- [what got in the way] → fix: [specific actionable change]
-
-Saves:
-- [rule/hook] caught [the specific real problem] — without it: [what would have shipped]
-
-Insights:
-- [something learned that should survive this session]
-
-Framework:
-- [cc-discipline improvement, if any — skip if none]
-```
-
-Rules:
-- **Only actionable friction** — Every friction item must have a "→ fix:" with a concrete change (adjust a threshold, add to CLAUDE.md, update memory, exempt a path).
-- **Only new** — Don't repeat friction that's already been addressed or recorded in memory.
-- **Be specific** — "streak-breaker was annoying" is not useful. "streak-breaker triggered 3x on config.yaml during template fill → fix: add config.yaml to docs/ exempt path, or raise config threshold to 10" is useful.
-- **Framework items are rare** — Most friction is project-specific. Only flag framework issues if the same problem would hit other projects too.
-- **Keep it short** — 3-5 items per section max. If you can't find friction, say "no friction found" and move on. An empty friction list is a good sign.
-
-Saves — read this before filling that section in:
-- **A save is not "what went well."** Log a save only when a rule or hook *changed the outcome*: it caught a real mistake, blocked a real loss, or stopped a wrong turn that was already in motion. "The rules kept me disciplined" is not a save. "git-guard blocked `git reset --hard` while 40 min of uncommitted work was in the tree" is.
-- **"no saves" is a real answer, and it is data.** Write it plainly rather than manufacturing one.
-- **Why this section exists:** friction is visible and saves are invisible — a rule that works silently suppresses the very failure it was written for, so the only naturally measurable signal is its cost. With cost-only data every rule eventually looks like pure overhead and gets cut, including the ones that are still load-bearing. The save log is what makes it possible to judge, later and with evidence, whether a given rule still earns its place.
-
-## After output
-
-Append both Friction and Saves to a `## Rule Ledger` section in `docs/progress.md` (create the section at the end of the file if it isn't there yet), one dated line each. This accumulates the record across sessions — a single retro proves nothing, twenty of them decide which rules stay.
-
-Then present the items. User decides:
-- "fix it" → apply the changes
-- "remember it" → write to memory via /commit
-- "skip" → move on
-
-Do not auto-apply fixes. Do not pad. Do not turn this into a report. (Appending to the ledger is not a fix — do that without asking.)