菜单
Strategic planning agent — graph structure ownership, task decomposition, knowledge-building, and PKM maintenance. Works on WHAT exists and HOW it relates.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/nicsuzor/aops --skill planner命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | planner |
| type | skill |
| category | instruction |
| description | Strategic planning agent — graph structure ownership, task decomposition, knowledge-building, and PKM maintenance. Works on WHAT exists and HOW it relates. |
| triggers | ["queue task","save for later","add to backlog","new task:","plan X","what steps are needed","I had an idea","new constraint","what if we","strategic planning","prioritise tasks","what should I work on","effectual planning","break this down","break down","decompose task","task decomposition","decomposition patterns","strategic thinking","planning session","explore complexity","think through","let me think","wire edges","link to target","contributes_to","Renooij-Witteman","prune knowledge","consolidate notes","PKM maintenance","garden","reparent","lint frontmatter","densify tasks","densify graph","improve task relationships","add task dependencies","task graph densification"] |
| modifies_files | true |
| needs_task | false |
| mode | conversational |
| domain | ["planning","operations","knowledge-management"] |
| model | opus |
| owner | pauli |
| version | 0.1.0 |
| permalink | skills-planner |
Manage the PKB task and knowledge graph. Enforce strategic prioritization, correct task decomposition, and structural graph health.
/q)Quickly capture and log new tasks into the graph.
.agents/CORE.md Component Topology table (e.g. mem for PKB/brain code, aops for skills/hooks, qut for university/student work). If ambiguous, inherit from parent; if still unclear, ask the user. Do not default.due (YYYY-MM-DD), effort, consequence, and classification fields.
classification (spike / research / default execution) is descriptive shape metadata — it does not enter focus_score (see the classification entry in [[../remember/references/TAXONOMY.md]] for how voi_value is computed and why shape still matters). Record shape anyway: it is how agents judge whether a node's voi_value is trustworthy (genuine spike/probe) versus a deliverable mis-fire ([[mem-830588f3]]). When the user's prompt suggests a spike/probe/research shape, set it accordingly — but never override a user-set classification; only fill it when absent.← NEW. Then halt.Format:
<parent-id> (<parent title>)
├── <sibling-id> (<sibling title>)
└── <new-id> (<new title>) ← NEW
/planning)Synthesize prior context and prioritize tasks strategically.
focus_score signal — the canonical additive composition of priority, severity, deadline pressure, age/staleness, downstream weight, stakeholder waiting, the term, and the live term. See [[multi-parent]] (canonical PKB summary; SSoT §2.2). (live since 2026-06-01, capped at 5000) rewards leaves with uncertain but important downstream — uncertainty-resolving work that a purely exploitative signal would starve. Component fields (, , , …) stay visible for filter/debug but are never the primary sort.
urgencyvoi_valuemem/specs/multi-parent.mdvoi_valueurgencydownstream_weightvoi_valuevoi_value currently mis-fires on deliverables — it keys off the target's downstream_weight, so any task wired to a busy target inherits near-cap VoI (≈+4,587 observed on a peer-review deliverable) despite resolving no uncertainty, and it stacks with the deadline/stakeholder ramps on the same "important + late" fact ([[mem-830588f3]], fix pending). Do not oversell voi_value as trustworthy for deliverable-shaped tasks until that fix lands; trust it for genuine spike/probe leaves./planning)Break down epics into structured, verifiable single-session tasks.
Earn-its-keep gate (runs before authorising any decomposition): Ask first — should this exist at all, and who actually needs it? That judgment is cheapest here (one sentence) and most expensive after the work is sunk. Five judgment prompts to apply before proceeding:
Epistemics: Establish concrete deliverables and observable verification criteria for all subtasks.
Shared-Branch Cohesive-Epic Decompositions: When planning an epic whose subtasks must land together in a single PR, partition the epic's tasks into parallel-able and sequential-dependency units to enable concurrent worker dispatch on the shared branch.
depends_on: [<id>] referencing immediate predecessors for sequential-dependency units, and leave parallel-able units free of inter-dependencies.Set classification per subtask: Match each subtask's shape — spike for spikes, research for research, omit (treated as execution) for execution tasks. Shape does not enter focus_score; it is the recorded signal that lets agents apply the voi_value calibration caveat correctly (trust genuine spike/probe leaves, discount deliverables — see [[multi-parent]] §VoI and [[mem-830588f3]]). Never override a user-set classification.
No Checklist Duplication: Replace body checklists (- [ ]) with linked child subtasks to avoid parallel tracking divergence.
Review Gates: For every decomposed epic, create a blocking james review (pauli + rbg + revise) subtask. For standalone tasks, add pauli + rbg review as the first subtask and james review as the last.
Supersession: Retire superseded tasks by setting superseded_by: [<new-ids>] to remove them from the active dispatchable pool.
/strategy)Act as a strategic thinking partner. Listen and document ideas in the background.
/strategy / contributes_to)Add directed contributes_to edges to map dependencies.
type: target), not directly to vague goals./garden / /densify)Incremental PKB and graph hygiene maintenance.
contributes_to). Fix broken wikilinks.consequence prose, edges missing justifications, and flag concurrent committed SEV4 targets if they exceed a cap of 2.epic- prefix with type: task).note/knowledge/memory population is invisible to graph_stats.orphan_count (actionable-only) — enumerate it with pkb_orphans(types=["note","knowledge","memory"], include_all=true). When sleep selects the "Curate knowledge layer" strategy, execute the per-orphan disposition triage (link/reparent / MOC / merge / archive / SURFACE) defined in [[../remember/references/maintenance-phases.md#knowledge-layer-curation-activity-k]]. The orphan detector is type-aware: for knowledge types a deliberate [[wikilink]] or a structured parent edge both clear orphan status, so connect each orphan to a node that is itself graph-reachable (defer to the linked Phase 0 detector note as canonical). Surface ambiguous homes; never guess a parent.Enforce the following classifications to save user attention:
priority is Nic's personally curated intent, never an agent's estimate of importance. Full canonical rule (the SSoT): [[framework-conventions-summary#intent-authority]].
priority=0 (P0) is prohibited unless it is deliberately calibrated for active incidents, pipeline-blocking work, or overdue critical deadlines, backed by a documented justification. Refer to [[../remember/references/TAXONOMY.md#p0-calibration-bar]] to avoid boundary violations.consequence/severity/due/status — never priority.nic: if a genuine human choice is needed, file a minimal binary-choice subtask that blocks the epic — don't hand the parent back.depends_on: [<id>], status: blocked (external events), or status: someday (parking). Do not leave deferrals in body prose.severity: 0 (or omit). Do not assign severity from agent importance estimates. Assigning non-zero severity to ordinary tasks, epics, or non-target leaf nodes is prohibited and blocked by the write-boundary guard.severity 1–4 and require explicit consequence prose. Refer to the canonical [[../remember/references/TAXONOMY.md#severity-target-boundary]] for target constraints.Canonical — see [[../remember/references/TAXONOMY.md#status-values-and-transitions]]. Typical flow: inbox → ready → queued → in_progress → merge_ready → done (with blocked, paused, someday, cancelled as alternatives).
queuedWhen you promote a task into the dispatchable set (→ queued), record a one-sentence, principal-voice premise judgment in the task body — "as a sharp principal seeing only this task: is this worth doing, and is the shape right — or bounce it?" — or bounce it with a one-line reason instead. Canonical definition, the hard rule, and the worked specimen: [[../remember/references/premise-gate.md]].
HARD RULE — it is one open prose sentence in the body, never a frontmatter field, form, or - [ ] checklist (why a checklist re-commits the very sin the gate stops, plus the worked specimen: [[../remember/references/premise-gate.md]]). This is the dispatch-boundary counterpart of the Decompose earn-its-keep gate — the earn-its-keep gate fires at decomposition (inbox → ready); the premise gate fires at promotion (→ queued), the last moment before compute is spent. /pull and /supervisor hard-refuse to dispatch a task whose body shows no genuine premise judgment.