From 16c0844421b4c7d4896371c0d57f75c1d49e464e Mon Sep 17 00:00:00 2001 From: YeonGyu-Kim Date: Thu, 28 May 2026 14:38:52 +0900 Subject: [PATCH] feat(shared-skills): incorporate ouroboros/gajae-code patterns into planning skills MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../omo-codex/plugin/skills/metis/SKILL.md | 20 +++++++++-- .../omo-codex/plugin/skills/momus/SKILL.md | 28 ++++++++++----- .../skills/planing-prometheustic/SKILL.md | 35 ++++++++++++------- packages/shared-skills/skills/metis/SKILL.md | 20 +++++++++-- packages/shared-skills/skills/momus/SKILL.md | 28 ++++++++++----- .../skills/planing-prometheustic/SKILL.md | 35 ++++++++++++------- 6 files changed, 120 insertions(+), 46 deletions(-) diff --git a/packages/omo-codex/plugin/skills/metis/SKILL.md b/packages/omo-codex/plugin/skills/metis/SKILL.md index 65e3650b4..d80164756 100644 --- a/packages/omo-codex/plugin/skills/metis/SKILL.md +++ b/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. @@ -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 diff --git a/packages/omo-codex/plugin/skills/momus/SKILL.md b/packages/omo-codex/plugin/skills/momus/SKILL.md index 7b3929e70..cc5dca07e 100644 --- a/packages/omo-codex/plugin/skills/momus/SKILL.md +++ b/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." --- @@ -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. @@ -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. + diff --git a/packages/omo-codex/plugin/skills/planing-prometheustic/SKILL.md b/packages/omo-codex/plugin/skills/planing-prometheustic/SKILL.md index 07889ceb3..bf75389f3 100644 --- a/packages/omo-codex/plugin/skills/planing-prometheustic/SKILL.md +++ b/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: -- Internal codebase patterns, conventions, similar implementations -- Test infrastructure assessment -- External docs for unfamiliar libraries +**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). -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): -- Core objective clearly defined? +CLEARANCE CHECKLIST (ALL must be YES for EVERY active component to proceed): +- 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. -ANY NO -> Ask the specific unclear question. +ALL YES across ALL components -> Announce: "All requirements clear. Generating plan." Then transition. +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 diff --git a/packages/shared-skills/skills/metis/SKILL.md b/packages/shared-skills/skills/metis/SKILL.md index 65e3650b4..d80164756 100644 --- a/packages/shared-skills/skills/metis/SKILL.md +++ b/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. @@ -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 diff --git a/packages/shared-skills/skills/momus/SKILL.md b/packages/shared-skills/skills/momus/SKILL.md index 7b3929e70..cc5dca07e 100644 --- a/packages/shared-skills/skills/momus/SKILL.md +++ b/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." --- @@ -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. @@ -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. + diff --git a/packages/shared-skills/skills/planing-prometheustic/SKILL.md b/packages/shared-skills/skills/planing-prometheustic/SKILL.md index 07889ceb3..bf75389f3 100644 --- a/packages/shared-skills/skills/planing-prometheustic/SKILL.md +++ b/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: -- Internal codebase patterns, conventions, similar implementations -- Test infrastructure assessment -- External docs for unfamiliar libraries +**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). -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): -- Core objective clearly defined? +CLEARANCE CHECKLIST (ALL must be YES for EVERY active component to proceed): +- 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. -ANY NO -> Ask the specific unclear question. +ALL YES across ALL components -> Announce: "All requirements clear. Generating plan." Then transition. +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