cc-discipline 2.7.0 → 2.8.1

package/global/CLAUDE.md

@@ -33,6 +33,7 @@ Don't skip the first three steps and jump straight to the fourth.
 - 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.7.0",
+  "version": "2.8.1",
   "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
   "bin": {
     "cc-discipline": "bin/cli.sh"

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

@@ -0,0 +1,192 @@
+---
+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.
+- **Simulate mode** — User gives a plan and wants to "dry run" it. Goal: walk through execution step by step, let hidden problems surface naturally.
+
+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.
+
+---
+
+# Simulate Mode
+
+You have a plan or proposal. Instead of analyzing it on paper, **walk through it as if you're actually executing it**, step by step. Let problems surface naturally.
+
+## Step 1: Extract execution steps
+
+Read the plan and break it into concrete sequential steps. For each step, identify:
+- What it requires (inputs, resources, preconditions)
+- What it produces (outputs, state changes)
+- What it assumes
+
+Present the steps and confirm with the user: "Is this the execution sequence?"
+
+## Step 2: Assign simulation agents
+
+Spawn one agent per phase or critical step. Each agent:
+- **Actually attempts to execute** (or traces through execution) of their assigned step
+- Works with real files, real code, real environment where possible
+- If can't actually execute (e.g., deployment plan), does a detailed walkthrough: "At this point I would need X, but looking at the current state, X is not available because..."
+- Reports for each step:
+  - **Went as planned** — step worked / would work as described
+  - **Missing precondition** — "Step 3 assumes X exists, but step 2 doesn't create it"
+  - **Harder than expected** — "This was described as 'configure Y' but actually requires Z, which takes much longer"
+  - **Hidden dependency** — "This step silently depends on A, which the plan doesn't mention"
+  - **Order problem** — "This needs to happen before step N, not after"
+  - **Ambiguity** — "The plan says 'set up the database' but doesn't specify which schema, migration, or seed data"
+
+## Step 3: Compile discoveries
+
+After all agents return, compile a simulation report:
+
+### Execution timeline
+Show the steps as actually executed (vs. as planned). Highlight where reality diverged from plan.
+
+### Issues discovered
+For each issue:
+- **Severity**: blocker / significant / minor
+- **When discovered**: which step
+- **Root cause**: why the plan missed this
+- **Fix**: specific change to the plan
+
+### Missing steps
+Steps that the plan didn't include but simulation revealed are necessary.
+
+### Revised plan
+Present the original plan with all fixes, missing steps, and reordering applied. Mark what changed and why.
+
+## Step 4: Present to user
+
+Show the simulation report. Let the user decide which fixes to adopt. The revised plan is a suggestion, not a mandate.
+
+---
+
+## 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**
+- **Simulating execution of a plan before committing to it — technical, engineering, or operational**
+- 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