一键导入
decision-mapping
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).
Analyze pi session token usage and produce a breakdown report. Sums the usage blocks recorded in pi session logs. Use when the user wants a token report, usage breakdown, "how much have I used", cached-vs-fresh token split, per-model or per-project cost/tokens, or asks to analyze pi usage.
Use when using the agent tool or delegating to subagents. Use it for tasks that benefit from isolated context: codebase exploration, planning, focused implementation, or code review.
Ask which skill or flow fits your situation. A router over the user-invoked skills in this repo.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
| name | decision-mapping |
| description | Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time. |
| disable-model-invocation | true |
This skill is invoked when a loose idea requires more than one agent session to turn into a plan. It creates a stateful decision map in a markdown file, and drives the user through a sequence of tickets to resolve the open questions - which may require either prototyping, research or discussion.
The decision map is a single compact Markdown file, one per planning effort, git-tracked alongside the project. It is the canonical artifact — the whole map is loaded as context into every session, so it must stay compact.
Assets created during tickets should be linked to from the map, not duplicated within it.
Numbered entries ("tickets"), each its own section keyed by its number:
## #1: Relational Or Non-Relational Database?
Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Grilling
### Question
<question-here>
### Answer
<answer-here>
Each ticket must be sized to one 100K token agent session.
There are three types of tickets:
/skill:prototype skill. Creates a prototype as an asset. Use this when "how should it look" or "how should it behave" is the key question./skill:grill-with-docs and /skill:domain-modeling skills. Asks one question at a time. The default case.The map is deliberately incomplete beyond the frontier. Your job is to investigate the frontier, and to resolve tickets in order to push the frontier forward. Push back the fog of war, one node at a time.
At some point, the fog of war should have been pushed back far enough that the path to the finish line is clear. At that point, no more tickets will be required and the decision map can be considered 'done'.
There are two ways this skill can be invoked: bootstrap and resume.
User invokes with a loose idea.
/skill:grill-with-docs + /skill:domain-modeling session to surface the open decisions. Ask one question at a time.User invokes with a path to an existing map and a ticket number.
/skill:grill-with-docs and /skill:domain-modeling.blocked_by edges).If the decisions made invalidate other parts of the map, update or delete those nodes.
The user may choose to run tickets in parallel, so expect other agents to make changes to the map.
Many times, the initial grilling will result in no fog of war. No unresolved tickets. Nothing to do, except implement.
In those situations, you should offer the user the chance to skip the decision map - since the decision map is only needed if multi-session decisions need to be made.
If they skip it, you should recommend either implementing directly or using /skill:to-prd to schedule a multi-session implementation.