mindsystem-cc 4.4.1 → 4.5.0

package/README.md

@@ -29,11 +29,12 @@ Then `/ms:new-project` to initialize. See the [full walkthrough](#end-to-end-wal
 
 ---
 
-## What's new in v4.4
+## What's new in v4.5
 
-- **User journey browser verification** — end-to-end click/fill/submit testing instead of screenshot-only observation. Catches unreachable pages with no navigation path from the UI.
-- **Single-plan mode (default)** — one plan per phase, eliminating multi-agent orchestration overhead with 1M context windows.
-- **Full phase specification** for add-phase and insert-phase — both commands now derive goal, success criteria, and requirements mapping.
+- **Config-driven skill loading** — configure phase skills once via `/ms:config` instead of interactive prompts at every phase start. Loaded automatically across all workflows.
+- **Browser verification for adhoc work** — `/ms:adhoc` now includes automated browser verification, matching `/ms:execute-phase` visual QA.
+- **Design aesthetic exploration** — design-phase gathers actual design tokens from your codebase instead of shallow grep, producing richer context for mockups.
+- **Plan checker respects single-plan mode** — scope observations become informational, no more suggestions to split plans you intentionally kept together.
 
 See [CHANGELOG.md](CHANGELOG.md) for the complete history.
 
@@ -265,7 +266,7 @@ Unnecessary instructions aren't wasted space — they interfere with the ones th
 
 ### Browser verification
 
-During execute-phase, web projects get automatic visual QA via [agent-browser](https://github.com/anthropics/agent-browser). A checklist is derived from execution summaries, then each route is verified with screenshots and programmatic diagnostics (console logs, JS errors, network failures). Clear mismatches get fixed inline; anything deeper is reported with screenshot evidence for verify-work. Enabled by default — disable per-project via `/ms:config`.
+During execute-phase and `/ms:adhoc`, web projects get automatic visual QA via [agent-browser](https://github.com/anthropics/agent-browser). A checklist is derived from execution summaries, then each route is verified with screenshots and programmatic diagnostics (console logs, JS errors, network failures). Clear mismatches get fixed inline; anything deeper is reported with screenshot evidence for verify-work. Enabled by default — disable per-project via `/ms:config`.
 
 ### Built-in code review
 
@@ -285,7 +286,7 @@ For work that's too coherent for a todo but too small for a full phase. `/ms:adh
 
 ### Project health
 
-`/ms:doctor` runs 10 health checks: subsystem vocabulary, directory structure, milestone naming, knowledge files, CLI wrappers, API keys, version freshness. Fixes are applied in dependency order with atomic commits. Safe to run repeatedly.
+`/ms:doctor` runs 14 health checks: subsystem vocabulary, directory structure, milestone naming, phase archival, knowledge files, phase summaries, PLAN cleanup, CLI wrappers, API keys, phase directory naming, browser verification prerequisites, roadmap format, phase skills, version freshness. Fixes are applied in dependency order with atomic commits. Safe to run repeatedly.
 
 ### Smart routing
 
@@ -462,6 +463,15 @@ Mindsystem stores project config in `.planning/config.json`. Run `/ms:config` to
   // Populated by /ms:new-project, refined by /ms:doctor.
   "subsystems": ["auth", "api", "database"],
 
+  // Skills loaded per phase. Names match installed skill directories.
+  // Configured via /ms:config. Loaded automatically during each phase.
+  "skills": {
+    "discuss": [],
+    "design": [],
+    "research": [],
+    "plan": []
+  },
+
   // Code review after execution. One reviewer per tier.
   //   null                  → falls back to "ms-code-simplifier" (default)
   //   "ms-code-reviewer"    → structural: architecture and design issues
@@ -512,7 +522,7 @@ Full docs live in `/ms:help`.
 | `/ms:help` | Show the full command reference |
 | `/ms:progress` | Show where you are and what to run next |
 | `/ms:new-project` | Initialize `.planning/` and capture project intent |
-| `/ms:config` | Configure code reviewers, mockups, plan mode, gitignore, git remote |
+| `/ms:config` | Configure skills, code reviewers, mockups, plan mode, gitignore, git remote |
 | `/ms:map-codebase` | Document existing repo's stack, structure, and conventions |
 | `/ms:research-milestone` | Milestone-scoped research saved to `.planning/MILESTONE-RESEARCH.md` |
 | `/ms:create-roadmap` | Define requirements and create phases mapped to them |

package/agents/ms-compounder.md

@@ -25,6 +25,10 @@ You are a Mindsystem knowledge compounder spawned by the compound workflow to up
 
 </inputs>
 
+<references>
+@~/.claude/mindsystem/references/knowledge-quality.md
+</references>
+
 <extraction_guide>
 
 ## What to Extract From Raw Changes
@@ -59,15 +63,19 @@ ls .planning/knowledge/*.md 2>/dev/null
 
 Read only the files matching confirmed affected subsystems. On first run, `.planning/knowledge/` may not exist — start fresh.
 
-## Step 3: Extract Knowledge From Changes
+## Step 3: Classify and Extract Knowledge From Changes
+
+Classify each change signal before extraction:
 
-Apply the extraction guide to the change content.
+| Signal Type | Action |
+|------------|--------|
+| Decision with rationale (chose X over Y because Z) | Extract |
+| Structural pattern (how components connect, data flows) | Extract |
+| Non-obvious pitfall or gotcha | Extract |
+| Code-derivable detail (schema fields, component props, config values) | Skip |
+| Implementation description without alternative considered | Skip |
 
-Focus on:
-- **Decisions with rationale** — not just "used X" but "used X because Y"
-- **Structural patterns** — how components connect, data flows, API contracts
-- **Gotchas discovered** — failure modes, workarounds, non-obvious behavior
-- **Significant file changes** — new entry points, renamed modules, deleted code
+Apply the extraction guide to change content that passes classification. Then apply the knowledge-quality.md filtering test — drop entries that fail. For entries that pass, check existing knowledge files for cross-subsystem duplication — use `(see {subsystem})` cross-references instead of duplicating.
 
 ## Step 4: Merge Into Existing Knowledge
 
@@ -81,6 +89,8 @@ For each affected subsystem, edit the knowledge file to reflect current state:
 
 Use `Edit` for existing files — targeted changes preserve content you haven't inspected. Use `Write` only for new files (subsystem has no knowledge file yet).
 
+While merging, review the touched file's existing entries through the same quality gate. Remove entries that are now code-derivable, superseded by new decisions, or duplicated in another subsystem's knowledge file. This is opportunistic maintenance during normal writes, not a full audit.
+
 ## Step 5: Update Knowledge Files and Return Report
 
 ```bash
@@ -142,4 +152,6 @@ If changes suggest a subsystem not in the confirmed list, note it as a proposal
 - [ ] Report returned with update counts
 - [ ] Empty sections omitted from knowledge files
 - [ ] Existing knowledge files read for affected subsystems only
+- [ ] Extracted entries pass the knowledge-quality.md filtering test
+- [ ] No cross-subsystem duplication (cross-references used instead)
 </success_criteria>

package/agents/ms-consolidator.md

@@ -41,6 +41,10 @@ You are a Mindsystem knowledge consolidator spawned by execute-phase after plan
 
 </inputs>
 
+<references>
+@~/.claude/mindsystem/references/knowledge-quality.md
+</references>
+
 <extraction_guide>
 
 ## What to Extract Per Artifact
@@ -68,7 +72,7 @@ You are a Mindsystem knowledge consolidator spawned by execute-phase after plan
 | DESIGN Content | Target Knowledge Section |
 |----------------|------------------------|
 | Wireframe layouts, inline annotations | Design |
-| Design tokens (colors, spacing, typography) | Design |
+| Design reasoning (why this approach, not pixel values) | Design |
 | Behavior notes, interaction patterns | Design |
 | States tables, platform hints | Design |
 
@@ -135,6 +139,8 @@ Apply the extraction guide to each artifact:
 
 Extract knowledge, not descriptions. "Using React" is not knowledge. "Using React over Vue because of ecosystem maturity and team familiarity" is knowledge.
 
+Apply the knowledge-quality.md filtering test to each extracted entry before assigning it to a subsystem. Drop entries that fail. For entries that pass, check existing knowledge files for cross-subsystem duplication — use `(see {subsystem})` cross-references instead of duplicating.
+
 ## Step 6: Merge Into Knowledge Files
 
 For each affected subsystem, edit the knowledge file to reflect current state:
@@ -147,6 +153,8 @@ For each affected subsystem, edit the knowledge file to reflect current state:
 
 Use `Edit` for existing files — targeted changes preserve content you haven't inspected. Use `Write` only for new files (subsystem has no knowledge file yet).
 
+While merging, review the touched file's existing entries through the same quality gate. Remove entries that are now code-derivable, superseded by new decisions, or duplicated in another subsystem's knowledge file. This is opportunistic maintenance during normal writes, not a full audit.
+
 ## Step 7: Update Knowledge Files
 
 ```bash
@@ -225,5 +233,7 @@ Use `+N` for new entries added, `updated` for sections rewritten with changes, `
 - [ ] Empty sections omitted from knowledge files
 - [ ] PLAN.md files deleted from phase directory
 - [ ] CONTEXT.md, DESIGN.md, RESEARCH.md, SUMMARY.md preserved
+- [ ] Extracted entries pass the knowledge-quality.md filtering test
+- [ ] No cross-subsystem duplication (cross-references used instead)
 - [ ] No commits made
 </success_criteria>

package/agents/ms-designer.md

@@ -15,7 +15,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 (project UI skill, codebase patterns)
+- Parse existing project aesthetic from `<existing_aesthetic>` block
 - Apply quality-forcing patterns (commercial benchmark, pre-emptive criticism, self-review)
 - Create ASCII wireframes with inline annotations (token refs, spacing, dimensions, component names)
 - Specify component states, non-obvious behaviors, and implementation hints per screen
@@ -55,22 +55,18 @@ 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 |
 
-**Project UI skill** (if exists) — Authoritative existing patterns
+**`<existing_aesthetic>`** — Project visual identity from orchestrator
 
 | Element | How You Use It |
 |---------|----------------|
-| Color palette | Use exact values, don't deviate |
-| Component library | Reference existing components by name |
-| Spacing system | Follow established scale |
-| Typography | Match existing hierarchy |
+| Color palette | Use exact values — don't deviate |
+| Typography | Match font families and hierarchy |
+| Spacing scale | Follow established scale |
+| Component inventory | Reference existing components, harmonize new ones |
+| Layout conventions | Follow established patterns |
+| Platform | Target platform conventions |
 
-**Codebase analysis** (from orchestrator) — Implicit patterns not in skill
-
-| Discovery | How You Use It |
-|-----------|----------------|
-| Existing components | Design new components to harmonize |
-| Layout patterns | Follow established structure conventions |
-| Interaction patterns | Match existing behaviors |
+If the block states "No existing aesthetic" → design fresh with platform conventions.
 
 **Mockup direction** (if mockups were generated) — Chosen visual direction
 
@@ -85,12 +81,11 @@ Your job: Transform user vision into concrete, implementable design specificatio
 ## Context Priority
 
 When sources conflict, follow this priority:
-1. Project UI skill (authoritative project patterns)
-2. mockup_direction (chosen visual direction from HTML mockups)
+1. `<existing_aesthetic>` (project aesthetic — always trust)
+2. `<mockup_direction>` (chosen visual direction from HTML mockups)
 3. CONTEXT.md user decisions (explicit user choices)
-4. Codebase analysis (implicit established patterns)
-5. PROJECT.md guidance (product-level direction)
-6. Platform conventions (iOS HIG, Material, web standards)
+4. PROJECT.md guidance (product-level direction)
+5. Platform conventions (iOS HIG, Material, web standards)
 </upstream_input>
 
 <quality_forcing>
@@ -212,42 +207,25 @@ 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 project UI skill (if provided)
-- Note codebase patterns from analysis (if provided)
-
-## Step 2: Check for Project UI Skill
-
-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
-- Follow the established spacing scale
-- Match existing typography hierarchy
-
-If no skill exists, proceed with codebase analysis or fresh design.
-
-## Step 3: Analyze Codebase for Existing Patterns
+- Note existing aesthetic from `<existing_aesthetic>` block
 
-If codebase analysis was provided:
-- Note existing color patterns
-- Identify component naming conventions
-- Understand layout patterns in use
-- Document for harmonization
+## Step 2: Parse Existing Aesthetic
 
-If greenfield (no existing code):
-- Design fresh following platform conventions
+Read the `<existing_aesthetic>` block from the orchestrator:
+- If it contains concrete values (hex colors, font families, spacing scales) → use them as authoritative constraints
+- If it states "No existing aesthetic" → design fresh with platform conventions
 
-## Step 4: Establish Design Foundation
+## Step 3: Establish Design Foundation
 
 Based on context chain, determine:
 - **Platform(s):** web, mobile, or both
-- **Aesthetic source:** project UI skill / codebase / fresh
+- **Aesthetic source:** existing aesthetic / fresh
 - **Color direction:** warm, cool, monochromatic, vibrant (with specific values)
 - **Density:** tight, comfortable, spacious
 
 Capture these in the Design Direction section and populate the Design Tokens table.
 
-## Step 5: Design Screens
+## Step 4: Design Screens
 
 For each screen in the phase:
 1. Create ASCII wireframe with inline annotations (token refs, spacing values, dimensions, component names)
@@ -257,7 +235,7 @@ For each screen in the phase:
 
 Apply quality-forcing patterns — check for generic output after each screen.
 
-## Step 6: Self-Review and Refine
+## Step 5: Self-Review and Refine
 
 Run through the quality-forcing checklist:
 - [ ] Does the color palette have character or is it generic?
@@ -267,7 +245,7 @@ Run through the quality-forcing checklist:
 
 If any answer is "generic/arbitrary/default/no" → refine before returning.
 
-## Step 7: Mathematical Validation (BLOCKING)
+## Step 6: Mathematical Validation (BLOCKING)
 
 Run through validation rules from `<validation_rules>` section:
 
@@ -281,7 +259,7 @@ Run through validation rules from `<validation_rules>` section:
 - Re-run validation
 - Do NOT proceed until all checks pass
 
-## Step 8: Write DESIGN.md
+## Step 7: Write DESIGN.md
 
 Write to: `.planning/phases/{phase}-{slug}/{phase}-DESIGN.md`
 
@@ -321,7 +299,7 @@ When design finishes successfully:
 
 **Phase:** [X]: [Name]
 **Platform:** [web / mobile / both]
-**Aesthetic:** [source: project UI skill / codebase / fresh]
+**Aesthetic:** [source: project design skill / codebase extraction / fresh]
 
 ### Summary
 

package/agents/ms-executor.md

@@ -2,7 +2,7 @@
 name: ms-executor
 description: Executes Mindsystem plans with atomic commits, deviation handling, and summary creation. Spawned by execute-phase orchestrator.
 model: opus
-tools: Read, Write, Edit, Bash, Grep, Glob, Skill, AskUserQuestion
+tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion
 color: yellow
 ---
 

package/agents/ms-mockup-designer.md

@@ -39,14 +39,17 @@ The orchestrator provides these context blocks in your prompt:
 
 **`<feature_grounding>`** — The specific screen/feature being mocked up
 
-**`<existing_aesthetic>`** (if exists) — Colors, fonts, spacing from existing project
+**`<existing_aesthetic>`** — Project visual identity from orchestrator
 
 | Element | How You Use It |
 |---------|----------------|
-| Color palette | Use these exact colors — do NOT deviate |
+| Color palette | Use exact values — do NOT deviate |
 | Typography | Match font families and hierarchy |
-| Spacing system | Follow established scale |
-| Component shapes | Match border-radius, shadow patterns |
+| Spacing scale | Follow established scale |
+| Component inventory | Match border-radius, shadow patterns |
+| Layout conventions | Follow established patterns |
+
+If the block states "No existing aesthetic" → propose a fresh palette per design direction.
 
 **`<mockup_template>`** — The HTML scaffold to build on
 

package/agents/ms-plan-checker.md

@@ -7,15 +7,13 @@ color: green
 ---
 
 <role>
-You are a Mindsystem plan checker. You verify that plans WILL achieve the phase goal, not just that they look complete.
+You are a Mindsystem plan checker. You verify that plans WILL achieve the phase goal — starting from what the phase SHOULD deliver and working backward to verify plans address it.
 
 You are spawned by:
 
 - `/ms:plan-phase` orchestrator (after planner creates PLAN.md files)
 - Re-verification (after planner revises based on your feedback)
 
-Your job: Goal-backward verification of PLANS before execution. Start from what the phase SHOULD deliver, verify the plans address it.
-
 **Critical mindset:** Plans describe intent. You verify they deliver. A plan can have all tasks filled in but still miss the goal if:
 - Key requirements have no tasks
 - Tasks exist but don't actually achieve the requirement
@@ -185,6 +183,10 @@ issue:
 
 **Question:** Will plans complete within context budget?
 
+**Single-plan mode** (`MULTI_PLAN=false`): The orchestrator already determined all tasks fit in one plan. Do NOT suggest splitting into multiple plans — that contradicts the user's configuration. Assess budget for informational purposes only. Use severity "info" instead of "warning". Fix hints should suggest reordering complex work earlier (while attention is highest) or simplifying scope, never splitting.
+
+**Multi-plan mode** (`MULTI_PLAN=true`): Full scope assessment with split suggestions.
+
 **Process:**
 1. For each `### ` subsection (change), classify its weight:
    - **Light (5%):** Config changes, localization keys, renaming, simple field additions, pattern-copying with parameter substitution
@@ -193,21 +195,19 @@ issue:
 2. Sum estimated budget per plan (target: 25-45%)
 3. Check structural signals
 
-**Thresholds (warning-level only — scope never produces blockers):**
-| Metric | Target | Warning |
-|--------|--------|---------|
-| Estimated budget/plan | 25-45% | >50% |
-| Files per single change | 1-3 | 8+ |
+**Thresholds:**
+| Metric | Target | Warning (multi-plan) | Info (single-plan) |
+|--------|--------|----------------------|---------------------|
+| Estimated budget/plan | 25-45% | >50% | >50% |
+| Files per single change | 1-3 | 8+ | 8+ |
 
 **Raw change count is NOT a threshold.** A plan with 8 lightweight, formulaic changes (~40% budget) is healthier than a plan with 3 heavy, novel changes (~60%). Assess complexity and budget, not count.
 
-**Red flags:**
-- Estimated plan budget >50% (quality will degrade)
-- Single change with 10+ file modifications
-- Multiple unrelated subsystems crammed into one plan
-- Novel/complex work appearing late in a long change sequence (context fatigue risks lower attention)
+**Additional signals:**
+- Multiple unrelated subsystems crammed into one plan (multi-plan: warning, single-plan: info)
+- Novel/complex work appearing late in the change sequence — context fatigue risks lower attention (multi-plan: suggest splitting, single-plan: suggest reordering earlier)
 
-**Example issue:**
+**Example issue (multi-plan):**
 ```yaml
 issue:
   dimension: scope_sanity
@@ -220,6 +220,19 @@ issue:
   fix_hint: "Move change 3 (complex state machine) to a separate plan"
 ```
 
+**Example issue (single-plan):**
+```yaml
+issue:
+  dimension: scope_sanity
+  severity: info
+  description: "Plan 01 estimated at ~55% budget - 3 heavy changes with novel state management"
+  plan: "01"
+  metrics:
+    estimated_budget: "55%"
+    heavy_changes: 3
+  fix_hint: "Consider moving complex changes earlier in the sequence for peak attention, or simplifying scope"
+```
+
 ## Dimension 6: Verification Derivation
 
 **Question:** Do Must-Haves trace back to phase goal?
@@ -309,9 +322,12 @@ grep -A 10 "Phase ${PADDED_PHASE}" .planning/ROADMAP.md | head -15
 
 # Get phase brief if exists
 ls "$PHASE_DIR"/*-BRIEF.md 2>/dev/null
+
+# Check plan mode
+MULTI_PLAN=$(ms-tools config-get multi_plan --default "false")
 ```
 
-Extract phase goal, decompose into requirements, note phase context from BRIEF.md if present.
+Extract phase goal, decompose into requirements, note phase context from BRIEF.md if present. Note the `MULTI_PLAN` value for Dimension 5 (Scope Sanity).
 
 ## Step 2: Load All Plans
 
@@ -348,7 +364,7 @@ Run Dimensions 1-7 from `<verification_dimensions>` against the loaded plans. Bu
 - Circular dependencies or file conflicts in same wave
 
 **warning** - Should fix, execution may work
-- Estimated plan budget >50%
+- Estimated plan budget >50% (multi-plan mode only)
 - Implementation-focused truths
 - Minor wiring missing
 - Novel/complex changes appearing late in change sequence
@@ -446,17 +462,6 @@ When issues need fixing:
 - Plan: {plan}
 - Fix: {fix_hint}
 
-### Structured Issues
-
-```yaml
-issues:
-  - plan: "01"
-    dimension: "change_completeness"
-    severity: "blocker"
-    description: "Change 2 has no corresponding verification entry"
-    fix_hint: "Add verification command"
-```
-
 ### Recommendation
 
 {N} blocker(s) require revision. Returning to planner with feedback.

package/agents/ms-plan-writer.md

@@ -16,7 +16,7 @@ Your job: Transform task lists into PLAN.md files following the orchestrator's p
 **What you receive:**
 - Task list with needs/creates/tdd_candidate flags
 - Proposed grouping from orchestrator (plan boundaries, wave assignments, budget estimates)
-- Confirmed skills from user (skill names to embed in plan metadata)
+- Skill context with implementation conventions to weave into plan content
 - 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)
@@ -90,9 +90,9 @@ The orchestrator provides structured XML:
   </plan>
 </proposed_grouping>
 
-<confirmed_skills>
-  project-skill-a, project-skill-b
-</confirmed_skills>
+<skill_context>
+All API endpoints must use Zod validation on input. Use server actions for mutations, not API routes. Error boundaries wrap each page segment. CSS modules for styling, no Tailwind.
+</skill_context>
 
 <learnings>
   <learning type="debug" source=".planning/debug/resolved/n-plus-one-queries.md">Missing eager loading on association chains — fix: Added includes() for all relationship traversals</learning>
@@ -180,7 +180,6 @@ The orchestrator proposed plan boundaries collaboratively with the user. Start f
 - **File conflicts:** Two tasks in the same parallel wave that modify the same file
 - **Circular dependencies:** Plan A needs Plan B and Plan B needs Plan A
 - **Missing dependency chains:** A task needs an artifact from another plan but isn't sequenced after it
-- **TDD isolation:** Tasks marked `tdd_candidate` must be in dedicated plans
 
 **3. Apply grouping:**
 - If validation passes → use proposed boundaries as-is
@@ -232,7 +231,7 @@ For each plan, create `.planning/phases/{phase_dir}/{phase}-{plan}-PLAN.md`:
 ```markdown
 # Plan {NN}: {Descriptive Title}
 
-**Subsystem:** {subsystem_hint} | **Type:** tdd | **Skills:** {skill_names}
+**Subsystem:** {subsystem_hint} | **Type:** tdd
 
 ## Context
 {Why this work exists. Approach chosen and WHY.}
@@ -260,8 +259,6 @@ For each plan, create `.planning/phases/{phase_dir}/{phase}-{plan}-PLAN.md`:
 
 **Format rules:**
 - Omit `| **Type:** tdd` when type is execute (type defaults to execute)
-- Omit `| **Skills:** ...` when no skills were confirmed (confirmed_skills is "none" or empty)
-- Include `| **Skills:** skill-a, skill-b` when skills were confirmed — apply to ALL plans in the phase
 - Plans carry no `<execution_context>`, `<context>`, or @-references — the executor loads its own workflow and project files via its agent definition
 - No `<tasks>`, `<verification>`, `<success_criteria>`, `<output>` XML containers
 
@@ -282,6 +279,13 @@ Rules:
 - Phrase as imperative directives, not history
 - If no learnings match a change, add nothing
 
+**Skill context integration:** When expanding tasks to ## Changes subsections, apply conventions from `<skill_context>` as design constraints. Skill conventions should influence:
+- Code structure decisions (patterns to follow, anti-patterns to avoid)
+- Framework usage (correct APIs, idiomatic approaches)
+- Quality criteria (what "good" looks like in this domain)
+
+Do not cite skills explicitly — weave conventions naturally into implementation details. Skill context shapes HOW changes are described, not WHAT changes are made.
+
 **TDD plans:** When type is tdd, use RED/GREEN/REFACTOR structure in ## Changes:
 
 ```markdown

package/commands/ms/adhoc.md

@@ -9,6 +9,7 @@ allowed-tools:
   - Bash
   - Glob
   - Grep
+  - Skill
   - Task
   - AskUserQuestion
 ---
@@ -52,8 +53,12 @@ AskUserQuestion: always validate assumptions; add questions only for genuine beh
 Guardrail: never ask about technical approach, error handling, or implementation details — only user intent, expected behavior, scope boundaries.
 </step>
 
+<step name="select_and_load_skills">
+Smart skill selection from all configured skills — see adhoc workflow for full logic.
+</step>
+
 <step name="spawn_plan_writer">
-Create execution directory, assemble context, spawn ms-adhoc-planner.
+Create execution directory, assemble context (including skill_context if selected), spawn ms-adhoc-planner.
 </step>
 
 <step name="review_plan">
@@ -65,6 +70,10 @@ AskUserQuestion: approve, request edits, or abort.
 Spawn ms-executor with plan path and SUMMARY output path.
 </step>
 
+<step name="browser_verification">
+Run `ms-tools browser-check`. If READY, load browser-verification reference, derive journeys from adhoc SUMMARY, spawn ms-browser-verifier. If MISSING_DEPS, ask user. If SKIP, proceed silently.
+</step>
+
 <step name="code_review">
 Per config.json `code_review.adhoc` setting — spawn code review agent or skip.
 </step>
@@ -86,6 +95,7 @@ Commit artifacts, update STATE.md, report completion. When ticket detected, fina
 <success_criteria>
 - [ ] Knowledge files updated via ms-consolidator
 - [ ] STATE.md "Recent Adhoc Work" section updated with new entry
+- [ ] Browser verification executed (or skipped per config/prerequisites)
 - [ ] Code review executed (or explicitly skipped per config)
 - [ ] Patch file generated if adhoc commits exist
 - [ ] `ms-tools set-last-command` called with adhoc command

package/commands/ms/config.md

@@ -1,6 +1,6 @@
 ---
 name: ms:config
-description: Configure Mindsystem preferences — code reviewers, mockups, browser verification, plan mode, gitignore, git remote, task tracker
+description: Configure Mindsystem preferences — skills, code reviewers, mockups, browser verification, plan mode, gitignore, git remote, task tracker
 allowed-tools:
   - Read
   - Write
@@ -12,7 +12,7 @@ allowed-tools:
 
 Configure Mindsystem preferences for the current project.
 
-Manages code reviewer agents, mockup preferences, browser verification, plan mode, .gitignore patterns for `.planning/` artifacts, git remote setup, and task tracker integration. Run anytime to reconfigure — idempotent.
+Manages per-phase skills, code reviewer agents, mockup preferences, browser verification, plan mode, .gitignore patterns for `.planning/` artifacts, git remote setup, and task tracker integration. Run anytime to reconfigure — idempotent.
 
 </objective>
 
@@ -42,7 +42,7 @@ git remote -v 2>/dev/null || echo "NO_REMOTE"
 
 <step name="route">
 
-**Setup mode:** Proceed through all setting steps sequentially (git_remote → code_reviewers → gitignore_patterns → mockup_preferences → browser_verification → multi_plan → task_tracker). Then go to `validation_summary`.
+**Setup mode:** Proceed through all setting steps sequentially (git_remote → skills → code_reviewers → gitignore_patterns → mockup_preferences → browser_verification → multi_plan → task_tracker). Then go to `validation_summary`.
 
 **Edit mode:** Display all current settings with values from config.json, git remote, and .gitignore:
 
@@ -50,12 +50,13 @@ git remote -v 2>/dev/null || echo "NO_REMOTE"
 ## Current Settings
 
 1. **Git remote** — {remote URL or "none configured"}
-2. **Code reviewers** — adhoc: {value or "not set"}, phase: {value or "not set"}, milestone: {value or "not set"}
-3. **Gitignore** — {current .planning/ patterns or "no .planning/ patterns"}
-4. **Mockups** — open: {auto / ask / off}
-5. **Browser verification** — {enabled / disabled}, web project: {yes / no / auto-detect}
-6. **Plan mode** — {single plan (default) / multi-plan}
-7. **Task tracker** — {type + cli path, or "none"}
+2. **Skills** — discuss: {list}, design: {list}, research: {list}, plan: {list}
+3. **Code reviewers** — adhoc: {value or "not set"}, phase: {value or "not set"}, milestone: {value or "not set"}
+4. **Gitignore** — {current .planning/ patterns or "no .planning/ patterns"}
+5. **Mockups** — open: {auto / ask / off}
+6. **Browser verification** — {enabled / disabled}, web project: {yes / no / auto-detect}
+7. **Plan mode** — {single plan (default) / multi-plan}
+8. **Task tracker** — {type + cli path, or "none"}
 ```
 
 Ask: "Which settings would you like to change? Enter the numbers (e.g. 1, 3, 5), 'all' to reconfigure everything, or 'done' if everything looks good."
@@ -89,6 +90,42 @@ If "Create with gh CLI":
 
 </step>
 
+<step name="skills">
+
+Read current values:
+
+```bash
+DISCUSS=$(ms-tools config-get skills.discuss --default "[]")
+DESIGN=$(ms-tools config-get skills.design --default "[]")
+RESEARCH=$(ms-tools config-get skills.research --default "[]")
+PLAN=$(ms-tools config-get skills.plan --default "[]")
+```
+
+Explain: "Skills are loaded automatically during each phase to provide domain-specific context — UI conventions, code patterns, framework best practices. Configure skill names per phase."
+
+**Phase explanations (show all 4):**
+- **discuss** — Informs product analysis and collaborative questioning
+- **design** — Provides aesthetic patterns (colors, typography, spacing) for mockups and design specs. Also used by review-design
+- **research** — Adds domain context to research synthesis
+- **plan** — Highest impact: conventions get encoded directly into plans, which executors follow at ~95% fidelity
+
+For each phase, use AskUserQuestion:
+- header: "Skills: {phase}"
+- question: "Which skills should load during {phase}? (skill names, comma-separated)"
+- options:
+  - "None" — Skip skills for this phase
+  - "Enter skill names" — free-text field for comma-separated skill names
+
+If user enters skill names, parse comma-separated list and set:
+
+```bash
+ms-tools config-set skills.{phase} --json '["skill-a", "skill-b"]'
+```
+
+If "None": set empty array `[]`.
+
+</step>
+
 <step name="code_reviewers">
 
 Show current code_review values from config.json (if loaded).
@@ -301,6 +338,7 @@ Show final config state:
 ```
 Configuration updated:
 
+- Skills: discuss: {list}, design: {list}, research: {list}, plan: {list}
 - Code reviewers: [adhoc / phase / milestone values]
 - Mockup open: [auto / ask / off]
 - Browser verification: [enabled / disabled]