Skill detail

ralplan

Turn an approved spec into a consensus-reviewed plan with a PRD (prd.json) of testable stories, gating vague /ralph or /team requests before they run unattended. Use ONLY when explicitly invoked (/ralplan), typically right after deep-interview hands off a spec, or when the user asks to plan before a ralph/team run. Do NOT use for direct small edits, and do not treat an invocation of /ralph or /team as implicitly requesting this — ralplan only runs when named.

Why we recommend it: Turns an approved spec into a consensus-reviewed plan with a prd.json of testable stories, gating vague ralph/team requests before unattended runs.

MatchDirectRecommended for Muse
Sourcesiddicky/​oh-my-musecodeExternal source
Reported installsNot reportedPopularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: ralplan
description: Turn an approved spec into a consensus-reviewed plan with a PRD (prd.json) of testable stories, gating vague /ralph or /team requests before they run unattended. Use ONLY when explicitly invoked (/ralplan), typically right after deep-interview hands off a spec, or when the user asks to plan before a ralph/team run. Do NOT use for direct small edits, and do not treat an invocation of /ralph or /team as implicitly requesting this — ralplan only runs when named.
---

# Ralplan

Convert an approved spec (or a request specific enough to skip straight to
planning) into a `prd.json` of testable stories, reviewed for consensus
before `ralph` is allowed to run unattended against it.

Explicit invocation only — there is no hook that auto-routes a vague `/ralph`
or `/team` request into this skill. If you want that gating, say so in
prose to the user yourself: "this looks underspecified for an unattended
ralph run — recommend `/ralplan` first," and let the user decide.

## Inputs

- An approved spec at `.omm/specs/<slug>.md` (preferred), or
- A request detailed enough to plan directly, when the user explicitly says
  to skip the interview stage.

## Producing the PRD

Write `.omm/state/prd.json` (create `.omm/state/` if missing) shaped as:

```json
{
  "goal": "one sentence",
  "source_spec": ".omm/specs/<slug>.md",
  "stories": [
    {
      "id": "US-001",
      "title": "short title",
      "description": "what this story delivers",
      "acceptance_criteria": [
        "testable, falsifiable statement",
        "another testable statement"
      ],
      "status": "pending"
    }
  ]
}
```

Every story's acceptance criteria must be testable by inspection, command
output, or reproducible check — not by opinion. "Code is cleaner" is not a
valid criterion; "muse skills validate <path> reports valid: true with zero
unsupported-skill-field diagnostics" is. `ralph` will iterate against this
file story by story, so vague criteria become the loop's failure mode later.

## Consensus review

Before presenting the plan, get a second opinion:

1. Default reviewer is the `critic` persona in-process:
   `subagent_spawn("critic", "review prd.json at .omm/state/prd.json against
   the spec for gaps, untestable criteria, and scope creep")`, then
   `subagent_wait` / `subagent_read_result`.
2. **`--critic=codex` or `--critic=claude` option.** When the user passes
   this, route the review through the named external CLI instead of the
   in-process critic persona. This requires the session to have been
   launched with `muse --disable-sandbox` (or `--yolo`) — say so explicitly
   if it was not, and stop rather than silently falling back to the
   in-process critic, since that changes what was actually reviewed.

   **Be honest about the tradeoff.** Shelling out to an external `codex` or
   `claude` CLI process costs two separate things. First, that review's work
   happens outside Muse's append-only audit trail — the external process's
   reasoning and any files it touches are not captured the way an in-session
   `subagent_spawn` result is. Second, the escalation is session-wide:
   `--disable-sandbox` removes filesystem and network sandboxing for
   everything in the session, not just the critic call.

   On Muse 1.3.0-R3057.1 the `--permission-profile` flag exists, but no
   profile is defined by default (the probe reports `profile does not
   exist`) and the enterprise-config shape that defines one is unconfirmed —
   so unless the session already has a usable profile, the broad carve-out
   is the actual price of an external critic. State this plainly in the
   review summary; do not soft-pedal it as equivalent to the in-process
   critic.
3. Incorporate the critic's findings into the PRD before presenting it.
   Untestable criteria, missing stories implied by the spec, and scope the
   critic flags as unjustified should be fixed, not just noted.

## Approval gate

Present the final `prd.json` contents (or a readable
Read the full source on GitHub (opens external page)
Context

Related work