When I develop software with AI, I try to describe the problem clearly before deciding how to solve it. A detailed prompt helps, but filling it with my preferred implementation can close off better options too early. These are the five habits I use.
1. Look for what already exists
Usually, someone has solved a similar problem, or a library already covers most of it. I ask the agent to inspect the project and research existing solutions first, then compare fit, maintenance, licensing, and integration cost. Reusing something still needs a reason; so does building it myself.
2. Describe the outcome
I explain what needs to become possible, why it matters, and how we will know it works. Unless I have already made a firm technical decision, I leave the implementation open. “Users can resume an interrupted upload” gives the agent more useful design space than prescribing a particular database and queue.
3. Describe the experience
I describe who uses the product, what triggers their visit, what they do, and what happens when something goes wrong. “After uploading a file, the user knows whether it succeeded and can recover from failure” explains the experience. A dashboard with a button in the top right is an interface choice. If that choice is already settled, I say so explicitly.
4. Use questions to challenge assumptions
I use Matt Pocock’s grilling skill to examine the requirements. My prompt below adds a preference for one question at a time, with options, tradeoffs, and a recommendation. This is where my initial technical and interface preferences can be challenged. In Claude Code, I ask for AskUserQuestion; elsewhere, I ask for the available equivalent or a plain-text question.
5. Turn decisions into executable work
Once we agree, I ask for a design document and architecture decision records (ADRs) under docs/. ADRs explain consequential choices and their alternatives; tasks explain the work. Each task needs prerequisites and a way to verify completion. A dependency “tree” can have shared prerequisites, so I request a directed acyclic graph (DAG) and an execution order as well.
Install grilling
With Node.js, npm, and Git installed, run the command for your agent in a terminal. These use the third-party Skills CLI to install Matt Pocock’s grilling skill for your user account.
Codex
npx skills@latest add mattpocock/skills --skill grilling --agent codex --globalClaude Code
npx skills@latest add mattpocock/skills --skill grilling --agent claude-code --globalRemove --global to install for the current project. Codex discovers user skills in ~/.agents/skills/; Claude Code uses ~/.claude/skills/. Start a new session if the skill does not appear. Invoke it with $grilling in Codex or /grilling in Claude Code.
A reusable planning prompt
Replace the brackets and paste the whole block. It works for a new product, a feature, or a change to an existing system. The interview produces a plan; execution starts with a separate prompt.
Help me plan this software development task. Do not implement it yet.
Outcome and why it matters: [describe the result]
Users and usage experience: [who, situation, journey, success, and failure/recovery]
Success criteria: [observable results]
Constraints: [existing system, compatibility, time, budget, security, etc.]
Confirmed decisions and their reasons: [list them, or write “none”]
Preferences open to challenge: [optional]
1. Investigate first
Inspect the relevant project and look for existing implementations, libraries, or services. Research current primary sources when available. Compare reuse, adaptation, and building from scratch by fit, maintenance, license, and integration cost. Link evidence and distinguish facts from assumptions. If research is unavailable, state what remains unverified.
2. Align with me before designing
Use the grilling skill. For this task, ask one question at a time and wait for my answer. Resolve prerequisite decisions before dependent ones. Look up discoverable facts yourself; ask me about choices.
For each question, offer 2–4 meaningful options with explanations and tradeoffs. Mark your recommendation and explain why; allow a custom answer. In Claude Code, use AskUserQuestion when available. In Codex or another agent, use its available question tool; otherwise present the same choices in text. Do not assume a tool exists.
Focus on outcomes, usage experience, scope, failure cases, and acceptance criteria. Keep implementation and interface choices open unless I marked them as confirmed. Challenge my preferences when a better option may exist, and surface conflicts with confirmed constraints.
Summarize our agreement and remaining uncertainties. Wait for my explicit confirmation of shared understanding before writing the plan or implementation.
3. After confirmation, document the plan
Use docs/[task-slug]/, following existing repository conventions where applicable:
- design.md: problem, users and journeys, goals/non-goals, constraints, proposed approach, acceptance criteria, risks, and verification strategy.
- adr/NNNN-short-title.md: one ADR per consequential architectural decision, with context, alternatives, decision, reasons, consequences, and status. Link the design document. Do not invent ADRs for routine steps.
- tasks.md: small, independently verifiable tasks with stable IDs, scope, prerequisites (depends_on IDs), expected outputs, acceptance criteria, verification steps, status, and links to relevant design sections/ADRs.
- dependency-graph.md: a Mermaid DAG covering every task, including isolated ones, plus a text dependency list and a topological execution order grouped into stages. Define A --> B as “B requires A”. Check for missing IDs and cycles. Show which tasks can run in parallel and which are blocked.
Ensure every acceptance criterion is covered by tasks. Tasks implement the agreed design and decisions; they do not merely rewrite the ADRs. End with the first ready task and how I can execute it. Stop before implementation.Continue one task at a time
After reviewing the documents, use this prompt again for each step. A task is ready only when all its prerequisites are complete.
Read docs/[task-slug]/design.md, adr/, tasks.md, and dependency-graph.md.
Execute [task ID, or “the next ready task”] only after checking that all prerequisites are complete. If it is blocked, explain why and list ready tasks instead.
Complete this task within its agreed scope, run its relevant verification, and update its status and verification evidence in tasks.md. If a newly discovered issue changes the design or ADRs, explain the impact and align with me before proceeding with that change.
Report what changed, verification results, and the next ready tasks. Stop before starting another task.Installation and tool references
Commands and tool guidance checked on 17 October 2026. Skills evolve; the prompt above explicitly sets my interview preferences.
- grilling — Matt Pocock
- Skills CLI — installation options
- Codex — local skills
- Claude Code — skills
- Claude Code — AskUserQuestion
Also on this blog
Unknown Known: When Monitoring Can't Keep Up With Resource Creation