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/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:
-**Blocking Issues** (max 3):
+If ITERATE or REJECT — **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>