# Clarification Timing

> Use when mid-task and unsure whether to interrupt the user with a question right now, defer it, or just proceed on a reasonable assumption — especially once meaningfully into a multi-step delegated task, where asking late can be worse than not asking at all.

- Skill: `presidenteog/clarification-timing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add presidenteog/clarification-timing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/presidenteog/clarification-timing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: PresidenteOG (https://skillmd.com/u/presidenteog)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/presidenteog/clarification-timing

---


# Clarification Timing

Adapted from https://raw.githubusercontent.com/ai-boost/awesome-prompts/main/prompts/clarification_timing_strategist.txt (ai-boost/awesome-prompts, GPL-3.0) — rewritten, not copied.

## Overview
"Ask earlier is always safer" is wrong. How much a clarification is worth depends on what's missing and how far into the work you already are — an open question that's cheap to raise up front can be actively harmful once most of the work is done. Decide by information type and by progress, not by instinct.

## When to use
- You've noticed an ambiguity partway through a task and are deciding whether it's worth interrupting the user now.
- You're about to take an irreversible or high-privilege action (deleting, publishing, force-pushing, sending) and something about scope or limits is unclear.
- You're tempted to ask about several small things one at a time.

## The four kinds of missing information
| Kind | What it covers | Window |
|---|---|---|
| Goal | What the user ultimately wants | Ask early, roughly the first tenth of the work. Past that, the value of asking collapses; proceed on the most conservative reading and flag the assumption in your final answer. |
| Input | Which data, files, or resources to operate on | Ask through roughly the first half of the work, while re-routing is still cheap. After that, validate the assumption silently instead of interrupting. |
| Constraint | Hard limits, budgets, or rules that must not be crossed | No window — ask immediately whenever discovered, and always before crossing an irreversible or high-privilege line, no matter how far along you are. |
| Context | Background that shapes interpretation but isn't a hard rule | Ask as soon as the ambiguity first affects interpretation, typically at setup. If missed, infer from what you observe rather than asking later. |

## Rules
1. Never let a goal or input question slip past the halfway point of the work — asked that late, it tends to land worse than just proceeding would have.
2. Constraint questions ignore all timing windows: they block before the irreversible step, full stop.
3. Batch — collect every open question, then ask once, grouped by kind, rather than interrupting repeatedly.
4. Don't ask what you can already infer with reasonable confidence from what you've already seen (files read, tool output, prior turns).
5. Before crossing either the goal or input window, run one check: what am I assuming here without evidence, and does it actually matter?

## How it surfaces
No fixed report format — this is a judgment call, not a structured deliverable. It resolves into one of two things:
- A **plain-language question**, asked once, covering everything genuinely still open (goal/input) or the one thing blocking an irreversible step (constraint) — not a numbered questionnaire, not multiple interruptions.
- Or, past the window: silent progress on the most conservative reading, with the assumption stated plainly wherever you report progress or results — not hidden, not made into a production.

## Example
Task: "clean up the old branches." Ninety percent through deleting stale ones, you notice one has commits nobody's looked at in six months with no merge record. That's a constraint question — irreversible action, ambiguous whether it's safe — so it gets asked now, in one sentence, regardless of how far along you are: "One branch, `feature/old-export`, has unmerged commits from March — delete it anyway, or hold it back?"