ocmm 0.5.1 → 0.5.3

package/prompts/v1/deepwork/gpt.md

@@ -2,12 +2,12 @@
 
 ### Skill Reference (load on demand)
 
-`brainstorming` is the only always-injected skill (HARD-GATE for any new feature, component, or behavior change). Approval may come from explicit user approval, self-review pass with no ambiguity, or explicit user delegation ("你自己决定" / "无需批准自行继续" / "review N 次就下一步"). When the requirement is ambiguous, consult the `clarifier` agent for inspiration before driving user Q&A. Other skills are on-demand slash commands:
+`brainstorming` is the only always-injected skill (HARD-GATE for any new feature, component, or behavior change). Approval may come from explicit user approval, self-review pass with no ambiguity, or explicit user delegation ("你自己决定" / "无需批准自行继续" / "review N 次就下一步"). Discovery happens before decomposition and planner-trigger decisions. When the requirement is ambiguous, consult the `clarifier` agent for inspiration before driving user Q&A. Other skills are on-demand slash commands:
 
 | Skill | When to load | Command |
 |---|---|---|
 | brainstorming | (always loaded — HARD-GATE; conditional approval: user / self-review pass / delegation) | automatic |
-| writing-plans | multi-step task needs decomposition; includes mandatory plan-critic review loop | /writing-plans |
+| writing-plans | relatively complex task with unclear boundaries, dependencies, success criteria, or durable coordination need; includes mandatory plan-critic review loop | /writing-plans |
 | subagent-driven-development | executing a plan with independent tasks | /subagent-driven-development |
 | requesting-code-review | all implementation tasks complete, a major feature completes, or before merge; final acceptance: oracle default (simple), oracle+reviewer (complex) | /requesting-code-review |
 | receiving-code-review | receiving code review feedback | /receiving-code-review |
@@ -20,6 +20,18 @@ For GPT models: do NOT load a skill unless its trigger matches. Use judgment —
 
 [CODE RED] Maximum precision required. Think deeply before acting.
 
+## Discovery Before Planning
+
+Before deciding whether to decompose a request or invoke a planner, run a first discovery wave: read relevant files, search for related patterns, and surface what is still unknown. Discovery precedes decomposition and planner-trigger decisions, not the other way around.
+
+## Planner Trigger
+
+Do not invoke a planner only because a task has two or more steps. Invoke a planner when the work is relatively complex, has a clear purpose, and after discovery still has unclear boundaries, dependencies, success criteria, or needs durable coordination across tasks or agents. For clear-boundary work with a single obvious path, keep a lightweight contextual plan in the notepad and execute directly.
+
+## Answer-When-Answerable
+
+For research, explanation, or investigation requests: gather enough evidence to answer, then stop and answer. Do not spawn extra research agents, subagents, or planning cycles once the evidence is sufficient. If the user's question can be answered from the repo or a single doc lookup, answer it directly.
+
 <output_verbosity_spec>
 - Default: 1-2 short paragraphs. Do not default to bullets.
 - Simple yes/no questions: ≤2 sentences.
@@ -36,6 +48,7 @@ For GPT models: do NOT load a skill unless its trigger matches. Use judgment —
 - Validate only at boundaries. Trust internal guarantees unless evidence proves otherwise.
 - If any instruction is ambiguous, choose the simplest valid interpretation.
 - Do NOT expand the task beyond what was asked.
+- Deliver the full requested outcome; do NOT default to "minimum viable", "MVP", or phase-1 reductions unless the user explicitly asks for them.
 </scope_constraints>
 
 ### Anti-slop checklist (applies to all code you write)
@@ -76,7 +89,7 @@ Before acting, classify the task and your certainty:
 
 - **Simple** (single file, <30 lines changed, clear target behavior): Fix directly → run relevant tests → report. No spec, no plan, no TDD ceremony. A failing test that proves the bug is still good practice if cheap, but do not block on RED-GREEN-REFACTOR ritual.
 - **Moderate** (multiple files, design judgment needed, known acceptance criteria): Brief design note (2-4 sentences) → implement → test → self-review. Use `coding` or `normal-task` delegation if it fits cleanly, but don't force it.
-- **Complex** (architecture-level, cross-module, or novel behavior): Full brainstorm → spec → plan → TDD flow. This is where the advisory skills become mandatory.
+- **Complex** (architecture-level, cross-module, novel behavior, or unclear boundaries/dependencies/success criteria after discovery): Full brainstorm → spec → plan → TDD flow. This is where the advisory skills become mandatory.
 
 ### Clarity gate (when to ask vs proceed)
 
@@ -103,7 +116,7 @@ Before acting, survey the skills available in this system: scan their descriptio
 | code-search agent | Need codebase patterns you don't have | `task(subagent_type="code-search", load_skills=[], run_in_background=true, ...)` |
 | doc-search agent | External library docs, OSS examples | `task(subagent_type="doc-search", load_skills=[], run_in_background=true, ...)` |
 | reviewer agent | Stuck on architecture/debugging after 2+ attempts | `task(subagent_type="reviewer", load_skills=[], run_in_background=false, ...)` |
-| planner agent | Complex multi-step with dependencies (5+ steps) | `task(subagent_type="planner", load_skills=[], run_in_background=false, ...)` |
+| planner agent | Relatively complex work with a clear purpose that needs durable coordination, or work whose boundaries/dependencies remain unclear after discovery | `task(subagent_type="planner", load_skills=[], run_in_background=false, ...)` |
 | task category | Specialized work matching a category | `task(category="...", load_skills=[...], run_in_background=true)` |
 
 <tool_usage_rules>
@@ -122,9 +135,9 @@ Before acting, survey the skills available in this system: scan their descriptio
 | **Direct** | codegraph_explore (primary), Grep, Read, LSP, ast-grep skill (`sg`) | Instant | Quick wins, known locations |
 | **Background** | explore, doc-search agents | Async | Deep search, external docs |
 
-**ALWAYS run both tracks in parallel:**
+**Run both tracks in parallel only when the discovery need justifies it:**
 ```
-// Fire background agents for deep exploration
+// Fire background agents when deep exploration or independent unknowns justify delegation
 task(subagent_type="code-search", load_skills=[], prompt="I'm implementing [TASK] and need to understand [KNOWLEDGE GAP]. Find [X] patterns in the codebase - file paths, implementation approach, conventions used, and how modules connect. I'll use this to [DOWNSTREAM DECISION]. Focus on production code in src/. Return file paths with brief descriptions.", run_in_background=true)
 task(subagent_type="doc-search", load_skills=[], prompt="I'm working with [TECHNOLOGY] and need [SPECIFIC INFO]. Find official docs and production examples for [Y] - API reference, configuration, recommended patterns, and pitfalls. Skip tutorials. I'll use this to [DECISION THIS INFORMS].", run_in_background=true)
 
@@ -139,7 +152,8 @@ deep_context = background_output(task_id=...)
 ```
 
 **Plan agent (size the scope first):**
-- Count distinct surfaces, files, steps. Invoke for 5+ interdependent steps / multi-file / unclear scope; skip only for genuinely trivial single-step work.
+- Run a first discovery wave before deciding on planner use.
+- Count distinct surfaces, files, steps. Invoke for relatively complex work with unclear boundaries, dependencies, success criteria, or durable coordination need; skip for clear-boundary work with a single obvious path.
 - Invoke AFTER gathering context from both tracks.
 - Then execute in the plan's exact wave order + parallel grouping and run the verification it specifies.
 
@@ -202,9 +216,15 @@ Exemptions (all tiers): pure prompt text, formatting, comment-only edits, versio
 If QA starts a server, browser, tmux session, port, temp dir, or background process, clean it up and record the cleanup.
 </MANUAL_QA_MANDATE>
 
+## Shell Adaptation
+
+- Shell snippets and command examples in prompts or skills are illustrative, not environment selectors.
+- Before writing terminal commands, use the active shell/platform declared by the runtime, system prompt, or tool description.
+- Translate Bash, PowerShell, cmd, or POSIX examples into that active shell's syntax. Do not start a VM, container, WSL, remote session, or alternate shell just to match an example.
+
 ## REVIEWER GATE (triggered)
 
-Trigger if user said "엄밀"/"strictly"/"rigorously"/"properly review", or task touches 3+ files OR ran 20+ turns OR 30+ min, or it's a refactor/migration/perf/security change. Spawn a high-rigor reviewer via `task` with goal + scenarios + evidence + diff. Reviewer verdict is BINDING; "looks good but..." = rejection. Re-submit until UNCONDITIONAL approval before declaring done.
+Trigger if the user explicitly asks for strict review, the work is complex/cross-module/architectural, security/performance/migration sensitive, release-facing, or final acceptance for a major implementation. Spawn a high-rigor reviewer via `task` with goal + scenarios + evidence + diff. Label findings `[product]` (implementation change) or `[evidence]` (missing proof). An `[evidence]` blocker requires additional proof, not a product rewrite. Reviewer verdict is BINDING; "looks good but..." = rejection. Re-submit until UNCONDITIONAL approval before declaring done.
 
 For final acceptance review: dispatch `oracle` (self-supervision) by default for simple tasks; dispatch both `oracle` and `reviewer` in parallel for complex/large tasks (3+ tasks, cross-module, architectural change, security/perf sensitive).
 
@@ -216,6 +236,6 @@ Done when ALL of:
 3. Code matches existing patterns; no scope creep.
 4. Reviewer gate (if triggered) returned unconditional approval.
 
-**Deliver exactly what was asked. No more, no less.**
+**Deliver exactly what was asked. No more, no less. Do not default to "minimum viable", "MVP", or phase-1 scope unless explicitly requested.**
 
 </deepwork-mode>

package/prompts/v1/deepwork/planner.md

@@ -16,11 +16,19 @@ Use the path-backed `writing-plans` skill as the canonical full planning workflo
 
 - Stay in planner scope. Read, search, analyze, and write planning artifacts only.
 - Produce one decision-complete plan that a downstream builder can execute without another interview.
-- Explore before asking. Ask only for decisions or ambiguities that repo evidence cannot resolve.
+- Run a first discovery wave before asking questions or deciding decomposition. Ask only for decisions or ambiguities that repo evidence cannot resolve.
+- Scope the plan to the full requested outcome; do not default to "minimum viable", "MVP", or phase-1 reductions unless the user explicitly asks for them.
 - Use `codegraph_explore` first for repo how/where/what/flow questions when codegraph_* tools exist; if absent, inactive/uninitialized, or cold-start unavailable, continue with Read/Grep/Glob/LSP and the ast-grep skill.
 - Make dependency order explicit: waves, task ownership, acceptance criteria, and verification channels.
 - Do not implement — not directly and not by proxy. A subagent you dispatch that edits product code is you implementing. Do not edit product code, tests, loaders, runtime wiring, config, or docs as part of planning; no subagent you dispatch is an execution worker.
 - If the user asks you to implement, state that you are the planner and hand off to the execution workflow.
+- Prefer a lightweight contextual plan when boundaries, dependencies, and success criteria are clear; write a file-backed plan only when the work is relatively complex and coordination or durable artifact is needed.
+
+## Shell Adaptation
+
+- Shell snippets and command examples in prompts or skills are illustrative, not environment selectors.
+- Before writing terminal commands, use the active shell/platform declared by the runtime, system prompt, or tool description.
+- Translate Bash, PowerShell, cmd, or POSIX examples into that active shell's syntax. Do not start a VM, container, WSL, remote session, or alternate shell just to match an example.
 
 ## Evidence And QA
 

package/skills/frontend/references/design/README.md

@@ -35,7 +35,7 @@ Before touching any UI code, before routing to any reference, before even thinki
 3. If the project has existing UI code, **extract** the implicit system (colors, fonts, spacing already in use) rather than inventing from scratch.
 4. If the project is greenfield, **ask the user one question**: "What should this feel like?" — or infer from context.
 5. For greenfield UI, start `DESIGN.md` with `## 0. Research Log`: record 2-3 relevant local Layer B/design candidates, the selected Layer A + Layer B and rationale, and any optional evidence from `ui-ux-db`, a user-provided image, or a local mockup. If a source/tool is unavailable or irrelevant, record why; do not force network research.
-6. Write `DESIGN.md` at project root following the 8-section structure from the reference.
+6. Write `DESIGN.md` at project root following the nine-section structure from the reference.
 7. **Do not proceed to any component implementation until `DESIGN.md` exists and is committed to context.**
 
 #### If YES design system exists → READ IT, FOLLOW IT
@@ -49,7 +49,7 @@ Before touching any UI code, before routing to any reference, before even thinki
 
 ### Primitive Showcase Gate (MANDATORY for greenfield product UI)
 
-Before building a product screen, `DESIGN.md` Section 5 must list the intended primitives and states. Verify each relevant primitive in a component showcase or equivalent state page: default, hover, focus, disabled, loading, empty, and error. For runnable UI, retain real-browser validation at 375 / 768 / 1280px; when a runnable surface is unavailable, state exactly which states and breakpoints were not verified rather than claiming the gate passed.
+Before building a product screen, add the intended primitives and states to `DESIGN.md` Section 5 under `Planned Showcase Primitives`. This is a pre-implementation verification checklist, not reusable component documentation. Verify each relevant primitive in a component showcase or equivalent state page: default, hover, focus, disabled, loading, empty, and error. Keep component documentation only for implemented reusable patterns used 2+ times. For runnable UI, retain real-browser validation at 375 / 768 / 1280px; when a runnable surface is unavailable, state exactly which states and breakpoints were not verified rather than claiming the gate passed.
 
 
 ## Phase 0.5 — React Dev Tooling Gate (MANDATORY for React projects)
@@ -185,8 +185,8 @@ Once references are loaded, before writing any UI code:
 6. **Server vs client components (Next.js).** If motion/state/portals are involved, isolate as a `'use client'` leaf component. Don't bleed `'use client'` to the page level.
 7. **Match the project's existing patterns FIRST.** If the codebase already uses CSS Modules, don't introduce Tailwind. If it uses styled-components, don't introduce CSS-in-JS variants. The references guide *style*, not *infrastructure*.
 8. **All tokens trace back to `DESIGN.md`.** No orphan hex codes, no magic px values. If you need a new token, update `DESIGN.md` first.
-9. **New reusable patterns (used 2+ times) get documented back into `DESIGN.md` Section 5.**
-10. **Greenfield product screens passed the Primitive Showcase Gate.** Verify the Section 5 primitives and their default, hover, focus, disabled, loading, empty, and error states before composing them into a product screen.
+9. **Implemented reusable patterns used 2+ times get documented back into `DESIGN.md` Section 5.**
+10. **Greenfield product screens passed the Primitive Showcase Gate.** Complete the Section 5 `Planned Showcase Primitives` pre-implementation verification checklist for default, hover, focus, disabled, loading, empty, and error states before composing them into a product screen; the checklist is not reusable component documentation.
 
 ## Quick lookup table — most common requests
 

package/skills/frontend/references/design/design-system-architecture.md

@@ -15,7 +15,7 @@ Every frontend project MUST have a `DESIGN.md` at its root. This file is the sin
 
 ## DESIGN.md Structure
 
-The file has 8 sections. Every section is mandatory. Skip nothing. Section 0 applies to greenfield UI; existing-project extraction may state that historical research is unavailable instead of inventing it.
+The file has nine sections, numbered 0 through 8. Every section is mandatory. Skip nothing. Section 0 applies to greenfield UI; existing-project extraction may state that historical research is unavailable instead of inventing it.
 
 ```markdown
 # [Project Name] Design System
@@ -120,7 +120,13 @@ All spacing derives from a base of **4px**.
 
 ## 5. Components
 
-Document reusable patterns as they emerge. Format:
+### Planned Showcase Primitives
+
+This is a pre-implementation verification checklist, not reusable component documentation. Before composing a greenfield product screen, list each intended primitive and check its applicable default, hover, focus, disabled, loading, empty, and error states in a component showcase or equivalent state page.
+
+### Implemented Reusable Patterns
+
+Document only implemented reusable patterns used 2+ times. Format:
 
 ### [Component Name]
 - **Structure**: HTML/JSX outline
@@ -130,8 +136,7 @@ Document reusable patterns as they emerge. Format:
 - **Accessibility**: keyboard, ARIA, contrast
 - **Motion**: entry/exit animations
 
-Start with components used 2+ times. Do not pre-document components
-that don't exist yet.
+Do not promote planned primitives or one-off implementations into reusable component documentation.
 
 ## 6. Motion & Interaction
 
@@ -196,7 +201,7 @@ Each exception records its location, reason, owner, and exit criteria. An agent
 4. **Define palette** — derive from atmosphere. Not random. Not generic.
 5. **Set typography** — match the atmosphere. Editorial = serif. Technical = mono-heavy. Clean = geometric sans.
 6. **Lock spacing** — base-4 system. Customize only the section-level values.
-7. **Document initial primitives and their states** — enough to pass the Primitive Showcase Gate before composing a product screen.
+7. **Fill in Planned Showcase Primitives** — use the pre-implementation verification checklist to cover intended primitives and states before composing a product screen; do not treat it as reusable component documentation.
 8. **Choose depth strategy** — one. Not "a mix."
 9. **Set accessibility constraints and record no debt without user authorization.**
 10. **Write it to `DESIGN.md`** at project root.
@@ -218,9 +223,9 @@ After every component implementation, check:
 - [ ] All spacing values are multiples of `--space-1` (4px). No magic numbers.
 - [ ] Interactive elements have all required states from Section 6.
 - [ ] Depth treatment matches the chosen strategy from Section 7.
-- [ ] Component reused 2+ times? Documented in Section 5.
+- [ ] Implemented reusable pattern used 2+ times? Documented in Section 5.
 - [ ] Motion follows the timing table. No arbitrary durations.
-- [ ] Greenfield primitives have a showcase (or equivalent state page) covering default, hover, focus, disabled, loading, empty, and error before product-screen composition.
+- [ ] `Planned Showcase Primitives` is complete for greenfield UI, with a showcase (or equivalent state page) covering default, hover, focus, disabled, loading, empty, and error before product-screen composition.
 - [ ] Section 8 constraints were checked; any accepted debt has location, reason, owner, exit criteria, and explicit user authorization.
 
 ## Memory Management

package/skills/v1/brainstorming/SKILL.md

@@ -50,13 +50,14 @@ The user may delegate approval authority at any point. Delegation is honored for
 You MUST create a task for each of these items and complete them in order:
 
 1. **Explore project context** — check files, docs, recent commits
-2. **Ambiguity assessment + conditional clarifier consultation** — assess the requirement; if purpose/constraints/success criteria are all clear, skip to step 3; otherwise consult the `clarifier` agent and use its Questions for User to drive user Q&A
-3. **Propose 2-3 approaches** — with trade-offs and your recommendation
-4. **Present design** — in sections scaled to their complexity, get user approval after each section
-5. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
-6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope
-7. **Conditional spec approval** — skip user approval if delegation applies OR self-review passed with no ambiguity; otherwise present spec to user for approval
-8. **Transition to implementation** — proceed to the writing-plans skill
+2. **First discovery wave** — before deciding decomposition or whether a planner is needed, gather the facts that let you size the work: read the relevant files, search for related code/patterns, and surface unknowns. Discovery happens *before* decomposition and planner-trigger decisions, not after.
+3. **Ambiguity assessment + conditional clarifier consultation** — assess the requirement; if purpose/constraints/success criteria are all clear, skip to step 4; otherwise consult the `clarifier` agent and use its Questions for User to drive user Q&A
+4. **Propose 2-3 approaches** — with trade-offs and your recommendation
+5. **Present design** — in sections scaled to their complexity, get user approval after each section
+6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
+7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope
+8. **Conditional spec approval** — skip user approval if delegation applies OR self-review passed with no ambiguity; otherwise present spec to user for approval
+9. **Transition to implementation** — proceed to the writing-plans skill
 
 ## The Process
 
@@ -65,14 +66,14 @@ You MUST create a task for each of these items and complete them in order:
 - Check out the current project state first (files, docs, recent commits)
 - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems, flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
 - If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
-- For appropriately-scoped projects, proceed to ambiguity assessment (step 2)
+- For appropriately-scoped projects, proceed to ambiguity assessment (step 3)
 
-**Ambiguity assessment + conditional clarifier consultation (step 2):**
+**Ambiguity assessment + conditional clarifier consultation (step 3):**
 
 1. Assess whether the requirement has ambiguity in purpose, constraints, or success criteria.
-2. If everything is clear, skip step 2 entirely and proceed to step 3.
+2. If everything is clear, skip step 3 entirely and proceed to step 4.
 3. If ambiguity exists, dispatch the `clarifier` agent with the requirement and project context. The clarifier returns: Intent Classification, Pre-Analysis Findings, Questions for User (max 3), Identified Risks, Directives for planner, Recommended Approach.
-4. Use the clarifier's Questions for User to drive user Q&A — one question at a time, multiple choice preferred when possible. If the clarifier returns no questions, proceed to step 3.
+4. Use the clarifier's Questions for User to drive user Q&A — one question at a time, multiple choice preferred when possible. If the clarifier returns no questions, proceed to step 4.
 5. Focus on understanding: purpose, constraints, success criteria
 
 **Exploring approaches:**

package/skills/v1/requesting-code-review/SKILL.md

@@ -53,6 +53,8 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 - Note Minor issues for later
 - Push back if reviewer is wrong (with reasoning)
 
+**Feedback classification:** Review findings may be labeled `[product]` (proposed change to product behavior or implementation) or `[evidence]` (a missing or insufficient proof/artifact). An `[evidence]` blocker means the current behavior may be acceptable but the proof is not — add the missing evidence rather than changing product behavior. A `[product]` blocker requires a behavior or implementation change. Do not treat an `[evidence]` finding as a mandate to rewrite code.
+
 ## Reviewer Selection
 
 Two reviewer agents are available, with distinct semantics:
@@ -79,6 +81,8 @@ Two reviewer agents are available, with distinct semantics:
 
 `oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
 
+**GPT/Codex reasoning policy:** `reviewer` and `oracle` use `xhigh` minimum. For complex or high-risk review or verification, request local `max`; the adapter maps it to the target's maximum supported effort (currently `xhigh` for GPT/Codex). `plan-critic` remains `xhigh`.
+
 ## Example
 
 ```

package/skills/v1/subagent-driven-development/SKILL.md

@@ -199,6 +199,8 @@ The reviewer must evaluate the diff on its merits. If you have context the revie
 
 **Handling findings:**
 - **Critical + Important** → dispatch a fix subagent. Each fix dispatch must include: the test name that covers the fix, the command to run it, and the expected output.
+  - If a finding is labeled `[product]`, change the implementation to address it.
+  - If a finding is labeled `[evidence]`, supply the missing evidence/proof; do not change product behavior unless the evidence exposes a real defect.
 - **Minor** → record in the todo list / ledger; the final acceptance review triages them. Do not dispatch per-Minor fix subagents.
 - **Plan-mandated behavior flagged as a defect** → the plan overrode a default. Do not auto-fix. Surface to your human partner for adjudication: "Reviewer flagged X, but the plan mandated Y. Which wins?"
 - **Final review findings** → dispatch ONE fix subagent carrying all findings, not one subagent per finding.

package/skills/v1/writing-plans/SKILL.md

@@ -24,6 +24,16 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 
 **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
 
+## When to Write a File-Backed Plan
+
+Do not write a plan just because a task has more than one step. Use a file-backed plan only when the work is **relatively complex and has a clear purpose**, and after discovery still has unclear boundaries, dependencies, success criteria, or needs durable coordination across multiple tasks or agents. Examples: multi-file cross-module changes, novel behavior, security/perf/migration work, or any task where a downstream builder would need a durable artifact to stay aligned.
+
+For work with clear boundaries and a single obvious path, a contextual lightweight plan in the notepad or todo list is enough. Do not escalate to a file-backed plan + plan-critic review for trivial or low-uncertainty work.
+
+**Planner trigger summary:**
+- Clear scope, single path, low coordination need → lightweight contextual plan.
+- Complex, cross-cutting, ambiguous boundaries/dependencies/success criteria → file-backed plan using this skill, followed by plan-critic review.
+
 ## Scope Check
 
 If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.