cc-discipline 2.6.1 → 2.8.0

package/global/CLAUDE.md

@@ -32,6 +32,8 @@ 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.
+- Do not comment on the time, suggest rest, say "good night", or advise the human to "continue tomorrow". The human's schedule is not your concern. Work when asked, stop when told.
 
 ---
 

package/init.sh

@@ -363,12 +363,14 @@ cp -r "$SCRIPT_DIR/templates/.claude/skills/evaluate" .claude/skills/
 cp -r "$SCRIPT_DIR/templates/.claude/skills/think" .claude/skills/
 cp -r "$SCRIPT_DIR/templates/.claude/skills/retro" .claude/skills/
 cp -r "$SCRIPT_DIR/templates/.claude/skills/summary" .claude/skills/
+cp -r "$SCRIPT_DIR/templates/.claude/skills/investigate" .claude/skills/
 echo "   ✓ /commit — smart commit (test → update memory → commit)"
 echo "   ✓ /self-check — periodic discipline check (use with /loop 10m /self-check)"
 echo "   ✓ /evaluate — evaluate external review/advice against codebase context"
 echo "   ✓ /think — stop and think before coding (ask → propose → wait)"
 echo "   ✓ /retro — post-task retrospective (project + framework feedback)"
 echo "   ✓ /summary — write high-quality compact option before /compact"
+echo "   ✓ /investigate — multi-agent cross-investigation and proposal review"
 
 # ─── Handle CLAUDE.md ───
 if [ ! -f "CLAUDE.md" ]; then
@@ -480,6 +482,7 @@ if [ "$INSTALL_MODE" = "fresh" ]; then
     echo -e "  ${GREEN}.claude/skills/think/${NC}        ← /think stop and think before coding"
     echo -e "  ${GREEN}.claude/skills/retro/${NC}        ← /retro post-task retrospective"
     echo -e "  ${GREEN}.claude/skills/summary/${NC} ← /summary before compacting"
+    echo -e "  ${GREEN}.claude/skills/investigate/${NC} ← /investigate multi-agent cross-investigation"
     echo -e "  ${GREEN}.claude/settings.json${NC}        ← Hooks configuration"
     echo -e "  ${GREEN}docs/progress.md${NC}             ← Progress log (maintained by Claude)"
     echo -e "  ${GREEN}docs/debug-log.md${NC}            ← Debug log (maintained by Claude)"
@@ -501,6 +504,7 @@ else
     echo -e "  ${GREEN}.claude/skills/think/${NC}        ← /think stop and think before coding"
     echo -e "  ${GREEN}.claude/skills/retro/${NC}        ← /retro post-task retrospective"
     echo -e "  ${GREEN}.claude/skills/summary/${NC} ← /summary before compacting"
+    echo -e "  ${GREEN}.claude/skills/investigate/${NC} ← /investigate multi-agent cross-investigation"
     if [ ! -f "$BACKUP_DIR/settings.json" ] || [ -f ".claude/.cc-discipline-settings-template.json" ]; then
         echo -e "  ${YELLOW}.claude/settings.json${NC}        ← See notes above"
     else

package/lib/doctor.sh

@@ -95,7 +95,7 @@ done
 # 6. Skills
 echo ""
 echo "Skills:"
-for skill in commit self-check evaluate think retro summary; do
+for skill in commit self-check evaluate think retro summary investigate; do
     if [ -d ".claude/skills/${skill}" ]; then
         ok "/${skill}"
     else

package/lib/status.sh

@@ -72,8 +72,9 @@ SKILLS=""
 [ -d ".claude/skills/think" ] && SKILLS="${SKILLS}/think "
 [ -d ".claude/skills/retro" ] && SKILLS="${SKILLS}/retro "
 [ -d ".claude/skills/summary" ] && SKILLS="${SKILLS}/summary "
+[ -d ".claude/skills/investigate" ] && SKILLS="${SKILLS}/investigate "
 SKILL_COUNT=$(echo "$SKILLS" | wc -w | tr -d ' ')
-echo -e "${GREEN}${SKILL_COUNT}/6${NC} (${SKILLS% })"
+echo -e "${GREEN}${SKILL_COUNT}/7${NC} (${SKILLS% })"
 
 # Settings
 echo -n "Settings: "

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-discipline",
-  "version": "2.6.1",
+  "version": "2.8.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/investigate/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: investigate
+description: Multi-agent cross-investigation. Two modes — research (explore from scratch) and review (challenge existing proposal). Spawns parallel agents per dimension, synthesizes with dialectical cross-check.
+---
+
+## Mode detection
+
+Determine which mode based on user input:
+
+- **Research mode** — User gives a topic/question with no existing proposal. Goal: build comprehensive understanding before forming an opinion.
+- **Review mode** — User gives an existing document, proposal, or design. Goal: stress-test it from multiple angles, find blind spots and weaknesses.
+
+State which mode you're using and why.
+
+---
+
+# Research Mode
+
+You are about to research a topic or design a solution. **Do NOT go deep on one angle.** Your job is to see the full picture before converging.
+
+## Step 1: Decompose into dimensions
+
+Before researching anything, identify 3-5 independent dimensions of the problem. Ask yourself:
+- What are the different angles this could be viewed from?
+- What are the stakeholders / affected systems / competing concerns?
+- What would a devil's advocate focus on?
+
+Output the dimensions as a numbered list. Each dimension should be genuinely different, not sub-points of the same thing.
+
+Example for "should we migrate from REST to GraphQL?":
+1. **Performance & scalability** — latency, payload size, caching implications
+2. **Developer experience** — learning curve, tooling, debugging
+3. **Existing ecosystem** — what breaks, migration cost, backward compatibility
+4. **Security** — query complexity attacks, authorization model changes
+5. **Business** — timeline pressure, team skills, client requirements
+
+## Step 2: Parallel investigation
+
+Spawn one subagent per dimension. Each agent:
+- Investigates ONLY its assigned dimension
+- Reads relevant code/docs for that angle
+- Lists findings with evidence (file paths, code references, data)
+- Flags risks and unknowns specific to that dimension
+- Does NOT try to propose a final solution — just reports findings
+
+Launch agents in parallel, not sequentially.
+
+## Step 3: Synthesize
+
+After all agents return, synthesize in the main conversation:
+
+### Cross-check matrix
+For each dimension pair, ask: do the findings conflict?
+
+```
+         | Dim 1 | Dim 2 | Dim 3 | Dim 4 |
+Dim 1    |   —   | conflict? | aligned? | ? |
+Dim 2    |       |   —   | ? | ? |
+...
+```
+
+### Blind spots
+- What did NO agent cover? What's missing from all reports?
+- What assumptions are shared across all dimensions (and might be wrong)?
+- What would someone who disagrees with ALL agents say?
+
+### Integrated findings
+Combine into a unified picture. Flag where dimensions support each other and where they pull in different directions.
+
+## Step 4: Present
+
+Output the integrated findings to the user. For each key finding:
+- Which dimensions support it
+- Which dimensions challenge it
+- Confidence level (strong / moderate / weak)
+- What would change your mind
+
+**Do NOT present a single recommendation without showing the tensions.** The user needs to see the trade-offs, not just your favorite answer.
+
+---
+
+# Review Mode
+
+You have an existing document, proposal, or design to evaluate. **Do NOT just validate it.** Your job is to find what's wrong, what's missing, and what would break.
+
+## Step 1: Read and summarize
+
+Read the document completely. Summarize its core claims and assumptions in 3-5 bullet points. Confirm with the user: "Is this what this document is proposing?"
+
+## Step 2: Decompose into challenge dimensions
+
+Identify 3-5 angles to challenge the proposal from:
+- **Feasibility** — Can this actually be built/done as described? What's underestimated?
+- **Alternatives** — What approaches did the proposal NOT consider? Why might they be better?
+- **Failure modes** — How could this fail? What happens when assumptions are wrong?
+- **Scalability / long-term** — Does this hold up at 10x scale or in 2 years?
+- **Domain-specific** — Does this violate any known constraints of the specific domain?
+
+Adapt dimensions to the document's domain. Not all apply to every proposal.
+
+## Step 3: Parallel challenge agents
+
+Spawn one agent per challenge dimension. Each agent:
+- Takes the proposal's claims at face value, then tries to **break** them
+- Reads relevant code/docs to verify the proposal's assumptions against reality
+- Produces: what's solid, what's questionable, what's wrong, what's missing
+- Includes evidence (code references, counterexamples, data)
+
+## Step 4: Synthesize review
+
+### Verdict per claim
+For each core claim from Step 1:
+- **Holds** — evidence supports it
+- **Questionable** — partially true but has gaps
+- **Wrong** — contradicted by evidence
+- **Unverifiable** — no way to confirm from available information
+
+### Blind spots
+What did the document completely fail to consider?
+
+### Strongest objection
+If you had to argue AGAINST this proposal in one paragraph, what would you say?
+
+### Constructive output
+Don't just tear it apart. For each issue found, suggest what would fix it.
+
+---
+
+## When to use this skill
+
+- Researching a technology choice or architectural decision
+- Investigating a complex bug with multiple possible root causes
+- Evaluating a migration or major refactor
+- **Reviewing an existing proposal, RFC, design doc, or plan**
+- **Stress-testing your own plan before presenting it to stakeholders**
+- Any situation where you catch yourself going deep on one angle and ignoring others
+- When the user says "you're being narrow" or "what about X?" — that's a sign you needed this from the start

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]