mindsystem-cc 3.10.1 → 3.11.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,7 +14,7 @@ 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
+- Task list with needs/creates/tdd_candidate flags
 - Phase context (number, name, goal, directory, requirements, depth)
 - 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>
@@ -149,8 +147,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 +155,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:**
@@ -233,7 +229,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 +254,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-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,16 @@ 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:**
 
+Discover project-level skills:
 ```bash
-# Check for implement-ui skill
-ls .claude/skills/*implement-ui* 2>/dev/null
+ls .claude/skills/*/SKILL.md 2>/dev/null
 ```
 
-If exists, load it as the authoritative source of existing patterns.
+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.
 
 **3d. Optional context - codebase analysis:**
 
@@ -140,7 +142,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.
@@ -240,15 +242,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 +395,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,7 +194,6 @@ 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
@@ -203,7 +202,6 @@ 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

package/commands/ms/review-design.md

@@ -117,12 +117,16 @@ ls .planning/phases/${PHASE_ARG}-*/*-DESIGN.md 2>/dev/null
 
 ### Step 2.3: Optional Context
 
-**implement-ui skill (if exists):**
+**Project UI skill (if exists):**
+
+Discover project-level skills:
 ```bash
-ls .claude/skills/*implement-ui* 2>/dev/null
+ls .claude/skills/*/SKILL.md 2>/dev/null
 ```
 
-If exists, load as authoritative source for existing patterns.
+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.
 
 **Codebase analysis:**
 - Detect platform (Flutter, React, etc.)
@@ -192,7 +196,7 @@ Apply quality-forcing patterns from `ai-driven-ui-design-system.md`:
 
 ### 3.5: Pattern Alignment
 
-If implement-ui skill or codebase patterns exist:
+If project UI skill or codebase patterns exist:
 - Check for consistent color usage
 - Check for consistent component patterns
 - Check for consistent spacing scale
@@ -478,7 +482,7 @@ Apply these patterns throughout the review:
 
 <success_criteria>
 - [ ] Target code scope clarified (via arguments or AskUserQuestion)
-- [ ] Context chain loaded (PROJECT.md, DESIGN.md if exists, implement-ui skill)
+- [ ] Context chain loaded (PROJECT.md, DESIGN.md if exists, project UI skill)
 - [ ] Code analyzed across all quality dimensions
 - [ ] Retroactive DESIGN.md created if missing
 - [ ] Improvements presented with benefits AND trade-offs

package/commands/ms/verify-work.md

@@ -41,7 +41,7 @@ Phase: $ARGUMENTS (optional)
 2. **Check for active UAT sessions** — Resume or start new
 3. **Find SUMMARY.md files** for the phase
 4. **Extract testable deliverables** from summaries
-5. **Classify tests by mock requirements** — Infer mock_type from test descriptions
+5. **Classify tests by mock requirements** — Use SUMMARY.md mock_hints when available; classify inline with keyword heuristics when absent. Confirm data availability with user before batching.
 6. **Group into batches** — By mock type, max 4 per batch, no-mock tests first
    - If any tests require mocks: Read `~/.claude/mindsystem/references/mock-patterns.md` and `~/.claude/mindsystem/workflows/generate-mocks.md` for mock generation guidance
 7. **For each batch:**

package/mindsystem/references/design-directions.md

@@ -93,7 +93,7 @@ Rule: If you can only tell variants apart by squinting at colors, they are not d
 
 <existing_aesthetic_constraint>
 
-When the project has an existing visual aesthetic (implement-ui skill, established codebase patterns):
+When the project has an existing visual aesthetic (project UI skill, established codebase patterns):
 
 **ALL variants use the same colors, fonts, and component shapes.** Directions differ ONLY in:
 - Layout and spatial organization