You are viewing the current published version.
Productivity Advanced Claude

Decision Backlog Triage Prompt

Convert a decision backlog into an evidence-linked priority queue based on urgency, impact, reversibility, readiness, ownership, dependencies, and next action.

View all versions
Best fortriage
ToolClaude
DifficultyAdvanced
Full Prompt
Triage the supplied decision backlog into a defensible, review-ready queue. Use Claude to analyze only the text, files, and other materials available in the current conversation. Do not imply access to project trackers, email, calendars, private repositories, or external systems unless their contents are explicitly provided.

Inputs
- Decision backlog: [Decision backlog]
- Operating context and objectives: [Decision context]
- Constraints, deadlines, capacity limits, and time zones: [Constraints and deadlines]
- Decision rights, approvers, escalation paths, and prohibited actions: [Authority and escalation rules]
- Existing prioritization definitions or service levels: [Triage policy]
- Notes, meeting records, issue exports, prior analyses, or other evidence: [Supporting materials]

Input handling
1. A readable backlog containing at least one identifiable decision is required. Each entry should ideally include an ID, decision statement, requester, relevant date, and current status. If no usable decision entries are supplied, return a Blocking Input Notice that identifies what is missing; do not create a backlog.
2. Decision context, deadlines, authority rules, and triage policy are important but may be incomplete. Ask a clarification question only when the omission prevents safe prioritization, such as an unknown statutory deadline, disputed approval authority, or an ambiguity that could materially alter an urgent escalation.
3. When bounded progress is safe, triage the available entries and preserve missing information as Unknown. Do not infer a confirmed owner, deadline, approval, or completed action.
4. If sources conflict, record the conflict, cite both source labels or backlog IDs, explain its effect on triage, and route the item for clarification rather than silently choosing one version.
5. If a referenced file or source cannot be inspected in the current conversation, label it Unavailable and do not claim to have reviewed it.

Evidence rules
- Label material assertions as Supplied fact, Inference, Assumption, Unknown, Conflict, or Unavailable.
- Cite the relevant backlog ID and source label for deadlines, dependencies, owners, approval rights, impact claims, and reported decisions.
- Treat unsupported urgency language such as “ASAP” as a signal to investigate, not as proof of priority.
- Distinguish a reported status from verified evidence. For example, “reported approved” is not “approval verified” unless an approval record is supplied.
- Use explicit dates and time zones when available. If only relative timing is supplied, preserve that wording and flag the ambiguity.

Triage method
1. Reconcile the intake.
   - Assign or preserve a stable ID for every entry.
   - Separate actual decisions from tasks, ideas, risks, questions, and status updates. Retain misclassified entries in the reconciliation rather than discarding them.
   - Detect exact and probable duplicates. Keep one primary entry and link duplicates, preserving any conflicting details.
   - Rewrite vague entries as proposed decision statements that identify the choice, decision maker, options, and consequence where the evidence supports doing so. Mark rewritten language as an Inference pending confirmation.

2. Assess each unique decision.
   - Urgency: identify hard deadlines, expiring options, blocked work, dependency timing, and cost of delay. Do not equate age, seniority, or requester pressure with urgency.
   - Impact: describe the likely operational, customer, financial, legal, security, privacy, safety, or strategic consequence using supplied evidence. Do not manufacture monetary estimates.
   - Reversibility: classify as readily reversible, reversible with material cost, or difficult to reverse, and explain the switching cost or lock-in.
   - Evidence readiness: identify the evidence already available, the evidence still needed, who could provide it, and whether waiting is likely to improve the decision.
   - Ownership: distinguish confirmed decision owner, confirmed approver, proposed owner, contributor, and escalation recipient. Never present a proposed assignment as accepted.
   - Dependencies: record decisions or work that this item blocks, items that block it, sequencing constraints, and circular dependencies.
   - Decision risk: identify the downside of deciding too early, deciding too late, or allowing the default outcome to occur.

3. Assign a disposition.
Use the supplied triage policy when it is complete and consistent with the authority rules. Otherwise apply these default bands and state that they are assumptions:
   - P0 — Immediate human escalation: a credible imminent safety, security, privacy, legal, regulatory, severe customer, or major financial consequence, or a hard deadline within 24 hours. P0 means escalate for authorized review; it does not authorize Claude to decide or act.
   - P1 — Decide next: material cost of delay, a near hard deadline, or multiple blocked commitments requiring review within one to three business days.
   - P2 — Schedule: meaningful decision with manageable delay and a clear review trigger or target window.
   - P3 — Defer or monitor: low current cost of delay, insufficient readiness, or no near-term dependency. Include a reassessment trigger so deferral does not become abandonment.
Also assign one routing state: Ready for decision, Clarification required, Waiting on evidence, Waiting on dependency, Escalation required, Deferred, Duplicate, Non-decision, or Candidate for closure. Use Candidate for closure unless supplied evidence confirms that closure was authorized.

4. Sequence the queue.
   - Rank within each priority band using deadline credibility, cost of delay, dependency leverage, evidence readiness, reversibility, and available decision-maker capacity.
   - Explain material trade-offs rather than relying on an unexplained numeric score.
   - Identify batching opportunities only when the decisions share an owner, evidence base, or review forum and batching will not endanger a deadline.
   - Flag priority inflation, circular dependencies, owner overload, conflicting deadlines, and queues with no authorized approver.

5. Define the next safe action.
For every active entry, provide one concrete next action, a confirmed or proposed action owner, a due date or event-based trigger, the expected evidence produced, and the handoff recipient. If authority is missing, the next action must be clarification or escalation—not execution.

Authority and safeguards
- This is analysis and proposed triage only. Do not approve or reject decisions, commit funds, accept risk, assign work as final, contact stakeholders, modify trackers, publish results, or execute downstream actions.
- Require explicit human authorization for decisions involving legal or regulatory obligations, personnel, security, privacy, safety, production operations, contractual commitments, public statements, or material spending.
- Minimize reproduction of personal, confidential, credential, or security-sensitive data. Refer to sensitive evidence by source label when full quotation is unnecessary. If secrets or credentials appear, do not repeat them; flag the exposure for authorized handling.
- Stop and request authorized review if the requested triage would bypass decision rights, conceal a material conflict, expose sensitive data, or treat an unverified assumption as grounds for a consequential action.
- Where delay creates risk, recommend an escalation path and reversible containment option if supported by the supplied authority rules. Do not claim that containment, notification, approval, or rollback occurred.

Required output
Produce the following sections in Markdown.

1. Intake and reconciliation
Report the number of supplied entries, unique decisions, probable duplicates, non-decisions, unusable entries, and entries analyzed. Explain any count difference.

2. Prioritized decision register
Create one row per unique decision with these columns:
ID; normalized decision statement; priority; routing state; deadline or trigger; urgency and cost-of-delay rationale; impact; reversibility; evidence available with source labels; evidence needed; dependencies; confirmed or proposed owner; approver or escalation route; next safe action; action due date or trigger; confidence; unknowns or conflicts.

3. Immediate escalation queue
List each P0 and P1 item with the escalation reason, deadline evidence, potential consequence, authorized recipient, reversible interim option if any, and approval required. State None identified if no supplied evidence supports an immediate escalation.

4. Clarification and evidence queue
For each blocked item, provide the exact question or evidence request, why it could change the priority or routing state, who is best placed to answer, and the response deadline or trigger.

5. Dependency and capacity view
Show blocking chains, circular dependencies, shared review forums, owner or approver overload, and sequencing conflicts. Identify which relationships are supplied facts versus inferences.

6. Deferred, duplicate, and non-decision register
Account for each item removed from the active queue. Include its linked primary ID or classification rationale, reassessment trigger where relevant, and evidence status.

7. Verification and acceptance report
Provide a checklist table with Check, Expected condition, Actual observation, Evidence, and Status. Verify at minimum that:
- every supplied entry is accounted for exactly once as a primary item or linked duplicate;
- intake totals reconcile with the register sections;
- every active decision has a priority, routing state, rationale, and next safe action;
- every P0 or P1 item has deadline or consequence evidence and an authorized escalation route, or is explicitly marked blocked;
- confirmed owners and approvers are supported by supplied evidence;
- assumptions, unknowns, conflicts, and unavailable sources remain visibly labeled;
- dependencies reference valid IDs and circular dependencies are flagged;
- deferred items have a review date or event-based trigger;
- no proposed, reported, blocked, or unverified action is described as approved, sent, implemented, resolved, or completed.
Use Pass, Fail, or Unresolved. Do not mark Pass without an actual observation and supporting evidence.

8. Human handoff
State the smallest safe review action, the person or authority needed, the items included, the evidence they should inspect, and the decision or approval requested. Keep all outcomes Proposed, Blocked, Reported, or Verified according to the evidence actually available.

Variables to Replace

  • Decision backlog
  • Decision context
  • Constraints and deadlines
  • Authority and escalation rules
  • Triage policy
  • Supporting materials

How to Use This Prompt

Open Claude, replace every bracketed variable with your actual backlog context, and attach or paste the relevant decision register, issue export, meeting notes, deadlines, decision-rights matrix, approval policy, and supporting evidence. If a variable is unavailable, write “Not provided” rather than guessing. Then run the prompt and have an authorized human review the triage register before changing trackers, escalating issues, assigning owners, or making decisions.

Example Use Case

A product operations lead pastes 45 unresolved steering-committee decisions into Claude along with launch milestones, meeting minutes, decision owners, and escalation rules. Claude reconciles duplicates, separates tasks from decisions, identifies two deadline-driven escalations, maps blocking chains, and returns an evidence-linked queue for the committee to review. No owner assignment, approval, or tracker update is treated as completed until a human supplies evidence.

Published change

Major: Replace the legacy Decision Backlog Triage Prompt template with a domain-specific input, evidence, authority, safety, workflow, output, and verification contract.