mindsystem-cc 3.11.0 → 3.12.0

package/agents/ms-plan-writer.md

@@ -15,7 +15,7 @@ Your job: Transform task lists into parallel-optimized PLAN.md files with proper
 
 **What you receive:**
 - Task list with needs/creates/tdd_candidate flags
-- Phase context (number, name, goal, directory, requirements, depth)
+- Phase context (number, name, goal, directory, requirements)
 - Project references (paths to STATE, ROADMAP, CONTEXT, prior summaries)
 - Relevant learnings from past work (debug resolutions, adhoc insights, established patterns, prior decisions, curated cross-milestone learnings)
 
@@ -62,7 +62,6 @@ The orchestrator provides structured XML:
   <phase_dir>.planning/phases/03-authentication</phase_dir>
   <phase_goal>Users can securely access accounts</phase_goal>
   <requirements>AUTH-01, AUTH-02</requirements>
-  <depth>standard</depth>
   <subsystem_hint>auth</subsystem_hint>
 </phase_context>
 
@@ -206,14 +205,6 @@ If any plan exceeds:
 - 10+ files: Split by subsystem
 - Complex domain (auth, payments): Consider extra split
 
-**Depth calibration:**
-| Depth | Plans/Phase | Tasks/Plan |
-|-------|-------------|------------|
-| Quick | 1-3 | 2-3 |
-| Standard | 3-5 | 2-3 |
-| Comprehensive | 5-10 | 2-3 |
-
-Tasks/plan is constant. Depth affects plan count, not size.
 </step>
 
 <step name="write_plan_files">

package/agents/ms-roadmapper.md

@@ -327,18 +327,6 @@ Track coverage as you go.
 - New milestone: Start at 1
 - Continuing milestone: Check existing phases, start at last + 1
 
-## Depth Calibration
-
-Read depth from config.json. Depth controls compression tolerance.
-
-| Depth | Typical Phases | What It Means |
-|-------|----------------|---------------|
-| Quick | 3-5 | Combine aggressively, critical path only |
-| Standard | 5-8 | Balanced grouping |
-| Comprehensive | 8-12 | Let natural boundaries stand |
-
-**Key:** Derive phases from work, then apply depth as compression guidance. Don't pad small projects or compress complex ones.
-
 ## Good Phase Patterns
 
 **Foundation → Features → Enhancement**
@@ -449,7 +437,6 @@ When presenting to user for approval:
 ## ROADMAP DRAFT
 
 **Phases:** [N]
-**Depth:** [from config]
 **Coverage:** [X]/[Y] requirements mapped
 
 ### Phase Structure
@@ -510,7 +497,7 @@ Orchestrator provides:
 - PROJECT.md content (core value, constraints)
 - research/FEATURES.md content (if exists - feature categorization)
 - research/SUMMARY.md content (if exists - phase suggestions)
-- config.json (depth setting, starting phase number)
+- config.json (starting phase number)
 
 Parse and confirm understanding before proceeding.
 
@@ -552,8 +539,6 @@ Apply phase identification methodology:
 1. Group requirements by natural delivery boundaries
 2. Identify dependencies between groups
 3. Create phases that complete coherent capabilities
-4. Check depth setting for compression guidance
-
 ## Step 5: Derive Success Criteria and Pre-Work Flags
 
 For each phase, apply goal-backward:
@@ -629,7 +614,6 @@ When files are written and returning to orchestrator:
 ### Summary
 
 **Phases:** {N}
-**Depth:** {from config}
 **Coverage:** {X}/{X} requirements mapped ✓
 
 | Phase | Goal | Requirements |
@@ -774,7 +758,6 @@ Roadmap is complete when:
 - [ ] All v1 requirements extracted with IDs
 - [ ] Research context loaded (if exists)
 - [ ] Phases derived from requirements (not imposed)
-- [ ] Depth calibration applied
 - [ ] Dependencies between phases identified
 - [ ] Success criteria derived for each phase (2-5 observable behaviors)
 - [ ] Success criteria cross-checked against requirements (gaps resolved)

package/commands/ms/design-phase.md

@@ -109,14 +109,7 @@ If exists, extract:
 
 **3c. Optional context — project UI skill:**
 
-Discover project-level skills:
-```bash
-ls .claude/skills/*/SKILL.md 2>/dev/null
-```
-
-If skills found, read the YAML frontmatter (name + description) of each SKILL.md. Identify any skill whose description indicates it provides UI implementation patterns (screens, widgets, components, theming, spacing, visual patterns).
-
-If a UI skill is found, read its full content. Extract aesthetic patterns (colors, components, spacing, typography) for the `<existing_aesthetic>` block passed to ms-designer.
+Before proceeding, check your available skills for one that provides domain expertise relevant to this project's UI implementation patterns. If found, invoke it via the Skill tool and extract aesthetic patterns (colors, components, spacing, typography) for the `<existing_aesthetic>` block passed to ms-designer.
 
 **3d. Optional context - codebase analysis:**
 
@@ -185,7 +178,7 @@ Follow mockup-generation workflow:
 4. Present directions to user for approval/tweaking
 5. Read platform template (mobile or web)
 6. Spawn 3 x ms-mockup-designer agents in parallel
-7. Present mockup file paths — user opens in browser
+7. Generate comparison page, open in browser, and present to user
 8. Handle selection (single pick, combine, tweak, more variants, or skip)
 9. Extract CSS specs from chosen variant into `<mockup_direction>` block
 

package/commands/ms/help.md

@@ -196,14 +196,9 @@ Execute all unexecuted plans in a phase with wave-based parallelization.
 - Spawns parallel agents for independent plans
 - Resumes automatically from interrupted execution
 - Creates SUMMARY.md for each completed plan
-- Respects max_concurrent_agents from config.json
 
 Usage: `/ms:execute-phase 5`
 
-Options (via `.planning/config.json` parallelization section):
-- `max_concurrent_agents`: Limit parallel agents (default: 3)
-- `min_plans_for_parallel`: Minimum plans to trigger parallelization (default: 2)
-
 ### Verification
 
 **`/ms:check-phase <number>`**

package/commands/ms/new-project.md

@@ -215,46 +215,9 @@ Do not compress. Capture everything gathered.
 
 </step>
 
-<step name="workflow_preferences">
-
-Ask workflow preferences in a single AskUserQuestion call (2 questions):
-
-Use AskUserQuestion with questions array:
-
-```
-questions: [
-  {
-    header: "Depth",
-    question: "How thorough should planning be?",
-    multiSelect: false,
-    options: [
-      { label: "Quick", description: "Ship fast (3-5 phases, 1-3 plans each)" },
-      { label: "Standard (Recommended)", description: "Balanced scope and speed (5-8 phases, 3-5 plans each)" },
-      { label: "Comprehensive", description: "Thorough coverage (8-12 phases, 5-10 plans each)" }
-    ]
-  },
-  {
-    header: "Execution",
-    question: "Run plans in parallel?",
-    multiSelect: false,
-    options: [
-      { label: "Parallel (Recommended)", description: "Independent plans run simultaneously" },
-      { label: "Sequential", description: "One plan at a time" }
-    ]
-  }
-]
-```
-
-**Notes:**
-- Depth controls compression tolerance, not artificial inflation
-- Parallelization spawns multiple agents for independent plans
-- All settings can be changed later in config.json
-
-</step>
-
 <step name="config">
 
-Create `.planning/config.json` with chosen depth, parallelization, and subsystems using `templates/config.json` structure.
+Create `.planning/config.json` with subsystems and code_review using `templates/config.json` structure.
 
 **Subsystems:** Derive 5-10 initial subsystems from the project context gathered during questioning. These are short, lowercase identifiers for the major functional areas of the project.
 
@@ -263,7 +226,7 @@ Examples by project type:
 - SaaS: `["auth", "dashboard", "analytics", "billing", "notifications", "ui", "api", "database"]`
 - Mobile app: `["auth", "onboarding", "feed", "messaging", "profile", "media", "api", "storage"]`
 
-Place `subsystems` array as the first field in config.json (before `depth`). These values are used throughout the system for consistent categorization of summaries, debug docs, and adhoc work.
+These values are used throughout the system for consistent categorization of summaries, debug docs, and adhoc work.
 
 </step>
 
@@ -340,7 +303,7 @@ Update `.planning/STATE.md` Last Command field (if STATE.md exists):
 - [ ] PROJECT.md captures full context with evolutionary structure
 - [ ] Requirements initialized as hypotheses (greenfield) or with inferred Validated (brownfield)
 - [ ] Key Decisions table initialized
-- [ ] config.json has depth and parallelization settings
+- [ ] config.json has subsystems and code_review settings
 - [ ] All committed to git
 
 </success_criteria>

package/commands/ms/review-design.md

@@ -119,14 +119,7 @@ ls .planning/phases/${PHASE_ARG}-*/*-DESIGN.md 2>/dev/null
 
 **Project UI skill (if exists):**
 
-Discover project-level skills:
-```bash
-ls .claude/skills/*/SKILL.md 2>/dev/null
-```
-
-If skills found, read the YAML frontmatter (name + description) of each SKILL.md. Identify any skill whose description indicates it provides UI implementation patterns (screens, widgets, components, theming, spacing, visual patterns).
-
-If a UI skill is found, load as authoritative source for existing patterns.
+Check your available skills for one that provides domain expertise relevant to this project's UI implementation patterns. If found, invoke it via the Skill tool and use as authoritative source for existing patterns.
 
 **Codebase analysis:**
 - Detect platform (Flutter, React, etc.)

package/mindsystem/references/scope-estimation.md

@@ -204,38 +204,6 @@ Waves: [01, 02, 03] (all parallel)
 **3 tasks:** Simple ~45%, Medium ~75% (risky), Complex 120% (impossible)
 </estimating_context>
 
-<depth_calibration>
-**Depth controls compression tolerance, not artificial inflation.**
-
-| Depth | Typical Phases | Typical Plans/Phase | Tasks/Plan |
-|-------|----------------|---------------------|------------|
-| Quick | 3-5 | 1-3 | 2-3 |
-| Standard | 5-8 | 3-5 | 2-3 |
-| Comprehensive | 8-12 | 5-10 | 2-3 |
-
-Tasks/plan is CONSTANT at 2-3. The 50% context rule applies universally.
-
-**Key principle:** Derive from actual work. Depth determines how aggressively you combine things, not a target to hit.
-
-- Comprehensive auth = 8 plans (because auth genuinely has 8 concerns)
-- Comprehensive "add favicon" = 1 plan (because that's all it is)
-
-Don't pad small work to hit a number. Don't compress complex work to look efficient.
-
-**Comprehensive depth example:**
-Auth system at comprehensive depth = 8 plans (not 3 big ones):
-- 01: DB models (2 tasks)
-- 02: Password hashing (2 tasks)
-- 03: JWT generation (2 tasks)
-- 04: JWT validation middleware (2 tasks)
-- 05: Login endpoint (2 tasks)
-- 06: Register endpoint (2 tasks)
-- 07: Protected route patterns (2 tasks)
-- 08: Auth UI components (3 tasks)
-
-Each plan: fresh context, peak quality. More plans = more thoroughness, same quality per plan.
-</depth_calibration>
-
 <summary>
 **2-3 tasks, 50% context target:**
 - All tasks: Peak quality
@@ -246,7 +214,6 @@ Each plan: fresh context, peak quality. More plans = more thoroughness, same qua
 
 **The rules:**
 - If in doubt, split. Quality over consolidation.
-- Depth increases plan COUNT, never plan SIZE.
 - Vertical slices over horizontal layers.
 - Explicit dependencies via `depends_on` frontmatter.
 - Autonomous plans get parallel execution.

package/mindsystem/templates/config.json

@@ -1,16 +1,5 @@
 {
   "subsystems": [],
-  "depth": "standard",
-  "parallelization": {
-    "enabled": true,
-    "plan_level": true,
-    "max_concurrent_agents": 3,
-    "min_plans_for_parallel": 2
-  },
-  "safety": {
-    "always_confirm_destructive": true,
-    "always_confirm_external_services": true
-  },
   "code_review": {
     "adhoc": null,
     "phase": null,

package/mindsystem/templates/roadmap.md

@@ -121,7 +121,7 @@ Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 
 <guidelines>
 **Initial planning (v1.0):**
-- Phase count depends on depth setting (quick: 3-5, standard: 5-8, comprehensive: 8-12)
+- Phase count derived from actual work (not a target number)
 - Each phase delivers something coherent
 - Phases can have 1+ plans (split if >3 tasks or multiple subsystems)
 - Plans use naming: {phase}-{plan}-PLAN.md (e.g., 01-02-PLAN.md)

package/mindsystem/workflows/execute-phase.md

@@ -170,7 +170,6 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
        <context>
        Plan: @{plan_path}
        Project state: @.planning/STATE.md
-       Config: @.planning/config.json (if exists)
        </context>
 
        <success_criteria>

package/mindsystem/workflows/execute-plan.md

@@ -77,12 +77,6 @@ SUMMARY naming follows same pattern:
 
 Confirm with user if ambiguous.
 
-<config-check>
-```bash
-cat .planning/config.json 2>/dev/null
-```
-</config-check>
-
 ```
 ⚡ Auto-approved: Execute {phase}-{plan}-PLAN.md
 [Plan X of Y for Phase Z]

package/mindsystem/workflows/mockup-generation.md

@@ -87,16 +87,22 @@ Task(prompt=assembled_context, subagent_type="ms-mockup-designer", description="
 </step>
 
 <step name="present_mockups">
-After all 3 agents return, display file paths:
+After all 3 agents return, generate comparison page and open it:
+
+```bash
+uv run ~/.claude/mindsystem/scripts/compare_mockups.py "${PHASE_DIR}/mockups"
+open "${PHASE_DIR}/mockups/comparison.html"
+```
+
+Display summary:
 
 ```markdown
-3 mockup variants generated:
+3 mockup variants generated — comparison page opened in browser.
 
+Individual variants for reference:
 - **A: {Direction A name}** — `.planning/phases/{phase}-{slug}/mockups/variant-a.html`
 - **B: {Direction B name}** — `.planning/phases/{phase}-{slug}/mockups/variant-b.html`
 - **C: {Direction C name}** — `.planning/phases/{phase}-{slug}/mockups/variant-c.html`
-
-Open these in your browser to compare.
 ```
 
 Use AskUserQuestion:

package/mindsystem/workflows/plan-phase.md

@@ -494,43 +494,16 @@ External service indicators:
 Note external services for risk scoring.
 
 <output_format>
-**After task identification, produce structured task list for handoff:**
+**Present a concise numbered task summary for the user:**
 
-```xml
-<task_list>
-  <task id="1">
-    <name>Create User model</name>
-    <type>auto</type>
-    <needs>nothing</needs>
-    <creates>src/models/user.ts</creates>
-    <tdd_candidate>false</tdd_candidate>
-    <action_hint>Define User type with id, email, createdAt</action_hint>
-    <verify_hint>tsc --noEmit passes</verify_hint>
-    <done_hint>User type exportable</done_hint>
-  </task>
-  <task id="2">
-    <name>Create login endpoint</name>
-    <type>auto</type>
-    <needs>src/models/user.ts</needs>
-    <creates>src/app/api/auth/login/route.ts</creates>
-    <tdd_candidate>true</tdd_candidate>
-    <action_hint>POST endpoint with bcrypt validation</action_hint>
-    <verify_hint>curl returns 200 with valid credentials</verify_hint>
-    <done_hint>Login works with valid credentials</done_hint>
-  </task>
-</task_list>
-```
+### Tasks Identified
+
+1. **Create User model** → `src/models/user.ts` (no dependencies)
+2. **Create login endpoint** → `src/app/api/auth/login/route.ts` (needs: Task 1) [TDD]
+
+Format: numbered list with task name, key files, dependency hint, and `[TDD]` flag if applicable. No XML.
 
-Each task captures:
-- `id`: Sequential identifier
-- `name`: Action-oriented task name
-- `type`: auto
-- `needs`: Files/types this task requires (or "nothing")
-- `creates`: Files/types this task produces (or "nothing")
-- `tdd_candidate`: true if should be TDD plan
-- `action_hint`: Brief implementation guidance (subagent expands)
-- `verify_hint`: How to verify completion
-- `done_hint`: Acceptance criteria
+**Retain full task details internally.** For each task, maintain in your analysis: id, name, type, needs, creates, tdd_candidate, action_hint, verify_hint, done_hint. These are needed for the handoff step — they just don't need to be displayed.
 </output_format>
 </step>
 
@@ -545,7 +518,7 @@ Assemble handoff payload:
 
 ```xml
 <task_list>
-  {tasks from break_into_tasks}
+  {Construct full task XML from your analysis. Each task needs: id, name, type, needs, creates, tdd_candidate, action_hint, verify_hint, done_hint. Use the same XML schema the plan-writer expects.}
 </task_list>
 
 <phase_context>
@@ -554,7 +527,6 @@ Assemble handoff payload:
   <phase_dir>.planning/phases/{PHASE}-{PHASE_NAME}</phase_dir>
   <phase_goal>{goal from ROADMAP}</phase_goal>
   <requirements>{REQ-IDs from ROADMAP}</requirements>
-  <depth>{from config.json or "standard"}</depth>
   <subsystem_hint>{best-match subsystem from config.json}</subsystem_hint>
 </phase_context>
 

package/mindsystem/workflows/transition.md

@@ -50,14 +50,6 @@ ls .planning/phases/XX-current/*-SUMMARY.md 2>/dev/null | sort
 - If counts match: all plans complete
 - If counts don't match: incomplete
 
-<config-check>
-
-```bash
-cat .planning/config.json 2>/dev/null
-```
-
-</config-check>
-
 **If all plans complete:**
 
 ```
@@ -71,8 +63,7 @@ Proceed directly to cleanup_handoff step.
 
 **If plans incomplete:**
 
-**SAFETY RAIL: always_confirm_destructive applies here.**
-Skipping incomplete plans is destructive — ALWAYS prompt regardless of mode.
+**SAFETY RAIL: Skipping incomplete plans is destructive — always confirm.**
 
 Present:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mindsystem-cc",
-  "version": "3.11.0",
+  "version": "3.12.0",
   "description": "A meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.",
   "bin": {
     "mindsystem-cc": "bin/install.js"