cc-discipline 2.8.0 → 2.8.1

package/package.json

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

@@ -9,6 +9,7 @@ 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.
 
@@ -126,6 +127,59 @@ 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
@@ -133,5 +187,6 @@ Don't just tear it apart. For each issue found, suggest what would fix it.
 - 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