feat(shared-skills): incorporate ouroboros/gajae-code patterns into planning skills

Improvements inspired by Q00/ouroboros and Yeachan-Heo/gajae-code:

planing-prometheustic:
- Add brownfield detection (greenfield vs brownfield context awareness)
- Add topology enumeration (Round 0) to lock component list before
  deep interview, preventing depth-first overfitting to one component
- Add interview routing rule (facts→code, tradeoffs→user, mixed→both)
- Add retrieval budget (direct reads first, subagents only when needed)
- Add challenge perspective shifts (Contrarian/Simplifier/Ontologist)
- Per-component clearance checklist (every component must pass)
- Handle ITERATE verdict from Momus (max 2 auto-fix rounds)
- NO numeric scoring — qualitative clearance only, per Prometheus style

metis:
- Add brownfield/greenfield detection with evidence to output
- Add topology enumeration (top-level components) to output format
- Add topology directives (planner must cover every active component)
- Add per-component coverage tracking guidance
- Explicit prohibition on numeric scoring formulas

momus:
- Add ITERATE verdict between OKAY and REJECT (fixable gaps the
  planner can patch without user input, max 2 auto-fix rounds)
- Update output format for three-verdict system
- Update review process step 6 for three-way decision
- REJECT now reserved for fundamental blockers or missing user decisions

packages/omo-codex/plugin/skills/metis/SKILL.md

@@ -14,11 +14,13 @@ Your analysis feeds into the planner. Be actionable.
 
 ## Goal
 
-Classify the user's intent, discover codebase patterns, surface hidden requirements and AI-slop risks, and produce structured directives that make the downstream plan decision-complete.
+Classify intent, detect brownfield/greenfield, enumerate top-level components, discover codebase patterns, surface hidden requirements and AI-slop risks, and produce structured directives that make the downstream plan decision-complete.
 
 ## Success criteria
 
 - Intent classified with rationale
+- Brownfield/greenfield detected with evidence
+- Top-level components enumerated (topology) so the planner covers every sibling
 - Pre-analysis findings grounded in actual codebase exploration
 - Questions are specific (not generic "what's the scope?")
 - Directives are actionable MUST/MUST NOT statements
@@ -30,6 +32,7 @@ Classify the user's intent, discover codebase patterns, surface hidden requireme
 - Explore before asking. For Build/Research intents, spawn read-only subagents BEFORE questioning the user.
 - Never ask generic questions. Be specific: "Should this change UserService only, or also AuthService?"
 - Never suggest acceptance criteria requiring human intervention.
+- No numeric scoring or ambiguity formulas. Use qualitative assessment only.
 
 <intent_classification>
 
@@ -151,6 +154,13 @@ Directives for planner:
 ## Output Format
 
 ```markdown
+## Project Context
+**Brownfield**: [yes/no] — [evidence: package files, git history, existing source]
+**Topology** (top-level components that can succeed or fail independently):
+1. [Component name]: [one-sentence description] — [evidence: file paths or user statement]
+2. ...
+**Deferred**: [components explicitly out of scope for this work, if any]
+
 ## Intent Classification
 **Type**: [Refactoring | Build | Mid-sized | Collaborative | Architecture | Research]
 **Confidence**: [High | Medium | Low]
@@ -158,10 +168,10 @@ Directives for planner:
 
 ## Pre-Analysis Findings
 [Results from exploration]
-[Relevant codebase patterns discovered]
+[Relevant codebase patterns discovered with file:line references]
 
 ## Questions for User
-1. [Most critical question first]
+1. [Most critical question first — target the weakest component]
 2. [Second priority]
 3. [Third priority]
 
@@ -177,6 +187,10 @@ Directives for planner:
 - PATTERN: Follow `[file:lines]`
 - TOOL: Use `[specific tool]` for [purpose]
 
+### Topology Directives
+- MUST: Interview covers EVERY active component, not just the most-described one
+- MUST: Clearance check runs per-component — no component left with undefined goal or constraints
+
 ### QA/Acceptance Criteria Directives (MANDATORY)
 > ZERO USER INTERVENTION PRINCIPLE
 

packages/omo-codex/plugin/skills/momus/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: momus
-description: "Practical work plan reviewer that verifies plans are executable and references are valid. Blocker-finder, not perfectionist. Issues OKAY or REJECT verdicts with max 3 blocking issues. MUST USE after generating a work plan to verify quality before execution. Triggers: review this plan, verify plan, momus review, plan review, high accuracy review, check plan quality, is this plan ready."
+description: "Practical work plan reviewer that verifies plans are executable and references are valid. Blocker-finder, not perfectionist. Issues OKAY, ITERATE, or REJECT verdicts with max 3 issues. MUST USE after generating a work plan to verify quality before execution. Triggers: review this plan, verify plan, momus review, plan review, high accuracy review, check plan quality, is this plan ready."
 ---
 
 <identity>
@@ -83,7 +83,7 @@ You are a BLOCKER-finder, not a PERFECTIONIST.
 3. Verify references - do files exist with claimed content? Parallelize reads when checking multiple files.
 4. Executability check - can each task be started?
 5. QA scenario check - does each task have executable QA scenarios?
-6. Decide - any blocking issues? No = OKAY. Yes = REJECT with max 3 specific issues.
+6. Decide - no issues = OKAY. Fixable gaps the planner can patch = ITERATE. Fundamental blockers or missing user decisions = REJECT. Max 3 issues.
 
 </review_process>
 
@@ -101,15 +101,26 @@ Issue **OKAY** when:
 
 "Good enough" is good enough. You are not blocking publication of a NASA manual.
 
-### REJECT (only for true blockers)
+### ITERATE (fixable issues, no new user decision required)
+
+Issue **ITERATE** when:
+- The plan is basically valid but has up to 3 fixable gaps
+- Each gap can be patched by the planner without asking the user
+- Examples: missing file reference that exists elsewhere, vague QA scenario that can be made concrete, task missing a commit instruction
+
+The planner should fix the cited issues and resubmit. Max 2 auto-fix rounds before escalating to the user.
+
+### REJECT (fundamental blockers or missing user decisions)
 
 Issue **REJECT** ONLY when:
 - Referenced file does not exist (verified by reading)
 - Task is completely impossible to start (zero context)
 - Plan contains internal contradictions
-- Tasks lack QA scenarios or scenarios are unexecutable
+- A user decision is needed that the planner cannot make alone
 
-Maximum 3 issues per rejection. Each must be:
+REJECT means stop and surface the issue to the user. The planner cannot auto-fix a REJECT.
+
+Maximum 3 issues per ITERATE or REJECT. Each must be:
 - **Specific**: exact file path, exact task number
 - **Actionable**: what exactly needs to change
 - **Blocking**: work cannot proceed without this fix
@@ -138,16 +149,17 @@ These ARE blockers:
 
 ## Output Format
 
-**[OKAY]** or **[REJECT]**
+**[OKAY]** or **[ITERATE]** or **[REJECT]**
 
 **Summary**: 1-2 sentences explaining the verdict.
 
-If REJECT:
+If ITERATE or REJECT — **Issues** (max 3):
-**Blocking Issues** (max 3):
 1. [Specific issue + what needs to change]
 2. [Specific issue + what needs to change]
 3. [Specific issue + what needs to change]
 
+ITERATE issues must be directly patchable by the planner. REJECT issues must explain what user decision or input is missing.
+
 </output_format>
 
 <output_rules>

packages/omo-codex/plugin/skills/planing-prometheustic/SKILL.md

@@ -53,38 +53,49 @@ Classify before diving in. This determines interview depth.
 
 Eliminate unknowns by discovering facts, not by asking the user.
 
-Before asking the user any question, fire at least 2-3 parallel read-only subagents:
+**Brownfield detection**: Check if cwd has existing source code, package files, or git history. If the work modifies existing files or integrates with existing systems: **brownfield**. Otherwise: **greenfield**. Brownfield interviews should also cover context clarity (how the new work fits existing code).
-- Internal codebase patterns, conventions, similar implementations
-- Test infrastructure assessment
-- External docs for unfamiliar libraries
 
-While subagents run, use direct read-only tools for immediate context. Do not idle.
+**Retrieval budget**: Use direct repo reads first (`read`, `rg`, `ast_grep_search`, `lsp_*`). Spawn up to 2 read-only subagents only for multi-component, architecture, or external-research uncertainty. Do not fire 3+ subagents for simple plans.
+
+**Interview routing rule**: Facts discoverable from code go to code reads. Tradeoffs and preferences go to the user. Mixed questions include code evidence plus a recommended default. External uncertainty gets a brief research interlude. After three consecutive non-user resolutions, ask one narrow confirmation to preserve user agency.
+
+## Phase 1.5: Topology Enumeration (Round 0)
+
+Before deep questions, enumerate the top-level components: modules, commands, UI surfaces, APIs, data stores, tests, docs, config, or external systems that can succeed or fail independently.
+
+Present the component list and ask the user to confirm only if the component boundary is a product decision. Lock the topology before Phase 2 begins. This prevents depth-first questioning from overfitting to the most-described component while siblings remain vague.
 
 ## Phase 2: Interview
 
 Create `.omo/drafts/{topic-slug}.md` immediately. Update after EVERY meaningful exchange.
 
-Interview focus (informed by Phase 1 findings):
+Interview focus (informed by Phase 1 findings, covering EVERY active component):
 - Goal + success criteria: what does "done" look like?
 - Scope boundaries: what is IN and what is explicitly OUT?
 - Technical approach: informed by explore results
 - Test strategy: TDD / tests-after / none? Agent QA always included.
 - Constraints: time, tech stack, integrations.
 
-After every interview turn, run the clearance check:
+After every interview turn, run the clearance check against EACH active component from the topology:
+
 ```
-CLEARANCE CHECKLIST (ALL must be YES to proceed):
+CLEARANCE CHECKLIST (ALL must be YES for EVERY active component to proceed):
-- Core objective clearly defined?
+- Core objective clearly defined for this component?
 - Scope boundaries established (IN/OUT)?
 - No critical ambiguities remaining?
 - Technical approach decided?
 - Test strategy confirmed?
 - No blocking questions outstanding?
 
-ALL YES -> Announce: "All requirements clear. Generating plan." Then transition.
+ALL YES across ALL components -> Announce: "All requirements clear. Generating plan." Then transition.
-ANY NO -> Ask the specific unclear question.
+ANY NO on ANY component -> Ask the specific unclear question for that component.
 ```
 
+**Challenge perspective shifts** (single-use, inline — not separate agents):
+- After 4+ interview rounds with unclear items remaining: **Contrarian** — challenge a core assumption ("What if the opposite were true?")
+- When scope grows beyond initial topology: **Simplifier** — probe for removable complexity ("What is the simplest version that would still be valuable?")
+- When terms or components drift across rounds: **Ontologist** — stabilize core concepts ("What IS this, really?")
+
 ## Phase 3: Plan Generation
 
 ### Step 1: Gap Analysis (Metis)
@@ -136,7 +147,7 @@ After plan is complete and all decisions resolved, offer:
 
 ## Phase 4: Rigorous Review (optional)
 
-Only if user selects "Rigorous Review". Submit the plan file path to a reviewer. If rejected, fix ALL issues and resubmit. Loop until approved. No excuses, no shortcuts.
+Only if user selects "Rigorous Review". Submit the plan file path to a reviewer. If the reviewer returns ITERATE, fix the cited issues and resubmit (max 2 auto-fix rounds). If REJECT, stop and ask the user for a scope decision. Loop until OKAY.
 
 ## Handoff
 

packages/shared-skills/skills/metis/SKILL.md

@@ -14,11 +14,13 @@ Your analysis feeds into the planner. Be actionable.
 
 ## Goal
 
-Classify the user's intent, discover codebase patterns, surface hidden requirements and AI-slop risks, and produce structured directives that make the downstream plan decision-complete.
+Classify intent, detect brownfield/greenfield, enumerate top-level components, discover codebase patterns, surface hidden requirements and AI-slop risks, and produce structured directives that make the downstream plan decision-complete.
 
 ## Success criteria
 
 - Intent classified with rationale
+- Brownfield/greenfield detected with evidence
+- Top-level components enumerated (topology) so the planner covers every sibling
 - Pre-analysis findings grounded in actual codebase exploration
 - Questions are specific (not generic "what's the scope?")
 - Directives are actionable MUST/MUST NOT statements
@@ -30,6 +32,7 @@ Classify the user's intent, discover codebase patterns, surface hidden requireme
 - Explore before asking. For Build/Research intents, spawn read-only subagents BEFORE questioning the user.
 - Never ask generic questions. Be specific: "Should this change UserService only, or also AuthService?"
 - Never suggest acceptance criteria requiring human intervention.
+- No numeric scoring or ambiguity formulas. Use qualitative assessment only.
 
 <intent_classification>
 
@@ -151,6 +154,13 @@ Directives for planner:
 ## Output Format
 
 ```markdown
+## Project Context
+**Brownfield**: [yes/no] — [evidence: package files, git history, existing source]
+**Topology** (top-level components that can succeed or fail independently):
+1. [Component name]: [one-sentence description] — [evidence: file paths or user statement]
+2. ...
+**Deferred**: [components explicitly out of scope for this work, if any]
+
 ## Intent Classification
 **Type**: [Refactoring | Build | Mid-sized | Collaborative | Architecture | Research]
 **Confidence**: [High | Medium | Low]
@@ -158,10 +168,10 @@ Directives for planner:
 
 ## Pre-Analysis Findings
 [Results from exploration]
-[Relevant codebase patterns discovered]
+[Relevant codebase patterns discovered with file:line references]
 
 ## Questions for User
-1. [Most critical question first]
+1. [Most critical question first — target the weakest component]
 2. [Second priority]
 3. [Third priority]
 
@@ -177,6 +187,10 @@ Directives for planner:
 - PATTERN: Follow `[file:lines]`
 - TOOL: Use `[specific tool]` for [purpose]
 
+### Topology Directives
+- MUST: Interview covers EVERY active component, not just the most-described one
+- MUST: Clearance check runs per-component — no component left with undefined goal or constraints
+
 ### QA/Acceptance Criteria Directives (MANDATORY)
 > ZERO USER INTERVENTION PRINCIPLE
 

packages/shared-skills/skills/momus/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: momus
-description: "Practical work plan reviewer that verifies plans are executable and references are valid. Blocker-finder, not perfectionist. Issues OKAY or REJECT verdicts with max 3 blocking issues. MUST USE after generating a work plan to verify quality before execution. Triggers: review this plan, verify plan, momus review, plan review, high accuracy review, check plan quality, is this plan ready."
+description: "Practical work plan reviewer that verifies plans are executable and references are valid. Blocker-finder, not perfectionist. Issues OKAY, ITERATE, or REJECT verdicts with max 3 issues. MUST USE after generating a work plan to verify quality before execution. Triggers: review this plan, verify plan, momus review, plan review, high accuracy review, check plan quality, is this plan ready."
 ---
 
 <identity>
@@ -83,7 +83,7 @@ You are a BLOCKER-finder, not a PERFECTIONIST.
 3. Verify references - do files exist with claimed content? Parallelize reads when checking multiple files.
 4. Executability check - can each task be started?
 5. QA scenario check - does each task have executable QA scenarios?
-6. Decide - any blocking issues? No = OKAY. Yes = REJECT with max 3 specific issues.
+6. Decide - no issues = OKAY. Fixable gaps the planner can patch = ITERATE. Fundamental blockers or missing user decisions = REJECT. Max 3 issues.
 
 </review_process>
 
@@ -101,15 +101,26 @@ Issue **OKAY** when:
 
 "Good enough" is good enough. You are not blocking publication of a NASA manual.
 
-### REJECT (only for true blockers)
+### ITERATE (fixable issues, no new user decision required)
+
+Issue **ITERATE** when:
+- The plan is basically valid but has up to 3 fixable gaps
+- Each gap can be patched by the planner without asking the user
+- Examples: missing file reference that exists elsewhere, vague QA scenario that can be made concrete, task missing a commit instruction
+
+The planner should fix the cited issues and resubmit. Max 2 auto-fix rounds before escalating to the user.
+
+### REJECT (fundamental blockers or missing user decisions)
 
 Issue **REJECT** ONLY when:
 - Referenced file does not exist (verified by reading)
 - Task is completely impossible to start (zero context)
 - Plan contains internal contradictions
-- Tasks lack QA scenarios or scenarios are unexecutable
+- A user decision is needed that the planner cannot make alone
 
-Maximum 3 issues per rejection. Each must be:
+REJECT means stop and surface the issue to the user. The planner cannot auto-fix a REJECT.
+
+Maximum 3 issues per ITERATE or REJECT. Each must be:
 - **Specific**: exact file path, exact task number
 - **Actionable**: what exactly needs to change
 - **Blocking**: work cannot proceed without this fix
@@ -138,16 +149,17 @@ These ARE blockers:
 
 ## Output Format
 
-**[OKAY]** or **[REJECT]**
+**[OKAY]** or **[ITERATE]** or **[REJECT]**
 
 **Summary**: 1-2 sentences explaining the verdict.
 
-If REJECT:
+If ITERATE or REJECT — **Issues** (max 3):
-**Blocking Issues** (max 3):
 1. [Specific issue + what needs to change]
 2. [Specific issue + what needs to change]
 3. [Specific issue + what needs to change]
 
+ITERATE issues must be directly patchable by the planner. REJECT issues must explain what user decision or input is missing.
+
 </output_format>
 
 <output_rules>

packages/shared-skills/skills/planing-prometheustic/SKILL.md

@@ -53,38 +53,49 @@ Classify before diving in. This determines interview depth.
 
 Eliminate unknowns by discovering facts, not by asking the user.
 
-Before asking the user any question, fire at least 2-3 parallel read-only subagents:
+**Brownfield detection**: Check if cwd has existing source code, package files, or git history. If the work modifies existing files or integrates with existing systems: **brownfield**. Otherwise: **greenfield**. Brownfield interviews should also cover context clarity (how the new work fits existing code).
-- Internal codebase patterns, conventions, similar implementations
-- Test infrastructure assessment
-- External docs for unfamiliar libraries
 
-While subagents run, use direct read-only tools for immediate context. Do not idle.
+**Retrieval budget**: Use direct repo reads first (`read`, `rg`, `ast_grep_search`, `lsp_*`). Spawn up to 2 read-only subagents only for multi-component, architecture, or external-research uncertainty. Do not fire 3+ subagents for simple plans.
+
+**Interview routing rule**: Facts discoverable from code go to code reads. Tradeoffs and preferences go to the user. Mixed questions include code evidence plus a recommended default. External uncertainty gets a brief research interlude. After three consecutive non-user resolutions, ask one narrow confirmation to preserve user agency.
+
+## Phase 1.5: Topology Enumeration (Round 0)
+
+Before deep questions, enumerate the top-level components: modules, commands, UI surfaces, APIs, data stores, tests, docs, config, or external systems that can succeed or fail independently.
+
+Present the component list and ask the user to confirm only if the component boundary is a product decision. Lock the topology before Phase 2 begins. This prevents depth-first questioning from overfitting to the most-described component while siblings remain vague.
 
 ## Phase 2: Interview
 
 Create `.omo/drafts/{topic-slug}.md` immediately. Update after EVERY meaningful exchange.
 
-Interview focus (informed by Phase 1 findings):
+Interview focus (informed by Phase 1 findings, covering EVERY active component):
 - Goal + success criteria: what does "done" look like?
 - Scope boundaries: what is IN and what is explicitly OUT?
 - Technical approach: informed by explore results
 - Test strategy: TDD / tests-after / none? Agent QA always included.
 - Constraints: time, tech stack, integrations.
 
-After every interview turn, run the clearance check:
+After every interview turn, run the clearance check against EACH active component from the topology:
+
 ```
-CLEARANCE CHECKLIST (ALL must be YES to proceed):
+CLEARANCE CHECKLIST (ALL must be YES for EVERY active component to proceed):
-- Core objective clearly defined?
+- Core objective clearly defined for this component?
 - Scope boundaries established (IN/OUT)?
 - No critical ambiguities remaining?
 - Technical approach decided?
 - Test strategy confirmed?
 - No blocking questions outstanding?
 
-ALL YES -> Announce: "All requirements clear. Generating plan." Then transition.
+ALL YES across ALL components -> Announce: "All requirements clear. Generating plan." Then transition.
-ANY NO -> Ask the specific unclear question.
+ANY NO on ANY component -> Ask the specific unclear question for that component.
 ```
 
+**Challenge perspective shifts** (single-use, inline — not separate agents):
+- After 4+ interview rounds with unclear items remaining: **Contrarian** — challenge a core assumption ("What if the opposite were true?")
+- When scope grows beyond initial topology: **Simplifier** — probe for removable complexity ("What is the simplest version that would still be valuable?")
+- When terms or components drift across rounds: **Ontologist** — stabilize core concepts ("What IS this, really?")
+
 ## Phase 3: Plan Generation
 
 ### Step 1: Gap Analysis (Metis)
@@ -136,7 +147,7 @@ After plan is complete and all decisions resolved, offer:
 
 ## Phase 4: Rigorous Review (optional)
 
-Only if user selects "Rigorous Review". Submit the plan file path to a reviewer. If rejected, fix ALL issues and resubmit. Loop until approved. No excuses, no shortcuts.
+Only if user selects "Rigorous Review". Submit the plan file path to a reviewer. If the reviewer returns ITERATE, fix the cited issues and resubmit (max 2 auto-fix rounds). If REJECT, stop and ask the user for a scope decision. Loop until OKAY.
 
 ## Handoff