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.
5 prompts
Start here: five prompts to try firstAll prompts
- Start here · 1
Turn a rough idea into a spec
Start every feature with a specification your agent can check its work against.
/spec add passwordless sign-in for existing accounts. Users drop off at the password step.$spec add passwordless sign-in for existing accounts. Users drop off at the password step.@planr-spec add passwordless sign-in for existing accounts. Users drop off at the password step.If
/specruns another command, use/planr:spec.With the OpenPlanr plugin for Codex, use
$planr:spec.Cursor applies the
planr-specrule 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.
- Start here · 2
Break a spec into stories and tasks
Get user stories and tasks with acceptance criteria and file-level changes.
/planr:plan SPEC-001$plan SPEC-001@planr-plan SPEC-001With the OpenPlanr plugin for Codex, use
$planr:plan.Cursor applies the
planr-planrule 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.
- Start here · 3
Ship one task, then stop
Build one task end to end and keep the change small enough to review.
/ship T-001$ship T-001@planr-ship T-001If
/shipruns another command, use/planr:ship.With the OpenPlanr plugin for Codex, use
$planr:ship.Cursor applies the
planr-shiprule 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.
- Start here · 4
Ask what is done, blocked, and next
Read delivery status from the plan in your repo without changing anything.
/planr:status$status@planr-statusWith the OpenPlanr plugin for Codex, use
$planr:status.Cursor applies the
planr-statusrule 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.
- Start here · 5
Design the screens before anyone builds them
One design direction in a studio you can click through, plus a design spec Plan can read.
/planr:design the onboarding checklist for new accounts on desktop and phone, with empty and error states$design the onboarding checklist for new accounts on desktop and phone, with empty and error states@planr-design the onboarding checklist for new accounts on desktop and phone, with empty and error statesWith the OpenPlanr plugin for Codex, use
$planr:design.Cursor applies the
planr-designrule 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
Revise only the screens your review pins point at, and keep everything else as it was.
/design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged.$design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged.@planr-design-review Apply the pinned feedback on the settings screens and leave the other screens unchanged.If
/design-reviewruns another command, use/planr:design-review.With the OpenPlanr plugin for Codex, use
$planr:design-review.Cursor applies the
planr-design-reviewrule 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
Check that stories, tasks, statuses, and references in the planning folder still agree.
/sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything.$sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything.@planr-sync Check whether the stories, tasks, and statuses under .planr/ still agree. Report what is out of step before changing anything.If
/syncruns another command, use/planr:sync.With the OpenPlanr plugin for Codex, use
$planr:sync.Cursor applies the
planr-syncrule 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
Assess release readiness without merging, publishing, or deploying anything.
/land the sign-in work on this branch$land the sign-in work on this branch@planr-land the sign-in work on this branchIf
/landruns another command, use/planr:land.With the OpenPlanr plugin for Codex, use
$planr:land.Cursor applies the
planr-landrule 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
Keyboard access, focus, accessible names, console errors, and failed requests on one page.
/browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests.$browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests.@planr-browser-qa Check the pricing page for keyboard access, visible focus, accessible names, console errors, and failed network requests.If
/browser-qaruns another command, use/planr:browser-qa.With the OpenPlanr plugin for Codex, use
$planr:browser-qa.Cursor applies the
planr-browser-qarule 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
Ask the plan review to focus on setup, defaults, error messages, and recovery.
/plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery.$plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery.@planr-plan-review SPEC-001. Focus on the first-run developer experience: setup, defaults, error messages, and recovery.If
/plan-reviewruns another command, use/planr:plan-review.With the OpenPlanr plugin for Codex, use
$planr:plan-review.Cursor applies the
planr-plan-reviewrule 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
Have the plan reviewed for migration, security, operability, and rollback risk.
/plan-review SPEC-001. Check the migration, security, and rollback plan before we build.$plan-review SPEC-001. Check the migration, security, and rollback plan before we build.@planr-plan-review SPEC-001. Check the migration, security, and rollback plan before we build.If
/plan-reviewruns another command, use/planr:plan-review.With the OpenPlanr plugin for Codex, use
$planr:plan-review.Cursor applies the
planr-plan-reviewrule 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
Decide major, minor, or patch from what changed for users, not from the size of the diff.
/release Choose the next version for this CLI and explain whether it is a major, minor, or patch release.$release Choose the next version for this CLI and explain whether it is a major, minor, or patch release.@planr-release Choose the next version for this CLI and explain whether it is a major, minor, or patch release.If
/releaseruns another command, use/planr:release.With the OpenPlanr plugin for Codex, use
$planr:release.Cursor applies the
planr-releaserule 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
See 3 materially different directions side by side, rate them, and develop the one you pick.
/design-loop Compare 3 directions for the dashboard home on desktop and phone.$design-loop Compare 3 directions for the dashboard home on desktop and phone.@planr-design-loop Compare 3 directions for the dashboard home on desktop and phone.If
/design-loopruns another command, use/planr:design-loop.With the OpenPlanr plugin for Codex, use
$planr:design-loop.Cursor applies the
planr-design-looprule 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
Get the root cause and the evidence for it, with no edits until you decide on a fix.
/investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet.$investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet.@planr-investigate Why does checkout fail for carts with a discount code? Find the cause, but don't change any code yet.If
/investigateruns another command, use/planr:investigate.With the OpenPlanr plugin for Codex, use
$planr:investigate.Cursor applies the
planr-investigaterule 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
Get SVG, PNG, and an accessible HTML version from one canonical document.
/diagram the request flow from the web app to the API and the queue as an architecture diagram$diagram the request flow from the web app to the API and the queue as an architecture diagram@planr-diagram the request flow from the web app to the API and the queue as an architecture diagramIf
/diagramruns another command, use/planr:diagram.With the OpenPlanr plugin for Codex, use
$planr:diagram.Cursor applies the
planr-diagramrule 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
Diagnose the OpenPlanr installation and preview any repair before it touches a file.
/planr:doctor The spec skill does not show up after setup. Find the cause and preview any repair before applying it.$doctor The spec skill does not show up after setup. Find the cause and preview any repair before applying it.@planr-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 applies the
planr-doctorrule 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
Reproduce the defect, establish why it happens, then apply a bounded fix.
/investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test.$investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test.@planr-investigate sign-in links expire after 30 seconds instead of 15 minutes. Reproduce it first, then fix it with a test.If
/investigateruns another command, use/planr:investigate.With the OpenPlanr plugin for Codex, use
$planr:investigate.Cursor applies the
planr-investigaterule 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
List blocked work, the dependency behind each block, and the most useful next step.
/planr:status SPEC-001. What is blocked, what is it waiting on, and what should happen next?$status SPEC-001. What is blocked, what is it waiting on, and what should happen next?@planr-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 applies the
planr-statusrule 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
One CTO lens on architecture, security, reliability, and delivery risk in an Operate cycle.
/cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration.$cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration.@planr-cto-review Review technology and delivery risk in the current operating review, focusing on the payments migration.If
/cto-reviewruns another command, use/planr:cto-review.With the OpenPlanr plugin for Codex, use
$planr:cto-review.Cursor applies the
planr-cto-reviewrule 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
Let a second agent build the task while your current agent reviews and verifies the result.
/delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them.$delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them.@planr-delegate Ask another coding agent to implement T-003, then review and verify its changes before you integrate them.If
/delegateruns another command, use/planr:delegate.With the OpenPlanr plugin for Codex, use
$planr:delegate.Cursor applies the
planr-delegaterule 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
Describe what you want and let the router pick the skill, say why, and start it.
/openplanr I have a rough feature idea and a release on Friday. Where do I start?$openplanr I have a rough feature idea and a release on Friday. Where do I start?@planr-openplanr I have a rough feature idea and a release on Friday. Where do I start?If
/openplanrruns another command, use/planr:openplanr.With the OpenPlanr plugin for Codex, use
$planr:openplanr.Cursor applies the
planr-openplanrrule 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
Refine the open backlog and select what fits capacity and the release cut.
/sprint two weeks, two engineers, release cut on the 23rd$sprint two weeks, two engineers, release cut on the 23rd@planr-sprint two weeks, two engineers, release cut on the 23rdIf
/sprintruns another command, use/planr:sprint.With the OpenPlanr plugin for Codex, use
$planr:sprint.Cursor applies the
planr-sprintrule 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
Turn loose requirements into observable criteria with stable IDs before anyone plans the work.
/spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it.$spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it.@planr-spec Clarify the requirements and acceptance criteria for team invitations by email before we plan it.If
/specruns another command, use/planr:spec.With the OpenPlanr plugin for Codex, use
$planr:spec.Cursor applies the
planr-specrule 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
When the request is already clear, skip the spec and get stories and tasks from it.
/planr:plan Create an implementation plan for a CSV export button on the monthly report page.$plan Create an implementation plan for a CSV export button on the monthly report page.@planr-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 applies the
planr-planrule 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
Turn a design and its design spec into UI tasks that carry the screens, states, and frames.
/planr:plan SPEC-001. Use the selected design direction and its design spec for the UI tasks.$plan SPEC-001. Use the selected design direction and its design spec for the UI tasks.@planr-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 applies the
planr-planrule 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
Get the ordered landing commands, their preconditions, and the recovery step for the first failure.
/land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails.$land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails.@planr-land Prepare the landing sequence for the billing changes on this branch, with the recovery step if the deploy fails.If
/landruns another command, use/planr:land.With the OpenPlanr plugin for Codex, use
$planr:land.Cursor applies the
planr-landrule 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
Sort open items into stale, blocked, and ready against the current code, with no sprint yet.
/sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet.$sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet.@planr-sprint Refine the open backlog only: mark what is stale, blocked, or ready, and don't create a sprint yet.If
/sprintruns another command, use/planr:sprint.With the OpenPlanr plugin for Codex, use
$planr:sprint.Cursor applies the
planr-sprintrule 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
Catch product, engineering, design, and developer-experience problems before implementation starts.
/plan-review SPEC-001$plan-review SPEC-001@planr-plan-review SPEC-001If
/plan-reviewruns another command, use/planr:plan-review.With the OpenPlanr plugin for Codex, use
$planr:plan-review.Cursor applies the
planr-plan-reviewrule 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
Open a local HTML file for review with comments, pins, threads, and an approve or request-changes decision.
/artifact Open ./prototype.html for review so I can pin comments on it.$artifact Open ./prototype.html for review so I can pin comments on it.@planr-artifact Open ./prototype.html for review so I can pin comments on it.If
/artifactruns another command, use/planr:artifact.With the OpenPlanr plugin for Codex, use
$planr:artifact.Cursor applies the
planr-artifactrule 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
7 executive lenses, one decision and action brief.
/operate activation, runway, and delivery risk this month$operate activation, runway, and delivery risk this month@planr-operate activation, runway, and delivery risk this monthIf
/operateruns another command, use/planr:operate.With the OpenPlanr plugin for Codex, use
$planr:operate.Cursor applies the
planr-operaterule 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
Start the local planning dashboard for this repository and open it in your browser.
/dashboard Start the dashboard for this repository and open it in my browser.$dashboard Start the dashboard for this repository and open it in my browser.@planr-dashboard Start the dashboard for this repository and open it in my browser.If
/dashboardruns another command, use/planr:dashboard.With the OpenPlanr plugin for Codex, use
$planr:dashboard.Cursor applies the
planr-dashboardrule 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
For a clear, local change, ask Ship directly; missing planning files do not block it.
/ship Fix the invoice date so it uses the account's locale$ship Fix the invoice date so it uses the account's locale@planr-ship Fix the invoice date so it uses the account's localeIf
/shipruns another command, use/planr:ship.With the OpenPlanr plugin for Codex, use
$planr:ship.Cursor applies the
planr-shiprule 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
Build the task while every file on its Preserve list stays unchanged.
/ship T-002. Leave every file on its Preserve list unchanged.$ship T-002. Leave every file on its Preserve list unchanged.@planr-ship T-002. Leave every file on its Preserve list unchanged.If
/shipruns another command, use/planr:ship.With the OpenPlanr plugin for Codex, use
$planr:ship.Cursor applies the
planr-shiprule 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
Have the challenger test the review's claims, alternatives, downside, and confidence.
/challenger-review Challenge the claims, alternatives, and downside in this month's operating review.$challenger-review Challenge the claims, alternatives, and downside in this month's operating review.@planr-challenger-review Challenge the claims, alternatives, and downside in this month's operating review.If
/challenger-reviewruns another command, use/planr:challenger-review.With the OpenPlanr plugin for Codex, use
$planr:challenger-review.Cursor applies the
planr-challenger-reviewrule 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
Check routes, forms, phone sizes, accessibility, console, and network behavior.
/browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link error$browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link error@planr-browser-qa the sign-in flow on /login at phone and desktop sizes, including the expired-link errorIf
/browser-qaruns another command, use/planr:browser-qa.With the OpenPlanr plugin for Codex, use
$planr:browser-qa.Cursor applies the
planr-browser-qarule 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
Find out why a test fails some of the time before anyone changes the test.
/investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test.$investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test.@planr-investigate The checkout total test fails about one run in ten in CI. Find the cause before changing the test.If
/investigateruns another command, use/planr:investigate.With the OpenPlanr plugin for Codex, use
$planr:investigate.Cursor applies the
planr-investigaterule 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
Synthesize an operating review into a prioritized decision queue and an action plan.
/chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions.$chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions.@planr-chair-review Turn the findings in this month's operating review into a prioritized decision queue and actions.If
/chair-reviewruns another command, use/planr:chair-review.With the OpenPlanr plugin for Codex, use
$planr:chair-review.Cursor applies the
planr-chair-reviewrule 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
Turn what shipped into user-facing notes and an updated changelog that does not read like a git log.
/release Write user-facing release notes for everything since the last tag and update the changelog.$release Write user-facing release notes for everything since the last tag and update the changelog.@planr-release Write user-facing release notes for everything since the last tag and update the changelog.If
/releaseruns another command, use/planr:release.With the OpenPlanr plugin for Codex, use
$planr:release.Cursor applies the
planr-releaserule 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.
No prompts match these filters
Clear a filter, or search with other words.
What makes these prompts work
- Name the outcome, not the steps. Say what should be true when the work is done; the skill finds the files.
- Give it a way to check. Ask for the test, the browser check, or the measurable target in the same prompt.
- Keep plan and build separate. Write the spec, plan it, then ship one task. Each step leaves a file you can review.