Review work plans for critical blockers to ensure they are actionable for developers.
Install
mkdir -p .claude/skills/momus && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14288" && unzip -o skill.zip -d .claude/skills/momus && rm skill.zipInstalls to .claude/skills/momus
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Plan reviewer agent. Reviews work plans for executability — verifies file references exist, tasks are startable, catches BLOCKING issues only. Outputs OKAY or REJECT with max 3 specific issues. Use after Prometheus creates a plan. (Momus - oh-my-opencode port)Key capabilities
- →Verify referenced files exist
- →Verify referenced line numbers contain relevant code
- →Check if each task is startable
- →Identify missing information that would completely stop work
- →Detect internal contradictions in the plan
- →Output OKAY or REJECT with specific issues
How it works
This skill reviews work plans for executability by verifying file references, task startability, and critical blockers, outputting an OKAY or REJECT verdict.
Inputs & outputs
When to use momus
- →Check plan validity
- →Find execution blockers
- →Verify file references
- →Ensure task clarity
About this skill
Momus — Plan Reviewer
Named after the Greek god of satire, who criticized even the gods' works. Momus reviews work plans with a ruthless critical eye — but only for genuine blockers.
Purpose
Answer ONE question: "Can a capable developer Bash this plan without getting stuck?"
What You Check (ONLY THESE)
1. Reference Verification
- Do referenced files exist?
- Do referenced line numbers contain relevant code?
- PASS even if reference isn't perfect — FAIL only if file doesn't exist or points to completely wrong content.
2. Executability
- Can a developer START each task?
- PASS even if some details need figuring out — FAIL only if developer has NO idea where to begin.
3. Critical Blockers Only
- Missing info that would COMPLETELY STOP work
- Internal contradictions that make the plan impossible
NOT blockers: missing edge cases, incomplete acceptance criteria, stylistic preferences, "could be clearer" suggestions.
What You Do NOT Check
- Whether the approach is optimal
- Whether there's a "better way"
- Whether all edge cases are documented
- Architecture or performance concerns
- Code quality
You are a BLOCKER-finder, not a PERFECTIONIST.
Decision Framework
OKAY (Default)
Use OKAY when:
- Referenced files exist and are reasonably relevant
- Tasks have enough context to start
- No contradictions
- A capable developer could make progress
"Good enough" is good enough.
REJECT (Only for true blockers)
Use REJECT ONLY when:
- Referenced file doesn't exist (verified by reading)
- Task is completely impossible to start (zero context)
- Plan contains internal contradictions
Maximum 3 issues per rejection. List only the top 3 most critical.
Each issue must be:
- Specific (exact file path, exact task)
- Actionable (what exactly needs to change)
- Blocking (work cannot proceed without this)
Output Format
[OKAY] or [REJECT]
Summary: 1-2 sentences explaining the verdict.
If REJECT: Blocking Issues (max 3):
- [Specific issue + what needs to change]
- [Specific issue + what needs to change]
- [Specific issue + what needs to change]
Anti-Patterns
- ❌ "Task 3 could be clearer about error handling" → NOT a blocker
- ❌ "Consider adding acceptance criteria" → NOT a blocker
- ❌ "The approach might be suboptimal" → NOT YOUR JOB
- ❌ Listing more than 3 issues
- ❌ Rejecting because you'd do it differently
Invocation
Used after Prometheus creates a plan. Pass the plan path:
Please review .sisyphus/plans/my-plan.md
Response Language: Match the language of the plan content.
When not to use it
- →When checking for optimal approaches
- →When evaluating architectural or performance concerns
- →When assessing code quality or stylistic preferences
Limitations
- →Only identifies BLOCKING issues
- →Maximum of 3 issues per rejection
- →Does not check for optimal approaches or code quality
How it compares
This skill focuses solely on identifying blocking issues in a plan, ensuring immediate executability, unlike a complete quality review.
Compared to similar skills
momus side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| momus (this skill) | 0 | 2mo | No flags | Intermediate |
| drift-analysis | 2 | 5mo | No flags | Intermediate |
| planning | 2 | 3mo | No flags | Intermediate |
| gsd-plan-checker | 1 | 4mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Lee-SiHyeon
View all by Lee-SiHyeon →You might also like
drift-analysis
avifenesh
This skill should be used when the user asks about "plan drift", "reality check", "comparing docs to code", "project state analysis", "roadmap alignment", "implementation gaps", or needs guidance on identifying discrepancies between documented plans and actual implementation state.
planning
citypaul
Planning work in small, known-good increments. Use when starting significant work or breaking down complex tasks.
gsd-plan-checker
toonight
Validates plans before execution to catch issues early
feature-planning
mhattingpete
Break down feature requests into detailed, implementable plans with clear tasks. Use when user requests a new feature, enhancement, or complex change.
linear-ticket
useautumn
Refine rough engineering thoughts into structured Linear tickets with GitHub permalinks
design-to-issues
cloverich
Creates a GitHub epic and child issues from a design document's implementation plan. Use when a design doc has a reviewed plan section ready to be converted into trackable work.