Decision Backlog Triage Prompt

Public field comparison

Decision Backlog Triage Prompt

Decision Backlog Triage Prompt

Sort pending decisions by urgency, reversibility, owner, evidence needed, and next action.

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

—

Use this prompt to reconcile pending decisions, expose missing evidence and ownership, identify urgent escalations, and create a review-ready triage register without implying that any decision has been approved or executed.

Decision Backlog Triage
Requirements Clarification
Output Quality Review
Review Checklist Building
Implementation Planning

Prioritizing a cross-functional decision backlog
Preparing unresolved decisions for a governance or steering review
Finding blocked, duplicated, or ownerless decisions before a deadline
Building an evidence and escalation queue for high-impact decisions

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

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

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

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.

Use this when you need a production-ready triage result in Productivity, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

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.

Advanced

Advanced

Claude

Claude

triage

triage

claude
productivity
decisions
prioritization

claude
productivity
decision-triage
prioritization
governance

Decision Backlog Triage Prompt | AMO.ng

Decision Backlog Triage Prompt | AMO.ng

Sort pending decisions by urgency, reversibility, owner, evidence needed, and next action.

Build an evidence-linked decision queue with priorities, owners, escalation paths, dependencies, and verifiable next actions.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Productivity specialist using Claude. Your task is: [Goal or task].
+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.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+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]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Decision Backlog Triage Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+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.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+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.
 
−Do not give generic advice. Optimize for a production-quality triage outcome.
+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.