Intent First: Confidence Gates and CI Guardrails for an Agent That Merges Alone

Three days ago I wrote about Anthropic’s AI-native SDLC: where the bottleneck moves once an agent writes most of the code. That post was the map. This one is a single trip on it: what I set up so Claude Code could ship on its own, and the one place where I refused to let it guess: the intent.

The project and what I wanted from it

The project is a personal one I work on, and a fairly complex one: a microservice architecture running on a Kubernetes cluster, five separate Git repositories, and event-driven communication between some of the components. The experience below comes from one of those repositories. It is built by a small team of Claude Code agents: a lead agent talks to me, and specialists each own their own files and concerns, including one for CI/CD and one that curates the AI context itself.

What I wanted fits in one sentence: I hand over a request, and the next thing I see is either a merged pull request with every check green, or one precise question. Not a stream of “shall I continue?”, not a pull request waiting three days for my click.

The pipeline at a glance

Every run starts from a trigger: a command, a fix, a new feature. It can come from me, from a ticket in a tracker such as Jira, or from the next item of a backlog. Whatever the source, it lands on one hub, the lead agent. The lead does not write the code. It checks the intent, routes the work to the specialist that owns the files, and closes the request.

Only two arrows come back to me. One is a question: the intent is unclear, or a task reached a real choice of direction. The other is a report: a check stayed red and the task stopped. Everything on the solid path runs alone. The rest of this post walks that path step by step, from the cheapest decision to the most detailed machinery.

Step 1: the intent gate

The first place autonomy breaks is the start. Most of my bad runs were not bad code. They were good code for a request I had not actually made: the agent had silently filled a gap in my prompt with the most conventional answer.

The fix is a skill called interview-me, vendored from Addy Osmani’s agent-skills. The lead runs it before it plans, delegates or edits anything. Step one: write your best read of the request in one sentence, with an honest confidence number. As the skill puts it, “The number forces honesty.”

My rule on top is a threshold. At 80% or more, the agent states its one-line read and goes. A precise ask costs one line. Below 80%, it stops executing and starts challenging me, in a strict form:

• One question per message, each with a guess. The format is Q: plus GUESS:, its best answer and why. The guess becomes the recommended option, so I usually answer with one click. Reacting to a wrong guess is much faster than writing an answer from nothing.
• A six-line restatement: Outcome, User, Why now, Success, Constraint, Out of scope. The skill is firm that “Including ‘Out of scope’ is non-negotiable.”
• An explicit yes. “Sounds good” is not a yes, and neither is “whatever you think”.

The vendored skill itself aims for about 95% before it stops interviewing. I keep both numbers: 80% decides whether the interview starts, and the skill’s test, “can I predict the user’s reaction to the next three questions?”, decides when it ends.

That six-line block is my intent.md. The skill offers to save it to docs/intent/<topic>.md, which I do only when the work spans sessions. Most of the time it travels another way: every brief the lead sends to a specialist opens with it. Specialists never interview me; when something is unclear they change nothing and hand back their questions as Q: plus GUESS:, and the lead asks me one per message.

It is the artifact Anthropic’s AI-native SDLC playbook puts at the start of its loop: intent “captured once, in the originator’s own words, as a version-controlled artifact the next stage can act on.” The confidence gate just decides when that needs a conversation and when one line will do.

What the interview aims for: a prompt Anthropic would recognize

The interview’s real job is to turn my prompt into one that follows Anthropic’s own advice. That advice is short:

• Clear and direct. “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.” (Prompting best practices)
• Context and motivation. “Providing context or motivation behind your instructions […] can give Claude more information about your goals and help it deliver more targeted responses.”
• Specific scope. “Claude can infer intent, but it can’t read your mind. Reference specific files, mention constraints, and point to example patterns.” (Claude Code best practices)
• A way to verify. “Give Claude a check it can run: tests, a build, a screenshot to compare.”
• Out of scope, stated. “The most useful specs are self-contained: they name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step that proves the feature works.”
• Examples, “one of the most reliable ways to steer Claude’s output format, tone, and structure.”
• Only what matters: “the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome” (Effective context engineering for AI agents).

The best practices even suggest the move I automated: “For larger features, have Claude interview you first.” Side by side, the six lines are that checklist:

The interview does not replace a good prompt. It is what happens when mine is not one.

Step 2: brainstorm only when the work needs a design

The repository also uses Superpowers, and its superpowers:brainstorming skill is genuinely good: one question at a time, two or three real alternatives with a recommendation, the design played back in chunks, a design document, and “Nothing gets built until your human partner approves the design doc.”

In my experience it is also the most expensive thing an agent can do before writing a line of code: many turns, many tokens, and a lot of my time reading design for work that did not need any. The skill’s own description says “You MUST use this before any creative work”. My CLAUDE.md overrides that on purpose: brainstorming is not the default.

The order is fixed. The interview settles what and why; brainstorming designs how, and only when the request needs it: a new feature or module, a contract or cross-repository change, several valid approaches, a risky or hard-to-reverse impact. A precise fix or a bounded change gets one line saying the brainstorm is skipped, and the work.

Anthropic points the same way: “Plan mode is useful, but also adds overhead,” and “If you could describe the diff in one sentence, skip the plan.” “Building effective agents” (December 19, 2024) recommends “finding the simplest solution possible, and only increasing complexity when needed.”

Step 3: guardrails that let the agent merge alone

The end of the chain rests on one rule in CLAUDE.md: once a task’s direction is settled, the lead delivers it as one pull request and, “when every guardrail is green, merge the pull request without asking”. Then it checks the deploy the merge starts, and takes the next task.

That rule is only safe because “green” means something:

• Locally, before every push: lint, typecheck, the tests the change touches, and a script that validates the AI configuration.
• In CI, on self-hosted runners: a job that cancels the run if the commit is already in main, one that detects whether code changed, a commit-message check with cocogitto, and a test job with lint, typecheck and a mandatory test subset kept under one minute. The full suite, about ten minutes, runs by hand.
• At merge time: “two branches green on their own can still break each other”, so when main has moved the agent merges it in, pushes and waits for the new run. A red production deploy is fixed at once, in a new pull request.
• A test floor, 6,651 tests in 628 files today, that no pull request may lower unless the tests go with deleted code.

Two limits keep it honest. At most three fix-and-push cycles per pull request; after the third, the task stops and reports what fails. “Building effective agents” says it plainly: “it’s also common to include stopping conditions (such as a maximum number of iterations) to maintain control.” And autonomy covers delivery, never direction: an architecture, a UX choice, the scope, a contract, a new dependency all come back to me, while unrelated tasks keep going. Some merges always wait for a human too: a check red or missing, an open review finding, a backend change not yet deployed, a manual step, anything irreversible.

Some guardrails sit on the agent’s own context. A PostToolUse hook runs after every edit and pushes back (exit code 2, which sends the reason to Claude so it corrects itself) when an edit writes dates, PR numbers or “next steps” into CLAUDE.md or an agent file. Product rules are backed by tests, not prose: every deletion needs the object’s reference typed into one shared dialog, and each new delete feature ships with a test proving it.

This is Anthropic’s guidance applied to the merge button. The Claude Code best practices: “Give Claude a check it can run […] It’s the difference between a session you watch and one you walk away from.” And: “Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens.” The playbook says the same at the governance level: “A skill is an advisory control while a hook is the deterministic layer behind it.”

Here is the whole loop, with every check on the way.

Practices I would keep

1. Make “done” machine-checkable first. Without lint, types and tests, autonomy just postpones the review.
2. Keep the gating check fast. A one-minute subset runs on every push; a ten-minute suite gets skipped.
3. Let CI decide the merge, not the model, and cap the retries at three.
4. Separate delivery from direction. Write down which choices the agent may settle and which come back to you.
5. Gate the intent with a number. Imperfect, but visible, and a visible number can be challenged.
6. Reserve heavy design for heavy work. Interview first; brainstorm only when there are several valid designs.
7. Put non-negotiables in hooks and tests, not prose, and guard the context files too.

What this does not solve

A confidence number is self-reported, and a model can be confidently wrong, so 80% is a trigger for a conversation, not a measure of truth. Green CI only proves what the tests check. That is why direction always comes back to me. But the trade has been worth it: my time now goes to a few questions when the intent is unclear, a decision at a real fork, and very little in between.

References

• Anthropic, The AI-native SDLC playbook, August 21, 2026.
• Anthropic, Building effective agents, December 19, 2024.
• Anthropic, Effective context engineering for AI agents, September 29, 2025.
• Claude Code docs, Best practices for Claude Code (the former anthropic.com/engineering/claude-code-best-practices article now redirects here), consulted October 24, 2026.
• Claude docs, Prompting best practices, sections “Be clear and direct”, “Add context to improve performance” and “Use examples effectively”, consulted October 24, 2026.
• Claude Code docs, Automate actions with hooks and Subagents, consulted October 24, 2026.
• Addy Osmani, agent-skills: interview-me (MIT).
• Jesse Vincent, Superpowers, brainstorming skill.
• My previous post, Anthropic’s AI-Native SDLC Explained.