mindsystem-cc 3.11.0 → 3.13.0

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/plan-phase.md

@@ -112,8 +112,9 @@ Check for `.planning/codebase/` and load relevant documents based on phase type.
 <success_criteria>
 
 - One or more PLAN.md files created in .planning/phases/XX-name/
-- Each plan has: objective, execution_context, context, tasks, verification, success_criteria, output
-- must_haves derived from phase goal and documented in frontmatter (truths, artifacts, key_links)
-- Tasks are specific enough for Claude to execute
+- Each plan has: Context, Changes, Verification, Must-Haves (pure markdown format)
+- Must-Haves derived as markdown checklist of user-observable truths
+- Changes are specific enough for Claude to execute
+- EXECUTION-ORDER.md created with wave groups and dependencies
 - User knows next steps (execute plan or review/adjust)
   </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/goal-backward.md

@@ -117,31 +117,16 @@ Key links get extra verification attention. These are where stubs and placeholde
 </the_process>
 
 <output_format>
-The derive_must_haves step produces a structured list for PLAN.md frontmatter:
-
-```yaml
-must_haves:
-  truths:
-    - "User can see existing messages"
-    - "User can send a message"
-    - "Messages persist across refresh"
-  artifacts:
-    - path: "src/components/Chat.tsx"
-      provides: "Message list rendering"
-    - path: "src/app/api/chat/route.ts"
-      provides: "Message CRUD operations"
-    - path: "prisma/schema.prisma"
-      provides: "Message model"
-  key_links:
-    - from: "Chat.tsx"
-      to: "api/chat"
-      via: "fetch in useEffect"
-    - from: "api/chat POST"
-      to: "database"
-      via: "prisma.message.create"
+The derive_must_haves step produces a markdown checklist for the plan's ## Must-Haves section:
+
+```markdown
+## Must-Haves
+- [ ] User can see existing messages
+- [ ] User can send a message
+- [ ] Messages persist across refresh
 ```
 
-This structure is machine-readable for verification after execution.
+Each item is a user-observable truth. The verifier derives artifacts and key_links from the plan's ## Changes section.
 </output_format>
 
 <examples>
@@ -261,7 +246,7 @@ Key links are verification priorities. Without them, you check everything equall
 
 The `derive_must_haves` step runs after gathering context, before breaking into tasks.
 
-Output: `must_haves` structure written to PLAN.md frontmatter.
+Output: must-haves written to the plan's ## Must-Haves section.
 
 Tasks are then designed to CREATE the artifacts and ESTABLISH the wiring.
 
@@ -269,7 +254,7 @@ Tasks are then designed to CREATE the artifacts and ESTABLISH the wiring.
 
 The `verify_phase_goal` step runs after all plans execute, before updating roadmap.
 
-Input: `must_haves` from PLAN.md frontmatter (or derived from goal if missing).
+Input: ## Must-Haves from plan markdown (or derived from goal if missing).
 
 Process: Check each truth against codebase, verify artifacts exist and aren't stubs, trace key links.