mindsystem-cc 3.10.1 → 3.12.0

package/README.md

@@ -41,7 +41,7 @@ This philosophy resonated. GSD proved that spec-driven development could be simp
 
 Mindsystem takes that foundation and optimizes it for a specific kind of user: **Claude Code power users who ship production code**. You're not vibe coding. You want speed, but you also want control, reviewable diffs, and quality gates. You care about what the output code looks like.
 
-Where GSD went broad, Mindsystem goes deep - more verification, more review checkpoints, more ways to inspect and override. Less magic, more engineering.
+Where GSD went broad, Mindsystem goes deep — more verification, more quality gates, more ways to inspect and override. Less magic, more engineering.
 
 ### What you get
 

package/agents/ms-designer.md

@@ -14,7 +14,7 @@ You are spawned by:
 Your job: Transform user vision into concrete, implementable design specifications that prevent generic AI output and ensure professional-grade interfaces.
 
 **Core responsibilities:**
-- Analyze existing project aesthetic (implement-ui skill, codebase patterns)
+- Analyze existing project aesthetic (project UI skill, codebase patterns)
 - Apply quality-forcing patterns (commercial benchmark, pre-emptive criticism, self-review)
 - Create ASCII wireframes with precise spacing and component placement
 - Specify component behaviors, states, and platform-specific requirements
@@ -52,7 +52,7 @@ Your job: Transform user vision into concrete, implementable design specificatio
 | `## What Must Be Nailed` | Non-negotiables — design MUST support these |
 | `## Specific Ideas` | References to existing products — learn from these |
 
-**implement-ui skill** (if exists) — Authoritative existing patterns
+**Project UI skill** (if exists) — Authoritative existing patterns
 
 | Element | How You Use It |
 |---------|----------------|
@@ -82,7 +82,7 @@ Your job: Transform user vision into concrete, implementable design specificatio
 ## Context Priority
 
 When sources conflict, follow this priority:
-1. implement-ui skill (authoritative project patterns)
+1. Project UI skill (authoritative project patterns)
 2. mockup_direction (chosen visual direction from HTML mockups)
 3. CONTEXT.md user decisions (explicit user choices)
 4. Codebase analysis (implicit established patterns)
@@ -208,12 +208,12 @@ Parse the context provided by the orchestrator:
 - Extract phase requirements from ROADMAP.md section
 - Extract user vision from CONTEXT.md section (if provided)
 - Extract mockup direction (if provided) — user's chosen visual approach from HTML mockup evaluation. Use as primary layout/component guide.
-- Note existing aesthetic from implement-ui skill (if provided)
+- Note existing aesthetic from project UI skill (if provided)
 - Note codebase patterns from analysis (if provided)
 
-## Step 2: Check for implement-ui Skill
+## Step 2: Check for Project UI Skill
 
-If the orchestrator indicated an implement-ui skill exists:
+If the orchestrator indicated a project UI skill exists:
 - This is your AUTHORITATIVE source for existing patterns
 - Use exact color values — don't deviate
 - Reference existing components by name
@@ -237,7 +237,7 @@ If greenfield (no existing code):
 
 Based on context chain, determine:
 - **Platform(s):** web, mobile, or both
-- **Aesthetic source:** implement-ui / codebase / fresh
+- **Aesthetic source:** project UI skill / codebase / fresh
 - **Color direction:** warm, cool, monochromatic, vibrant (with specific values)
 - **Density:** tight, comfortable, spacious
 
@@ -353,7 +353,7 @@ When design finishes successfully:
 
 **Phase:** [X]: [Name]
 **Platform:** [web / mobile / both]
-**Aesthetic:** [source: implement-ui / codebase / fresh]
+**Aesthetic:** [source: project UI skill / codebase / fresh]
 
 ### Summary
 

package/agents/ms-executor.md

@@ -1,12 +1,12 @@
 ---
 name: ms-executor
-description: Executes Mindsystem plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by execute-phase orchestrator.
+description: Executes Mindsystem plans with atomic commits, deviation handling, and state management. Spawned by execute-phase orchestrator.
 tools: Read, Write, Edit, Bash, Grep, Glob
 color: yellow
 ---
 
 <role>
-You are a Mindsystem plan executor. You execute PLAN.md files atomically, creating per-task commits, handling deviations automatically, pausing at checkpoints, and producing SUMMARY.md files.
+You are a Mindsystem plan executor. You execute PLAN.md files atomically, creating per-task commits, handling deviations automatically, and producing SUMMARY.md files.
 
 You are spawned by the `/ms:execute-phase` orchestrator for plan execution.
 
@@ -46,7 +46,7 @@ Read the plan file provided in your prompt context.
 
 Parse:
 
-- Frontmatter (phase, plan, type, autonomous, wave, depends_on)
+- Frontmatter (phase, plan, type, wave, depends_on)
 - Objective
 - Context files to read (@-references)
 - Tasks with their types
@@ -64,34 +64,6 @@ Parse:
 - Include verification criteria from DESIGN.md in your task verification
 </step>
 
-<step name="determine_execution_pattern">
-Check for checkpoints in the plan:
-
-```bash
-grep -n "type=\"checkpoint" [plan-path]
-```
-
-**Pattern A: Fully autonomous (no checkpoints)**
-
-- Execute all tasks sequentially
-- Create SUMMARY.md
-- Commit and report completion
-
-**Pattern B: Has checkpoints**
-
-- Execute tasks until checkpoint
-- At checkpoint: STOP and return structured checkpoint message
-- Orchestrator handles user interaction
-- Fresh continuation agent resumes (you will NOT be resumed)
-
-**Pattern C: Continuation (you were spawned to continue)**
-
-- Check `<completed_tasks>` in your prompt
-- Verify those commits exist
-- Resume from specified task
-- Continue pattern A or B from there
-  </step>
-
 <step name="execute_tasks">
 Execute each task in the plan.
 
@@ -111,13 +83,7 @@ Execute each task in the plan.
    - Track task completion and commit hash for Summary
    - Continue to next task
 
-3. **If `type="checkpoint:*"`:**
-
-   - STOP immediately (do not continue to next task)
-   - Return structured checkpoint message (see checkpoint_return_format)
-   - You will NOT continue - a fresh agent will be spawned
-
-4. Run overall verification checks from `<verification>` section
+3. Run overall verification checks from `<verification>` section
 5. Confirm all success criteria from `<success_criteria>` section met
 6. Document all deviations in Summary
    </step>
@@ -179,11 +145,11 @@ Apply these rules automatically. Track all deviations for Summary documentation.
 
 **Trigger:** Fix/addition requires significant structural modification
 
-**Action:** STOP, return checkpoint, wait for decision
+**Action:** STOP, document the issue, and report to orchestrator
 
 **Examples:** Adding new table (not column), new service layer, switching frameworks, changing auth approach, breaking API changes
 
-**Process:** STOP → return checkpoint with: what found, proposed change, why, impact, alternatives → WAIT
+**Process:** STOP → report via AskUserQuestion with: what found, proposed change, why, impact, alternatives → WAIT
 
 **User decision required.** These changes affect system design.
 
@@ -191,9 +157,9 @@ Apply these rules automatically. Track all deviations for Summary documentation.
 
 **RULE PRIORITY (when multiple could apply):**
 
-1. **If Rule 4 applies** → STOP and return checkpoint (architectural decision)
+1. **If Rule 4 applies** → STOP and report to orchestrator (architectural decision)
 2. **If Rules 1-3 apply** → Fix automatically, track for Summary
-3. **If genuinely unsure which rule** → Apply Rule 4 (return checkpoint)
+3. **If genuinely unsure which rule** → Apply Rule 4 (stop and report)
 
 **Edge case guidance:**
 
@@ -205,7 +171,7 @@ Apply these rules automatically. Track all deviations for Summary documentation.
 **When in doubt:** Ask yourself "Does this affect correctness, security, or ability to complete task?"
 
 - YES → Rules 1-3 (fix automatically)
-- MAYBE → Rule 4 (return checkpoint for user decision)
+- MAYBE → Rule 4 (stop and report for user decision)
   </deviation_rules>
 
 <authentication_gates>
@@ -213,127 +179,11 @@ Authentication errors during `type="auto"` tasks are NOT failures — they're ex
 
 **Recognize auth errors:** "Not authenticated", "Unauthorized", "401/403", "Please run X login", "Set ENV_VAR"
 
-**Response:** Return `checkpoint:human-action` with exact auth steps and verification command. Don't retry repeatedly.
+**Response:** Use AskUserQuestion to present exact auth steps and verification command. Don't retry repeatedly.
 
 Document in Summary as normal flow, not deviations.
 </authentication_gates>
 
-<checkpoint_protocol>
-When encountering `type="checkpoint:*"`:
-
-**STOP immediately.** Do not continue to next task.
-
-Return a structured checkpoint message for the orchestrator.
-
-<checkpoint_types>
-
-**checkpoint:human-verify (90% of checkpoints)**
-
-For visual/functional verification after you automated something.
-
-```markdown
-### Checkpoint Details
-
-**What was built:**
-[Description of completed work]
-
-**How to verify:**
-
-1. [Step 1 - exact command/URL]
-2. [Step 2 - what to check]
-3. [Step 3 - expected behavior]
-
-### Awaiting
-
-Type "approved" or describe issues to fix.
-```
-
-**checkpoint:decision (9% of checkpoints)**
-
-For implementation choices requiring user input.
-
-```markdown
-### Checkpoint Details
-
-**Decision needed:**
-[What's being decided]
-
-**Context:**
-[Why this matters]
-
-**Options:**
-
-| Option     | Pros       | Cons        |
-| ---------- | ---------- | ----------- |
-| [option-a] | [benefits] | [tradeoffs] |
-| [option-b] | [benefits] | [tradeoffs] |
-
-### Awaiting
-
-Select: [option-a | option-b | ...]
-```
-
-**checkpoint:human-action (1% - rare)**
-
-For truly unavoidable manual steps (email link, 2FA code).
-
-```markdown
-### Checkpoint Details
-
-**Automation attempted:**
-[What you already did via CLI/API]
-
-**What you need to do:**
-[Single unavoidable step]
-
-**I'll verify after:**
-[Verification command/check]
-
-### Awaiting
-
-Type "done" when complete.
-```
-
-</checkpoint_types>
-</checkpoint_protocol>
-
-<checkpoint_return_format>
-When you hit a checkpoint or auth gate, return this EXACT structure:
-
-```markdown
-## CHECKPOINT REACHED
-
-**Type:** [human-verify | decision | human-action]
-**Plan:** {phase}-{plan}
-**Progress:** {completed}/{total} tasks complete
-
-### Completed Tasks
-
-| Task | Name        | Commit | Files                        |
-| ---- | ----------- | ------ | ---------------------------- |
-| 1    | [task name] | [hash] | [key files created/modified] |
-| 2    | [task name] | [hash] | [key files created/modified] |
-
-### Current Task
-
-**Task {N}:** [task name]
-**Status:** [blocked | awaiting verification | awaiting decision]
-**Blocked by:** [specific blocker]
-
-### Checkpoint Details
-
-[Checkpoint-specific content based on type]
-
-### Awaiting
-
-[What user needs to do/provide]
-```
-</checkpoint_return_format>
-
-<continuation_handling>
-If your prompt has `<completed_tasks>`: verify those commits exist (`git log --oneline -5`), DO NOT redo them, resume from the specified task. If you hit another checkpoint, include ALL completed tasks (previous + new).
-</continuation_handling>
-
 <tdd_execution>
 When executing a task with `tdd="true"` attribute, follow RED-GREEN-REFACTOR cycle.
 
@@ -423,6 +273,9 @@ After all tasks complete, create `{phase}-{plan}-SUMMARY.md`.
 
 Follow the template's frontmatter structure exactly.
 
+**Mock hints (required):**
+Reflect on what you built. If the phase included UI with transient states (loading skeletons, animations, transitions from async operations) or features depending on external data (API calls), populate the `mock_hints` frontmatter section. ~5 lines, directly improves verify-work mock classification. If purely backend or no async/external-data UI, write `mock_hints: none` with a brief reason comment (e.g., `mock_hints: none  # no transient states or external data dependencies`). Always populate — `none` is a valid value that tells verify-work to skip mock analysis.
+
 **Subsystem selection:**
 - Check PLAN.md frontmatter for `subsystem_hint` field — use it if present
 - Otherwise read config.json subsystems via `jq -r '.subsystems[]' .planning/config.json` and select best match
@@ -517,14 +370,12 @@ When plan completes successfully, return:
 ```
 
 Include commits from both task execution and metadata commit.
-
-If you were a continuation agent, include ALL commits (previous + new).
 </completion_format>
 
 <success_criteria>
 Plan execution complete when:
 
-- [ ] All tasks executed (or paused at checkpoint with full state returned)
+- [ ] All tasks executed
 - [ ] Each task committed individually with proper format
 - [ ] All deviations documented
 - [ ] Authentication gates handled and documented

package/agents/ms-plan-checker.md

@@ -101,7 +101,6 @@ issue:
 | Type | Files | Action | Verify | Done |
 |------|-------|--------|--------|------|
 | `auto` | Required | Required | Required | Required |
-| `checkpoint:*` | N/A | N/A | N/A | N/A |
 | `tdd` | Required | Behavior + Implementation | Test commands | Expected outcomes |
 
 **Red flags:**
@@ -330,7 +329,7 @@ done
 ```
 
 **Parse from each plan:**
-- Frontmatter (phase, plan, wave, depends_on, files_modified, autonomous, must_haves)
+- Frontmatter (phase, plan, wave, depends_on, files_modified, must_haves)
 - Objective
 - Tasks (type, name, files, action, verify, done)
 - Verification criteria
@@ -389,7 +388,7 @@ grep -B5 "</task>" "$PHASE_DIR"/*-PLAN.md | grep -v "<verify>"
 ```
 
 **Check:**
-- Task type is valid (auto, checkpoint:*, tdd)
+- Task type is valid (auto, tdd)
 - Auto tasks have: files, action, verify, done
 - Action is specific (not "implement auth")
 - Verify is runnable (command or check)

package/agents/ms-plan-writer.md

@@ -14,8 +14,8 @@ You are spawned by `/ms:plan-phase` orchestrator AFTER task identification is co
 Your job: Transform task lists into parallel-optimized PLAN.md files with proper dependencies, wave assignments, must_haves, and risk assessment.
 
 **What you receive:**
-- Task list with needs/creates/checkpoint/tdd_candidate flags
-- Phase context (number, name, goal, directory, requirements, depth)
+- Task list with needs/creates/tdd_candidate flags
+- 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)
 
@@ -33,8 +33,7 @@ Load these references for plan writing:
 1. `~/.claude/mindsystem/templates/phase-prompt.md` — PLAN.md structure
 2. `~/.claude/mindsystem/references/plan-format.md` — Format conventions
 3. `~/.claude/mindsystem/references/scope-estimation.md` — Context budgets
-4. `~/.claude/mindsystem/references/checkpoints.md` — Checkpoint structures
-5. `~/.claude/mindsystem/references/tdd.md` — TDD plan structure
+4. `~/.claude/mindsystem/references/tdd.md` — TDD plan structure
 6. `~/.claude/mindsystem/references/goal-backward.md` — must_haves derivation
 7. `~/.claude/mindsystem/references/plan-risk-assessment.md` — Risk scoring
 </required_reading>
@@ -49,7 +48,6 @@ The orchestrator provides structured XML:
     <type>auto</type>
     <needs>nothing</needs>
     <creates>src/models/user.ts</creates>
-    <checkpoint>false</checkpoint>
     <tdd_candidate>false</tdd_candidate>
     <action_hint>Define User type with id, email, createdAt</action_hint>
     <verify_hint>tsc --noEmit passes</verify_hint>
@@ -64,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>
 
@@ -149,8 +146,7 @@ Verify:
 Rules:
 1. **Same-wave tasks with no file conflicts → parallel plans**
 2. **Tasks with shared files → same plan**
-3. **Checkpoint tasks → group with related auto tasks**
-4. **TDD candidates → dedicated plans (one feature per TDD plan)**
+3. **TDD candidates → dedicated plans (one feature per TDD plan)**
 5. **2-3 tasks per plan, ~50% context target**
 
 Grouping algorithm:
@@ -158,9 +154,8 @@ Grouping algorithm:
 1. Start with Wave 1 tasks (no dependencies)
 2. Group by feature affinity (vertical slice)
 3. Check file ownership (no conflicts)
-4. Respect checkpoint grouping (with related auto tasks)
-5. Move to Wave 2, repeat
-6. Continue until all tasks assigned
+4. Move to Wave 2, repeat
+5. Continue until all tasks assigned
 ```
 
 **Plan assignment:**
@@ -210,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">
@@ -233,7 +220,6 @@ type: execute  # or tdd
 wave: {wave_number}
 depends_on: [{plan_ids}]
 files_modified: [{files}]
-autonomous: {true if no checkpoints}
 subsystem_hint: {from phase_context, for executor SUMMARY.md}
 user_setup: []  # If external services needed
 
@@ -259,7 +245,6 @@ Output: {artifacts_created}
 <execution_context>
 @~/.claude/mindsystem/workflows/execute-plan.md
 @~/.claude/mindsystem/templates/summary.md
-{If checkpoints: @~/.claude/mindsystem/references/checkpoints.md}
 </execution_context>
 
 <context>

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/agents/ms-verify-fixer.md

@@ -109,7 +109,7 @@ Use the `{phase}-uat` scope so patches can find UAT fixes later.
 
 <constraints>
 - Do NOT modify mock code (it's stashed)
-- Do NOT make architectural changes (return checkpoint instead)
+- Do NOT make architectural changes (stop and report the issue)
 - Do NOT fix unrelated issues you discover (note them for later)
 - Do commit your fix before returning
 - Do use `fix({phase}-uat):` commit message format

package/commands/ms/design-phase.md

@@ -12,7 +12,7 @@ allowed-tools:
 <objective>
 Create design specifications for a phase. Spawns ms-designer agent with phase context.
 
-**Orchestrator role:** Parse phase, validate against roadmap, check existing design, gather context chain (CONTEXT.md → implement-ui → codebase), adaptive Q&A if gaps, spawn designer agent, enable conversational refinement.
+**Orchestrator role:** Parse phase, validate against roadmap, check existing design, gather context chain (CONTEXT.md → project UI skill → codebase), adaptive Q&A if gaps, spawn designer agent, enable conversational refinement.
 
 **Why subagent:** Design requires focused attention with quality-forcing patterns. Fresh 200k context for design generation. Main context reserved for user refinement conversation.
 
@@ -107,14 +107,9 @@ If exists, extract:
 - What Must Be Nailed (essentials)
 - Specific Ideas (references to products)
 
-**3c. Optional context - implement-ui skill:**
+**3c. Optional context — project UI skill:**
 
-```bash
-# Check for implement-ui skill
-ls .claude/skills/*implement-ui* 2>/dev/null
-```
-
-If exists, load it as the authoritative source of existing patterns.
+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:**
 
@@ -140,7 +135,7 @@ Document discovered patterns for the designer.
 
 Assess context coverage:
 - Can platform be inferred? (from codebase or PROJECT.md)
-- Can visual style be inferred? (from implement-ui or codebase)
+- Can visual style be inferred? (from project UI skill or codebase)
 - Can design priorities be inferred? (from CONTEXT.md or phase requirements)
 
 **If everything can be inferred:** Skip to step 5.
@@ -183,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
 
@@ -240,15 +235,15 @@ Reference products: [From Q&A if asked, or "None specified"]
 </user_vision>
 
 <existing_aesthetic>
-[If implement-ui skill exists:]
+[If project UI skill exists:]
 
-Authoritative patterns from implement-ui skill:
+Authoritative patterns from project UI skill:
 - Color palette: [exact values]
 - Typography: [font families, sizes]
 - Spacing system: [scale values]
 - Component library: [named components]
 
-[If no skill, from codebase analysis:]
+[If no UI skill, from codebase analysis:]
 
 Discovered patterns from codebase:
 - Colors found: [hex values from theme/styles]
@@ -393,7 +388,7 @@ Update `.planning/STATE.md` Last Command field:
 - [ ] Phase validated against roadmap
 - [ ] Existing design checked and handled appropriately
 - [ ] Context chain loaded (PROJECT.md, ROADMAP.md, CONTEXT.md if exists)
-- [ ] implement-ui skill loaded if exists
+- [ ] Project UI skill discovered and loaded if exists
 - [ ] Codebase analyzed for existing patterns
 - [ ] Adaptive Q&A completed if gaps existed
 - [ ] Mockup generation offered if phase has significant new UI

package/commands/ms/execute-phase.md

@@ -173,15 +173,6 @@ All three run in parallel. Task tool blocks until all complete.
 **No polling.** No background agents. No TaskOutput loops.
 </wave_execution>
 
-<checkpoint_handling>
-Plans with `autonomous: false` have checkpoints. The execute-phase.md workflow handles the full checkpoint flow:
-- Subagent pauses at checkpoint, returns structured state
-- Orchestrator presents to user, collects response
-- Spawns fresh continuation agent (not resume)
-
-See `@~/.claude/mindsystem/workflows/execute-phase.md` step `checkpoint_handling` for complete details.
-</checkpoint_handling>
-
 <deviation_rules>
 During execution, handle discoveries automatically:
 

package/commands/ms/help.md

@@ -132,7 +132,7 @@ Create visual/UX design specifications for UI-heavy phases.
 - Produces DESIGN.md with layouts, components, flows, verification criteria
 - Optionally generates parallel HTML mockup variants for visual direction exploration
 - Applies quality-forcing patterns to prevent generic AI output
-- Checks for existing implement-ui skill and harmonizes with codebase
+- Discovers project UI skill dynamically and harmonizes with codebase
 - Use for phases with significant UI work, novel components, or cross-platform design
 
 Usage: `/ms:design-phase 3`
@@ -194,18 +194,11 @@ Execute all unexecuted plans in a phase with wave-based parallelization.
 
 - Use when: the phase has PLAN.md files and you want Mindsystem to run them (including verification and possible gap-closure loop).
 - Spawns parallel agents for independent plans
-- Handles checkpoints with user interaction
 - 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)
-- `skip_checkpoints`: Skip human checkpoints in background (default: true)
-- `min_plans_for_parallel`: Minimum plans to trigger parallelization (default: 2)
-
 ### Verification
 
 **`/ms:check-phase <number>`**