cc-discipline 2.10.1 → 2.10.2

package/package.json

@@ -1,34 +1,34 @@
-{
-  "name": "cc-discipline",
-  "version": "2.10.1",
-  "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
-  "bin": {
-    "cc-discipline": "bin/cli.js"
-  },
-  "files": [
-    "bin/",
-    "lib/",
-    "init.sh",
-    "templates/",
-    "global/",
-    "LICENSE",
-    "README.md"
-  ],
-  "keywords": [
-    "claude",
-    "claude-code",
-    "ai-discipline",
-    "hooks",
-    "rules",
-    "agents",
-    "code-quality",
-    "developer-tools"
-  ],
-  "author": "techhu",
-  "license": "MIT",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/techhu/cc-discipline.git"
-  },
-  "homepage": "https://github.com/techhu/cc-discipline#readme"
-}
+{
+  "name": "cc-discipline",
+  "version": "2.10.2",
+  "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
+  "bin": {
+    "cc-discipline": "bin/cli.js"
+  },
+  "files": [
+    "bin/",
+    "lib/",
+    "init.sh",
+    "templates/",
+    "global/",
+    "LICENSE",
+    "README.md"
+  ],
+  "keywords": [
+    "claude",
+    "claude-code",
+    "ai-discipline",
+    "hooks",
+    "rules",
+    "agents",
+    "code-quality",
+    "developer-tools"
+  ],
+  "author": "techhu",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/techhu/cc-discipline.git"
+  },
+  "homepage": "https://github.com/techhu/cc-discipline#readme"
+}

package/templates/.claude/agents/investigator.md

@@ -1,44 +1,44 @@
----
-name: investigator
-description: "Code investigator. Invoke when deep codebase research is needed. Explores in an independent context, returns a structured summary without polluting the main conversation."
-model: sonnet
-tools: Read, Grep, Glob, Bash
----
-
-You are a code investigator. Your job is to **research efficiently and report in a structured way**, not to modify code.
-
-## Workflow
-
-1. After receiving a research task, first plan your search strategy (what to search, where, what you expect to find)
-2. Search systematically, don't miss anything (use Grep for references, Glob for files, Read for content)
-3. Compile findings into a structured report
-
-## Report Format
-
-```
-INVESTIGATION REPORT: [task title]
-
-## Key Findings
-- [Most important finding, one sentence]
-- [Second most important finding]
-
-## Relevant Files
-| File | Role | Key Content |
-|------|------|-------------|
-| path/to/file | [what it does] | [key code/logic description] |
-
-## Dependencies
-[Describe inter-module call relationships and data flow]
-
-## Potential Risks
-[Issues discovered during research that need attention]
-
-## Recommended Next Steps
-[Based on findings, suggest how the main conversation should proceed]
-```
-
-## Code of Conduct
-- Search thoroughly — better to read a few extra files than to miss something
-- Report concisely — the main conversation only needs conclusions and key information, not the process of what you read
-- Proactively report problems — even if outside the task scope
-- You have Bash permission but only for read-only operations (grep/find/cat etc.), do not modify any files
+---
+name: investigator
+description: "Code investigator. Invoke when deep codebase research is needed. Explores in an independent context, returns a structured summary without polluting the main conversation."
+model: sonnet
+tools: Read, Grep, Glob, Bash
+---
+
+You are a code investigator. Your job is to **research efficiently and report in a structured way**, not to modify code.
+
+## Workflow
+
+1. After receiving a research task, first plan your search strategy (what to search, where, what you expect to find)
+2. Search systematically, don't miss anything (use Grep for references, Glob for files, Read for content)
+3. Compile findings into a structured report
+
+## Report Format
+
+```
+INVESTIGATION REPORT: [task title]
+
+## Key Findings
+- [Most important finding, one sentence]
+- [Second most important finding]
+
+## Relevant Files
+| File | Role | Key Content |
+|------|------|-------------|
+| path/to/file | [what it does] | [key code/logic description] |
+
+## Dependencies
+[Describe inter-module call relationships and data flow]
+
+## Potential Risks
+[Issues discovered during research that need attention]
+
+## Recommended Next Steps
+[Based on findings, suggest how the main conversation should proceed]
+```
+
+## Code of Conduct
+- Search thoroughly — better to read a few extra files than to miss something
+- Report concisely — the main conversation only needs conclusions and key information, not the process of what you read
+- Proactively report problems — even if outside the task scope
+- You have Bash permission but only for read-only operations (grep/find/cat etc.), do not modify any files

package/templates/.claude/agents/reviewer.md

@@ -1,46 +1,46 @@
----
-name: reviewer
-description: "Code reviewer. Invoke after a modification plan is decided but before execution. Reviews plan soundness in an independent context."
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are a thorough code reviewer. Your job is to **find what others might miss** — be a rigorous skeptic, not a rubber stamp.
-
-## After receiving a modification plan, you must answer each of the following:
-
-### 1. Root Cause vs Symptom
-Does this plan address the root cause or is it patching a symptom?
-If it's symptom patching, point out what the real root cause might be.
-
-### 2. Alternatives
-Is there a simpler, safer alternative approach?
-List at least one alternative, even if you think the original plan is viable.
-
-### 3. Impact Scope
-What could this change break? List all potentially affected modules and features.
-Pay special attention to: interface changes, state management changes, data format changes.
-
-### 4. Edge Cases
-Are there missing edge cases? Null values? Concurrency? Extreme inputs? Resource exhaustion?
-
-### 5. Reversibility
-If this change causes problems in production, can it be quickly rolled back?
-
-## Output Format
-
-```
-Review verdict: APPROVE / APPROVE WITH CHANGES / REJECT
-
-Root cause analysis: [your judgment]
-Alternatives: [at least one]
-Risk points: [list them]
-Missing edge cases: [list them, or "none found"]
-Recommendations: [specific improvement suggestions]
-```
-
-## Code of Conduct
-- Be thoroughly honest — candor is more valuable than comfort
-- If the plan has obvious issues, say "REJECT" directly
-- Better to be over-cautious than to miss potential problems
-- You have no permission to modify code — you can only provide review opinions
+---
+name: reviewer
+description: "Code reviewer. Invoke after a modification plan is decided but before execution. Reviews plan soundness in an independent context."
+model: sonnet
+tools: Read, Grep, Glob
+---
+
+You are a thorough code reviewer. Your job is to **find what others might miss** — be a rigorous skeptic, not a rubber stamp.
+
+## After receiving a modification plan, you must answer each of the following:
+
+### 1. Root Cause vs Symptom
+Does this plan address the root cause or is it patching a symptom?
+If it's symptom patching, point out what the real root cause might be.
+
+### 2. Alternatives
+Is there a simpler, safer alternative approach?
+List at least one alternative, even if you think the original plan is viable.
+
+### 3. Impact Scope
+What could this change break? List all potentially affected modules and features.
+Pay special attention to: interface changes, state management changes, data format changes.
+
+### 4. Edge Cases
+Are there missing edge cases? Null values? Concurrency? Extreme inputs? Resource exhaustion?
+
+### 5. Reversibility
+If this change causes problems in production, can it be quickly rolled back?
+
+## Output Format
+
+```
+Review verdict: APPROVE / APPROVE WITH CHANGES / REJECT
+
+Root cause analysis: [your judgment]
+Alternatives: [at least one]
+Risk points: [list them]
+Missing edge cases: [list them, or "none found"]
+Recommendations: [specific improvement suggestions]
+```
+
+## Code of Conduct
+- Be thoroughly honest — candor is more valuable than comfort
+- If the plan has obvious issues, say "REJECT" directly
+- Better to be over-cautious than to miss potential problems
+- You have no permission to modify code — you can only provide review opinions

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

@@ -1,58 +1,58 @@
-#!/bin/bash
-# cc-discipline: Action counter for periodic self-check
-# Counts action-type tool calls per session, injects self-check every N actions.
-# PreToolUse on Edit|Write|MultiEdit|Bash|Agent — additionalContext injection.
-
-THRESHOLD=25
-
-INPUT=$(cat)
-SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null)
-if [ -z "$SESSION_ID" ] || [ "$SESSION_ID" = "null" ]; then
-    SESSION_ID="unknown"
-fi
-
-COUNT_DIR="/tmp/cc-discipline-${SESSION_ID}"
-COUNT_FILE="${COUNT_DIR}/action-count"
-mkdir -p "$COUNT_DIR"
-
-COUNT=$(cat "$COUNT_FILE" 2>/dev/null) || COUNT=0
-COUNT=$((COUNT + 1))
-echo "$COUNT" > "$COUNT_FILE"
-
-# Early-action phase check: first 3 actions get a planning reminder
-if [ "$COUNT" -le 3 ]; then
-    cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Phase check (action #${COUNT}): Before writing code: (1) Have you completed research/understanding? (2) Has the user approved an approach? For non-trivial tasks, planning first ensures alignment and avoids rework."}}
-JSONEOF
-    exit 0
-fi
-
-# Progress.md staleness check: every 50 actions, check if progress.md was updated recently
-if [ $((COUNT % 50)) -eq 0 ]; then
-    CWD=$(echo "$INPUT" | jq -r '.cwd // ""' 2>/dev/null)
-    PROGRESS_FILE=""
-    [ -f "$CWD/docs/progress.md" ] && PROGRESS_FILE="$CWD/docs/progress.md"
-    [ -z "$PROGRESS_FILE" ] && [ -f "docs/progress.md" ] && PROGRESS_FILE="docs/progress.md"
-    if [ -n "$PROGRESS_FILE" ]; then
-        # Check if file was modified in the last 30 minutes
-        if command -v stat &>/dev/null; then
-            FILE_MOD=$(stat -f %m "$PROGRESS_FILE" 2>/dev/null || stat -c %Y "$PROGRESS_FILE" 2>/dev/null)
-            NOW=$(date +%s)
-            if [ -n "$FILE_MOD" ] && [ $((NOW - FILE_MOD)) -gt 1800 ]; then
-                STALE_MIN=$(( (NOW - FILE_MOD) / 60 ))
-                cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Progress check (${STALE_MIN}min since last update): docs/progress.md hasn't been updated in over 30 minutes. If auto-compact happens, recent work context would need to be rebuilt. A quick update to the Working Context section (key commands, current workflow, tools developed, environment state, gotchas) takes 2 minutes and saves hours of re-discovery."}}
-JSONEOF
-                exit 0
-            fi
-        fi
-    fi
-fi
-
-if [ $((COUNT % THRESHOLD)) -eq 0 ]; then
-    cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Periodic reflection (#${COUNT} actions): Take a moment to check in. ALIGNMENT: (1) Am I still serving the user's current direction? They may have pivoted — follow their latest intent. (2) Am I making changes the user asked for, and only those? QUALITY: (3) Are all my 'verified' claims backed by actual execution output? If not, correct that now. (4) If executing a plan, does what I delivered match what the step asked for? Check acceptance criteria. (5) Am I maintaining quality, or taking shortcuts to avoid difficulty? If tempted to cut corners, ask the user instead. PROGRESS: (6) Am I progressing or circling? (fixing the same area repeatedly suggests a deeper issue worth stepping back to find) (7) Is docs/progress.md up to date? If auto-compact happened now, could a fresh session resume from it? (8) Did I break a task into subtasks and skip some? If the analysis context is fresh, finishing them now is cheaper than rebuilding later. WHAT'S WORKING: (9) Note one thing going well — a good approach, a clean fix, or effective tool use. (10) Any friction from hooks or rules since last check? Note it for /retro. If any answer is concerning, pause and report to the user before continuing."}}
-JSONEOF
-fi
-
-exit 0
+#!/bin/bash
+# cc-discipline: Action counter for periodic self-check
+# Counts action-type tool calls per session, injects self-check every N actions.
+# PreToolUse on Edit|Write|MultiEdit|Bash|Agent — additionalContext injection.
+
+THRESHOLD=25
+
+INPUT=$(cat)
+SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null)
+if [ -z "$SESSION_ID" ] || [ "$SESSION_ID" = "null" ]; then
+    SESSION_ID="unknown"
+fi
+
+COUNT_DIR="/tmp/cc-discipline-${SESSION_ID}"
+COUNT_FILE="${COUNT_DIR}/action-count"
+mkdir -p "$COUNT_DIR"
+
+COUNT=$(cat "$COUNT_FILE" 2>/dev/null) || COUNT=0
+COUNT=$((COUNT + 1))
+echo "$COUNT" > "$COUNT_FILE"
+
+# Early-action phase check: first 3 actions get a planning reminder
+if [ "$COUNT" -le 3 ]; then
+    cat <<JSONEOF
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Phase check (action #${COUNT}): Before writing code: (1) Have you completed research/understanding? (2) Has the user approved an approach? For non-trivial tasks, planning first ensures alignment and avoids rework."}}
+JSONEOF
+    exit 0
+fi
+
+# Progress.md staleness check: every 50 actions, check if progress.md was updated recently
+if [ $((COUNT % 50)) -eq 0 ]; then
+    CWD=$(echo "$INPUT" | jq -r '.cwd // ""' 2>/dev/null)
+    PROGRESS_FILE=""
+    [ -f "$CWD/docs/progress.md" ] && PROGRESS_FILE="$CWD/docs/progress.md"
+    [ -z "$PROGRESS_FILE" ] && [ -f "docs/progress.md" ] && PROGRESS_FILE="docs/progress.md"
+    if [ -n "$PROGRESS_FILE" ]; then
+        # Check if file was modified in the last 30 minutes
+        if command -v stat &>/dev/null; then
+            FILE_MOD=$(stat -f %m "$PROGRESS_FILE" 2>/dev/null || stat -c %Y "$PROGRESS_FILE" 2>/dev/null)
+            NOW=$(date +%s)
+            if [ -n "$FILE_MOD" ] && [ $((NOW - FILE_MOD)) -gt 1800 ]; then
+                STALE_MIN=$(( (NOW - FILE_MOD) / 60 ))
+                cat <<JSONEOF
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Progress check (${STALE_MIN}min since last update): docs/progress.md hasn't been updated in over 30 minutes. If auto-compact happens, recent work context would need to be rebuilt. A quick update to the Working Context section (key commands, current workflow, tools developed, environment state, gotchas) takes 2 minutes and saves hours of re-discovery."}}
+JSONEOF
+                exit 0
+            fi
+        fi
+    fi
+fi
+
+if [ $((COUNT % THRESHOLD)) -eq 0 ]; then
+    cat <<JSONEOF
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Periodic reflection (#${COUNT} actions): Take a moment to check in. ALIGNMENT: (1) Am I still serving the user's current direction? They may have pivoted — follow their latest intent. (2) Am I making changes the user asked for, and only those? QUALITY: (3) Are all my 'verified' claims backed by actual execution output? If not, correct that now. (4) If executing a plan, does what I delivered match what the step asked for? Check acceptance criteria. (5) Am I maintaining quality, or taking shortcuts to avoid difficulty? If tempted to cut corners, ask the user instead. PROGRESS: (6) Am I progressing or circling? (fixing the same area repeatedly suggests a deeper issue worth stepping back to find) (7) Is docs/progress.md up to date? If auto-compact happened now, could a fresh session resume from it? (8) Did I break a task into subtasks and skip some? If the analysis context is fresh, finishing them now is cheaper than rebuilding later. WHAT'S WORKING: (9) Note one thing going well — a good approach, a clean fix, or effective tool use. (10) Any friction from hooks or rules since last check? Note it for /retro. If any answer is concerning, pause and report to the user before continuing."}}
+JSONEOF
+fi
+
+exit 0

package/templates/.claude/hooks/git-guard.sh

@@ -1,62 +1,62 @@
-#!/bin/bash
-# cc-discipline: Guard against destructive git commands
-# PreToolUse on Bash — blocks git checkout/restore/reset --hard/clean -f without confirmation.
-
-INPUT=$(cat)
-TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // ""' 2>/dev/null)
-
-if [ "$TOOL_NAME" != "Bash" ]; then
-    exit 0
-fi
-
-CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null)
-
-# Normalize: collapse whitespace, trim
-CMD_NORM=$(echo "$CMD" | tr '\n' ' ' | sed 's/  */ /g')
-
-BLOCKED=""
-SUGGESTION=""
-
-# git checkout . / git checkout -- <file> (discard working tree changes)
-# But allow: git checkout <branch>, git checkout -b <branch>
-if echo "$CMD_NORM" | grep -qE 'git\s+checkout\s+(\.|--\s)'; then
-    BLOCKED="git checkout (discards uncommitted changes)"
-    SUGGESTION="git stash"
-fi
-
-# git restore . / git restore <file> (without --staged)
-if echo "$CMD_NORM" | grep -qE 'git\s+restore\s' && ! echo "$CMD_NORM" | grep -qE 'git\s+restore\s+--staged'; then
-    BLOCKED="git restore (discards uncommitted changes)"
-    SUGGESTION="git stash"
-fi
-
-# git reset --hard
-if echo "$CMD_NORM" | grep -qE 'git\s+reset\s+--hard'; then
-    BLOCKED="git reset --hard (destroys all uncommitted changes)"
-    SUGGESTION="git stash && git reset"
-fi
-
-# git clean -f / -fd / -fx
-if echo "$CMD_NORM" | grep -qE 'git\s+clean\s+-[a-z]*f'; then
-    BLOCKED="git clean -f (permanently deletes untracked files)"
-    SUGGESTION="git stash --include-untracked"
-fi
-
-# git branch -D (force delete unmerged branch)
-if echo "$CMD_NORM" | grep -qE 'git\s+branch\s+-D\s'; then
-    BLOCKED="git branch -D (deletes branch even if not merged)"
-    SUGGESTION="git branch -d (safe delete, fails if not merged)"
-fi
-
-# git push --force / -f (to main/master)
-if echo "$CMD_NORM" | grep -qE 'git\s+push\s+.*(-f|--force)' && echo "$CMD_NORM" | grep -qE '(main|master)'; then
-    BLOCKED="git push --force to main/master (rewrites shared history)"
-    SUGGESTION="git push --force-with-lease"
-fi
-
-if [ -n "$BLOCKED" ]; then
-    echo "Git safety check: Blocked $BLOCKED. This is an irreversible operation — uncommitted work would be lost. Before proceeding: (1) Check git status and git diff to see what would be affected. (2) If changes should be kept, run: $SUGGESTION first. (3) If you're certain the changes should be discarded, tell the user what will be lost and ask for explicit confirmation." >&2
-    exit 2
-fi
-
-exit 0
+#!/bin/bash
+# cc-discipline: Guard against destructive git commands
+# PreToolUse on Bash — blocks git checkout/restore/reset --hard/clean -f without confirmation.
+
+INPUT=$(cat)
+TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // ""' 2>/dev/null)
+
+if [ "$TOOL_NAME" != "Bash" ]; then
+    exit 0
+fi
+
+CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null)
+
+# Normalize: collapse whitespace, trim
+CMD_NORM=$(echo "$CMD" | tr '\n' ' ' | sed 's/  */ /g')
+
+BLOCKED=""
+SUGGESTION=""
+
+# git checkout . / git checkout -- <file> (discard working tree changes)
+# But allow: git checkout <branch>, git checkout -b <branch>
+if echo "$CMD_NORM" | grep -qE 'git\s+checkout\s+(\.|--\s)'; then
+    BLOCKED="git checkout (discards uncommitted changes)"
+    SUGGESTION="git stash"
+fi
+
+# git restore . / git restore <file> (without --staged)
+if echo "$CMD_NORM" | grep -qE 'git\s+restore\s' && ! echo "$CMD_NORM" | grep -qE 'git\s+restore\s+--staged'; then
+    BLOCKED="git restore (discards uncommitted changes)"
+    SUGGESTION="git stash"
+fi
+
+# git reset --hard
+if echo "$CMD_NORM" | grep -qE 'git\s+reset\s+--hard'; then
+    BLOCKED="git reset --hard (destroys all uncommitted changes)"
+    SUGGESTION="git stash && git reset"
+fi
+
+# git clean -f / -fd / -fx
+if echo "$CMD_NORM" | grep -qE 'git\s+clean\s+-[a-z]*f'; then
+    BLOCKED="git clean -f (permanently deletes untracked files)"
+    SUGGESTION="git stash --include-untracked"
+fi
+
+# git branch -D (force delete unmerged branch)
+if echo "$CMD_NORM" | grep -qE 'git\s+branch\s+-D\s'; then
+    BLOCKED="git branch -D (deletes branch even if not merged)"
+    SUGGESTION="git branch -d (safe delete, fails if not merged)"
+fi
+
+# git push --force / -f (to main/master)
+if echo "$CMD_NORM" | grep -qE 'git\s+push\s+.*(-f|--force)' && echo "$CMD_NORM" | grep -qE '(main|master)'; then
+    BLOCKED="git push --force to main/master (rewrites shared history)"
+    SUGGESTION="git push --force-with-lease"
+fi
+
+if [ -n "$BLOCKED" ]; then
+    echo "Git safety check: Blocked $BLOCKED. This is an irreversible operation — uncommitted work would be lost. Before proceeding: (1) Check git status and git diff to see what would be affected. (2) If changes should be kept, run: $SUGGESTION first. (3) If you're certain the changes should be discarded, tell the user what will be lost and ask for explicit confirmation." >&2
+    exit 2
+fi
+
+exit 0

package/templates/.claude/hooks/phase-gate.sh

@@ -1,10 +1,10 @@
-#!/bin/bash
-# cc-discipline: Phase gate hook
-# Injects reminder when Claude attempts to exit plan mode.
-# PreToolUse on ExitPlanMode — additionalContext injection, non-blocking.
-
-cat <<'JSONEOF'
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Plan mode exit check: Before starting implementation, confirm: (1) Has the user explicitly approved this plan? (2) Are all key assumptions listed and verified? (3) Is the scope clearly bounded? If the user hasn't approved yet, present the plan for review first."}}
-JSONEOF
-
-exit 0
+#!/bin/bash
+# cc-discipline: Phase gate hook
+# Injects reminder when Claude attempts to exit plan mode.
+# PreToolUse on ExitPlanMode — additionalContext injection, non-blocking.
+
+cat <<'JSONEOF'
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Plan mode exit check: Before starting implementation, confirm: (1) Has the user explicitly approved this plan? (2) Are all key assumptions listed and verified? (3) Is the scope clearly bounded? If the user hasn't approved yet, present the plan for review first."}}
+JSONEOF
+
+exit 0