Planr Openplanr

---
name: planr-openplanr
description: Route a planning, specification, delivery, delegation, design, review, diagram, release, or operating request to the best OpenPlanr skill. Use when the right skill is unclear or the request spans several.
license: MIT
---

# OpenPlanr Router

Decide which OpenPlanr skill owns the request, say which one and why in one
line, then invoke it. Invoke a skill by its host name: the skill id without the
`planr-` prefix, namespaced under `planr` (`planr-plan` is `/planr:plan` in
Claude Code and `$planr:plan` in Codex). Do not perform the routed work here.

## Route by intent

| The user wants to… | Skill |
| --- | --- |
| Turn a vague idea or requirement into a measurable specification | `planr-spec` |
| Break a specification or intent into stories and tasks | `planr-plan` |
| Check a plan before implementation starts | `planr-plan-review` |
| Ask another coding agent to implement a task while the active agent orchestrates | `planr-delegate` |
| Build, fix, finish, or ship local work | `planr-ship` |
| Find the root cause of a bug, regression, or odd behavior | `planr-investigate` |
| Test the running application in a real browser | `planr-browser-qa` |
| Design a new interface or a coherent design direction | `planr-design` |
| Compare several design directions | `planr-design-loop` |
| Revise an existing design with pinned feedback | `planr-design-review` |
| Create or check an architecture, process, sequence, or data diagram | `planr-diagram` |
| Share, import, or export an HTML artifact review | `planr-artifact` |
| Know what is done, pending, blocked, or next | `planr-status` |
| Refine the open backlog and select the sprint for the next release cut | `planr-sprint` |
| See planning or Operate state in the browser | `planr-dashboard` |
| Check artifacts for graph, status, or schema drift | `planr-sync` |
| Judge release readiness or prepare a landing sequence | `planr-land` |
| Pick a versioning scheme, bump versions, write release notes | `planr-release` |
| Diagnose the CLI, plugins, installation, or upgrade state | `planr-doctor` |
| Run a leadership operating review across all lenses | `planr-operate` |
| Get one executive lens on an Operate cycle | `planr-ceo-review`, `planr-cto-review`, `planr-cpo-review`, `planr-cmo-review`, `planr-coo-review` |
| Stress-test an Operate cycle's claims, or synthesize its decisions | `planr-challenger-review`, `planr-chair-review` |

## Boundaries

- Explicitly asking another coding agent to implement routes to `planr-delegate`,
  even if the request also says build or Ship. Plain implementation stays with
  host-native `planr-ship`; merely mentioning an agent is not delegation. Native
  parallel implementation agents remain part of Ship. Asking another agent to
  review code does not request implementation delegation.
- PLAN and SHIP are separate user-invoked workflows. Route to one; never chain
  `planr-plan` into `planr-ship` on the user's behalf.
- When a request spans several skills, route to the earliest step in that
  order (spec → plan → plan-review → ship → land → release) and name the rest.
- When the request is not OpenPlanr work at all, say so and answer directly
  without invoking a skill.
- Ask one concise question only when two candidate skills would produce
  materially different work.

## Return

Announce the selected skill and its purpose once, then let that skill return the
achieved result, deliverable links, actual verification and any next action.
Do not duplicate its final summary or include raw routing transcripts. If routing
is blocked, state the unresolved choice or unavailable skill and the smallest
recovery action. Keep existing identifiers and native invocations; summary
wording never triggers a second invocation.