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
This commit is contained in:
YeonGyu-Kim
@@ -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
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user