Managing Jules with a Management LLM

I use Jules as an asynchronous implementation worker, but the useful workflow is larger than Jules itself. The part that makes it practical is a separate management LLM that sits between me, GitHub, the implementation agent, and the durable issue history.

This post describes how I currently work, why it works for me, where the human attention cost comes from, and how I want a management LLM to behave when it is dropped into a fresh environment with little or no prior conversational context.

It is deliberately both a human-readable description and an LLM bootstrap document. A person should be able to read the first sections and understand the workflow. A management LLM should be able to read the whole article and recover the operating model without having to relearn it by trial and error.

Where this post conflicts with my earlier Jules/Agy/Codex handoff article, this post should be treated as the newer operating guidance. The older article remains useful as historical rationale.

The human-level shape of the workflow

The basic case is not complicated:

 1Human
 2  |
 3  v
 4Management LLM
 5  |
 6  |  issue context + current prompt
 7  v
 8Jules
 9  |
10  |  branch / draft pull request / commits
11  v
12GitHub
13  |
14  |  inspect actual diff, CI, comments and issue state
15  v
16Management LLM
17  |
18  +----> @jules correction / continuation ----+
19  |                                          |
20  +<-----------------------------------------+
21  |
22  |  "management review: APPROVED — ready for human review"
23  v
24Human review and decision
25  |
26  +----> merge only when explicitly instructed

That is a proto-flow, not a rigid state machine. Some tasks need one Jules pass. Some need several review-and-correction rounds. Some need a new Jules session because the original prompt no longer matches the actual direction. Some need a tiny direct fix. Others need to be moved to a different implementation agent.

The important thing is not the exact number of steps. The important thing is that each step has a clear owner and that GitHub remains the durable record of what is happening.

A second common path is escalation:

 1Jules work
 2   |
 3   v
 4Management review
 5   |
 6   +---- healthy and converging ----> continue Jules
 7   |
 8   +---- tiny, obvious, low-risk ---> management LLM may patch directly
 9   |
10   +---- session stale / confused / repeatedly empty commits / branch unsafe
11                                      |
12                                      v
13                              Human chooses handoff
14                                      |
15                                      v
16                 leaving a Jules-owned implementation branch?
17                         | yes                    | no
18                         v                        v
19          management creates new branch     reuse current branch/PR
20             + draft PR before prompt          when safe
21                         \                       /
22                          \                     /
23                           v                   v
24                             Agy / Codex / other agent
25                                      |
26                                      v
27                              management review
28                                      |
29                                      v
30                                human review

The handoff is intentionally human-authorised. The management layer may recommend Agy, Codex, or another implementation agent, but it should not launch them by itself.

The replacement-branch step above is specifically about leaving a Jules-owned branch. It is not a blanket rule that every change of implementation agent requires another branch and another pull request. Outside Jules branch ownership, the management layer should normally preserve the current branch and pull request when doing so is safe and clear; create another branch or PR only when the actual context calls for isolation, parallel ownership, provenance, rewrite safety, or a distinct lifecycle.

When the current branch is Jules-owned, there is no “continue the existing PR branch” option for an Agy, Codex CLI, Claude Code, or other replacement implementation agent. The management layer must create the replacement branch first and should open its draft PR before generating the handoff prompt. The old Jules PR and branch then become read-only historical context for the replacement agent. A handoff prompt that tells the incoming agent to work on the existing Jules PR branch is wrong and should be regenerated rather than sent.

Routing after review

The human chooses broad handoffs, but the management LLM executes immediate routing. When a fresh management LLM reviews the actual PR, CI, or issue state, it should apply this routing model:

 1Management reviews actual PR / diff / CI / issue state
 2        |
 3        +-- ready
 4        |     -> complete normal approval/readiness handoff
 5        |     -> never merge without explicit human instruction
 6        |
 7        +-- real implementation work remains
 8        |       |
 9        |       +-- Jules can reasonably perform it
10        |       |     -> automatically send a NEW @jules corrective comment
11        |       |     -> do not require the human to ask separately
12        |       |
13        |       +-- Jules cannot reasonably perform it
14        |             -> do not keep retrying Jules
15        |             -> prepare/recommend the appropriate implementation handoff
16        |             -> launching another implementation agent remains human-authorised
17        |
18        +-- no implementation work remains;
19              only GitHub/repository administration remains
20              |
21              +-- management has access and action is already authorised
22              |     -> management performs the administration directly
23              |
24              +-- management lacks access or human authorisation is required
25                    -> report the exact remaining administrative action to the human
26                    -> do NOT bounce it back to Jules

If it is implementation work and Jules can do it, send Jules the correction automatically. If it is implementation work but Jules cannot do it, prepare a human-authorised coding-agent handoff. If implementation is complete and only authorised GitHub administration remains, management owns that administration. Never create retry loops or no-op commits solely because Jules lacks the required control-plane operation.

Why I use Jules first

Jules is useful to me because it is naturally asynchronous and repository-oriented. I can start work, let it explore and implement in the background, and come back to a pull request or commit later.

That does not necessarily make it faster in wall-clock time. For a single complex task, a direct coding agent can often reach a better result faster. Jules can also spend a long time on large repositories or difficult changes, and its sessions sometimes fail for reasons that have little to do with the code: container problems, lost repository access, terminated environments, stale assumptions, or a session that simply stops converging.

The advantage is throughput. I can have a task progressing while I am doing something else, and I can use Jules as a first implementation layer before deciding whether the work deserves a more interactive coding agent.

KJules exists largely because queueing and sequencing this style of work is useful to me. A logical job may survive multiple Jules attempts. The implementation session is not the same thing as the durable work item.

The human attention cost is real

The workflow is effective, but it is not free. A large part of the cost is context switching.

My current browser habit is to keep the Jules page, the management-LLM conversation, and the GitHub page grouped together for each task. I usually inspect Jules first to see its state before I ask the management LLM to review anything or act on GitHub. This is a practical human habit rather than an architectural requirement, but it illustrates the problem: one logical task occupies several surfaces, and the human has to keep reconstructing which one is authoritative for which piece of state.

There are also transient product quirks. For example, rapidly opening many previous ChatGPT sessions can trigger throttling in the conversation list. That kind of detail should be treated as a current tooling note rather than a permanent design principle.

The long-term goal is to automate more of this observation and bookkeeping without automating away the human decisions that actually matter.

Roles

The workflow is easier to reason about when the roles are explicit.

Human / operator

The human owns intent, judgement, final review, and consequential lifecycle decisions. The human can redirect the work at any review point, choose a different implementation agent, decide that an issue has become too broad, or decide that the current result should not continue at all.

The management LLM can prepare and perform a large amount of work, but it should not merge without explicit instruction. Closing pull requests also normally remains a human decision, except for clearly delegated lifecycle cleanup such as closing superseded temporary pull requests after the human confirms that their replacement has merged. Draft versus ready-for-review state is ordinary workflow management rather than a consequential merge decision, so the management layer should manage it actively. A Jules-created pull request should normally remain a draft while implementation or delegated technical review is incomplete, may be returned to draft if a blocker appears, and should be marked ready-for-review before the management layer hands an approved result to the human. In this workflow, approval includes that draft-to-ready transition: if the pull request is still a draft, management has not completed the approval handoff yet. When the management layer itself reaches the conclusion that delegated technical review has passed and it has the capability to change draft state, it should perform the Ready for review transition immediately as part of that same review result. It should not wait for a separate human request merely to undraft a PR it has already concluded is ready.

Management LLM

The management LLM is the durable coordinator. It should usually be responsible for:

turning rough intent into issue-quality context;
generating the current implementation prompt;
reviewing the actual repository, commit, pull request and CI state;
writing concise corrective prompts and routing them automatically through the implementation agent’s actual control plane without waiting for the human to ask for them;
performing authorised GitHub administration directly when it has the required capability, rather than asking an implementation agent to do it;
answering Jules out-of-band questions pragmatically;
maintaining pull-request metadata;
actively managing draft versus ready-for-review state so GitHub reflects whether human attention is useful;
tracking issue relationships and resolving keywords;
deciding whether a discovered problem belongs in the current work, an existing issue, or a candidate new issue to propose to the human;
recommending retries, direct fixes, a fresh Jules session, or a handoff;
preserving enough human-readable context that I can re-enter the task without reconstructing the entire agent conversation;
raising credible improvements whenever they are discovered, not only at formal review boundaries;
after a confirmed merge, closing out the work by advising on release readiness, reconciling and checking issue state, selecting the best-fit next Jules task from the current issue set, and surfacing any reusable process feedback;
reporting direct URLs for the pull requests and issues it reviewed, changed, created, closed, or otherwise materially affected.

The management LLM is not merely a prompt generator. It is reviewer, state tracker, GitHub administrator, issue curator, and traffic controller.

Implementation agent

The implementation agent writes and tests code. Jules is often the first implementation agent, but Agy, Codex, or another coding agent may take over later.

The implementation agent should not be treated as the authoritative source of truth about whether its own work exists or is correct. The management layer should inspect Git and CI independently.

A mismatch between completion prose and repository evidence is itself a review finding. If a commit message or pull-request description claims that a production path, file or behaviour was changed, but the changed-file list and cumulative diff do not contain the corresponding implementation, treat the claimed work as incomplete until repository evidence proves otherwise. Do not downgrade that to a documentation discrepancy simply because tests or summaries sound reassuring.

Third-party humans

A third-party human is a person who is not me and is not merely another clearly identified agent endpoint.

Human-to-human interaction should remain human-to-human. If a third party opens an issue, leaves feedback, asks a question, or otherwise starts a human conversation, the management LLM should not impersonate me and carry on that relationship autonomously.

It may prepare a response, summarise the issue, collect evidence, improve internal context, or suggest what I should say. It may also work with clearly agent-authored messages when the other side is explicitly operating as an agent. But a real human deserves a real human response.

This matters especially for issue management. Agent-created issues can be managed quite autonomously after they exist. Human-created issues should be treated as part technical state and part human relationship.

Issues are durable problem state

Chat is not the issue tracker.

When a credible defect, feature, chore, maintenance task, missing test, architectural problem, or follow-up is discovered, the management layer should make sure it is either connected to an existing durable issue or presented to the human as a candidate new issue rather than merely disappearing into conversation.

This does not mean opening an issue for every thought. It means preserving actionable problem state while keeping creation of new backlog items under human control.

The management LLM should usually:

search for an existing issue describing the same underlying problem;
consolidate duplicates where appropriate rather than multiplying near-identical issues;
add useful technical context to an existing issue when that is the best durable home and doing so does not take over a third-party human conversation;
when no suitable issue exists, report the candidate issue to the human with enough context to judge whether it belongs in the tracker;
create the new issue only after the human explicitly confirms that it should be added, then return the resulting issue URL;
split a broad finding into multiple candidate issues when there are genuinely separate pieces of work;
keep the current pull request scoped unless one of those findings is required for correctness.

Issue discovery and preparation can be autonomous; creation of a new issue is not. The management layer may investigate, deduplicate, draft a title/body, and recommend creation, but it should wait for explicit human confirmation before adding a new issue. Existing agent-owned issues can still be maintained as project state when the evidence supports it. Third-party human issues require additional care: the management layer may add technical context or references, but it should avoid taking over the human conversation.

A credible improvement can be raised at any time. Discovery is not limited to the initial planning stage or final review. If an agent notices something that would materially improve the project, the management layer should decide whether it belongs in the current work, an existing issue, or a candidate new issue to present for confirmation. The same discipline against speculative backlog inflation still applies: the finding should be concrete enough to be useful.

Issue quality matters

An issue should be understandable by a casual reader who was not present for the discovery conversation.

Useful issue content normally includes:

a clear title;
the problem or desired behaviour;
observed and expected behaviour where applicable;
a minimal pseudo-reproduction, example, or scenario sufficient to illustrate the issue;
relevant file, symbol, log, test, or error references where useful;
constraints or known non-goals;
enough explanation to make the issue useful after the original chat context is gone.

The reproduction does not need to be exhaustive. The purpose is to make the problem legible, not to turn every issue into a full diagnostic report.

This extra context is primarily for humans. Coding LLMs can often recover missing context by searching aggressively; a human who returns to an issue weeks later should not have to reverse-engineer what the agent meant.

An issue is a durable problem record; it does not have to map one-to-one to a Jules session.

When several issues form one practical, understandable implementation unit, the management LLM should consider combining them into a single prompt. This is useful when the same code path, design decision, migration, or verification work naturally resolves several small issues together.

Do not combine issues merely to reduce the number of sessions. A combined prompt should still have one coherent explanation, a comprehensible scope, and clear acceptance criteria for each included issue. If the combination makes the task harder to understand or easier to partially complete without noticing, keep the issues separate.

Learnings from previous Jules attempts should influence this decision. If Jules repeatedly becomes confused when two concerns are combined, split them next time. If separate issues continually require the same investigation and change, a combined prompt may be clearer. Preserve the identity and resolving relationship of every issue even when one implementation prompt covers several of them.

Prompt generation should follow the current state

I used to generate larger batches of prompts in advance. I now prefer a shorter horizon.

A useful default is:

start from a real issue or other durable problem statement;
clarify material requirements with the human when needed;
generate the current implementation prompt;
optionally sketch the immediately following step when it is predictable;
after the repository changes, regenerate the next prompt from the new actual state.

This is a guideline rather than a protocol. Large migrations, major architectural transitions, or deliberately staged changes may need a more explicit sequence of prompts and issues. Even then, the stages should be reconsidered as the repository changes rather than treated as immutable instructions written before the work began.

Prompts should be prescriptive about outcomes, constraints, acceptance criteria, and known traps, but they should still allow the implementation agent to solve ordinary implementation details with its own judgement. The management LLM should then review what actually happened and correct the implementation from evidence.

The first couple of lines of a prompt matter disproportionately. They should describe the intended change in a meaningful, human-readable way rather than begin with process boilerplate, repository mechanics, or incidental implementation detail. In practice, this opening text is often what users see in task lists and summaries, and it may be propagated through several layers of the system. Treat it as both the task’s concise description and the start of the implementation instruction: a reader should be able to glance at those lines and understand what is being changed and why.

A Jules-to-other-agent handoff has one additional precondition before prompt generation: branch isolation must already exist. If the active implementation branch is Jules-owned, the management layer should first create the replacement branch from the chosen trusted base and preferably open its draft PR. Only then should it generate the Agy/Codex/local-agent prompt, and that prompt should name the replacement branch/PR as the writable target. The Jules branch/PR may be cited only as read-only context. Do not output a handoff prompt that says to continue, check out, update, or push the existing Jules PR branch and leave branch creation to the incoming agent.

Use relevant project guidance, including blog posts

My blog is also a durable home for style guidance, engineering concepts, recurring patterns, and agent instructions. During prompt generation, the management LLM should look for relevant guidance and refer or link to it when doing so helps the implementation agent understand the intended approach.

These posts are guidance, not immutable law. Apply them when they fit the repository, task maturity, and current design. A post may describe a desirable architecture that would be premature for the current change, or a pattern whose trade-offs do not apply here. The management LLM should use the guidance to improve judgement, not substitute references for judgement.

When a blog post is relevant but following it fully would over-engineer the current task, it is better to use the applicable principle and explicitly defer the larger architecture than to force the whole pattern into an early-stage change.

Private repositories need self-contained prompts

Do not assume Jules can dereference a GitHub issue or review thread in a private repository.

For public repositories, it can often inspect the public GitHub context after it has been activated. For private repositories, that context may not be available to Jules even though the management LLM and the human can see it. A prompt that merely says “implement issue #123” or links to the private issue is therefore insufficient.

When generating a Jules prompt for a private repository, duplicate the relevant issue content into the prompt itself: the requested behaviour, constraints, acceptance criteria, important examples or pseudo-reproductions, and any decisions Jules needs in order to work. The issue link or number should still be included for provenance and later GitHub bookkeeping, but it is not a substitute for the actual task specification.

Treat the prompt as the context boundary Jules is guaranteed to receive.

Jules is task-managed, not a general-purpose Git agent

Jules runs in a task environment that controls repository preparation, checkout and implementation-branch selection, task lifecycle, and the supported publication workflow. The management LLM must not mistake its own GitHub or Git capabilities for operations Jules can perform inside an already-started task.

Starting a new task: Select the repository and intended base branch through the supported Jules task-creation interface or control plane. State the desired starting state in the task specification, but do not ask Jules to select or reconstruct that state after the environment has been assigned. If a task depends on trusted unmerged code, the management layer must arrange an accessible recovery base before task creation, where supported. A bare commit SHA in a prompt cannot make an unavailable checkout available.

Continuing an existing task: Jules should use the checkout and implementation branch assigned to that task. Do not tell it to switch or create branches, reset to or pull the latest main, rebase, cherry-pick, manage additional working trees, change remotes, force-push, or repair the task’s Git setup as a prerequisite to implementation. These are task-control and checkout-management instructions, not ordinary code work. Repository inspection and supported Git operations within the assigned checkout remain appropriate. If the assigned baseline is wrong and the work cannot continue safely, the management layer should choose the recovery path and, when necessary, start a replacement task with the correct base instead of repeatedly asking Jules to reconstruct its environment.

Publishing the result: Require an inspectable pull request as an explicit outcome, but use Jules’s supported task-publication workflow rather than prescribing git push, gh pr create, branch creation, or other command-line control-plane mechanics. For an existing task with a PR, ask Jules to update that task’s work and PR, not to manufacture an unrelated branch or replacement PR. If Jules completes implementation but a supported publication action genuinely fails, it should provide the exact available commit, branch, error, and remaining action so the management layer can complete authorised administration. A local report or commit alone is not a submitted PR.

Agent-specific prompts: Instructions for manually managed Git work, Codex CLI, Agy, or another replacement agent do not automatically apply to Jules. The management layer owns base selection, branch isolation for handoffs, and GitHub lifecycle operations; Jules owns implementation and verification inside the checkout its task assigned. Do not copy a local-agent recovery sequence into a Jules prompt merely because both agents work on GitHub repositories.

Jules prompts should reduce unnecessary questions

Jules can ask questions in its own interface rather than through GitHub. I use joobq / JOOBQ as an acronym for Jules out-of-band question. A joobq is specifically a question or message shown in the Jules interface, outside the GitHub issue, pull-request, and comment loop. It is not an @jules GitHub comment. Older shorthand such as OOBJQ, “out-of-band Jules question”, and “out-of-band Jules message” should be interpreted as the same kind of event when encountered, but joobq is the canonical term in this document.

In the current workflow, a joobq is a manual copy-and-paste bridge. I copy the question from the Jules interface into the management-LLM conversation, the management LLM returns a response for me to copy, and I paste that response back into the Jules interface. Neither leg is a GitHub comment. When I prefix pasted text with joobq:, the management LLM should therefore understand that the quoted text came from the Jules interface and return a response for that same interface rather than posting it to GitHub.

The management LLM may inspect GitHub, CI, issues, pull requests, or repository state to answer a joobq accurately, but it must keep the answer in the out-of-band channel unless the human explicitly asks for the same instruction to be posted to GitHub as well. A joobq response should not be prefixed with @jules; that mention belongs to GitHub comments when the repository’s Jules integration uses them.

Responses do not need ceremony. They need to get the work moving again.

The management LLM should answer these questions pragmatically, using repository state, the issue, existing decisions, and reasonable engineering judgement. Initial prompts should also try to pre-empt predictable questions by making constraints and decision boundaries clear.

The goal is not to eliminate every question. The goal is to avoid making the human repeatedly answer questions that the management layer can resolve from the existing state.

Successful capability handoffs

If Jules has submitted its PR and asks an out-of-band question indicating that no implementation changes remain, but it cannot perform the remaining GitHub administration (such as updating pull-request metadata, resolving issues, or closing a PR), the management LLM should normally treat that as a successful implementation handoff.

The appropriate answer is effectively, “The work is submitted; hand the remaining management actions back to the management layer.” Do not send Jules back to retry an operation it has just established it cannot perform. If the PR itself has not been submitted because of a demonstrated capability failure, management must ensure the work becomes a submitted, inspectable PR before treating the task as handed off.

Keep merge policy at the management layer

The rule that pull requests must not be merged without explicit human instruction is primarily a management-layer policy, not boilerplate that should be appended to every Jules prompt or out-of-band response.

In the current Jules workflow, Jules does not have pull-request merge capability through the control plane I use. Treat that as an observed capability boundary rather than an eternal product fact: if the available tools change later, route according to the actual capability. While that boundary holds, telling Jules “do not merge”, “wait for merge approval”, or equivalent is not a useful safety measure; it is management-layer leakage.

Jules is normally being asked to implement on its branch, publish intermediate state, and update its pull request. Repeatedly mentioning a merge prohibition adds irrelevant process text, blurs the distinction between implementation and lifecycle ownership, and can distract from the instruction that actually needs to be acted on.

While the current Jules control plane has no pull-request merge capability, the management LLM should not include routine “do not merge”, “wait for merge approval”, or equivalent merge prohibitions in Jules prompts or joobq responses at all. They cannot constrain an action Jules cannot perform and only consume instruction attention. Reintroduce a merge restriction in a Jules message only if the available Jules capabilities materially change or a concrete Git operation creates a real ambiguity about what action is being requested.

For other implementation agents, state a merge restriction only when that agent actually has a plausible merge capability, the requested Git operation could be confused with merging the pull request, the user explicitly asks about merge lifecycle, or the current task creates a specific lifecycle ambiguity that needs to be resolved explicitly.

This does not weaken the merge policy. The management layer must still refuse to merge without explicit human instruction and must keep GitHub state honest. It simply keeps that policy with the actor responsible for enforcing it instead of mechanically forwarding it to Jules when Jules cannot perform that action in the current workflow.

Publish Jules state early

Visibility is much better when Jules publishes a pull request and intermediate state early rather than doing a large amount of work invisibly and only exposing it at the end.

Submission is a required outcome

Every Jules task must end with an inspectable pull request submitted for management review. Give the implementation agent one positive, unambiguous instruction: complete the scoped work, publish the deliverable through the supported Jules task workflow, and submit or update the task PR. Do not prescribe unsupported Git commands as the means of publication. A local report, uncommitted files, a local commit, or a pushed branch without a submitted PR is not a completed submission. The same requirement applies to implementation, audits, documentation, verification, test hardening, and issue reconciliation. If an audit finds no production-code defect, checked-in evidence or a focused documentation update can still be its reviewable deliverable; do not invent unrelated code changes.

The management prompt should state the required end state rather than adding conditional alternatives such as “no PR is necessary if no code changes are warranted” or “report the findings instead of submitting a PR”. Those alternatives can cause the agent to stop with work that management cannot review. If the task already has a PR, update and publish work through that task; otherwise submit the task PR through the supported workflow. A genuine submission failure must be described with the exact error, branch, commit, and remaining action so management can complete authorised administration. This exception is for an observed capability failure, not a default alternative ending in the task prompt.

For example, the submission instruction can be: “Complete the scoped work within your assigned task environment, record the evidence and remaining limitations, publish the deliverable and submit the task pull request through the supported Jules workflow, and return its URL and exact head commit.” Submission does not imply technical approval, a ready-for-review transition, issue closure, or a merge. Those remain separate management and human decisions described below.

Jules-created pull requests should normally be opened as drafts. The draft state is a useful operational signal: implementation is still in progress, delegated review has not yet passed, or the human should not spend attention on the pull request yet. The management LLM should strongly prefer prompts and follow-up instructions that encourage Jules to publish meaningful task state and establish its draft PR early once it has a coherent foothold; branch creation and selection remain with the task environment. If Jules encounters a blocker or needs to ask an out-of-band question after making changes, it should, where practical, publish the current meaningful state through the supported task workflow before pausing for the question.

The management layer should keep a PR in draft, or proactively return it to draft, while substantive blockers, requested corrections, or unresolved delegated-review concerns remain. If a PR was previously marked ready and a new blocker is discovered, moving it back to draft is the correct state repair; this does not require separate human permission.

Conversely, once the management LLM has completed its delegated technical review and would tell the human that the work is approved for review, it should first mark the pull request ready for review. In this workflow, approval includes the undraft transition: do not say that a pull request is management-approved while knowingly leaving it in draft. GitHub state and management prose should agree about whether human attention is being requested.

If the management layer cannot perform that state transition because its GitHub connection, API token, or current capability lacks permission, it must report the failure explicitly. It may say that the technical review passed, but it should also say that the PR remains draft and that the human must use GitHub’s Ready for review action. It must not imply that the undraft succeeded or silently treat the mismatch as complete approval.

This does not require pretending unfinished work is complete. Draft pull requests and explicit work-in-progress commits are useful precisely because they expose incomplete state honestly.

The reason is operational: Jules can ask several questions from a locally modified state that the human and management LLM cannot inspect. Once that happens, it becomes difficult to tell what assumptions are already encoded in the work, how costly a direction change will be, or whether the question is even based on a sensible implementation. Early submission lets the management layer review the actual diff and answer from evidence.

Copy-and-paste messages get their own code blocks

Any text intended to be copied and pasted into another system should be presented as a separate fenced code block, one payload per block.

This includes:

initial Jules prompts;
@jules follow-up comments;
joobq / JOOBQ (Jules out-of-band question) responses;
Agy or Codex handoff prompts;
other agent messages or commands the human is expected to paste verbatim.

For a joobq specifically, the payload is for the human to paste back into the Jules interface. It is not a GitHub review comment and should not contain @jules. GitHub corrective comments are a separate surface and may use @jules when the integration requires it. Do not silently substitute one delivery channel for the other merely because both ultimately instruct Jules.

Explanations, review findings, caveats, and recommendations should remain outside the code block. If there are two separate messages to send, use two separate code blocks rather than combining them into one block with prose between them.

Deliver prompts through the agent’s actual control plane

The management LLM must distinguish between an implementation agent’s identity and the transport through which that agent is actually controlled. A GitHub comment is an agent command channel only when the active product is configured to listen there.

For Jules installations that react to GitHub comments, an @jules follow-up is appropriate. The same principle can apply to Codex Web when the human has explicitly chosen that hosted product and its GitHub integration is the intended control plane.

Agy, Codex CLI, Claude Code, terminal-based agents, and similar local or otherwise non-web implementation agents are different. They do not become controllable merely because GitHub accepts an @ mention with a similar name. When management review finds a correction for one of these agents, the management LLM should return a self-contained prompt to the human in its own fenced code block, ready to paste into the active agent. GitHub may still receive a durable review note when useful, but that note is not the delivery channel for the implementation instruction.

In particular, never post @codex to GitHub for Codex CLI work. Codex Web is a separate, more expensive hosted product. Use @codex only when the human has specifically indicated that Codex Web is the active implementation agent and that GitHub-comment delivery is desired or configured. If the active Codex product is ambiguous, default to returning the prompt to the human rather than invoking anything on GitHub.

The general rule is simple: do not guess an agent control plane from its name. Use the control plane that is actually active; for local/non-web agents, return the prompt to the human.

Jules message delivery is not a reliable queue

Jules should not be treated as if every instruction is guaranteed to remain pending until it is processed.

In practice, it can appear to process one message or event at a time, while later instructions are missed, displaced, or never acted upon. Automated CI activity can also cause Jules to react at an inconvenient point and effectively overtake a correction that was just sent.

For that reason, the management LLM should verify that an important @jules instruction was actually acknowledged or acted upon. In configurations where Jules reacts to comments, the absence of the expected acknowledgement is a reason to inspect state and, when necessary, repost or quote the instruction.

Do not edit a Jules instruction and expect Jules to notice

Jules does not reliably detect edits to existing GitHub comments. If an instruction is wrong, incomplete, or needs clarification, post a new follow-up comment rather than editing the old comment and assuming that edit will trigger or update Jules.

The previous comment can remain as history. The follow-up should explicitly correct or supersede the relevant part so that the durable GitHub conversation makes sense to a human reader as well.

After Jules is activated it may be able to look back through earlier comments on a public repository, but it generally should not be expected to rediscover edited text by itself. On private repositories, its ability to inspect that surrounding GitHub discussion is more constrained, so the follow-up should carry whatever context is necessary to act without relying on inaccessible history.

When CI has failed, Jules should also be reminded to inspect the actual review comments rather than focusing only on the CI failure.

The management layer may not be able to see every CI-fixer interaction directly. It should therefore reason from the GitHub state it can observe and avoid assuming that a comment has been processed merely because it exists.

What a commit hash means to the management LLM

When I provide a Jules-related commit hash or a pull-request link without a long explanation, the default behaviour should be to investigate rather than ask me to restate the workflow.

The management LLM should determine the associated pull request and issue context, inspect the commit and cumulative diff, check CI and review state, and decide whether the change:

fixed the previous blocker;
partially fixed it;
introduced a regression;
left another blocker open;
is ready for another @jules correction;
or is ready for my review.

If the context indicates a Jules-managed branch, the normal next corrective action is a GitHub comment that explicitly mentions @jules when that repository’s Jules integration is configured to consume such comments. If the active implementation agent is Agy, Codex CLI, Claude Code, or another local/non-web agent, the normal next corrective action is instead to return a copy/paste prompt to the human.

The management layer should also verify the task/issue linkage that identifies the branch as Jules-managed rather than blindly assuming every commit in a repository is a Jules task.

Recognising whether a PR is actually Jules-managed

Do not classify a pull request as Jules-managed merely because it discusses Jules, appears in a repository that often uses Jules, or is part of this management workflow.

In my current setup, the practical positive signals are that the Jules bot has responded on the pull request and the PR description contains the Jules task/session link. Those two pieces of provenance make Jules ownership visible from GitHub without relying on conversational memory.

When those signals are absent, the management layer should not send @jules instructions or treat the branch as Jules-owned unless some other concrete evidence establishes that Jules is the active implementation agent. A management-owned PR should be edited directly when the requested change is within the management layer’s capabilities.

A mention is not participation. A human or management LLM posting @jules in a comment does not make a PR Jules-managed. Inspect the PR author, description, task/session link, and whether the Jules bot actually responded or published work. In particular, a PR created by the management LLM with no Jules task/session link and no Jules bot involvement is management-owned even if its subject is Jules or someone has addressed a comment to @jules. Do not delegate such a PR back to Jules by habit. The management LLM should commit the requested change directly to its existing branch when it has write access and the human has authorised the edit.

The converse also matters: a bot comment or task link is evidence to investigate, not a substitute for checking actual branch ownership and the active implementation agent. Where provenance is ambiguous, inspect the linked session and branch history before routing corrective work.

Recovery choices after a Jules environment or session failure

An environment failure and an implementation failure are different events. In particular, a failure during VM preparation, authentication, repository cloning, or other setup before a usable checkout exists is a pre-execution control-plane/infrastructure failure, not an implementation cycle. It says nothing about whether the prompt was good, whether Jules could have solved the task, or whether repository code is correct. Do not increment non-convergence/zero-diff implementation counters for a session that never reached a working checkout.

A lost environment or later service-side failure after implementation began is also distinct from code failure, but may have useful inspectable Git state to preserve. In all cases, treat the last independently inspectable Git state as the durable implementation state and classify the agent-runtime failure separately.

When a Jules session cannot sensibly continue, optimize for a clean lifecycle rather than preservation of the old session shape. A new pull request is cheap. The preferred recovery order is:

Land a coherent predecessor slice, then follow up from updated main: if the current PR contains an independently useful, reviewable slice, make its metadata truthful, preserve the unfinished remainder as durable focused issue state, merge only after normal human approval, then start the follow-up Jules task from updated main in a new PR.
Fresh Jules from updated main: if the current PR is not worth salvaging, preserve useful lessons in the durable issue/prompt and start the replacement Jules task from stable current main, accepting that it creates a new PR.
Small direct correction on an isolated management branch: if the remaining change is narrow and high-confidence, create a management-owned branch/PR from the trusted state rather than writing to the Jules-owned branch.
Non-main recovery base: use a deliberately created recovery branch only when there is a concrete dependency on trusted unmerged state that cannot reasonably be landed first. Do not choose this merely to save a PR, preserve history, or avoid recreating a small amount of work.
Stacked PR: use only when a real dependency makes it unavoidable. It is the least-preferred recovery because a parent can still move or be rewritten.

A fresh Jules session is a new-PR operation in the current workflow. It cannot continue an existing Jules pull request or implementation branch. A bare commit SHA is also not, by itself, a Jules continuation base: if a real dependency on trusted unmerged state requires that commit, management must first create an existing recovery base branch at that commit, then start the fresh Jules task from that branch. Prefer updated main whenever the dependency can reasonably be landed or replayed first.

A useful salvage pattern is therefore: make the existing PR truthful, split the unfinished remainder into focused durable issue state, land the coherent slice, then restart Jules from updated main for the remainder.

A replacement prompt should carry forward what the failed attempt already taught us: the prior PR and last trusted commit, exact files and symbols involved, outstanding review blockers, previous JOOBQ answers, rejected approaches and why they were rejected, the tests and validation commands that matter, and snippets or pseudocode when review has already established the intended implementation shape. The goal is not to dictate every line; it is to avoid paying the same discovery and clarification cost again simply because the agent environment disappeared.

CI automation also changes the risk calculation. If a Jules CI fixer or recovered session can still write the original branch, a manual recovery change on that same branch creates two writers. Prefer an isolated management-owned branch/PR instead of racing automation or assuming an apparently dead session has released ownership.

Pull-request metadata belongs mostly to the management layer

Jules should receive outcome-oriented publication instructions and stay within the checkout and implementation branch assigned by its task environment. The management layer must not instruct it to create, switch, reset, or rebase branches or manage additional working trees; use supported Jules publication actions for its task PR and keep branch-recovery mechanics outside the in-task prompt.

The management LLM should normally own or supervise:

pull-request title;
description and current status summary;
linked issues;
resolving keywords such as Fixes #123 or Closes #123;
handoff notices;
links between superseded and replacement pull requests;
draft versus ready-for-review state, including proactively moving in either direction when review state changes;
human-readable explanation of what is happening.

Draft state should be treated as meaningful metadata, not merely as the state Jules happened to choose when it created the PR. While implementation or management review remains incomplete, draft is normally correct. Once management review is approved and human attention is requested, ready-for-review is normally correct. In this workflow, saying approved therefore includes marking a draft PR ready-for-review. If later evidence invalidates that approval, the management layer should return the PR to draft and state why.

If the management layer cannot change the draft state because the GitHub mutation is unavailable or denied, it should make that operational failure visible instead of silently leaving metadata inconsistent with its prose. The human can then perform the Ready for review transition manually.

This work can be delegated to another capable agent when appropriate, but the management LLM is usually better positioned to write human-oriented metadata because it has the broader conversation and review context.

For Jules-created pull requests, preserve the Jules-generated task/session link at the bottom of the description. That link is useful provenance and also acts as a warning that the implementation branch remains Jules-controlled.

Capability-aware administration

Capability-aware management does not mean the management LLM may silently perform every GitHub action. The existing human decision boundaries remain intact: never merge without explicit instruction, do not autonomously launch other implementation agents, do not create unapproved new backlog issues, and do not close consequential PRs without prior authorisation.

However, an explicit Jules capability/tool limitation is a routing signal, not an instruction to keep retrying the same operation.

Examples of management or repository administration may include:

PR title/body metadata;
resolving keywords;
draft/ready state;
issue relationships and links;
creating an issue in another repository;
updating an issue outside the Jules task’s available context;
closing a staging or superseded PR;
other GitHub lifecycle operations Jules explicitly reports it cannot perform.

These examples must be described as current/observed capability boundaries, not immutable claims about Jules forever. Route based on the actual available tool surface. Once an action is authorised, and management has the required GitHub capability, management should perform it directly rather than asking Jules to perform an operation Jules cannot perform. If management also lacks the capability, it should report the precise remaining action to the human.

Branch ownership matters

A Jules branch should be treated as owned by Jules for as long as Jules may still be able to publish to it.

Jules can force-push or otherwise rewrite its branch from its own view of the session. External implementation commits on that branch can therefore be lost or overwritten later. A failed VM, expired authentication, apparently terminated session, clean working tree, or belief that Jules is “done” is not evidence that the branch has stopped being Jules-owned. A stale or recovered Jules session may still push later.

The safe rule is:

If another implementation agent takes over from a Jules-owned branch, create another branch before the replacement agent writes or pushes. The replacement agent must not be instructed to continue the existing Jules PR branch.

A human-authorised local repair or analysis is different from a full implementation takeover. Another agent may inspect a chosen trusted commit in detached or equivalent local state and return a patch, diff, local commit, or review without creating a branch, pull request, or push. That does not transfer ownership of the Jules branch and does not authorise publication. If the result is later going to become published implementation work, create a non-Jules branch first and apply the reviewed result there.

This is specifically a Jules branch-ownership safety rule, not a generic requirement for every implementation-agent switch. If work is already on a human/management-owned branch, an Agy-owned branch, a Codex-owned branch, or another branch that the incoming agent can safely continue, the normal choice is to keep the existing branch and pull request. Create another branch or replacement PR only when context gives a concrete reason, such as rewrite risk, conflicting or parallel ownership, a deliberately separate line of work, provenance requirements, or a lifecycle boundary that is clearer as a new PR.

Before handing work away from Jules, the management layer should perform a branch-ownership preflight:

identify the current implementation branch and pull request;
identify which agent still has write ownership of that branch;
identify the last independently reviewed good commit that should become the handoff base;
create the replacement branch from that commit before the new implementation agent is instructed to modify or push;
open a replacement draft pull request early;
only after steps 4 and 5, generate the replacement-agent prompt and point it at the new branch/PR;
name the old Jules branch and PR as read-only historical context in the replacement-agent prompt;
explicitly prohibit pulling, rebasing, merging, force-updating, or pushing the old Jules branch as part of the new implementation line.

If the management layer can create branches and pull requests itself, it should do that setup directly rather than delegating branch isolation to the incoming implementation agent. This prevents the handoff prompt from accidentally treating the Jules branch as the writable target and makes the ownership transition visible in GitHub before any replacement-agent work begins.

When leaving a Jules-owned branch, a replacement branch can begin from:

the exact trusted Jules commit, when another replacement implementation agent genuinely needs that state;
current main, which is preferred for a fresh Jules session after any independently useful predecessor work has landed;
another deliberately chosen trusted base.

When replacing a Jules-owned implementation branch, create the replacement pull request as a draft as early as practical. Cross-link the old and new pull requests and make the handoff visible in GitHub so a human who is tabbing between tasks can understand which implementation is active.

That cross-link should be reciprocal rather than relying on one PR description to tell the whole story. The original Jules PR should record why Jules stopped, the last trusted commit when one exists, and the replacement PR. The replacement PR should link back to the superseded Jules PR and identify the commit or base from which continuation began. These links are part of the handoff record, not optional decoration.

When the handoff is caused by a Jules service or execution-environment failure, attribute it as narrowly as the evidence supports. A virtual-machine setup failure, repository-clone failure, authentication/access failure, lost environment, or similar agent-side infrastructure problem should not be described as an implementation failure. Prefer wording such as “Jules reported an environment-preparation/repository-clone failure” when that is what is known, and avoid inventing a deeper root cause. Sanitize logs before posting them publicly: do not copy credentials, tokens, private proxy hostnames, internal addresses, or other sensitive transient infrastructure details merely to prove that the agent failed.

The old Jules pull request should not normally be closed while the replacement is still active. Its closure timing can affect tools that use GitHub state to sequence or track Jules work, including queued tasks. It may need to remain open until the replacement is merged or closed, or it may need to be retired earlier when doing so is necessary for the next Jules job to proceed.

Once the human tells the management layer that the replacement pull request has merged, the management layer is authorised to perform the ordinary cleanup without asking for a second per-PR confirmation: verify the merge, close any still-open superseded Jules or temporary handoff pull requests, repair cross-links or status text where useful, and reconcile the linked issue state. This cleanup authority does not include merging the superseded pull request.

Replacement agents do not inherit GitHub context

Before giving Agy, Codex, or another replacement/local agent branch mechanics and recovery history, state the goal of the handoff clearly near the start of the prompt. The incoming agent should be able to tell from the first few lines whether it is being asked to finish an issue, repair a specific PR, salvage a safe subset, perform an audit, produce a patch without publishing, or deliberately reduce scope and leave the remainder durable. State the desired end state as well: for example, a reviewable replacement PR, a bounded fix with tests, or an evidence-backed assessment with no repository mutation.

This goal statement is management information, not motivational prose. It prevents a replacement agent from spending scarce interactive-agent credit reconstructing whether it is supposed to preserve the old implementation, replace it, merely review it, or chase the entire original issue. Branch ownership, trusted commits, review findings and detailed constraints should follow the goal rather than obscuring it.

A replacement or local coding agent must not be assumed to inherit GitHub issue, pull-request, review, comment, CI-discussion, or management context merely because it has the repository checkout, branch, or commit.

A normal handoff prompt should explicitly identify the target repository, relevant issue and pull-request URLs/numbers, the trusted base, the old read-only Jules branch/PR, the replacement writable branch/PR when a takeover is authorised, and the material acceptance criteria. It should also direct the agent to retrieve the issue body/comments, PR description/diff/conversation, reviews and relevant CI state before implementing.

Where command-line GitHub tooling is available, practical inspection may include commands such as:

1gh issue view <issue> --repo owner/repo --comments
2gh pr view <pr> --repo owner/repo --comments
3gh pr diff <pr> --repo owner/repo

When ordinary gh pr view does not expose enough inline-review detail, use gh api or an equivalent connected GitHub tool. The particular interface is not the rule; actual retrieval is. An agent must not claim it reviewed GitHub context that it never retrieved.

If GitHub access is unavailable to the incoming agent, the management layer should inline the material context into the prompt: issue requirements, observed versus expected behaviour, outstanding review blockers, architectural constraints, previous decisions and acceptance criteria. Treat the handoff prompt as the definitive boundary for everything the incoming agent is guaranteed to know.

After an authorised handoff, management should verify that the replacement agent actually retrieved or was supplied the external context and acted consistently with it before relying on the agent’s plan or completion claim.

Repository identity is part of task state

Multi-repository work creates another publication failure mode: the implementation can be correct while being committed or proposed in the wrong repository.

Before any push, pull-request creation, or repository mutation, the implementation agent—and the management layer when it can inspect the state—should verify that the durable task agrees with the intended owner/repo, current working tree, origin remote, active branch, and explicit repository/base supplied to the PR operation. A successful commit or PR creation is not proof that the repository is correct.

If work was produced in the wrong checkout, do not solve that by committing patch files, saved .git configuration, or other transport artifacts into whichever repository happens to be active. Re-home the real changes into the intended repository on a clean branch and make any mistaken durable artifact clearly point to the corrected work.

On handoff, restate the target owner/repo near the start of the prompt and have the incoming agent verify its remote before publishing. Dependency repositories may be inspected or changed by separate explicitly scoped tasks, but they are not interchangeable with the consumer repository.

Recovering when two agents already wrote the Jules branch

If the ownership gate was missed and Jules later writes over a branch another implementation agent had continued, do not treat the newest commit as the new baseline merely because it is newest or because CI happens to be green.

Instead:

stop additional writes to the contested branch;
identify the last independently reviewed good commit before the ownership conflict;
preserve any local or unpublished replacement-agent work before changing branches;
create a new replacement branch and draft PR from that trusted commit;
replay only the intended replacement-agent work onto the new branch;
compare later Jules commits against the trusted checkpoint separately;
salvage only narrow Jules changes that are independently correct and useful;
discard broad rollback/recreation work rather than letting it redefine the implementation line;
continue management review and CI on the isolated replacement PR.

A later Jules commit can contain a good isolated fix while still being destructive overall. Salvage that fix by reimplementing it or cherry-picking only the proven-safe piece; do not accept the contaminated commit wholesale.

When local-agent credits are scarce or run out

Scarce Agy, Codex, or other interactive/local-agent credit is a scheduling constraint and a routing input, not evidence that the current issue should automatically be restarted or handed back to Jules. Management should consider marginal value before the credit reaches zero.

When Jules remains viable, prefer spending its larger asynchronous quota on substantial bounded implementation and preserve scarcer interactive-agent credit for work where it buys more: branch recovery, difficult debugging, security-sensitive protocol review, resolving a small set of concrete blockers, or getting an otherwise sound pull request across the line. Do not send an expensive replacement agent through broad discovery that Jules can reasonably perform later simply because Jules is temporarily unavailable.

Running out of Agy, Codex, or another local-agent credit is therefore the strongest version of the same scheduling constraint, not a special signal about code correctness.

The management layer should first classify the current work:

safe to land: the PR is independently reviewed, release-safe and green, and remaining uncertainty is non-blocking validation or hardening;
safe to park: useful durable progress exists, but more implementation is needed and there is no urgent reason to finish it immediately;
urgent and incomplete: the current task still has a release blocker or time-sensitive dependency that cannot reasonably wait for local-agent credit to return.

For safe-to-land work, prefer finishing the management lifecycle instead of extending the implementation loop indefinitely. Move non-blocking live/manual validation or extra hardening into a focused follow-up issue, mark the PR ready for human review when appropriate, and merge only after explicit human instruction. Do not recreate the large original issue merely because the preferred implementation agent ran out of credit near the finish line.

For safe-to-park work, preserve the current branch, PR, issue state, last reviewed good commit, and an explicit resumption prompt. If there is a useful queue of unrelated or independently mergeable issues, let Jules spend its asynchronous capacity there from stable main while the parked task waits for local-agent credit. This is usually safer and more productive than forcing Jules into a fragile handoff solely to keep one task moving.

For urgent and incomplete work, a Jules takeover may be warranted despite its higher failure rate, but isolate it deliberately. Create a new Jules-owned branch from the last reviewed good commit or other trusted base; do not point Jules at the Agy/Codex branch as a shared write target. Give Jules a small, bounded, self-contained task and keep the usual evidence/review loop tight.

A Jules PR stacked on an unmerged Agy/Codex parent is a last resort. Prefer, in order:

land the safe parent first and let Jules start from updated main;
park the current task and use Jules on independent queued issues;
split a release-safe subset from the remaining work;
only when urgency leaves no better option, use an explicitly isolated Jules child branch/PR whose parent dependency is documented and whose diff will be revalidated after the parent moves.

If the local agent runs out of credit in the middle of uncommitted work, preserve that work before any handoff: commit it to an isolated branch when safe, or at minimum capture a patch and the exact base commit. Never let credit exhaustion turn into silent loss of the best-known implementation state.

The practical goal is continuity without pretending all agents have the same reliability profile. Jules’ failure rate may be tolerable when it is buying useful parallel throughput, especially across a queue of bounded issues; it is much less attractive as an emergency writer on a large contested branch.

Avoid pull-request stacks behind Jules

Jules works poorly when it is not the first layer in a pull-request stack, because its view of the repository and branch can lag behind later changes and it can clobber work it did not create.

For now, avoid building stacks where Jules depends on an unmerged parent PR created by another agent.

A stack with Jules at the first layer can be workable when Jules is intended to merge first and later work builds on top of that stable result. Even then, use the pattern deliberately rather than assuming Jules understands arbitrary stacked-PR state.

Review by evidence, not completion prose

I do not normally read every line while Jules is actively working. I let a stage reach a meaningful checkpoint, then ask the management LLM to inspect the real state.

The management LLM should review:

the cumulative diff, not only the newest prose summary;
the latest meaningful commit;
relevant tests and CI;
unresolved review findings;
issue and resolving-keyword state;
whether earlier correct decisions survived later fixes;
whether the change has widened beyond the intended scope.

If the reviewed PR is not approvable but the remaining problem is concrete and Jules-solvable, the management LLM should normally post a new @jules corrective comment immediately. Do not merely report “changes requested” and wait for the human to ask for the prompt. For CI failures, inspect enough state to identify the failing job or step and provide useful evidence, but do not consume excessive management context reading huge logs when deeper interactive diagnosis belongs with an implementation agent. Never weaken, bypass, or ignore CI just to make the PR appear green.

When that delegated technical review passes, the management layer has approved the work for human review. Approval is a GitHub state transition as well as prose: if the PR is a draft, the management layer should mark it ready for review first, then report approval. Only after the GitHub state reflects that transition should it use wording with the same meaning as:

Management review: APPROVED — ready for human review.

The accompanying message should make clear that management approval has actually been given, identify any residual caveats worth my attention, and say that the remaining decision is mine. This approval is not an automatic merge instruction and does not substitute for my final judgement.

If the delegated technical review passes but the management layer cannot mark the PR ready because the GitHub operation is unavailable or denied, it should not pretend the workflow transition succeeded. It should say that the technical review passed, that the PR remains draft because the ready-for-review mutation failed, and that the human needs to perform that transition. Once the state is repaired, the ordinary APPROVED — ready for human review wording is appropriate.

If the delegated review does not pass, or if a blocker is discovered after an earlier approval, the management layer should not leave the PR in a misleading ready state. It should keep or return the PR to draft, clearly state that management approval is not currently in force, and continue the correction/review loop.

My review may result in merge approval, another round in the same session, a new Jules session, new follow-up issues, a direct management fix, or a handoff to a different coding agent.

Recovery is judgement-based

There is no single hard retry count for Jules failures.

Useful recovery actions include:

answer a joobq;
restate or simplify the instruction;
repost a missed @jules comment;
let the current session retry;
salvage and land an independently useful predecessor slice, then follow up from updated main;
start a fresh Jules session from stable updated main, accepting a new PR as the normal outcome;
make a very small, obvious fix on an isolated management-owned branch;
use a non-main Jules recovery base only when a concrete unmerged dependency makes it necessary;
recommend moving the work to another implementation agent.

Schedule observation and pressure instead of relying on memory

A stalled Jules session is a good candidate for bounded scheduled observation. The schedule should inspect real repository state before deciding whether to send another message; it should not blindly post the same reminder on a timer.

A useful scheduled check can inspect the pull-request head, cumulative diff, changed files, comments, CI, and linked issue state. If meaningful implementation or bookkeeping progress has occurred, the check should remain quiet. If there is still no progress and GitHub comments are the active Jules control plane, it may post a concise @jules continuation or pressure message.

An acknowledgement is not execution. A reaction or other indication that Jules saw an instruction proves only that the control plane received it; it does not prove capacity was allocated, a VM started, the repository cloned successfully, or implementation began. Use workspace/repository evidence—such as a successful checkout, branch/commit movement, changed files, or an explicit runtime state—to distinguish “instruction acknowledged” from “task actually executing”.

Count zero-diff or no-changed-file commits as failed Jules cycles, not as progress when they arise from a non-converging implementation session. Keep the count visible enough that later decisions are based on evidence rather than reassuring commit messages. Do not count a tool-induced no-op created solely by a submit/metadata wrapper as implementation progress or automatically as implementation failure; classify it according to the underlying state.

Time and failed attempts are different signals. A practical heuristic is to require both a reasonable wall-clock window and several failed cycles before recreating a session when the only evidence is lack of progress. Around a day plus roughly three failed pressure/message cycles can be a useful default, but this is a heuristic rather than an SLA.

The polling cadence should match the likely failure mode and should be capped. When credits or transient service capacity are likely constraints, checks every few hours may be enough. When active recovery is wanted, an hourly conditional check for a bounded period can be reasonable. An old session should not receive indefinite automated pressure.

Every scheduled retry should carry the current task facts rather than merely saying “try again”. Preserve decisions already answered, name work already complete, state what remains, and prohibit known failure loops such as manufacturing placeholder commits. If the session eventually needs replacement, build the new prompt from current main, current durable issue state, answered questions, and useful evidence from the failed attempt.

Pressure should stop early when Jules reports a concrete capability blocker that repeated comments cannot fix. At that point another empty commit is not a useful retry. Record the blocker accurately, stop the pressure schedule, and either let the management layer perform authorised bookkeeping when it has the required capability or prepare a human-authorised handoff/restart that can materially change the capability.

Scheduled recovery does not change lifecycle authority. It must not merge, launch another implementation agent, create unapproved backlog items, or otherwise turn a retry timer into autonomous project management. Its job is to observe, nudge, count failure cycles, stop when pressure cannot help, and prepare a clean restart when the bounded recovery window is exhausted.

Record Jules failures and handoffs durably

When Jules itself fails, distinguish implementation failure from agent/service/environment failure. If the evidence says Jules could not prepare its virtual machine, clone or access the repository, authenticate, retain its environment, or otherwise reach the point where it could continue implementation, record that narrow fact in GitHub rather than implying that the code or requested approach failed.

A handoff away from a failed Jules session should normally leave a durable trail:

identify the last trusted commit, if there is one;
create the replacement branch from that commit or another deliberately chosen trusted base;
open the replacement PR as a draft;
comment on the original Jules PR with a sanitized failure summary, the last trusted commit, and the replacement PR link;
comment on the replacement PR with a backlink to the original Jules PR, the continuation commit/base, and the reason for the handoff;
preserve the original PR long enough for its normal queue/lifecycle purpose, then retire it under the ordinary cleanup rules after the replacement is resolved.

The replacement-agent prompt should be generated after steps 2 and 3. It should name the new replacement branch/PR as the only writable continuation target and name the Jules branch/PR only as read-only provenance and source material.

Failure attribution should be evidence-based and conservative. If only the failure category is known, say so. Do not turn an error from an internal proxy, credential helper, container, or repository-clone layer into an unsupported claim about the underlying root cause. Public GitHub comments should summarize the useful category and omit secrets and internal infrastructure details.

Repeated empty commits are a useful warning sign. Roughly three or four empty commits in a row should bias the management layer toward restart or handoff, particularly when the task is complex and the implementation has not progressed far enough to justify preserving the session.

However, distinguish repeated empty/no-useful commits caused by a confused or non-converging implementation session from tool-induced/no-op commits caused by a submit/metadata mechanism when the actual implementation is already complete. The second case must not automatically trigger the “three or four empty commits -> restart/handoff” heuristic.

Do not ask Jules to create an empty commit merely to:

acknowledge review feedback;
indicate that a task is complete;
simulate closing a PR;
make a metadata-only state transition;
create evidence that it saw a comment.

If there is no repository change to make, there should normally be no commit.

That is a heuristic, not a magic threshold. If only one or two small fixes remain, a direct management patch may be simpler and safer—but it should still be made on an isolated management-owned branch rather than turning the Jules branch into a shared workspace.

When the management LLM may patch directly

There is no fixed line-count threshold.

The useful question is whether the management layer can make the change with high confidence and verify it sufficiently from repository state and CI.

A direct fix is more reasonable when:

the required change is obvious and local;
the risk of hidden behavioural coupling is low;
CI can verify the important consequences;
no special local environment or interactive test is required;
the change is made on an isolated management-owned branch rather than continuing implementation on a Jules-owned branch.

If the change requires substantial testing that CI cannot perform, broad architectural judgement, or extended implementation work, use a real implementation agent instead.

Resolving keywords and issue lifecycle

The management LLM owns the outcome even when it delegates the mechanism.

If a pull request should resolve an issue, make sure an appropriate keyword such as Fixes #123, Closes #123, or the repository’s equivalent appears in the authoritative pull-request metadata or commit history.

Jules can be asked to include the resolving relationship, but the management layer should verify it and repair the PR metadata when necessary rather than trusting that it happened.

An issue should not be marked resolved merely because an agent claims the code is done. The repository lifecycle should remain honest: pending fixes are pending, merged fixes are merged, and partial fixes should leave the issue open with useful updated context.

After the human confirms that a pull request has merged, the management layer should verify that every intended resolving relationship produced the expected issue state. If an issue that should be complete remains open, or a partially addressed issue was closed incorrectly, repair that state or metadata as part of post-merge cleanup. Newly discovered follow-up work should still be reported to the human first and should become a new issue only after explicit confirmation.

Human issues and agent issues are not identical

Agent-created issues are mostly project state. They can be consolidated, rewritten, split, enriched, or closed autonomously when the evidence supports it after they exist.

A third-party human issue also represents a relationship with another person.

The management LLM may improve technical clarity, connect related work, or prepare a response, but it should not casually rewrite the social meaning of what that person asked or answer them as if it were me.

The management layer should make the human more informed, not make the human disappear from the conversation.

Closing, merging and draft state

The merge restriction in this section applies to the management layer and any actor that actually has merge authority. It is not a standing sentence that should be copied into every Jules prompt. The implementation agent should receive lifecycle restrictions only when they are relevant to an action it can realistically perform or when a concrete ambiguity makes the boundary necessary.

The strong default is simple:

do not merge without explicit human instruction;
do not close active pull requests without explicit human instruction or a clearly delegated lifecycle rule;
Jules-created pull requests should normally start as drafts so unfinished agent work does not present itself as waiting for human review;
the management LLM is authorised to move pull requests between draft and ready-for-review proactively as the review state changes;
keep or return a PR to draft while substantive blockers, requested corrections, or unresolved delegated-review concerns remain;
when management review passes, immediately mark the PR ready-for-review before telling the human that it is approved and ready to inspect; approval in this workflow includes that undraft transition, and no additional human confirmation is required solely for the draft-to-ready action;
if the ready-for-review mutation is unavailable or denied, report that the technical review passed but the PR remains draft, and tell the human that the manual Ready for review action is still required;
if new evidence invalidates an earlier approval, return the PR to draft and explicitly revoke or qualify that management approval until the blocker is resolved;
when replacing a Jules-owned implementation branch, create the replacement PR as a draft early enough that the transition is visible;
after the human confirms a replacement PR has merged, close superseded temporary/handoff PRs and reconcile linked issue state as ordinary delegated cleanup;
write transition comments and reciprocal cross-links so GitHub tells the story even when the human has not read the agent chat.

Ready-for-review means that management has finished its delegated review and is deliberately requesting human attention. It does not mean that the PR may be merged without explicit human instruction.

This is important because the GitHub record is what survives after the individual sessions become difficult to find or remember.

After a merge, close out the work and choose what comes next

A merge is a lifecycle boundary, not merely the end of a pull request. Once the human tells the management layer that the intended pull request has merged, the management layer should perform a short closeout pass before moving on.

The closeout should cover:

verify the merged pull request and its final head/state;
verify that intended resolving keywords closed the right issue or issues and correct routine stale issue state when necessary;
close any still-open superseded Jules pull requests or temporary handoff/recovery pull requests created solely to reach the merged result;
preserve useful cross-links and provenance so cleanup does not erase the history of the handoff;
assess release readiness and explicitly advise whether the new state is a sensible patch, minor, or major release candidate when the repository uses versioned releases; if it is not ready to release, say why. This is advice only: do not publish a release without human instruction;
rescan the completed PR, review comments, agent reports, related issues and other credible follow-up findings for work that was newly discovered, created, deferred, left over, or made obsolete by the merge;
search for an existing open issue for each actionable finding before proposing a new issue;
review the relevant open issues for accuracy against the now-merged repository state. Routine factual maintenance may be performed when authorised, but if an issue would need a material change in scope, acceptance criteria, meaning, ownership, or another consequential detail, ask the human before rewriting it;
after human confirmation, create approved new issues and return their direct URLs;
report direct URLs for the merged/reviewed pull request, any superseded pull requests touched during cleanup, and every issue materially affected.

The issue reconciliation should be visible rather than implied. When there are findings, present them in a compact table such as:

Finding	Existing durable issue	Current state	Proposed action
Follow-up discovered during review	#123	Open and still accurate	Keep; consider for a future Jules task
Left-over work with no issue	None yet	Actionable candidate	Ask whether to create a new issue
Previously open issue now satisfied by the merge	#124	Stale	Reconcile or close if authorised

Use real direct links in an actual closeout report. Do not invent an issue URL for an unapproved candidate. If no unrepresented actionable follow-up remains, say so explicitly.

Only after that reconciliation should the management LLM choose what Jules could do next. It should rescan the current relevant issue set at that time rather than blindly reusing a previously planned next task, because priorities, dependencies, active pull requests, and issue accuracy may have changed during the completed work.

The continuation suggestion should identify the issue or coherent group of issues that is the best fit for the current circumstances, explain briefly why it fits now, and provide a draft Jules prompt that can be accepted, redirected, split, combined differently, or discarded. Before suggesting it, verify that the work is still open, still relevant, not already covered by another active pull request, and not primarily a third-party human conversation that requires my response before implementation should proceed. Use learnings from the just-completed Jules work when deciding how much to combine, how much context to repeat, and which traps to call out.

The closeout report should also include useful management feedback: what changed, what remains uncertain, any notable agent behaviour, and any other information that may affect the next decision.

Finally, use the completed cycle as a lightweight process retrospective. If the agents’ actions or results expose a significant, reusable flaw in this management process—for example a rule that is wrong, materially incomplete, or repeatedly not followed because the guidance is unclear—suggest the specific change that should be made to this article and ask the human for permission before editing it. This should be rare. Do not churn the process documentation for one-off repository quirks or ordinary implementation mistakes.

This remains a recommendation layer, not an automatic queue consumer. Release publication, material issue reframing, creation of new issues, launch of the next implementation session, and changes to this process article remain human-controlled where the surrounding rules require confirmation.

Repository-first continuation and dependency-unblocked work

Start with the repository that just merged

After a human confirms a pull request merged, verify the merge, reconcile issues and superseded pull requests, and review the new state of that same repository. The first proposed next task and first complete copy-and-paste Jules prompt must target that repository. Search its current open issues and PRs for an actionable, coherent follow-up. Prefer existing durable issue state over inventing new backlog work. Do not automatically replace that primary prompt with a task in a dependency, generator, tooling or otherwise related repository merely because the completed work exposed a problem there.

An upstream defect with an existing issue is already accounted for. Link it as a dependency or an optional separate task; it is not a reason to displace the consumer repository’s next prompt. If the original repository has no suitable unblocked work, say there is currently no eligible in-repository prompt rather than silently treating a different repository as its continuation. The human can explicitly redirect the focus.

The report should show the in-repository follow-up first, with its own issue/PR links, scope and executable prompt. Other-repository candidates belong in a separately labelled Additional unblocked work section, after the primary result. Give each repository its own distinct prompt and branch/PR lifecycle; never combine implementation instructions for unrelated repositories into one Jules session. Return one copy-and-paste payload per fenced code block.

Look for work that the merge actually unblocks

Closeout must also inspect existing dependency relationships, blockers and follow-up issues in the same and related repositories. Search issue and PR descriptions, linked dependencies, version pins, review notes and release metadata for tasks whose prerequisites may have changed. Distinguish three states:

Ready now: the exact prerequisite is satisfied, the target issue is still open and accurate, no active PR already covers it, and the implementation can begin from the target repository’s current trusted base.
Waiting for a release or adoption: the upstream source change is merged but the target requires a published version, package, image or other release artifact, or still needs an explicit dependency upgrade. Record the candidate and its gate, but do not call it unblocked or start a downstream implementation PR yet.
Already accounted for or not yet ready: the upstream defect itself remains open, another PR already implements the target, the target issue has become obsolete, or prerequisites are unknown. Maintain links and report the blocker rather than fabricating a new task.

For cross-repository consumers, a merged upstream PR is not automatically equivalent to an available dependency. Verify the actual release/tag or published artifact and that it contains the fix, is accessible to the consumer, and can be selected by the consumer’s version/pin constraints. If the target intentionally consumes unreleased commits, require an explicit documented exception rather than silently treating a merge as a release. Do not infer readiness from a release plan, a green upstream CI run or an issue being closed.

When release readiness is the blocker, the continuation report should identify the upstream issue/PR, required release or version, target repository and downstream issue; state waiting for upstream release and present any proposed prompt conditionally, to be revalidated against actual GitHub/release state before use. Publishing a release remains a human-controlled action under the main management policy.

Turn newly unblocked tasks into separate, reviewable PRs

Once an eligible target is unblocked, search for its existing issue and active PR before creating anything. Update cross-links and the existing issue when appropriate; do not file a duplicate merely because a prerequisite was satisfied. Determine whether the target needs a straightforward dependency bump/regeneration or substantial implementation. For a narrow, high-confidence change within delegated management authority, management may create a separate target-repository branch and draft PR directly, implement the change and verify it with that repository’s tests and CI. Do not create an empty placeholder PR or assume green CI alone proves the intended behavior.

For work needing Jules or another implementation agent, provide a separate, self-contained target-repository prompt with the verified release/version, prerequisite issue/PR, current target base, exact acceptance criteria, tests and known traps. Establish branch/PR ownership in accordance with the main article. Starting an additional agent session remains a human choice unless explicitly delegated; when authorisation to start the work is given, establish the appropriate draft PR and review it normally. Do not present speculative or blocked prompts as immediately executable.

Opening a downstream draft PR does not authorise merging it. A new PR must pass its own review and CI and remain within its target issue’s scope. If a released generator or dependency changes canonical output, regenerate from the authoritative source with the selected released version and keep drift checks strict; do not hand-edit generated output or suppress meaningful differences.

Required post-merge answer order

Closeout: verified merge, issue reconciliation, superseded PR cleanup, CI/release state and links.
Primary next prompt — same repository: select an open, unblocked issue or coherent issue group from the repository just merged; give its own full Jules prompt first. If none exists, state that explicitly.
Additional unblocked work — other repositories: only include independently verified, ready targets. State the prerequisite release/version and target issue/PR, and supply each optional prompt or authorised draft PR separately. Do not elevate these above the primary prompt.
Waiting on release or another prerequisite: list relevant linked candidates with the exact gate and no premature implementation claim. Recheck the release and target issue before turning them into prompts or PRs.
Management feedback: notable changes, uncertainty, agent behavior and any process improvement worth preserving.

The answer should remain useful even when there is no cross-repository work. A recorded upstream issue does not create a standing instruction to work upstream next; the operator’s current repository remains the default focus until they choose otherwise.

A compact bootstrap contract for a fresh management LLM

If this article is being used to bootstrap a new management session, the following is the minimum operating contract:

Treat GitHub issues, pull requests, commits, review comments and CI as the durable state. Do not rely on an implementation agent’s prose summary when the repository can be inspected.
Use Jules as an asynchronous implementation worker, not as the sole planner, reviewer, issue manager or source of truth.
Generate prompts from the current repository and issue state. Prefer the current prompt and near-term next step over a long pre-written chain unless the work genuinely requires staged migration planning. Make the first couple of prompt lines a meaningful human-readable description of the intended change, because that text may become the visible task summary throughout the workflow.
Issues and Jules sessions do not need a one-to-one mapping. Combine related issues when they form one coherent, understandable implementation unit; split them when combining would obscure scope or acceptance criteria. Use learnings from previous Jules attempts to improve that judgement.
For private repositories, make Jules prompts self-contained. Include the relevant issue description, constraints, examples and acceptance criteria in the prompt itself; an issue link or number alone is not enough.
Consult relevant durable project guidance, including applicable blog posts, while generating prompts. Link or refer to it when useful, but apply it with judgement rather than treating every pattern as mandatory or prematurely engineering the full ideal design.
Keep actionable discoveries durable, but do not create new issues autonomously. Search existing issues first, consolidate or enrich an appropriate existing issue when warranted, and present genuinely new candidate issues to the human for confirmation. Create them only after an explicit yes, then return their URLs.
Respect third-party humans. Do not impersonate the operator in human-to-human issue or review conversations.
Encourage Jules to publish a branch and draft PR with meaningful intermediate state early. Treat draft as the normal initial state for Jules-created PRs, not as an exceptional failure state. When Jules has made changes and then needs to ask a question, prefer that it submit the current inspectable state before pausing, where practical.
Treat joobq / JOOBQ as the acronym for Jules out-of-band question: a question copied from the Jules interface into the management-LLM conversation, outside the normal GitHub review loop. Return the answer as a copy/paste payload for the Jules interface; do not post it to GitHub or add @jules unless the human explicitly asks for GitHub delivery too. Interpret older OOBJQ wording as the same event when encountered.
Put every Jules message and every other copy/paste payload in its own fenced code block. Keep explanation outside the block and do not combine distinct messages into one copy-and-paste block. Preserve the intended destination: joobq responses go back to the Jules interface; GitHub review-loop corrections go to GitHub.
On Jules-managed work, inspect each meaningful checkpoint. When correction is needed and Jules can reasonably perform it, post a new @jules comment automatically rather than waiting for the human to ask. Use @jules only when that is how the repository’s integration is configured.
For Agy, Codex CLI, Claude Code, or another local/non-web agent, return the corrective prompt to the human for copy/paste instead of trying to invoke the agent through GitHub. Never use @codex for Codex CLI. Treat Codex Web as a separate hosted product and use @codex only when the human explicitly says Codex Web is the active agent and GitHub-comment delivery is intended.
Do not edit an existing Jules instruction as the way to change course. Post a new follow-up comment containing the correction, because Jules does not reliably detect comment edits.
Verify important Jules instructions were acknowledged or acted upon. Repost when necessary rather than assuming comments form a reliable queue.
Treat Jules branches as Jules-owned for as long as Jules may still be able to publish to them. If another implementation agent takes over from Jules, do not generate a prompt that targets the existing Jules PR branch. First create a new branch from the last trusted commit or other deliberately chosen trusted base and preferably open an early draft replacement PR; only then generate the replacement-agent prompt and name that new branch/PR as the writable target. A failed VM/session/authentication attempt does not release Jules ownership. A human-authorised detached/local repair may inspect a trusted commit and return a patch/diff without publishing, but it must not mutate the Jules branch.
Preserve Jules provenance/task links in Jules-created PR descriptions when updating metadata.
Own PR metadata, resolving relationships, and draft/ready-for-review state. If Jules explicitly reports it cannot perform an administrative capability, treat that as a routing signal, not a retry loop. Perform the administration directly when authorised, or report the exact remaining action to the human. Keep or return unfinished work to draft. When delegated technical review passes, approval includes marking the PR ready-for-review before asking the human to review it. If that GitHub mutation fails or is not permitted, disclose the failure and say that the PR remains draft instead of implying that approval state was fully applied.
Use direct patches only for small, high-confidence work that can be adequately verified, and publish them on isolated management-owned branches rather than treating a Jules branch as shared. Otherwise recommend an implementation agent.
Repeated empty Jules commits, stale context, clobbered changes, lack of convergence, or clear Jules environment/access failures are reasons to consider a fresh Jules session or a human-authorised handoff. For a fresh Jules session, prefer a new PR from updated main; use a non-main recovery base only for a concrete dependency on trusted unmerged state, and remember that a bare commit SHA must first be made an existing base branch. Do not trigger this heuristic for tool-induced no-op commits. Never ask Jules to create an empty/no-op commit merely to acknowledge feedback, signal completion, or simulate a state transition.
Avoid non-first-layer Jules PR stacks. Jules is safest when working from a stable base that does not depend on later external commits.
When delegated review passes, first mark the PR ready-for-review immediately in the same review turn, then say explicitly: “Management review: APPROVED — ready for human review.” Do not merely recommend moving the PR out of draft or wait for a separate confirmation when management already has authority and capability to perform the transition. If the state transition cannot be performed, say that technical review passed but the PR remains draft and needs the human’s Ready for review action; do not claim the transition succeeded.
If blockers remain or reappear, the PR should be draft and management approval should not be presented as current. The management LLM may move PRs in either direction between draft and ready without asking first.
Do not merge without explicit human instruction. This is a management-layer rule for actors that actually have merge authority; do not mechanically copy “do not merge” or equivalent into Jules prompts or joobq responses when Jules lacks merge capability in the current control plane. Do not close active PRs without explicit instruction unless a specific lifecycle rule has been delegated. Once the human confirms that a replacement PR merged, closing its superseded temporary/handoff PRs and reconciling linked issue state is delegated cleanup and does not require another per-PR confirmation.
After a confirmed merge, perform a closeout pass before moving on: verify cleanup and issue resolution; advise whether the merged state is a sensible patch, minor, or major release candidate when releases apply; scan newly discovered, deferred and left-over work and map it to existing open issues or human-approved candidate issues; check relevant open issues remain accurate, asking before material reframing; present follow-up findings with direct links; rescan the current issue set and suggest the best-fit next Jules prompt rather than reusing a stale plan or launching it automatically; and, only when the completed cycle exposes a significant reusable flaw in this management process, propose a specific update to this article and ask permission before changing it.
Keep management communication explicit. State what you inspected, what you changed in GitHub, what remains uncertain, and what action you are proposing so the human can safely supervise multiple tasks without guessing.
Whenever GitHub work is reviewed or changed, include direct URLs to the pull request or pull requests and issue or issues materially affected. If a new issue was proposed but not yet approved, say that explicitly rather than inventing a URL.
When Agy/Codex/local-agent credit is scarce or exhausted, classify the current work before changing agents and spend the remaining interactive-agent budget where its marginal value is highest. Prefer Jules for substantial bounded asynchronous implementation when it remains viable, and reserve scarcer interactive-agent credit for bounded repair, difficult debugging, security-sensitive review, or getting an otherwise sound PR across the line. Prefer landing a reviewed green PR plus a focused follow-up, or parking it durably and using Jules on independent queued issues. If urgency genuinely requires Jules to take over unfinished work, give Jules a new isolated branch from a trusted commit; do not share the local agent’s branch, and treat a Jules PR stacked behind an unmerged non-Jules parent as a last resort.
For stalled Jules sessions, use bounded scheduled condition checks rather than blind repeated comments. Inspect repository state before each nudge, count zero-diff/no-changed-file implementation cycles as failed cycles, stop early on real progress or an explicit capability blocker, and cap the recovery window. When both a reasonable wall-clock interval and several failed cycles have elapsed without progress, regenerate a fresh prompt from current durable state rather than indefinitely pressuring the old session.
Never assume a local or replacement agent has read an issue, PR, comment, review thread or CI discussion merely because it has the Git checkout. Explicitly require retrieval of that GitHub context or inline the material context when access is unavailable, and verify the agent actually acted from it.
Before any push, PR creation, or repository mutation, verify the intended owner/repo, working tree, origin, active branch and explicit PR destination all agree. A valid PR in the wrong repository is still a publication failure; re-home the real changes instead of committing transport artifacts into the accidental repository.
Classify Jules failures by execution stage. VM provisioning, authentication, clone, or other setup failure before a usable checkout is a pre-execution infrastructure/control-plane failure, not an implementation cycle. Do not count it as non-convergence or infer anything about the implementation approach from it.
Distinguish acknowledgement from execution. A reaction or acknowledgement proves an instruction reached the Jules control plane; verify workspace startup or repository progress before treating the task as running.
When generating an Agy/Codex/replacement-agent management prompt, state the implementation goal and desired end state near the start, before branch mechanics and historical detail. Make explicit whether the agent is auditing, repairing, finishing, salvaging a safe subset, reducing scope, or producing a non-publishing patch, and what successful completion should leave behind.
When agent completion prose claims a file, production path or behaviour changed, verify that claim against the changed-file list and cumulative diff. If the implementation evidence is absent, treat the claimed work as incomplete rather than merely correcting the summary.
After a confirmed merge, give the first full Jules prompt for the repository just merged. Inspect its open issues and PRs before recommending work elsewhere. In addition, check whether the merge unblocks work in this or other repositories; verify any required released version and consumer pin before presenting a separate executable prompt or creating an authorised draft PR in the target repository. If a dependency is merged but unreleased, mark dependent work as waiting; do not let an existing upstream issue replace the original repository’s primary prompt.

Let the workflow teach the workflow

This article should evolve as stable lessons emerge.

The management layer may propose or create focused pull requests that improve this document when repeated experience reveals a useful general rule, failure mode, or recovery pattern. The purpose is to make future sessions better at bootstrapping themselves rather than depending on conversational memory that may not be available.

The most important constraint on those edits is generality.

Do not turn this article into a scrapbook of one repository’s bugs, one unusual CI failure, or one temporary product quirk. Repository-specific facts belong in the repository. This document should contain reusable process knowledge that is likely to help again.

That is ultimately the reason for writing it: not to freeze one exact sequence of clicks, but to preserve the management model well enough that both humans and LLMs can enter the workflow with the same expectations.