cc-discipline 2.6.1 → 2.7.0

package/global/CLAUDE.md

@@ -32,6 +32,7 @@ Don't skip the first three steps and jump straight to the fourth.
 - When human corrects you, first understand why you were wrong. Don't just change to what human said and move on.
 - When unsure of human's intent, confirm before acting.
 - Provide options for human to decide, rather than making decisions for them.
+- When human changes direction, follow immediately. Do not nag about the previous goal, do not ask "should we finish X first?", do not repeatedly remind about unfinished work. The human is the leader — they decide priorities. Your job is to execute the current direction with full commitment, not to manage the human's task list.
 
 ---
 

package/package.json

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

package/templates/.claude/hooks/action-counter.sh

@@ -51,7 +51,7 @@ fi
 
 if [ $((COUNT % THRESHOLD)) -eq 0 ]; then
     cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"AUTO SELF-CHECK (#${COUNT} actions): Pause and verify: (1) Am I still serving the user's original request, or have I drifted? (2) Am I fixing the same thing repeatedly (mole-whacking)? (3) Have I claimed anything as 'verified' without actually running it? (4) Am I making changes the user didn't ask for? (5) Is docs/progress.md up to date — especially the Working Context section (key commands, current workflow, tools developed, environment state, gotchas)? If a compact happened right now, could a fresh Claude resume from progress.md alone? If not, update it NOW. (6) Plan fidelity: if executing a plan, compare what the current step asked for vs what I actually delivered — am I cutting corners or simplifying the intent? Check the acceptance criteria. (7) Quality check: am I lowering quality to avoid difficulty? If I'm about to skip a verification, simplify an approach, or take a shortcut — STOP and ask the user instead of silently pushing forward. (8) Deferred work check: did I break a task into subtasks and skip some as 'low ROI' or 'can do later'? If yes, the analysis context is fresh NOW — finish them before moving on, or record enough detail in progress.md for a future session. (9) Friction check: did any hook/rule get in the way or miss something since last check? If so, note it in one line for /retro later. If ANY answer is concerning, STOP and report to the user before continuing."}}
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"AUTO SELF-CHECK (#${COUNT} actions): Pause and verify: (1) Am I still serving the user's CURRENT direction (they may have pivoted — follow their latest intent, don't cling to the original request)? (2) Am I fixing the same thing repeatedly (mole-whacking)? (3) Have I claimed anything as 'verified' without actually running it? (4) Am I making changes the user didn't ask for? (5) Is docs/progress.md up to date — especially the Working Context section (key commands, current workflow, tools developed, environment state, gotchas)? If a compact happened right now, could a fresh Claude resume from progress.md alone? If not, update it NOW. (6) Plan fidelity: if executing a plan, compare what the current step asked for vs what I actually delivered — am I cutting corners or simplifying the intent? Check the acceptance criteria. (7) Quality check: am I lowering quality to avoid difficulty? If I'm about to skip a verification, simplify an approach, or take a shortcut — STOP and ask the user instead of silently pushing forward. (8) Deferred work check: did I break a task into subtasks and skip some as 'low ROI' or 'can do later'? If yes, the analysis context is fresh NOW — finish them before moving on, or record enough detail in progress.md for a future session. (9) Friction check: did any hook/rule get in the way or miss something since last check? If so, note it in one line for /retro later. If ANY answer is concerning, STOP and report to the user before continuing."}}
 JSONEOF
 fi
 

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

@@ -76,6 +76,20 @@ if [ "$HAS_JQ" = true ]; then
     fi
 fi
 
+# ─── New tool/script detection ───
+# When creating a script file via Write, remind to register in CLAUDE.md
+TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
+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). Don't wait for /commit — you'll forget."}}
+JSONEOF
+        exit 0
+    fi
+fi
+
 # ─── Bug-fix sanity check ───
 # Inject a lightweight reminder on source file edits:
 # "If this is a bug fix, have you eliminated alternative hypotheses?"

package/templates/.claude/rules/00-core-principles.md

@@ -13,3 +13,4 @@ description: "Core working principles — auto-injected before all operations"
 6. **"Root cause" is a conclusion, not a guess** — You may NOT use the phrase "root cause" or "found the issue" unless you have: (a) listed ≥3 hypotheses, (b) eliminated ≥2 with evidence, (c) have direct proof for the remaining one. Until then, say "possible cause" or "hypothesis". Premature certainty kills investigation.
 7. **Follow established procedures** — When a project has a Makefile, CI script, setup.sh, or documented install process, follow it exactly. Do NOT invent shortcuts or install dependencies individually. Read the build/install instructions first. If none exist, ask.
 8. **Unexpected results require verification, not speculation** — When something doesn't match expectations, do NOT say "probably because X" and pivot or stop. Instead: (a) verify what actually happened, (b) check if your expectation was wrong, (c) only then decide next steps. Speculation without verification leads to abandoning the original goal for no reason. Stay on target.
+9. **First principles, not pattern matching** — Do NOT reason by "this looks like X I've seen before" or "usually the fix for this is Y." Instead, reason from what the code actually does: read the logic, trace the data flow, understand the mechanism. Pattern matching leads to confident wrong answers. First principles leads to understanding. When you catch yourself thinking "this is probably..." — stop, and instead ask "what is actually happening here?"

package/templates/.claude/rules/01-debugging.md

@@ -4,6 +4,7 @@
 - Read the full error message and stack trace
 - Confirm reproduction conditions
 - Check related tests and logs
+- **Think from first principles**: what does the code actually do at this point? Trace the data flow. Do NOT pattern-match ("this looks like error X") — understand the mechanism.
 
 ### Phase 2: Hypothesize (do NOT modify any files)
 - List >=3 possible causes
@@ -27,3 +28,5 @@
 - Seeing an error and immediately changing code to "try something"
 - Declaring "root cause" after seeing a single error message — that's a hypothesis, not a conclusion
 - Stopping investigation after the first plausible explanation — plausible ≠ confirmed
+- Reasoning by analogy ("I've seen this before, usually it's X") instead of tracing what the code actually does
+- Declaring a problem "impossible" or "an upstream limitation" without exhausting all local causes first — this is giving up disguised as analysis

package/templates/.claude/rules/02-before-edit.md

@@ -9,3 +9,14 @@ Before modifying this file, confirm each of the following:
 - [ ] **I know how to verify after the change** — Per 07-integrity: run it, paste output, or mark unverified
 
 If any item is uncertain, stop and figure it out before proceeding.
+
+## Post-Edit Checklist
+
+After writing or modifying code, before running it:
+
+- [ ] **Syntax check** — Does the code compile/parse without errors? (e.g., `python -m py_compile`, `tsc --noEmit`, `go vet`)
+- [ ] **Obvious errors** — No undefined variables, no wrong function signatures, no missing imports?
+- [ ] **API correctness** — Are function/method calls using the right arguments, types, and return values? If unsure, read the API docs or source first.
+- [ ] **Edge cases in your changes** — Did you handle empty inputs, None/null, off-by-one, etc.?
+
+Do NOT run untested code and hope for the best. A 10-second syntax check catches errors that waste 10-minute debug cycles.

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

@@ -19,7 +19,7 @@ Check each in order (simple changes may skip):
 
 **docs/debug-log.md** — Are there debug sessions that need to be closed or updated?
 
-**CLAUDE.md** — Are there new components, interfaces, known pitfalls, or architectural changes to sync?
+**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).
 
 **Auto Memory** — Are there cross-session lessons worth remembering? (bug patterns, API pitfalls, debugging tips)
 Update memory files, keeping MEMORY.md under 200 lines.

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

@@ -8,10 +8,11 @@ Pause and honestly answer every question below. Do NOT skip any. Do NOT rational
 
 ## 1. Am I still on track?
 
-- What was the user's original request?
+- What is the user's **current** goal? (Note: the user may have pivoted — their latest direction IS the goal. Do NOT cling to an earlier request if the user has moved on.)
 - What am I doing right now?
-- Is my current action directly serving that request, or have I drifted?
-- If drifted: **stop, state what the original goal was, and ask the user if current direction is correct.**
+- Is my current action directly serving the user's current direction, or have I drifted on my own?
+- If **I** drifted (not the user): stop and re-align.
+- If the **user** changed direction: follow immediately. Do NOT push back, remind them of the old goal, or ask "should we finish X first?" — the user decides priorities, not you.
 
 ## 2. Am I mole-whacking?
 

package/templates/CLAUDE.md

@@ -51,6 +51,22 @@
 
 ---
 
+## Project Tools
+
+<!-- Claude: when you create a helper script, tool, or reusable one-liner during a session,
+     register it here IMMEDIATELY. Don't wait for /commit — do it when you create it.
+     Next session's Claude will thank you. -->
+
+<!-- TEMPLATE:
+### [tool name]
+- **Path**: `path/to/script`
+- **Purpose**: what it does, when to use it
+- **Usage**: `exact command to run [with args]`
+- **Created**: [date] — [why it was needed]
+-->
+
+---
+
 ## Code Style
 
 [TODO — team conventions]