菜单
Create or refine Planr product plans and build plans before implementation. Use for app ideas, PRDs, architecture slices, scoped implementation contracts, and converting broad work into map-ready items.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Drive one feature or scope to verified completion without per-step human prompting. Use when the user says build until done, loop on this, or finish autonomously. Sequences plan, map, work, live verification, and independent review until the map is clean and evidence proves the feature actually runs.
Live verification for web features. Use when a web map item needs proof it actually runs in a browser before review, including planr-loop step 4. Discovers the host's existing browser capability, runs the changed flow against the dev server, and logs replayable evidence. Ships no browser tooling of its own.
Prepare a long-running goal for autonomous execution on Planr. Use when the user states a broad goal, wants to start a /goal run, or asks to set up a goal. Compiles intent into a checked plan, a linked map, and a durable goal contract, then prints the starter command for the host's loop driver without implementing anything.
Execute one Planr map item to evidence-backed completion. Use after a task has been picked or when the next step is implementation, docs, tests, scripts, integration work, or a fix item.
Review a Planr item or scoped implementation against map state, plan acceptance criteria, logs, changed files, and verification evidence. Use for findings-first audits and review gates.
Use Planr as the live local task graph for coding-agent coordination. Trigger when work needs project planning, build-plan splitting, map creation, dependency links, picking, log-backed closure, review gates, handoff context, interruption recovery, or multi-client coordination.
| name | planr-plan |
| description | Create or refine Planr product plans and build plans before implementation. Use for app ideas, PRDs, architecture slices, scoped implementation contracts, and converting broad work into map-ready items. |
Use this when scope, ownership, acceptance criteria, or verification must be defined before implementation.
planr project show --json
planr plan new "App idea" [--platform web] [--ai] [--backend]
planr plan refine <plan-id> --note "decision, constraint, or assumption"
planr plan check <plan-id>
planr plan split <plan-id> --slice "narrow implementation slice"
planr map build --from <build-plan-id>
A product plan package must include:
A build plan must include:
Before writing the task list, check whether the project declares model routing: planr agents list --json. If routes exist, their work_type selectors are the project's use-case vocabulary (e.g. frontend, backend, design) — and tagging is your job, not the user's; never ask a human to name work types.
Declare the use case in the task list itself — map build seeds annotated tasks with that work type directly:
### TASK-001 (backend): REST API for todos
- [ ] (frontend) Build the form and list view
Match by the task's actual work (UI/components/styling -> a frontend route, API/server/storage -> backend, and so on); unannotated tasks stay code, which the default route covers. For maps that were already built without annotations, retag instead: planr item update <item-id> --work-type frontend. The payoff: every pick packet then carries the right profile, model, and paired skill for its use case, so dispatch needs no human routing knowledge.
Planning is complete only when planr plan check <plan-id> passes and the next command is clear: split further, build map, or ask the user for a blocking decision.
When the map is built, linked, and tagged, end by naming the execution handoff explicitly — the user should never have to guess the next prompt: Use $planr-loop on plan <build-plan-id>. Stop condition: all items closed with evidence, reviews complete, live verification logged. (On hosts with a /goal primitive, $planr-goal wraps the same loop for long-running autonomous runs.)
plan check rejects empty scaffolds: build plans must have content in ## Scope Decision, ## Verification, and ## Acceptance Criteria; product plans must have content in ## Problem, ## Requirements, and ## Success Criteria of PRODUCT_SPEC.md. Write those sections before checking — do not pad them to satisfy the gate.