Part 3: The intake gate - Making entry surfaces converge
The last article argued for a rule: when the prompt and the status disagree, the status wins and the agent stops. That's the principle. This one is about the mechanism — because a principle only holds if it can be enforced on every path an agent can be reached on, and Jira offers several paths.
All of them can be triggered with no instructions at all.
The surface problem, enumerated
There are, in current Jira, at least six ways an item can end up in front of an agent:
-
A transition action — the agent runs when the item moves into a configured status. Configurable from the workflow editor or the board column menu; these are two windows onto the same setting, not two features.
-
A direct assignment — the agent is added as the item's assignee.
-
An "@mention" in a comment — the agent is pinged by name.
-
The Agents panel's "Start work" button — a human opens the side panel and hits the button.
-
A Jira automation flow — a rule invokes the agent on an issue event, schedule, or field change.
-
A CLI or IDE invocation — the agent is asked, from outside Jira, to work on a named item.
Every path is a way of supplying context
What separates these paths isn't who triggers them or where they live in the UI. It's how each one lets you hand the agent its context — and part of that context is the repository. Jira cannot start a coding agent without knowing which repository it's meant to work in, so every path has to answer that question somewhere.
Some let you answer it up front. The transition action has a prompt field: put the repository URL at the top of it and the invocation carries everything it needs. An "@mention" works the same way, with the comment body serving as the prompt. An automation rule's action prompt does too. In each case the context is written up front, and the run proceeds without interruption.
The rest defer it. Direct assignment has no prompt field at all, so there's nowhere to write a repository. "Start work" offers no opportunity to supply anything either. Both open the agent panel, which presents a repository selector alongside an optional context box — prefilled, in some cases, from the item itself.
And the panel isn't only the destination for those two. Any invocation that leaves the repository unresolved ends up there: a transition action without a URL, a bare "@mention" with nothing but the agent's name. Most paths, most of the time, lead back to the same panel. What differs is whether you arrive there because the surface gave you no other option, or because you didn't use the one it offered
The CLI or IDE route is the exception. The repository is ambient — you're already working in it — so there is nothing to supply and no panel to return to.
None of this is checked against where the item actually sits in the workflow.
Nothing about the workflow travels with the item
Whichever path you take, the same thing is missing at the other end.
When the handoff happens, the agent receives the item and whatever context the invoker supplied. It does not receive the item's status, what that status means in your process, or what is supposed to have happened before work begins. An item in Awaiting Refinement arrives looking exactly like one in Awaiting Development. The agent has no way to tell the difference, and no reason to ask.
That gap is the same across every surface. And each path offers only a brief, optional window in which it could have been closed: the prompt on a transition action, the body of an "@mention", an automation rule's action prompt, the context box in the agent panel. All free text that someone has to remember to fill in correctly, every time.
Consider an item that is nowhere near ready for development. It can still reach a coding agent in a single action:
-
Sitting in Awaiting Refinement, it can be assigned to a development agent by anyone with Assign Issues — a permission granted far more broadly than people assume.
-
Sitting in In Readiness Evaluation, it can be @mentioned to an agent by anyone with Add Comments, and if that comment carries a repository URL, the run proceeds with no further input.
-
Sitting in Backlog, it shows the agent panel to anyone who can view it, with "Start work" and agent assignment available directly from there.
None of these transition the item, so nothing in the workflow reacts — no validator, no condition, no post-function. The board is unchanged. But the handoff has happened, and the agent is now working on something the process considers unready.
Closing that gap surface by surface means writing the same workflow-aware context six times and hoping it is applied consistently. It will not be, because the surfaces have different authors, different permissions and different fields.
Two concrete cases from the previous article make the point. CLIGUI-45 and CLIGUI-40 were both work items where a coding agent wrote code against a status that said no code should be written yet. In neither case was there a working intake gate to stop it. The two arrived by different routes — one through a board transition, the other through direct assignment — but ended up in the same place, because neither route carried anything about where the item sat in the workflow. Hand an item to a coding agent and it codes. That is the default, and without an intake gate there is nothing to say otherwise.
The intake gate
The intake gate is the fix, and it's a small idea. Before doing any of the phase-specific work an agent might be capable of — refinement, readiness evaluation, implementation, code review — the agent runs the same short preflight, in the same order, on every invocation.
It reads the item's current status. It compares the status against what it was asked to do. If they agree, it dispatches to the phase-specific skill and proceeds. If they don't, it says so out loud and stops.
That's the whole gate.
Everything below is different ways to make sure it actually runs — because a preface you hope the agent will consult first isn't a gate at all.
The doorman and the specialists
The doorman is not a refinement specialist or a review specialist. He doesn't know how to write acceptance criteria or audit a PR. His job is exactly one thing: decide what kind of work is legitimate on this item right now, and hand the visitor to the right specialist — or send them home.
There are two good reasons to keep the doorman completely separate from the specialists he directs.
The first is that the doorman has to act before the agent knows which specialist it needs. If the doorman's checks were folded into the refinement specialist, an invocation that arrived via a comment saying "please implement this" would never reach them — the agent, hearing "implement", would go straight to the development specialist instead, and the doorman's checks would never run. The doorman has to be the one the agent always consults, regardless of what the prompt sounded like.
A doorman who starts learning the specialists' jobs loses the plot fast. The doorman's whole value is that he's consistent, unhurried, and identical every time someone walks through the door. Every specialist concern you push onto him makes it harder for the agent to run reliably on the paths that don't carry instructions. The doorman should have one job, a short brief, and no exceptions.
In this project it's .claude/skills/jira-work-intake. It sits alongside the specialists — jira-refinement, definition-of-ready, jira-development, jira-review — but it's not one of them. It's the doorman.
Two-part evidence: structure plus substance
The gate can't just check the current status and declare the path was walked. A status of Awaiting Development by itself doesn't tell you whether readiness actually ran or whether someone simply moved the item forward without it. The gate has to be a little stricter than that.
Call this principle P4, from the workflow design doc:
P4. Evidence is two-part. Structural: the changelog shows the expected transition. Substantive: a marker comment posted after the most recent claim.
Both parts have to be present or the gate refuses to advance. Structural evidence alone — Awaiting Development with the right changelog trail — proves the path was walked. It doesn't prove the work happened. That's what marker comments are for (article 7 goes into their grammar properly): each phase leaves a Refinement: SHAPED, Readiness: READY, Development: COMPLETE or Review: APPROVED comment as substantive evidence that the phase actually produced its output — one of a closed set, not free text. The gate reads both.
Concretely, the intake check for an item arriving in development looks like this:
The item is in Awaiting Development. Its changelog shows the transition Handoff for development was fired from In Readiness Evaluation. A Readiness: READY marker comment exists, posted after the most recent claim into In Readiness Evaluation. This item is legitimately available for development work. Proceeding.
Or, in the CLIGUI-45 shape:
The item is in In Readiness Evaluation. The invocation asks for implementation. From this status the legitimate work is readiness evaluation, not development. No Readiness: READY marker exists, and even if it did, it would not authorise implementation from this status. Not taking action.
The gate isn't cleverer than that. It doesn't need to be. Two things checked — the status and the marker — catch the whole class of failure the previous article was about.
Evidence before state
There's a related principle worth naming, because it's the difference between a marker comment being useful and being a formality. Call it P5:
P5. Post the marker, then transition. Otherwise a reader between the two sees a state change with nothing backing it.
The order matters. If the readiness reviewer transitions the item to Awaiting Development and then posts the Readiness: READY comment, there is a window — however short — in which a development agent could read the item, see Awaiting Development, look for the marker, not find one, and refuse. That's the worst case: a correct gate producing a wrong answer because the evidence hadn't landed yet. Post the marker first and the window closes: either the marker is there and the transition has fired, or the marker is there and the transition is about to, or neither is there and the item is unambiguously not ready.
P5 is one of those workflow rules that sounds pedantic until it isn't. It costs nothing to follow, and it removes an entire class of "the item was in a legitimate state but the evidence wasn't visible yet" race. Adopt it.
What the gate looks like when it catches something
The gate's whole job is to be visible when it fires. A silent refusal is worse than a wrong action, because nobody knows whether to intervene. The gate's output, on a mismatch, should be a short comment on the item that names three things:
-
What status the item is in.
-
What work the status permits.
-
What the invocation asked for, and why it's not that.
Something like this, posted straight to the ticket:
Three properties of that response are worth being deliberate about. It doesn't apologise — apology reads as the agent might come around. It doesn't offer alternatives — the agent's job is to enforce the workflow, not to route around it. And it names the workflow as the thing that made the decision, not the agent — because if the reader wants to argue with it, they need to argue with the workflow.
The gate doesn't enforce itself
The gate's reliability is only as strong as the session configuration behind it — which means it lives or dies on what's in the agent's persistent instructions, or its CLAUDE.md / AGENTS.md equivalent. Write it in there, and make it the first thing loaded.
In this project that rule is a single line:
Load these; do not improvise.
Followed by a short list of the skills the agent must consult, and a stronger rule for the one that matters most:
If you cannot read jira-work-intake, stop and say so. Do not proceed from the prompt alone.
Two things about that pair are worth flagging. First, the "cannot read" clause isn't theoretical. Skills load conditionally; sometimes they don't. An agent that can't read the gate is an agent flying blind, and the right answer is to refuse rather than to guess. Second, "do not improvise" is doing a lot of work. A well-trained agent handed a rich prompt will always want to be helpful. The instruction is to prefer being useless-and-safe to being helpful-and-wrong.
One precondition, easy to miss: an agent can only enforce this if it can see the item. The gate has to read a status, read a changelog, find a marker comment and post one. So treat Jira tool access as a requirement for any agent you let near a work item, not a nice-to-have. An agent without it cannot run the gate at all — and the honest response to that is to fix the configuration, or keep the agent away from Jira, not to hope the instructions make up the difference.
You can't make the platform enforce this. You can make your agents good enough that they enforce it on themselves.
What the gate doesn't do
Two things it doesn't do, worth spelling out, because both are tempting.
It doesn't rewrite the item. The gate is a router, not an author. If the item is in Awaiting Refinement and the invocation asks for implementation, the gate refuses; it does not helpfully draft acceptance criteria on its way out. Drafting acceptance criteria is the refinement skill's job, and the refinement skill runs only when its own claim transition fires. Mixing those responsibilities produces exactly the CLIGUI-40 shape — an agent that "kindly" started work while it was writing the spec that authorises it.
It doesn't move the item to a status where the work would be legitimate. This is the subtler temptation. An item in Awaiting Refinement handed to a development agent could, in principle, be transitioned by that agent through refinement and readiness and out into Awaiting Development, and then implementation could begin. That would be catastrophic: the agent would be authoring the spec, auditing its own authoring, and building against what it wrote. Every principle in this series is designed to prevent that. The gate's answer to "the item isn't in a status where I can do the requested work" is not to take action — not to make the item into one where the requested work is legal.
Both temptations look like helpfulness. Both are exactly the class of failure the workflow exists to catch. The gate's whole value is that it doesn't succumb to them.
Try this before the next article
Open your team's AGENTS.md, your Copilot instructions, or your CLAUDE.md project prompt — whatever you use as the persistent instructions your coding agents load on every invocation. Somewhere near the top, add a single sentence that says, in your own words:
Before acting on anything, read the current status of the Jira item this invocation refers to. If the request and the status disagree, side with the status, say so, and stop.
That's the seed of an intake gate. It won't catch everything — a proper gate reads marker comments and dispatches to phase-specific skills, which article 4 is about — but this one sentence, sitting at the top of the instructions every invocation loads, will catch most cases where an agent acts before the item is ready for that work.
The rest of the series builds outward from there.
Next: Skills as load-bearing SDLC roles. How analyst, reviewer, developer and auditor stop being cultural labels and become discrete skill files with their own authority and exit conditions — and why "the role is what the agent puts on, not who the agent is".
A note on how this was made
Every idea in my writing comes from real work — built, broken, and figured out before a single word is written. The writing is documentation, not speculation. I start with voice dictation: a raw thought dump of ideas, objectives, and what I've actually been working on. From there, I collaborate with AI to shape that into something readable — structuring drafts and editing through a custom Rovo agent, configured with carefully curated instructions to review and refine work against my preferences, personality, and style. Artwork is a separate creative process — concepts originate from my own ideas and are brought to life using a combination of Google Gemini, ChatGPT, and Photoshop. The ideas, the experience, the creative direction — those are mine. AI is how I move fast and bring them to life.
Before anything is published, every claim and every idea goes through multiple review cycles to make sure it accurately reflects the thoughts and experience I originally set out to convey. If something reads well, that's the process working. If something doesn't, that's on me.
Was this helpful?
Thanks!
Ben Spillane
1 comment