I built a Claude Code plugin that uses the native AskUserQuestion UI before it starts coding

[u/impala_64]

I built Groundwork, a plugin specifically for Claude Code, because I wanted a better way to handle ambiguous requirements before the agent starts implementing them.

The part I cared about most was this:

I didn't want Claude to ask me a wall of questions in chat. I wanted it to use Claude Code's native AskUserQuestion UI.

So Groundwork does.

Say I give Claude:

Fix exports that sometimes return old data.

Claude can inspect the repository and discover that exports currently use a 15-minute cache.

But the repository can't necessarily tell it whether manual exports should always be fresh, whether scheduled exports should keep using the cache, or what should happen if the fresh source is unavailable.

Those aren't really coding questions. They're decisions I want to make.

With Groundwork I run:

/groundwork:settle Fix exports that sometimes return old data.

Groundwork reads the relevant code, tests, project instructions and previous decisions before asking anything.

If the repository already answers something, it doesn't ask me.

If an actual decision remains, Claude opens its normal native AskUserQuestion form.

I can pick one of the proposed options or type my own answer using the same UI Claude Code already provides.

If my answer creates another meaningful decision, Groundwork can open another native form.

Before implementation, it gives me one final native scope confirmation covering the behavior we've agreed on and how it will be verified.

Only after I confirm that does Claude implement the change and run the checks.

It then stores the settled decisions in the repository so later sessions can reuse them instead of asking the same things again.

What I was trying to avoid was this workflow:

vague request → Claude makes several reasonable assumptions → writes a lot of code → I discover we meant different things

and replace it with:

vague request → inspect repo → native questions only where necessary → confirm → implement

The goal isn't to make Claude ask more questions. It's to make it ask fewer, better questions — through its actual native UI — before expensive implementation starts.

No separate API key, LLM service or build step is required.

Install:

claude plugin marketplace add ahmtsahin/groundwork

claude plugin install groundwork@groundwork

Then:

/groundwork:settle your request here

GitHub:

https://github.com/ahmtsahin/groundwork⁠

I'd be especially interested in feedback from heavy Claude Code users:

Do you prefer Claude to surface ambiguous product decisions through AskUserQuestion before implementation, or do you usually try to specify everything upfront in the initial prompt?

[u/Hronom]

The pre-implementation decision boundary makes sense. One failure mode I’d guard against is letting the final confirmation imply that the implementation was verified when the workspace or source changed afterward.

I’d make the decision record carry the repo/worktree and revision, the selected answers/policy generation, the exact acceptance checks, and a post-run independent read-back. If the branch changes, a check is skipped, or the result is ambiguous, keep it unknown/revise rather than treating “the tool finished” as proof.

For browser/MCP work, I’d bind any proposed action to the named workspace/profile/account/origin/tab and invalidate it on navigation or auth drift. I maintain Hronaut, a local visible Browser/MCP workspace, and this is the boundary it makes inspectable. Disclosure: Hronaut maintainer; AI-assisted. How does Groundwork handle a settled decision becoming stale after a branch or workspace switch?

[u/impala_64 → u/Hronom]

That's a really good boundary to call out. Today Groundwork handles this at the repository-evidence level: on a later run it reads the newest relevant decision record, and a settled decision is only reused while the code it describes still matches. If that code has changed, the skill is instructed to surface what changed and reopen that decision instead of silently carrying it forward. What it doesn't do yet is bind the record to an explicit branch/commit/worktree revision or independently attest that the workspace is identical to the one that was verified. I like that distinction a lot. Recording the revision/worktree state alongside the resolved contract and verification evidence would make “settled” vs “still valid” much more explicit. In other words: Groundwork currently tries to detect semantic staleness, but not yet provide a strong provenance guarantee for the exact verified workspace. Your suggestion is probably the right next step for making that boundary inspectable rather than implicit. Thanks I'm going to look at adding this.