archived/skills/decision-extract/SKILL.md
Extract pending decisions from task queue, prioritize by blocking count, output to daily note for batch processing.
npx skillsauth add nicsuzor/academicops decision-extractInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Taxonomy note: This skill provides domain expertise (HOW) for extracting pending decisions from the task queue. See [[TAXONOMY.md]] for the skill/workflow distinction.
Extract pending decisions from your task queue and format them for batch processing in your daily note.
A decision is a task that:
Examples:
Not decisions: Write code, research topic, draft document, fix bug
Note on external dependencies: Tasks waiting for others (e.g., "waiting for Ella's examples") are included because you can still make decisions about them:
/decision-extract when you want to batch-process pending decisions/daily skill includes a decision count summary automaticallyQuery tasks that are waiting for your input:
# Get waiting tasks assigned to user
waiting_tasks = mcp__pkb__list_tasks(
status="waiting",
assignee="nic",
limit=50
)
# Get review tasks assigned to user
review_tasks = mcp__pkb__list_tasks(
status="review",
assignee="nic",
limit=50
)
Exclude high-level planning items that aren't actionable decisions:
EXCLUDED_TYPES = ["project", "epic", "goal"]
decisions = [
task for task in (waiting_tasks + review_tasks)
if task.type not in EXCLUDED_TYPES
]
For each decision, determine how many tasks it's blocking:
topology = mcp__pkb__get_task_network()
# Match decision IDs to topology entries to get blocking_count
for decision in decisions:
entry = find_in_topology(decision.id, topology)
decision.blocking_count = entry.blocking_count if entry else 0
Sort decisions by:
blocking_count (descending) - decisions blocking most work firstpriority (ascending) - P0 before P1 before P2created (ascending) - older decisions firstdecisions.sort(key=lambda d: (-d.blocking_count, d.priority, d.created))
high_priority = [d for d in decisions if d.blocking_count >= 2]
medium_priority = [d for d in decisions if d.blocking_count == 1]
low_priority = [d for d in decisions if d.blocking_count == 0]
Generate markdown for the daily note's ## Pending Decisions section:
## Pending Decisions
You have **{total}** decisions pending ({high} high priority).
### High Priority (Blocking Multiple Tasks)
#### D001: {task_title}
- **Task**: `{task_id}`
- **Blocks**: {blocking_count} tasks
- **Context**: {first 200 chars of task body}
- **Created**: {days_ago} days ago
**Decision**: [ ] Approve [ ] Reject [ ] Defer
**Notes**: _________________
---
### Medium Priority (Blocking 1 Task)
#### D002: {task_title}
...
### Low Priority (No Dependencies)
#### D003: {task_title}
...
---
**Instructions**: Mark your decisions above, then run `/decision-apply` to process them.
<!-- decision-metadata
decisions:
- id: D001
task_id: {task_id}
decision: null
processed: false
- id: D002
...
-->
Insert the ## Pending Decisions section immediately after ## Focus:
## Focus
[existing focus content]
## Pending Decisions
[generated decision content]
## Task Tree
[existing tree]
If ## Pending Decisions already exists in the daily note:
Use Edit tool to update, not Write (preserve surrounding content).
When /daily runs, include a summary in the Focus section:
## Focus
[priority dashboard]
**Pending Decisions**: {count} ({high_priority} blocking other work)
→ Run `/decision-extract` to review and process
[rest of focus content]
This summary uses the same query logic (Steps 1-3) but only outputs the count, not the full list.
| Scenario | Behavior | | ------------------------ | ---------------------------------------------------------- | | No decisions found | Output "No pending decisions. Your queue is clear." | | Daily note missing | Create minimal daily note with decisions section | | Task details unavailable | Include task ID and title only, note "details unavailable" |
## Pending Decisions
You have **4** decisions pending (2 high priority).
### High Priority (Blocking Multiple Tasks)
#### D001: Approve authentication provider choice
- **Task**: `aops-abc123`
- **Blocks**: 3 tasks (login-ui, session-mgmt, user-tests)
- **Context**: Options are Auth0 vs Cognito. See comparison doc for trade-offs.
- **Created**: 5 days ago
**Decision**: [ ] Auth0 [ ] Cognito [ ] Need more info
**Notes**: _________________
---
#### D002: Sign off on API schema v2
- **Task**: `aops-def456`
- **Blocks**: 2 tasks
- **Context**: Breaking changes from v1. Migration path documented.
- **Created**: 3 days ago
**Decision**: [ ] Approve [ ] Request changes [ ] Defer
**Notes**: _________________
---
### Low Priority (No Dependencies)
#### D003: Review PR #789 - typo fix
- **Task**: `aops-ghi789`
- **Blocks**: 0 tasks
- **Context**: Single character typo in README
- **Created**: 1 day ago
**Decision**: [ ] Approve [ ] Skip
**Notes**: _________________
---
**Instructions**: Mark your decisions above, then run `/decision-apply` to process them.
/decision-apply - Process annotated decisions and update tasks/daily - Includes decision count in morning briefing/pull - Pull next task to work on (after decisions are cleared)tools
Program / portfolio supervision — the autonomous top loop above /supervisor. "Ready the release" → discover and decompose the constituent epics → run /supervisor on each → surface only escalations + merge-ready PRs. Stateless tick driven by /loop; all cross-tick state lives in the program task body.
development
Mirror PKB tasks onto the Cowork native task list at claim time and sync completion back to PKB. Cowork-only; ships only in the cowork build of aops-core.
testing
Instruction quality gate — reviews agent instructions (task bodies, workflow steps, skill procedures, self-test protocols) for shallow-execution vulnerabilities before deployment. Two modes: author (pre-hoc review) and audit (trace a failure back to the instruction gap). The bar is excellence, not compliance.
content-media
Design-stage fitness rubric — persona immersion, scenario design, dimensions that define what excellence looks like for the people a feature serves. Two modes — author (produce a rubric for a new spec) and critique (red-team an existing spec). Output lives on the spec, not in the verification brief. Owned by pauli.