When an AI assistant gives a weak answer, the instinct is to ask again—add another sentence, clarify one more detail, paste one more snippet… and hope the next reply lands.
That works, but it’s slow. You’re paying (in time and attention) for something you could do upfront: send a small, structured bundle of context and constraints so the assistant can produce a recommendation you can actually act on.
I call this bundle a Decision Packet.
It’s not a “better prompt” in the clever-wording sense. It’s a format—like a good GitHub issue template—that makes it easier for you to provide the right inputs and for the assistant to produce an answer that’s specific, scoped, and checkable.
Below is the template, plus concrete examples you can copy into your own workflow.
What a Decision Packet is (and isn’t)
A Decision Packet is:
- A 1–2 minute structured context dump
- Optimized for recommendations (what to do next), not just explanations
- Designed to reduce “it depends” by forcing trade-offs into the open
A Decision Packet is not:
- A full document
- A brainstorming session
- A request for the assistant to “figure everything out”
Think of it like handing someone a well-prepared folder before a meeting.
The Decision Packet template
Copy/paste this and fill it in. Keep it short; the goal is signal density.
# Decision Packet
## 1) The decision
I need to decide: <A vs B vs C>.
## 2) Why now
What triggered this decision? What happens if we do nothing?
## 3) Constraints (hard)
- <time/budget/legal/tech constraints>
- <must-keep requirements>
## 4) Preferences (soft)
- <nice-to-haves>
- <things we prefer but can trade away>
## 5) Current state
- What exists today?
- What’s already been tried?
- What is known to be broken?
## 6) Options on the table
A) <option>
B) <option>
C) <option>
## 7) Success criteria
In 2–4 weeks, we’ll call this successful if:
- <measurable outcomes>
## 8) Risks & unknowns
- <unknown #1>
- <unknown #2>
## 9) Output request
Return:
- A recommendation (pick A/B/C or propose D)
- A short rationale
- A step-by-step plan
- A "pre-mortem" (how this could fail)
- The smallest next experiment to reduce uncertainty
Why these sections work
- The decision forces you to ask for a choice, not a lecture.
- Constraints vs preferences prevents accidental scope creep.
- Success criteria turns opinions into something you can evaluate.
- Risks & unknowns invites the assistant to ask better questions.
- Output request makes the response shape predictable (and therefore reusable).
Example 1: Choosing a queue vs. cron for a data pipeline
Here’s what a filled-out packet looks like.
# Decision Packet
## 1) The decision
I need to decide: run this pipeline via cron jobs vs. a proper queue worker.
## 2) Why now
We’re adding 5x more customers next month. Current cron-based approach is already flaky.
## 3) Constraints (hard)
- Team: 2 engineers
- Must run on our current VPS (no managed cloud services for now)
- Need retries + visibility into failures
## 4) Preferences (soft)
- Prefer simple ops
- Prefer minimal new dependencies
## 5) Current state
- A nightly cron pulls data from 3 APIs, normalizes, and writes to Postgres
- Failures are only visible via logs; no alerts
- Backfills are manual and painful
## 6) Options on the table
A) Keep cron, add better logging + alerts
B) Add a lightweight queue (e.g., Redis + worker)
C) Use Postgres as a queue (advisory locks / job table)
## 7) Success criteria
In 4 weeks:
- Failures alert within 5 minutes
- Retries are automatic
- Backfills can be triggered with one command
## 8) Risks & unknowns
- Unsure how often API rate limits hit us
- Unsure how many jobs per run we need after growth
## 9) Output request
Return:
- A recommendation
- Rationale
- Step-by-step plan
- Pre-mortem
- Smallest experiment
A good response to that should look like something you can turn into a ticket plan—not a philosophical debate.
Example 2: “Which approach should we use for auth?” (without boiling the ocean)
Auth questions often spiral because nobody states what matters.
# Decision Packet
## 1) The decision
I need to decide: build auth ourselves vs. use an external provider.
## 2) Why now
We’re shipping a B2B feature set and need SSO and audit logs.
## 3) Constraints (hard)
- Must support enterprise SSO (SAML/OIDC)
- Must support role-based access control
- We’re in the EU; data residency matters
## 4) Preferences (soft)
- Prefer lower long-term maintenance
- Prefer fast initial delivery
## 5) Current state
- Existing app has email/password only
- No proper user management UI
- We already have Postgres + Redis
## 6) Options on the table
A) DIY (store users, sessions, MFA, etc.)
B) External provider (Auth0/Clerk/etc.)
C) Hybrid (provider for SSO + core user tables in-app)
## 7) Success criteria
In 6 weeks:
- SSO works for 2 pilot customers
- Audit trail exists for permission changes
- Engineers can debug auth issues without guessing
## 8) Risks & unknowns
- Legal review timeline is unclear
- Not sure how many enterprise customers will require SAML
## 9) Output request
Return:
- Recommendation
- Rationale
- Step-by-step plan
- Pre-mortem
- Smallest experiment
The “smallest next experiment” is the secret weapon
Most decisions aren’t blocked on “not enough intelligence.” They’re blocked on uncertainty.
The best assistants don’t just pick an option; they suggest a cheap way to reduce uncertainty:
- A spike/prototype
- A measurement
- A stakeholder check
- A failure-mode test
When you ask for the smallest experiment explicitly, you get answers that move work forward.
How to use Decision Packets day-to-day
1) Save the template somewhere you actually use
Notion, a repo, a snippet manager, even a text file. The win comes from repetition.
2) Keep packets intentionally incomplete
A packet is allowed to include unknowns. The point is to label them.
3) Ask for clarifying questions before recommendations (when stakes are high)
If the decision is expensive or irreversible, modify the Output Request:
First, ask up to 5 clarifying questions.
Then, if enough info exists, recommend.
Otherwise, propose the smallest experiment.
4) Turn the response into an artifact
Copy the plan into:
- A ticket breakdown
- An ADR (architecture decision record)
- A project README
If the assistant’s output can’t be turned into an artifact, your packet probably lacked constraints or success criteria.
Common failure modes (and fixes)
Failure: You asked for “thoughts” instead of a decision.
Fix: Make the decision binary/ternary (A/B/C) and ask for a recommendation.Failure: The answer is generic.
Fix: Add one more constraint (time/budget/stack) and one measurable success criterion.Failure: The assistant over-optimizes for a single metric (e.g., speed).
Fix: Put trade-offs in Preferences (“prefer speed, but not if it destroys debuggability”).
Closing
Better AI output usually comes from better inputs—but “better” doesn’t mean longer.
A Decision Packet is a fast way to provide the kind of context that humans naturally ask for in a meeting: what are we deciding, what are the constraints, what does success look like, and what are we afraid of?
If you try this, start small: pick one real decision this week and send it as a packet. You’ll feel the difference immediately.
Top comments (0)