planr-investigate
Diagnose a bug, regression, error, or unexplained behavior and optionally implement a bounded fix. Use for root-cause investigation, including before any fix, not planned feature delivery.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 6
- Forks
- 1
01 前言 Front Matter
- name
- planr-investigate
- description
- Diagnose a bug, regression, error, or unexplained behavior and optionally implement a bounded fix. Use for root-cause investigation, including before any fix, not planned feature delivery.
02 资源文件 5
- 参考文档agents/openai.yaml417 B
- 参考文档openplanr.skill.json1.1 KB
- 参考文档references/backlog-filing.md4.0 KB
- 参考文档references/fail-first.md1.7 KB
- 参考文档references/findings.md3.9 KB
03 SKILL.md 正文
OpenPlanr Investigate
Find the cause before proposing a fix. Use the request, repository, runtime output, and focused experiments as context. Keep the investigation lightweight and make every diagnostic useful to the requested outcome.
Investigate
- Restate the observed failure and the smallest reproducible case.
- Trace the relevant call path, state, configuration, and recent changes.
- Form competing hypotheses and run the cheapest discriminating checks first.
- Identify the root cause only when the observations distinguish it from plausible alternatives.
- Report exact errors and unavailable tools without prescribing a workflow ceremony.
Fix when requested
When the user asked for a fix, implement the smallest coherent correction within the requested repository and run focused regression checks. Preserve unrelated work. Ask only when a missing product decision or an irreversible external action genuinely blocks progress. Prove the regression test with fail-first.
Findings outside the cause
Report other defects you notice as findings, and never fix them in this change unless they block the requested fix. The established cause is never a finding. Backlog filing lists and files backlog items with your own file tools.
Return
Lead with the established cause or clearly labeled remaining hypothesis. Link changed files and relevant evidence, and distinguish executed checks from source inspection. For a blocked experiment, state what remains known and the exact next diagnostic or recovery action. Preserve the detailed investigation in its existing report rather than returning raw tool transcripts.
- Cause: established root cause, or the strongest remaining hypotheses.
- Change: files and behavior changed, or none for diagnosis-only work.
- Checks: commands and results.
- Issues: unresolved uncertainty or blocker, or none; then findings outside the cause, each with its disposition.
Omit empty sections in the human summary. Different wording does not justify another experiment or corrective run.
04 同仓库更多 Skills
design
暂无简介
planr-sync
Audit OpenPlanr planning artifacts for graph and protocol drift. Use when statuses, references, schemas, or generated planning views may be inconsistent.
planr-status
Inspect project delivery or one feature's pipeline status without changing state. Use when the user asks what is done, pending, blocked, or next.
planr-sprint
Refine every open backlog item against the code and the calendar, refute the picks, and select a sprint that fits capacity and the release cut. Use before a cut or sprint; not for decomposing one specification or reporting status.
planr-spec
Shape vague product or engineering intent into a clear, measurable Protocol-compatible specification grounded in the current repository. Use when requirements need clarification before planning or implementation.
planr-ship
Implement an OpenPlanr plan, specification, task, or clearly stated request end to end in the current repository. Use when the user asks to build, implement, fix, finish, or ship local work, or to plan and implement an accepted change. Invoke before editing files for the requested change. Not for planning only, landing, release, or work handed to another coding agent.