{"slug": "resolve-open-questions-a-qa-skill-for-claude-code", "title": "Resolve Open Questions: a /qa Skill for Claude Code", "summary": "A developer known as @atwellpub has created a /qa skill for Claude Code that forces the AI agent to resolve open questions before writing any code. The skill enters plan mode, interrogates the agent's last reply or performs a full sweep, and presents all decisions in a single batch, refusing to build until the user answers. It aims to prevent unresolved decisions from surfacing after work is complete.", "body_md": "**By @atwellpub, GBTI Network Member.** Originally published on\n\nClaude Code loads any markdown file at `.claude/skills/<name>/SKILL.md`\n\nas a reusable slash command (a \"skill\"). This one gives your agent a `/qa`\n\ncommand that stops before it builds, pulls every unresolved decision into a single batch of questions, and refuses to write code until you have answered them.\n\nIt exists because open questions have a habit of surfacing at the wrong end of the work. A sprint finishes, and only then does the agent raise the decisions it should have raised at the start, at exactly the point where acting on them means redoing something.\n\nThe mechanism is plan mode, invoked deliberately. The agent puts ITSELF into a read-only state, does its research there, asks everything it found in one batch, and only then acts. That ordering is the whole feature.\n\n`.claude/skills/qa/`\n\nin your repo, or `~/.claude/skills/qa/`\n\nto have it in every project.`SKILL.md`\n\ninside it.`/qa`\n\nin Claude Code.Nothing to configure. The skill reads your project, not a config file.\n\n```\n---\nname: qa\ndescription: \">\"\n  Resolve the open questions before the work proceeds. Invoke for \"/qa\", \"/qa continue\", \"/qa proceed\",\n  \"/qa deep\", \"/qa <topic>\", or when the user asks you to ask your questions first, clarify before\n  building, or answer the things you just raised. By default it interrogates only YOUR OWN LAST REPLY:\n  the questions, options and flagged decisions already sitting in it. \"/qa deep\" runs the full\n  six-category sweep instead. Every mode enters plan mode; \"continue\" and \"proceed\" skip the plan\n  approval and build straight from the answers.\n---\n\n# /qa: resolve the open questions before building\n\nThe point of this command is to move every decision that is the user's call OUT of your head and\ninto one batch of questions, answered before any code is written. No silent defaults, no drip of\nad-hoc questions later.\n\nThe common case is small and cheap: a reply just ended with open questions in it, and the user wants\nthose answered properly instead of letting them evaporate. That is the default. The exhaustive sweep\nis a separate, deliberate mode, because it costs real tokens and most invocations do not need it.\n\n## Read the argument first, it selects the mode\n\n`continue`, `proceed` and `deep` are reserved words. Anything else is a topic.\n\n| Invocation | Mode |\n|---|---|\n| `/qa` | **Ask and hold, last reply.** Enter plan mode (`EnterPlanMode`), interrogate your own last reply, ask what it left open, then present a plan for approval (`ExitPlanMode`). Write nothing until approved. |\n| `/qa continue` or `/qa proceed` | **Ask and go.** Identical, minus the confirmation before acting: once the answers land you build straight from them, with no plan written for review. |\n| `/qa deep` | **Full sweep.** Step 2's six categories instead of the last-reply scope. Use when starting real work, not when closing out a reply. |\n| `/qa deep continue` or `/qa deep proceed` | Full sweep, no approval round. Scope and approval are independent. |\n| `/qa <anything else>` | **Scoped.** The trailing text names the subject to interrogate. Add `continue` or `proceed` to drop the approval round for it. |\n\nEvery mode enters plan mode and holds its read-only discipline until the questions are answered. The\nquestion-asking discipline in step 3 is identical in all of them; only the SCOPE and the approval\nround change.\n\n## Step 1: verify before you ask\n\nNever ask what the repository can answer. Check the claims your questions rest on before putting them\nto the user, so every question is one that genuinely cannot be resolved without them. A question the\ncode already answers is noise, and it teaches the user that /qa wastes their time.\n\nIn the default mode this is targeted, not a survey: confirm the specific facts behind the items your\nlast reply raised. A flagged failure may already have its reason recorded somewhere; an offered option\nmay turn out to be impossible or already done. Verifying first routinely dissolves a question or\nchanges what it should have been.\n\n## Step 2: what to interrogate\n\n**Default: your own last reply.** Re-read the reply you just gave and pull out everything you left\nopen: questions you asked, options you offered, decisions you named as the user's, caveats you\nattached, and anything you said you COULD do next. That set is the batch. Do not sweep the codebase.\n\nIf the last reply left nothing open, say so plainly and stop. Do not go hunting for work to justify\nthe invocation.\n\n**Deep (`/qa deep`): the full sweep.** Cover all of these, not just the obvious one:\n\n1. **The request itself.** Scope boundaries, what is deliberately excluded, naming, placement.\n2. **The governing doc.** If the work traces to a planning document (a scope of work, a ticket, a\n   spec), its open-questions section is the primary source. Pull those forward verbatim.\n3. **What the audit surfaced.** Which existing pattern to reuse, where a shared helper lives,\n   whether to extend a surface or add one.\n4. **Anything you were about to default silently.** If you caught yourself picking, it is a\n   question. This is the highest-yield category.\n5. **The user's call by nature.** Product and UX behavior, copy, data-shape changes, anything\n   irreversible or outward-facing, and anything that costs money or needs provisioning.\n6. **Conflicts.** Where the request contradicts an existing convention, the code, or an earlier\n   decision, surface the conflict rather than quietly picking a side.\n\n## Step 3: how to ask\n\n- **One batch, numbered, in prose.** Free-form conversational questions, not multiple-choice\n  pickers, unless a question is a genuine either/or.\n- **Give each question a recommendation.** State the option you would take and why, so the user can\n  answer \"your call\" on any of them and you are still unblocked.\n- **Give each question its stakes in one line.** What changes depending on the answer. A question\n  whose answer changes nothing should not be asked.\n- **Order by consequence**, most structural first.\n- **Say so when there are none.** If verification resolved everything, report that plainly and state\n  the assumptions you are proceeding under. Do not manufacture questions to justify the command.\n\n## Step 4: after the answers\n\n- **Do not re-ask.** Answered means settled; carry it forward without relitigating.\n- **Record the resolutions where they belong.** If a planning doc raised the question, write the\n  answer back into it so it reads as resolved, not still open.\n- In ask-and-hold mode, present the plan for approval. In continue/proceed mode, leave plan mode as\n  soon as the answers land and build, without composing a plan for review. The harness still\n  surfaces a single prompt on the way out of plan mode; that is a formality, not a review round, so\n  keep what you write there to a line or two.\n- If something genuinely new surfaces mid-build, finish everything that does not depend on it, then\n  raise the one question at the right moment.\n\n## Reminders\n\n- Follow the project's own plan-mode and writing conventions throughout.\n- The command is about decisions, not permission. Do not turn it into a request to confirm work the\n  user already asked for.\n```\n\nThe argument controls two independent things: how wide the agent looks, and whether a plan gets approved before it acts.\n\n`/qa`\n\n`/qa continue`\n\n`/qa proceed`\n\n`/qa deep`\n\n`/qa <anything else>`\n\n`\"/qa the rate limiter\"`\n\nasks everything unresolved about the rate limiter specifically.Scope and approval compose, so `/qa deep continue`\n\nruns the wide sweep and then builds from your answers without a plan to approve.\n\nThe narrow default is the important design choice. An exhaustive sweep on every invocation is expensive and mostly wasted, because the usual reason you type `/qa`\n\nis that the agent just handed you a list of open questions and you want them asked properly rather than left to evaporate.\n\n**Tune the deep sweep.** Step 2 lists six places to look under `/qa deep`\n\n. The list is deliberately generic, so add the categories your projects actually produce. A team with a design system adds \"which token or component does this reuse\". A team with a data model adds \"does this change a stored shape, and what happens to existing rows\". A regulated project adds an approvals category. The sweep is only as good as its list, and it only runs when you ask for it.\n\n**Point it at your planning docs.** The highest-yield item in the sweep is a governing document with an open-questions section, since those questions are already written and already yours to answer. If your project keeps scopes of work, tickets or design docs, name that location explicitly in step 2 so the agent reads it every time.\n\n**Decide how hard the hold is.** As written, bare `/qa`\n\nwill not touch a file until you approve a plan. If that is heavier than you want for routine work, make `continue`\n\nthe implied default in your copy and reserve the plan-approval round for large changes.\n\n**Decide what \"last reply\" means to you.** The default reads the agent's most recent message and treats everything it left open as the batch. If your sessions tend to sprawl across several exchanges before you reach for `/qa`\n\n, widen that to the current thread of work, or just type `/qa deep`\n\nwhen the narrow read would miss something.\n\nThe resource shared in this post is a new prompt published by GBTI Network member [Hudson Atwell](https://dev.to/realatwellpub).\n\nAre you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit\n\n[https://gbti.network]To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly:\n\n[https://gbti.network/members/atwellpub/]", "url": "https://wpnews.pro/news/resolve-open-questions-a-qa-skill-for-claude-code", "canonical_source": "https://dev.to/gbti-network/resolve-open-questions-a-qa-skill-for-claude-code-1jp2", "published_at": "2026-07-31 17:22:00+00:00", "updated_at": "2026-07-31 17:33:45.310007+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "artificial-intelligence"], "entities": ["Claude Code", "@atwellpub", "GBTI Network"], "alternates": {"html": "https://wpnews.pro/news/resolve-open-questions-a-qa-skill-for-claude-code", "markdown": "https://wpnews.pro/news/resolve-open-questions-a-qa-skill-for-claude-code.md", "text": "https://wpnews.pro/news/resolve-open-questions-a-qa-skill-for-claude-code.txt", "jsonld": "https://wpnews.pro/news/resolve-open-questions-a-qa-skill-for-claude-code.jsonld"}}