When an 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 sometimes works. It also burns time.
A better move is to do a little structure upfront. Instead of sending a vague question and fixing the conversation mid-flight, send a small bundle of context and constraints so the answer can be specific on the first pass.
I call this bundle a Decision Packet.
It is not a magic prompt. It is a format.
Think of it like a good issue template or a one-page brief before a meeting. You are making the decision space visible: what you are deciding, why now, what cannot change, what would count as success, and what still feels uncertain.
That alone dramatically improves the quality of the recommendation you get back.
What a Decision Packet is
A Decision Packet is a short, structured context block for recommendation-style questions.
Use it when you want help with questions like:
- Should we keep cron or move to a queue?
- Should we build this in-house or buy a tool?
- Which rollout plan is safest?
- What is the best next step with current constraints?
A Decision Packet is optimized for choosing and planning, not for open-ended brainstorming.
That distinction matters. A lot of low-value assistant output comes from asking for “thoughts” when what you actually need is a decision with trade-offs.
Why this works better than a longer prompt
Most bad answers are not caused by a lack of model intelligence. They come from missing context.
Usually one of these is unclear:
- the real decision
- the hard constraints
- the success criteria
- the known risks
- the output format you want back
A Decision Packet closes those gaps without turning your prompt into a wall of text.
It also prevents the classic loop:
- ask a vague question
- get a generic answer
- clarify constraints
- get a better answer
- realize success criteria were never stated
- start over
The packet front-loads the important parts, so the first answer is more likely to be usable.
The template
Copy this and keep it somewhere easy to grab.
# 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 has 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 will call this successful if:
- <measurable outcomes>
## 8) Risks and unknowns
- <unknown #1>
- <unknown #2>
## 9) Output request
Return:
- A recommendation
- A short rationale
- A step-by-step plan
- A pre-mortem
- The smallest next experiment to reduce uncertainty
The last line is the part most people skip, and it is one of the most useful.
Example 1: cron vs queue for a growing pipeline
Here is what a real packet can look like.
# Decision Packet
## 1) The decision
I need to decide: keep this data pipeline on cron jobs vs move to a queue worker.
## 2) Why now
We are adding 5x more customers next month. The current cron-based approach is already flaky.
## 3) Constraints (hard)
- Team: 2 engineers
- Must run on our current VPS
- Need retries and visibility into failures
## 4) Preferences (soft)
- Prefer simple operations
- Prefer minimal new dependencies
## 5) Current state
- A nightly cron pulls from 3 APIs, normalizes data, and writes to Postgres
- Failures are only visible in logs
- Backfills are manual and painful
## 6) Options on the table
A) Keep cron and add better logging and alerts
B) Add a lightweight queue with workers
C) Use Postgres as a queue with a jobs table
## 7) Success criteria
In 4 weeks:
- Failures alert within 5 minutes
- Retries are automatic
- Backfills can be triggered with one command
## 8) Risks and unknowns
- We are unsure how often API rate limits hit us
- We do not know the true job volume after growth
## 9) Output request
Return:
- A recommendation
- A short rationale
- A step-by-step plan
- A pre-mortem
- The smallest next experiment
That packet gives the assistant enough to make a grounded recommendation instead of producing a blog-post-shaped non-answer.
Example 2: build auth or buy it
Auth conversations go off the rails fast because teams often argue without agreeing on what matters.
# Decision Packet
## 1) The decision
I need to decide: build auth ourselves vs use an external provider.
## 2) Why now
We are shipping B2B features and need SSO and audit logs.
## 3) Constraints (hard)
- Must support SAML or OIDC
- Must support role-based access control
- EU data residency matters
## 4) Preferences (soft)
- Prefer lower long-term maintenance
- Prefer fast initial delivery
## 5) Current state
- Existing app only supports email/password
- No real user management UI exists yet
- We already run Postgres and Redis
## 6) Options on the table
A) DIY auth
B) External provider
C) Hybrid approach
## 7) Success criteria
In 6 weeks:
- SSO works for 2 pilot customers
- Permission changes are auditable
- Engineers can debug auth issues without guesswork
## 8) Risks and unknowns
- Legal review timeline is unclear
- We do not know how many customers will require SAML immediately
## 9) Output request
Return:
- A recommendation
- A short rationale
- A step-by-step plan
- A pre-mortem
- The smallest next experiment
Now the discussion is anchored in trade-offs, not opinions.
The smallest next experiment is the secret weapon
A lot of decisions are blocked by uncertainty, not by a lack of ideas.
That is why the best output often is not “choose B.” It is “choose B, but first run this cheap test so you can confirm the assumptions.”
Examples of useful small experiments:
- prototype one queue worker and measure operational pain
- talk to legal before committing to a provider shortlist
- run a backfill simulation with realistic load
- write down failure modes before rollout planning
When you ask explicitly for the smallest experiment, you get answers that move work forward instead of just sounding smart.
How to use this in real work
Three habits make this pattern stick.
1) Save the template somewhere obvious
Put it in a snippets tool, a notes app, or your repo. If it takes effort to find, you will stop using it.
2) Keep packets short
This is not a spec. It is a high-signal briefing. If a section takes forever to fill, you are overdoing it.
3) Ask clarifying questions first for expensive decisions
For high-stakes choices, change the output request to:
First, ask up to 5 clarifying questions.
Then recommend if enough information exists.
Otherwise, propose the smallest next experiment.
That prevents false confidence when the packet still has important gaps.
Common failure modes
Failure: You asked for advice, not a choice.
Fix: Write the decision as A vs B vs C.
Failure: The answer is generic.
Fix: Add one hard constraint and one measurable success criterion.
Failure: The recommendation ignores trade-offs.
Fix: Separate constraints from preferences.
Failure: The answer sounds polished but does not help execution.
Fix: Require a step-by-step plan and a smallest next experiment.
Closing
Better assistant output usually comes from better inputs, but better does not mean longer.
A Decision Packet is just a compact way to provide the context a thoughtful teammate would ask for anyway: what are we deciding, what matters, what cannot change, what would count as success, and where are the unknowns?
Try it once on a real decision this week. Pick something live, fill the packet in two minutes, and compare the result with your normal prompting style.
You will probably notice the same thing I did: less back-and-forth, fewer generic answers, and a much clearer next step.
Top comments (0)