--- title: Prompt library description: Copy-ready prompts for OpenPlanr skills, tagged by task and role. Each one shows the command for your host and why it works. url: https://openplanr.dev/docs/prompts updated: 2026-10-06 related: [] --- # Prompt library Copy-ready prompts for OpenPlanr skills, tagged by task and role. Each one shows the command for your host and why it works. ## [Turn a rough idea into a spec](https://openplanr.dev/docs/prompts/spec-from-idea.md) Start every feature with a specification your agent can check its work against. Claude Code: ```text /spec add passwordless sign-in for existing accounts. Users drop off at the password step. ``` If /spec runs another command, use /planr:spec. Codex: ```text $spec add passwordless sign-in for existing accounts. Users drop off at the password step. ``` With the OpenPlanr plugin for Codex, use $planr:spec. Cursor: ```text @planr-spec add passwordless sign-in for existing accounts. Users drop off at the password step. ``` Cursor applies the planr-spec rule when you mention it in chat. Why this works: Name the change and the problem it solves. The skill reads your repository for the rest, and when a missing decision would change the scope, it asks at most 3 short questions at a time. Requirements and acceptance criteria come out observable, so the work can be checked against them. ## [Break a spec into stories and tasks](https://openplanr.dev/docs/prompts/plan-a-spec.md) Get user stories and tasks with acceptance criteria and file-level changes. Claude Code: ```text /planr:plan SPEC-001 ``` Codex: ```text $plan SPEC-001 ``` With the OpenPlanr plugin for Codex, use $planr:plan. Cursor: ```text @planr-plan SPEC-001 ``` Cursor applies the planr-plan rule when you mention it in chat. Why this works: Plan reads the saved spec, so every story keeps its acceptance criteria and every task names its files, its dependencies, and the checks that prove it is done. It stops after the plan and never starts building on its own. ## [Ship one task, then stop](https://openplanr.dev/docs/prompts/ship-one-task.md) Build one task end to end and keep the change small enough to review. Claude Code: ```text /ship T-001 ``` If /ship runs another command, use /planr:ship. Codex: ```text $ship T-001 ``` With the OpenPlanr plugin for Codex, use $planr:ship. Cursor: ```text @planr-ship T-001 ``` Cursor applies the planr-ship rule when you mention it in chat. Why this works: Ship reads the task, its story, its acceptance criteria, and the spec before it changes code, then runs the checks the repository defines. One task at a time keeps each change small enough to review as one pull request. ## [Ask what is done, blocked, and next](https://openplanr.dev/docs/prompts/status-check.md) Read delivery status from the plan in your repo without changing anything. Claude Code: ```text /planr:status ``` Codex: ```text $status ``` With the OpenPlanr plugin for Codex, use $planr:status. Cursor: ```text @planr-status ``` Cursor applies the planr-status rule when you mention it in chat. Why this works: Status reads your planning files, task statuses, and dependency graph without changing them, then reports ready and blocked work and the most useful next action. It is read-only, so ask as often as you like. ## [Design the screens before anyone builds them](https://openplanr.dev/docs/prompts/design-before-build.md) One design direction in a studio you can click through, plus a design spec Plan can read. Claude Code: ```text /planr:design the onboarding checklist for new accounts on desktop and phone, with empty and error states ``` Codex: ```text $design the onboarding checklist for new accounts on desktop and phone, with empty and error states ``` With the OpenPlanr plugin for Codex, use $planr:design. Cursor: ```text @planr-design the onboarding checklist for new accounts on desktop and phone, with empty and error states ``` Cursor applies the planr-design rule when you mention it in chat. Why this works: Name the screens, the sizes, and the states. Design builds one direction you can review as a canvas, a prototype, and a walkthrough, then writes a 10-section design spec that Plan reads before it splits the UI work. ## [Apply pinned design feedback](https://openplanr.dev/docs/prompts/apply-pinned-feedback.md) Revise only the screens your review pins point at, and keep everything else as it was. Claude Code: ```text /design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged. ``` If /design-review runs another command, use /planr:design-review. Codex: ```text $design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged. ``` With the OpenPlanr plugin for Codex, use $planr:design-review. Cursor: ```text @planr-design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged. ``` Cursor applies the planr-design-review rule when you mention it in chat. Why this works: Design Review maps each pin to a stable screen and anchor, changes only the targeted source, and checks the revised screens in a browser before it resolves a pin. Pins it cannot place are reported as unresolved, not attached somewhere else. ## [Audit the plan for drift](https://openplanr.dev/docs/prompts/audit-plan-drift.md) Check that stories, tasks, statuses, and references in the planning folder still agree. Claude Code: ```text /sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything. ``` If /sync runs another command, use /planr:sync. Codex: ```text $sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything. ``` With the OpenPlanr plugin for Codex, use $planr:sync. Cursor: ```text @planr-sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything. ``` Cursor applies the planr-sync rule when you mention it in chat. Why this works: Sync audits read-only by default. It applies local repairs only when you ask for reconciliation, and it pushes to GitHub or Linear only when you ask for external sync. ## [Check a branch is ready to land](https://openplanr.dev/docs/prompts/ready-to-land.md) Assess release readiness without merging, publishing, or deploying anything. Claude Code: ```text /land the sign-in work on this branch ``` If /land runs another command, use /planr:land. Codex: ```text $land the sign-in work on this branch ``` With the OpenPlanr plugin for Codex, use $planr:land. Cursor: ```text @planr-land the sign-in work on this branch ``` Cursor applies the planr-land rule when you mention it in chat. Why this works: Land reads the branch, the worktree, and the checks that already ran, then answers ready, conditional, or blocked, with the blockers, the landing sequence, and a recovery step. It prepares the commands but does not merge, publish, or deploy. ## [Check a page for accessibility and console errors](https://openplanr.dev/docs/prompts/check-page-accessibility.md) Keyboard access, focus, accessible names, console errors, and failed requests on one page. Claude Code: ```text /browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests. ``` If /browser-qa runs another command, use /planr:browser-qa. Codex: ```text $browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests. ``` With the OpenPlanr plugin for Codex, use $planr:browser-qa. Cursor: ```text @planr-browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests. ``` Cursor applies the planr-browser-qa rule when you mention it in chat. Why this works: Browser QA checks navigation, forms, responsive layout, keyboard access, visible focus, accessible names, console errors, and failed requests in a real browser. Checks it could not run are reported as unverified, never as a pass. ## [Check a plan's first-run developer experience](https://openplanr.dev/docs/prompts/review-plan-developer-experience.md) Ask the plan review to focus on setup, defaults, error messages, and recovery. Claude Code: ```text /plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery. ``` If /plan-review runs another command, use /planr:plan-review. Codex: ```text $plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery. ``` With the OpenPlanr plugin for Codex, use $planr:plan-review. Cursor: ```text @planr-plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery. ``` Cursor applies the planr-plan-review rule when you mention it in chat. Why this works: Plan Review covers the first-run and everyday developer experience, including setup, diagnostics, defaults, and recovery. It uses only the review lenses the work needs, so naming the focus keeps the findings on the part you care about. ## [Check migration and rollback before you build](https://openplanr.dev/docs/prompts/review-plan-rollback.md) Have the plan reviewed for migration, security, operability, and rollback risk. Claude Code: ```text /plan-review SPEC-001. Check the migration, security, and rollback plan before we build. ``` If /plan-review runs another command, use /planr:plan-review. Codex: ```text $plan-review SPEC-001. Check the migration, security, and rollback plan before we build. ``` With the OpenPlanr plugin for Codex, use $planr:plan-review. Cursor: ```text @planr-plan-review SPEC-001. Check the migration, security, and rollback plan before we build. ``` Cursor applies the planr-plan-review rule when you mention it in chat. Why this works: Plan Review checks scope, sequencing, architecture, migration, security, operability, testing, and rollback in proportion to the change. Any must-fix issue turns the verdict to needs revision and names the plan section and the change that would resolve it. ## [Choose the next version number](https://openplanr.dev/docs/prompts/choose-next-version.md) Decide major, minor, or patch from what changed for users, not from the size of the diff. Claude Code: ```text /release Choose the next version for this CLI and explain whether it is a major, minor, or patch release. ``` If /release runs another command, use /planr:release. Codex: ```text $release Choose the next version for this CLI and explain whether it is a major, minor, or patch release. ``` With the OpenPlanr plugin for Codex, use $planr:release. Cursor: ```text @planr-release Choose the next version for this CLI and explain whether it is a major, minor, or patch release. ``` Cursor applies the planr-release rule when you mention it in chat. Why this works: Release picks the bump from how each change affects users. A CLI or library that others install and pin follows SemVer strictly, and the chosen scheme goes into a release profile so later releases follow it instead of deciding again. ## [Compare 3 design directions](https://openplanr.dev/docs/prompts/compare-design-directions.md) See 3 materially different directions side by side, rate them, and develop the one you pick. Claude Code: ```text /design-loop Compare 3 directions for the dashboard home on desktop and phone. ``` If /design-loop runs another command, use /planr:design-loop. Codex: ```text $design-loop Compare 3 directions for the dashboard home on desktop and phone. ``` With the OpenPlanr plugin for Codex, use $planr:design-loop. Cursor: ```text @planr-design-loop Compare 3 directions for the dashboard home on desktop and phone. ``` Cursor applies the planr-design-loop rule when you mention it in chat. Why this works: Design Loop builds 3 materially different directions for the same journey in a live review studio. You pin and rate them on the board, and it develops the direction you select. Until you select one, it reports the comparison as awaiting selection. ## [Diagnose a failure without changing code](https://openplanr.dev/docs/prompts/diagnose-without-fixing.md) Get the root cause and the evidence for it, with no edits until you decide on a fix. Claude Code: ```text /investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet. ``` If /investigate runs another command, use /planr:investigate. Codex: ```text $investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet. ``` With the OpenPlanr plugin for Codex, use $planr:investigate. Cursor: ```text @planr-investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet. ``` Cursor applies the planr-investigate rule when you mention it in chat. Why this works: Without a request to fix, Investigate stays diagnostic. It reports the established cause or the strongest remaining hypotheses, the checks it ran, and what is still uncertain. ## [Draw the request flow as a diagram](https://openplanr.dev/docs/prompts/diagram-the-flow.md) Get SVG, PNG, and an accessible HTML version from one canonical document. Claude Code: ```text /diagram the request flow from the web app to the API and the queue as an architecture diagram ``` If /diagram runs another command, use /planr:diagram. Codex: ```text $diagram the request flow from the web app to the API and the queue as an architecture diagram ``` With the OpenPlanr plugin for Codex, use $planr:diagram. Cursor: ```text @planr-diagram the request flow from the web app to the API and the queue as an architecture diagram ``` Cursor applies the planr-diagram rule when you mention it in chat. Why this works: Name the kind of diagram you want. The skill turns your description into one canonical document, and the offline engine lays it out and renders SVG, PNG, and accessible HTML from it, with a manifest that binds the set. ## [Find out why a skill is missing](https://openplanr.dev/docs/prompts/diagnose-setup.md) Diagnose the OpenPlanr installation and preview any repair before it touches a file. Claude Code: ```text /planr:doctor The spec skill does not show up after setup. Find the cause and preview any repair before applying it. ``` Codex: ```text $doctor The spec skill does not show up after setup. Find the cause and preview any repair before applying it. ``` With the OpenPlanr plugin for Codex, use $planr:doctor. Cursor: ```text @planr-doctor The spec skill does not show up after setup. Find the cause and preview any repair before applying it. ``` Cursor applies the planr-doctor rule when you mention it in chat. Why this works: Doctor checks the CLI, the pipeline, the agent adapters, the installation, and the lock, and previews every repair. Installing packages, changing versions, and deleting files always wait for your confirmation. ## [Find the root cause before you fix it](https://openplanr.dev/docs/prompts/investigate-first.md) Reproduce the defect, establish why it happens, then apply a bounded fix. Claude Code: ```text /investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test. ``` If /investigate runs another command, use /planr:investigate. Codex: ```text $investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test. ``` With the OpenPlanr plugin for Codex, use $planr:investigate. Cursor: ```text @planr-investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test. ``` Cursor applies the planr-investigate rule when you mention it in chat. Why this works: Investigate starts from the smallest reproducible case and tests competing causes before it names one. It changes code only when you ask for a fix, and then runs focused regression checks. ## [Find what is blocked and why](https://openplanr.dev/docs/prompts/find-what-is-blocked.md) List blocked work, the dependency behind each block, and the most useful next step. Claude Code: ```text /planr:status SPEC-001. What is blocked, what is it waiting on, and what should happen next? ``` Codex: ```text $status SPEC-001. What is blocked, what is it waiting on, and what should happen next? ``` With the OpenPlanr plugin for Codex, use $planr:status. Cursor: ```text @planr-status SPEC-001. What is blocked, what is it waiting on, and what should happen next? ``` Cursor applies the planr-status rule when you mention it in chat. Why this works: Status reports counts, ready and blocked work, dependency problems, and the most useful next action, for the whole project or one feature. It reads local files by default and queries GitHub or Linear only when you ask for live remote state. ## [Get the technology and delivery-risk view](https://openplanr.dev/docs/prompts/technology-risk-review.md) One CTO lens on architecture, security, reliability, and delivery risk in an Operate cycle. Claude Code: ```text /cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration. ``` If /cto-review runs another command, use /planr:cto-review. Codex: ```text $cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration. ``` With the OpenPlanr plugin for Codex, use $planr:cto-review. Cursor: ```text @planr-cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration. ``` Cursor applies the planr-cto-review rule when you mention it in chat. Why this works: The CTO lens is read-only. Each risk it raises names likelihood, impact, exposure, and reversibility, and keeps observed failures apart from inferred future risk. It does not present architectural preference or generic technical debt as business risk. ## [Hand a task to another coding agent](https://openplanr.dev/docs/prompts/delegate-to-another-agent.md) Let a second agent build the task while your current agent reviews and verifies the result. Claude Code: ```text /delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them. ``` If /delegate runs another command, use /planr:delegate. Codex: ```text $delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them. ``` With the OpenPlanr plugin for Codex, use $planr:delegate. Cursor: ```text @planr-delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them. ``` Cursor applies the planr-delegate rule when you mention it in chat. Why this works: Delegate is for work you explicitly hand to another agent's CLI. That agent builds and tests in its own worktree; your current agent reviews the observed changes, runs its own checks, and applies accepted changes as an uncommitted diff. ## [Not sure which skill? Ask the router](https://openplanr.dev/docs/prompts/route-a-mixed-request.md) Describe what you want and let the router pick the skill, say why, and start it. Claude Code: ```text /openplanr I have a rough feature idea and a release on Friday. Where do I start? ``` If /openplanr runs another command, use /planr:openplanr. Codex: ```text $openplanr I have a rough feature idea and a release on Friday. Where do I start? ``` With the OpenPlanr plugin for Codex, use $planr:openplanr. Cursor: ```text @planr-openplanr I have a rough feature idea and a release on Friday. Where do I start? ``` Cursor applies the planr-openplanr rule when you mention it in chat. Why this works: The router names the skill that owns your request and why, in one line, then invokes it. When a request spans several steps, it starts with the earliest in the order spec, plan, plan review, ship, land, release, and names the rest. ## [Pick the next sprint against the real code](https://openplanr.dev/docs/prompts/pick-the-sprint.md) Refine the open backlog and select what fits capacity and the release cut. Claude Code: ```text /sprint two weeks, two engineers, release cut on the 23rd ``` If /sprint runs another command, use /planr:sprint. Codex: ```text $sprint two weeks, two engineers, release cut on the 23rd ``` With the OpenPlanr plugin for Codex, use $planr:sprint. Cursor: ```text @planr-sprint two weeks, two engineers, release cut on the 23rd ``` Cursor applies the planr-sprint rule when you mention it in chat. Why this works: Sprint reads every open item against the code and the calendar, tests its picks, and fits the survivors to your capacity and the next cut. Putting capacity in the prompt saves a question: the skill asks only for what the repository cannot answer. ## [Pin down acceptance criteria before planning](https://openplanr.dev/docs/prompts/clarify-acceptance-criteria.md) Turn loose requirements into observable criteria with stable IDs before anyone plans the work. Claude Code: ```text /spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it. ``` If /spec runs another command, use /planr:spec. Codex: ```text $spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it. ``` With the OpenPlanr plugin for Codex, use $planr:spec. Cursor: ```text @planr-spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it. ``` Cursor applies the planr-spec rule when you mention it in chat. Why this works: Spec writes requirements and acceptance criteria that can be observed, each criterion with a stable AC-NNN ID. Plan later maps every ID to a task and to a check in that task's test requirements. ## [Plan straight from a clear request](https://openplanr.dev/docs/prompts/plan-from-intent.md) When the request is already clear, skip the spec and get stories and tasks from it. Claude Code: ```text /planr:plan Create an implementation plan for a CSV export button on the monthly report page. ``` Codex: ```text $plan Create an implementation plan for a CSV export button on the monthly report page. ``` With the OpenPlanr plugin for Codex, use $planr:plan. Cursor: ```text @planr-plan Create an implementation plan for a CSV export button on the monthly report page. ``` Cursor applies the planr-plan rule when you mention it in chat. Why this works: Plan accepts a specification or a clear product request. Start with Spec when the scope is still vague; when it is already clear, Plan reads the repository and writes the stories and tasks directly. ## [Plan UI work from a finished design](https://openplanr.dev/docs/prompts/plan-ui-from-design.md) Turn a design and its design spec into UI tasks that carry the screens, states, and frames. Claude Code: ```text /planr:plan SPEC-001. Use the selected design direction and its design spec for the UI tasks. ``` Codex: ```text $plan SPEC-001. Use the selected design direction and its design spec for the UI tasks. ``` With the OpenPlanr plugin for Codex, use $planr:plan. Cursor: ```text @planr-plan SPEC-001. Use the selected design direction and its design spec for the UI tasks. ``` Cursor applies the planr-plan rule when you mention it in chat. Why this works: Plan reads the design document, the selected direction, and the 10-section design spec, and checks that they describe the same direction before it splits the UI work. Screen IDs, component recipes, responsive frames, and flows become task context. ## [Prepare the merge and deploy steps](https://openplanr.dev/docs/prompts/prepare-landing-sequence.md) Get the ordered landing commands, their preconditions, and the recovery step for the first failure. Claude Code: ```text /land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails. ``` If /land runs another command, use /planr:land. Codex: ```text $land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails. ``` With the OpenPlanr plugin for Codex, use $planr:land. Cursor: ```text @planr-land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails. ``` Cursor applies the planr-land rule when you mention it in chat. Why this works: Land returns readiness, blockers, the ordered landing sequence with its preconditions, recovery guidance for the first meaningful failure, and one next action. The commands are prepared for you to run, not run by the skill. ## [Refine the backlog without picking a sprint](https://openplanr.dev/docs/prompts/refine-the-backlog.md) Sort open items into stale, blocked, and ready against the current code, with no sprint yet. Claude Code: ```text /sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet. ``` If /sprint runs another command, use /planr:sprint. Codex: ```text $sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet. ``` With the OpenPlanr plugin for Codex, use $planr:sprint. Cursor: ```text @planr-sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet. ``` Cursor applies the planr-sprint rule when you mention it in chat. Why this works: Sprint reads each open item in full and checks the code it names before believing its claim. A refine-only run writes the refinement note without creating a sprint, and any run can be repeated and compared with the last one. ## [Review a plan before anyone builds it](https://openplanr.dev/docs/prompts/review-the-plan.md) Catch product, engineering, design, and developer-experience problems before implementation starts. Claude Code: ```text /plan-review SPEC-001 ``` If /plan-review runs another command, use /planr:plan-review. Codex: ```text $plan-review SPEC-001 ``` With the OpenPlanr plugin for Codex, use $planr:plan-review. Cursor: ```text @planr-plan-review SPEC-001 ``` Cursor applies the planr-plan-review rule when you mention it in chat. Why this works: Plan Review runs after Plan and before Ship. It returns one verdict (ready, ready with improvements, or needs revision) and, for each material issue, names the plan section and the change that would fix it. ## [Review an HTML prototype with pinned comments](https://openplanr.dev/docs/prompts/review-an-html-artifact.md) Open a local HTML file for review with comments, pins, threads, and an approve or request-changes decision. Claude Code: ```text /artifact Open ./prototype.html for review so I can pin comments on it. ``` If /artifact runs another command, use /planr:artifact. Codex: ```text $artifact Open ./prototype.html for review so I can pin comments on it. ``` With the OpenPlanr plugin for Codex, use $planr:artifact. Cursor: ```text @planr-artifact Open ./prototype.html for review so I can pin comments on it. ``` Cursor applies the planr-artifact rule when you mention it in chat. Why this works: The artifact is bundled into immutable bytes and runs in a sandboxed, network-blocked frame, so its scripts stay interactive without running as part of the review page. You can export the feedback as Markdown. ## [Run a monthly operating review](https://openplanr.dev/docs/prompts/operate-review.md) 7 executive lenses, one decision and action brief. Claude Code: ```text /operate activation, runway, and delivery risk this month ``` If /operate runs another command, use /planr:operate. Codex: ```text $operate activation, runway, and delivery risk this month ``` With the OpenPlanr plugin for Codex, use $planr:operate. Cursor: ```text @planr-operate activation, runway, and delivery risk this month ``` Cursor applies the planr-operate rule when you mention it in chat. Why this works: Operate builds one shared brief, runs the strategy, technology, product, growth, and operations reviews, has a challenger test the material claims, and ends with a board report: a prioritized decision queue and an action plan. ## [See the plan on a local board](https://openplanr.dev/docs/prompts/open-the-dashboard.md) Start the local planning dashboard for this repository and open it in your browser. Claude Code: ```text /dashboard Start the dashboard for this repository and open it in my browser. ``` If /dashboard runs another command, use /planr:dashboard. Codex: ```text $dashboard Start the dashboard for this repository and open it in my browser. ``` With the OpenPlanr plugin for Codex, use $planr:dashboard. Cursor: ```text @planr-dashboard Start the dashboard for this repository and open it in my browser. ``` Cursor applies the planr-dashboard rule when you mention it in chat. Why this works: The dashboard binds only to your machine's loopback address and reuses a compatible server that is already running. It opens a browser only when you ask, which is why the prompt says so. ## [Ship a small fix without a plan](https://openplanr.dev/docs/prompts/ship-a-direct-fix.md) For a clear, local change, ask Ship directly; missing planning files do not block it. Claude Code: ```text /ship Fix the invoice date so it uses the account's locale ``` If /ship runs another command, use /planr:ship. Codex: ```text $ship Fix the invoice date so it uses the account's locale ``` With the OpenPlanr plugin for Codex, use $planr:ship. Cursor: ```text @planr-ship Fix the invoice date so it uses the account's locale ``` Cursor applies the planr-ship rule when you mention it in chat. Why this works: Ship works from a task or from a clearly stated request. For a direct request, the request plus the repository is enough context, and it still finds and runs the repository's checks before it reports. ## [Ship a task without touching protected files](https://openplanr.dev/docs/prompts/ship-within-preserve.md) Build the task while every file on its Preserve list stays unchanged. Claude Code: ```text /ship T-002. Leave every file on its Preserve list unchanged. ``` If /ship runs another command, use /planr:ship. Codex: ```text $ship T-002. Leave every file on its Preserve list unchanged. ``` With the OpenPlanr plugin for Codex, use $planr:ship. Cursor: ```text @planr-ship T-002. Leave every file on its Preserve list unchanged. ``` Cursor applies the planr-ship rule when you mention it in chat. Why this works: Every task lists files to create, files to modify, and files to preserve. Ship treats Create and Modify as the expected surface, adds companion files when correctness needs them, and leaves Preserve entries unchanged. ## [Stress-test an operating review](https://openplanr.dev/docs/prompts/challenge-the-operating-review.md) Have the challenger test the review's claims, alternatives, downside, and confidence. Claude Code: ```text /challenger-review Challenge the claims, alternatives, and downside in this month's operating review. ``` If /challenger-review runs another command, use /planr:challenger-review. Codex: ```text $challenger-review Challenge the claims, alternatives, and downside in this month's operating review. ``` With the OpenPlanr plugin for Codex, use $planr:challenger-review. Cursor: ```text @planr-challenger-review Challenge the claims, alternatives, and downside in this month's operating review. ``` Cursor applies the planr-challenger-review rule when you mention it in chat. Why this works: The challenger tests only claims that could change a decision: unsupported claims, a weak assumption repeated by several advisors, a missing alternative, or downside nobody named. It does not invent objections to look busy. ## [Test the change in a real browser](https://openplanr.dev/docs/prompts/browser-qa-flow.md) Check routes, forms, phone sizes, accessibility, console, and network behavior. Claude Code: ```text /browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link error ``` If /browser-qa runs another command, use /planr:browser-qa. Codex: ```text $browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link error ``` With the OpenPlanr plugin for Codex, use $planr:browser-qa. Cursor: ```text @planr-browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link error ``` Cursor applies the planr-browser-qa rule when you mention it in chat. Why this works: Give the route, the sizes, and the failure case. Browser QA starts or reuses your local app, exercises the flow in a real browser, and reports what it covered. It reports findings instead of fixing them, so rerun it after the fix. ## [Track down a flaky test](https://openplanr.dev/docs/prompts/track-down-a-flaky-test.md) Find out why a test fails some of the time before anyone changes the test. Claude Code: ```text /investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test. ``` If /investigate runs another command, use /planr:investigate. Codex: ```text $investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test. ``` With the OpenPlanr plugin for Codex, use $planr:investigate. Cursor: ```text @planr-investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test. ``` Cursor applies the planr-investigate rule when you mention it in chat. Why this works: Investigate traces the call path, state, configuration, and recent changes, then runs the cheapest checks that tell competing causes apart. Asking for the cause first keeps the fix on the code instead of on the test. ## [Turn review findings into decisions](https://openplanr.dev/docs/prompts/turn-findings-into-decisions.md) Synthesize an operating review into a prioritized decision queue and an action plan. Claude Code: ```text /chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions. ``` If /chair-review runs another command, use /planr:chair-review. Codex: ```text $chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions. ``` With the OpenPlanr plugin for Codex, use $planr:chair-review. Cursor: ```text @planr-chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions. ``` Cursor applies the planr-chair-review rule when you mention it in chat. Why this works: The chair reads the advisor and challenger notes, ranks each decision P0, P1, P2, or unranked, and gives every action a first step, an expected result, a check, and a condition to revisit it. It suggests an owner only when the notes support one. ## [Write release notes users can read](https://openplanr.dev/docs/prompts/write-release-notes.md) Turn what shipped into user-facing notes and an updated changelog that does not read like a git log. Claude Code: ```text /release Write user-facing release notes for everything since the last tag and update the changelog. ``` If /release runs another command, use /planr:release. Codex: ```text $release Write user-facing release notes for everything since the last tag and update the changelog. ``` With the OpenPlanr plugin for Codex, use $planr:release. Cursor: ```text @planr-release Write user-facing release notes for everything since the last tag and update the changelog. ``` Cursor applies the planr-release rule when you mention it in chat. Why this works: Release classifies each change by one question: does a user have to do, know, or expect something different now? The notes lead with what users can do, describe fixes by the symptom users saw, and leave internal work out.