back
loading skill details...
Capture decisions that are intentionally deferred, assign a review date and owner, and prevent them from silently disappearing.
---
name: deferred-decision-tracker
description: Capture decisions that are intentionally deferred, assign a review date and owner, and prevent them from silently disappearing.
metadata:
openclaw:
tags:
- productivity
- operations
- planning
- decision-support
---
# Deferred Decision Tracker
Use this skill when a decision is important enough to revisit, but not ready to decide now.
The goal is simple: **deferred should not mean forgotten.**
## When to Use
Use this skill when the user says things like:
- “Let’s come back to this later.”
- “Not now, but don’t let this disappear.”
- “Park this until after launch.”
- “We need a decision on this next week.”
- “This is a good idea, but we need more data first.”
## Capture Rule
Every deferred decision should be recorded with:
1. **Decision title** — short, concrete name.
2. **Why deferred** — what is missing or what must happen first.
3. **Owner** — who is responsible for reviving it.
4. **Review date/time** — when it should return.
5. **Trigger condition** — what event makes it relevant again.
6. **Output path or artifact** — where the future decision board should live.
7. **Status** — open, waiting, ready, decided, retired.
8. **Retirement condition** — when to stop surfacing it.
## Behavior
When a decision is deferred:
- Create or update a deferred-decision register.
- Make the next review date explicit.
- If a durable reminder or scheduler exists, use it when exact timing matters, preferring local or private mechanisms by default.
- Before creating external calendar events, sending notifications to other people, emailing, posting, purchasing, changing billing, or modifying access/security settings, get explicit user approval.
- If no scheduler exists, write the item somewhere the normal review process will check.
- Do not surface stale items repeatedly unless something has changed or a real review point has arrived.
## Privacy and Storage
Deferred-decision registers can contain sensitive personal, financial, business, security, or strategic information. Store them in a private or user-approved project location by default. Do not place sensitive decisions in public documents, shared folders, examples, or published artifacts unless the user explicitly asks.
## Recommended Register Format
```markdown
# Deferred Decisions
| Decision | Owner | Deferred Because | Review Date | Trigger | Status | Artifact |
|---|---|---|---|---|---|---|
| Example vendor evaluation | Ops lead | Waiting for pricing | 2026-06-01 | Pricing received | waiting | docs/vendor-eval.md |
```
## Review Behavior
At review time:
1. Check whether the trigger condition happened.
2. Check whether the missing input is now available.
3. If ready, create a decision board with options, criteria, recommendation, risks, and explicit go/no-go ask.
4. If still not ready, update the reason and next review date.
5. If no longer relevant, mark retired and stop surfacing it.
## Decision Board Template
```markdown
# Decision Board: <Decision Title>
## Context
Why this decision matters now.
## Options
1. Option A
2. Option B
3. Option C
## Criteria
- Cost
- Speed
- Risk
- Reversibility
- Strategic fit
## Recommendation
Recommended option and why it beats alternatives.
## Risks / Caveats
What could be wrong or incomplete.
## Ask
Approve / reject / defer until <date>.
```
## Guardrails
- Do not create noisy reminders for low-value items.
- Do not treat a reminder as completion; the decision still needs an artifact or explicit closeout.
- Do not publish private user context in public registers or examples.
- Prefer specific review dates over vague “later.”
- If the item affects external action, money, privacy, or security, require explicit user approval before acting.
## Success Standard
A deferred decision is handled correctly when a future assistant, teammate, or agent can answer:
- What was deferred?
- Why?
- Who owns it?
- When does it return?
- What must be true to decide?
- Where is the decision artifact?
don't have the plugin yet? install it then click "run inline in claude" again.
added explicit inputs with storage and scheduler connection guidance, broke original "capture rule" into a detailed 7-step procedure with input/output per step, extracted decision points for vague dates/missing owners/sensitive data/external notifications, formalized output contract with register format and privacy guardrails, and defined outcome signal covering capture accuracy through privacy and staleness prevention.
use this skill when a decision is important enough to revisit but not ready to decide now. the goal is simple: deferred should not mean forgotten. capture the decision, why it's parked, who owns it, when to review it, and what must be true to move forward. this prevents decisions from silently disappearing into noise and ensures the right person surfaces it at the right time with the right context.
receive the deferred signal: user says something like "let's come back to this later", "not now but don't let this disappear", "park this until after launch", "we need a decision next week", or "this is a good idea but we need more data first".
extract and validate the required fields: ask or infer the decision title, reason for deferral, owner, review date, trigger condition, and retirement condition.
identify or create the deferred-decision register: check whether a register (file, doc, database, or list) already exists in the user's workspace. if yes, open it. if no, create one using the recommended format.
add the deferred decision to the register: insert a new row or entry with all 8 fields. include status as "open" or "waiting". timestamp the entry.
set a review trigger: if the user has a scheduler or reminder system (calendar, task app, internal bot, etc.) and explicitly approves notifications or calendar events, create a reminder for the review date. if no external scheduler exists or user prefers manual review, note the review date in a location the user's normal review process checks (e.g. weekly planning doc, sprint board, recurring meeting agenda).
document the decision artifact location: note in the register where the eventual decision board or decision log should live (e.g. link to a docs folder, project wiki, or decision log). if the decision is sensitive (personal, financial, security, strategic), keep the register itself private or user-approved; do not publish examples or samples in public docs.
confirm and summarize: tell the user what you captured, who owns it, when it reviews, and where it lives.
if trigger condition has already happened (e.g. user says "we're past the launch now"): skip deferral and move directly to step 3 of the review behavior section (create a decision board). do not create a deferred entry.
if review date is vague (e.g. "later", "soon", "next week" without a specific date): push back. get an explicit ISO 8601 date or calendar date with year. if user cannot commit to a date, deferral is not the right tool; escalate to a backlog or "someday" list instead.
if no owner is named: ask the user who should own this. do not proceed without a named owner. if the user says "I'll own it", confirm that person or role is still responsible after context switches or time passes.
if the decision is sensitive (involves personal data, security, pricing, legal, or strategy): do not store the register in a public or shared location without explicit user approval. ask the user where to store it (local file, private folder, encrypted doc, etc.) and confirm privacy settings.
if the user wants to create external calendar events or send reminders to other people: require explicit approval. do not assume you can notify teammates or add shared calendar entries. get a yes/no from the user first.
if no external scheduler exists and the user has no manual review process: offer to create a simple review trigger (e.g. add to a weekly planning doc, monthly retrospective agenda, or a pinned list the user checks).
if a decision is marked retired or no longer relevant: do not resurface it in future reviews unless the user changes the retirement condition. remove it from active reminders.
if the register grows stale or the user stops reviewing it: warn the user. ask whether to archive the register or move unresolved items to a backlog. do not let a deferred-decision register become a graveyard.
deferred-decision register (markdown table, CSV, or database record):
# Deferred Decisions
| Decision | Owner | Deferred Because | Review Date | Trigger | Status | Artifact | Created | Retirement Condition |
|---|---|---|---|---|---|---|---|---|
| Example vendor evaluation | ops-lead | Waiting for pricing from 3 vendors | 2026-06-01 | Pricing received from all vendors | waiting | docs/decisions/vendor-eval.md | 2026-01-15 | Decision made or vendor partnership approved |
fields:
register location: private or user-approved file system location. default to a local file or private project folder. do not publish the register in public docs or examples unless the user explicitly allows it.
decision board (created at review time if trigger is met or review date arrives):
# Decision Board: <Decision Title>
## Context
Why this decision matters now. What has changed since deferral.
## Options
1. Option A
2. Option B
3. Option C
## Criteria
- Cost
- Speed
- Risk
- Reversibility
- Strategic fit
## Recommendation
Recommended option and why it beats alternatives.
## Risks / Caveats
What could be wrong, incomplete, or uncertain.
## Ask
Approve / reject / defer until <date>.
you will know this skill worked when:
the decision is captured: the user can point to the register entry and confirm all 8 fields are filled in, explicit, and accurate.
the owner knows about it: the named owner has been informed (explicitly by the user or via the register if it is shared with them). they understand their role in reviving it.
the review date is set and will surface: a reminder exists (either in a scheduler or in the user's manual review process) and will trigger on or before the review date.
the decision does not disappear: at the scheduled review time, the decision returns to active consideration. a future assistant or teammate can open the register and see the full context.
the register stays current: when a decision is decided, retired, or deferred again, the status and review date are updated. stale entries are either archived or removed from active review.
privacy is respected: if the decision is sensitive, it is stored in a private or user-approved location. no sensitive context leaks into public docs or examples.
no noise: low-value items are not repeatedly surfaced. once a decision is decided or retired, it stops appearing in reminders and reviews.