スキル一覧に戻る
ryanthedev

oberplan

by ryanthedev

Claude Code skills for enhanced workflows

13🍴 1📅 2026年1月17日
GitHubで見るManusで実行

SKILL.md


name: oberplan description: Use when ANY planning, scoping, or design work is needed BEFORE implementation. Invoke when user asks to "build", "create", "implement", "add feature", "design", or describes desired functionality. CRITICAL - this skill dispatches FIRST, identifies relevant lens skills, clarifies requirements, and produces agent-executable plans. Triggers on "help me build", "I want to create", "let's implement", "design a", "plan for", "how should we approach", "figure out how to", or any request that requires understanding WHAT to build before building it.

Skill: oberplan

Meta-skill that orchestrates planning by loading domain-specific lens skills, clarifying requirements, and producing agent-executable plans.

The Iron Law

NO PLAN SHIPS WITHOUT USER CONFIRMATION AND FINAL REVIEW

This applies to:

  • "Quick" features
  • "Obvious" implementations
  • Plans that "should be straightforward"
  • Your 5th plan after 4 successes

Skipping phases = agents execute wrong plans = rework.


Required Workflow

1. Lens Selection (match user intent to domain skill)
      ↓
2. Requirements Clarification (guiding questions, expected outputs)
      ↓
3. Plan Construction (phase-by-phase OR finalized, per user preference)
      ↓
4. User Confirmation (explicit approval)
      ↓
5. Final Review (catch gaps before dispatch)
      ↓
6. Plan Quality Review (code review the plan itself)
      ↓
7. Save Plan to File (persist for execution)
      ↓
8. Output (agent-executable planning document)
      ↓
9. Generate Execution Prompt (oberprompt bootstrap for fresh context)
      ↓
10. Execution Handoff (provide bootstrap prompt for fresh context)

Phase 1: Lens Selection

Before ANY planning, identify the domain skill that provides the right "lens" for understanding this problem.

Process

  1. Parse user request for domain signals
  2. Match to available lens skills
  3. Load the skill to inform subsequent phases

Domain-to-Skill Mapping

User Intent SignalsLens SkillWhy
"frontend", "UI", "component", "page", "design"frontend-designVisual/interaction patterns
"API", "endpoint", "backend", "service"backend architecture skillSystem integration patterns
"debug", "fix", "broken", "not working"oberdebugHypothesis-driven investigation
"prompt", "agent", "LLM", "AI behavior"oberpromptPrompt engineering principles
"refactor", "clean up", "improve code"code-foundationsConstruction principles
General/unclearNone (proceed with generic planning)Avoid over-specialization

Output

LENS SELECTED: [skill-name]
RATIONALE: [why this lens fits]
LOADING: [invoke skill to inform subsequent phases]

If no lens matches, proceed directly to Phase 2 with generic planning approach.


Phase 2: Requirements Clarification

Do NOT plan until requirements are understood.

Guiding Questions (ask in batches of 2-3)

CategoryQuestions
Outcome"What does success look like?" / "How will you know it's done?"
Scope"What's in scope? What's explicitly NOT in scope?"
Constraints"Any technical constraints, timeline, or dependencies?"
Users"Who uses this? What's their workflow?"
Integration"What existing systems does this touch?"
Output format"Should I walk through phase-by-phase, or deliver a finalized plan?"

Decision: Interactive vs Finalized

User SaysInterpretationAction
"walk me through it", "let's discuss", "phase by phase"Interactive modePresent each plan section, get feedback, iterate
"just give me the plan", "finalized", "I trust you"Finalized modeComplete full plan, present for single approval
UnclearDefault to interactiveSafer - catches misalignment early

Output

REQUIREMENTS CONFIRMED:
- Outcome: [what success looks like]
- Scope: [in/out boundaries]
- Constraints: [technical, timeline, dependencies]
- Mode: [Interactive | Finalized]

Phase 3: Plan Construction

Plan Structure

Every plan MUST include:

SectionPurposeRequired?
ObjectiveSingle sentence: what we're buildingYES
DeliverablesConcrete outputs agents will produceYES
PhasesOrdered steps with clear boundariesYES
Agent AssignmentWhich agent type handles each phaseYES
DependenciesWhat must complete before each phaseYES
Validation CriteriaHow to verify each phase succeededYES
CheckpointsQuality gates between phasesYES
Risks/AssumptionsWhat could go wrong, what we're assumingYES

Checkpoints

See checkpoint-templates.md for checkpoint types, capability proofs, placement rules, and templates.

Interactive Mode

For each phase:

  1. Present phase details
  2. Ask: "Does this align with your expectations? Any adjustments?"
  3. Incorporate feedback
  4. Proceed to next phase

Finalized Mode

  1. Construct complete plan
  2. Present entire plan
  3. Ask for single approval

Phase Template

See phase-templates.md for phase and document templates.


Phase 4: User Confirmation

MANDATORY - Do not proceed without explicit approval.

Confirmation Request

PLAN COMPLETE

[Summary of phases]

Ready to proceed? Please confirm:
- [ ] Scope is correct
- [ ] Phase order makes sense
- [ ] Agent assignments are appropriate
- [ ] Nothing critical is missing

Reply "approved" to proceed to final review, or specify changes.
User ResponseAction
"approved", "looks good", "yes"Proceed to Phase 5
Specific feedbackRevise plan, re-present for confirmation
"wait", "hold on", "not sure"Pause, ask clarifying questions

Phase 5: Final Review

After user approval, systematic gap check.

Review Checklist (Complete EVERY item)

#CheckVerification
1Each phase has exactly ONE responsible agentNo shared ownership
2Agent skills are explicitly assignedSubagents don't inherit
3Dependencies form valid DAG (no cycles)Phases can execute in order
4Validation criteria are testableNot vague like "works correctly"
5Checkpoints after every implementation phaseNo impl→impl without quality gate
6Tests specified for each checkpointNot just "verify it works"
7Capability proofs before visual/rendering workProve it renders before building on it
8Edge cases consideredWhat if X fails?
9Integration points identifiedWhere do phases connect?
10Rollback path existsCan we undo if wrong?

Gap Detection

For each phase, ask:

  • "What could go wrong here?"
  • "What am I assuming that might not be true?"
  • "What would an agent need to know that isn't explicitly stated?"

Output

FINAL REVIEW COMPLETE:
- Gaps identified: [list or "none"]
- Mitigations added: [list or "n/a"]
- Plan status: READY FOR QUALITY REVIEW

Phase 6: Plan Quality Review

Code review the plan itself before execution.

Plans are code for agents. They have edge cases, implicit assumptions, and phases that may be too vague.

Review Process

Dispatch a review agent (via oberagent) to evaluate the plan:

Task(
  subagent_type="general-purpose",
  description="Review: implementation plan quality",
  prompt="Review this implementation plan for completeness and executability.

  PLAN:
  [Full plan content]

  REVIEW CRITERIA:
  1. Phase objectives are actionable (not vague)
  2. Agent prompts have enough context to succeed
  3. Checkpoints have testable pass criteria
  4. Dependencies are explicit (no hidden assumptions)
  5. Risk mitigations are realistic
  6. Nothing requires information not available at that phase

  RETURN FORMAT:
  VERDICT: [READY | NEEDS_REVISION]

  If NEEDS_REVISION:
  ISSUES:
  - [Phase N] - [specific issue]

  SUMMARY: [1-2 sentences]"
)
VerdictAction
READYProceed to Save Plan
NEEDS_REVISIONRevise plan, re-review (max 2 cycles)

Phase 7: Save Plan to File

Persist the plan for execution in this or a fresh context.

File Location

~/.local/state/oberplan/plans/{project-name}-{timestamp}.md

File Format

Include: Plan content, execution instructions, and bootstrap prompt.


Phase 8: Output

Produce agent-executable planning document.

See phase-templates.md for the document format.


Phases 9-10: Bootstrap & Handoff

See bootstrap-guide.md for execution prompt generation and handoff procedures.


Red Flags - STOP and Reconsider

If You're ThinkingRealityAction
"Requirements are obvious"Obvious to you ≠ obvious to userAsk the guiding questions anyway
"Skip to finalized, user is busy"Fast planning = slow reworkDefault to interactive mode
"This phase is too small to plan"Small gaps compoundEvery phase needs the template
"User already approved"Approval ≠ no gaps existFinal review is mandatory
"I'll figure it out during execution"That's not planningComplete the plan first
"No lens skill matches"Proceed without over-specializingGeneric planning is valid
"We can test everything at the end"Late bugs are 10x more expensiveCheckpoint after every impl phase
"Checkpoints add overhead"Debugging without checkpoints adds moreQuality gates are mandatory

Integration

With oberexec

After plan approval, provide bootstrap prompt for fresh context execution. oberexec handles subagent-driven execution with checkpoints.

With oberagent

  • Phase 6: Dispatch plan review agent via oberagent
  • Execution: oberexec uses oberagent for all dispatches (in fresh context)

With oberprompt

  • Phase 9: Use oberprompt principles to craft the bootstrap prompt for fresh context execution
  • Ensures bootstrap prompt is outcome-focused, minimal constraints, high confidence

With oberdebug

If user request involves fixing bugs, redirect to oberdebug - debugging is not planning.

With code-foundations

  • Phase 6: Plan review agent invokes code-foundations for quality evaluation
  • Phases are designed with code-foundations principles (clear objectives, testable outputs)

スコア

総合スコア

45/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

0/5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です