An agent reads a bug report, finds a plausible cause, and opens an issue. Another agent did that yesterday, and a third already wrote the fix. Somebody now has to reconcile the new work.

Before the agent decides there is a new job, it should inspect the identity of the code, the existing discussion, and the result of any earlier action. Repository access alone does not supply these, so the workflow has to carry them from one step to the next, with your existing agent and the GitHub integration.

Start with the revision the report describes#

A customer reports that a settings change disappears after refresh. The agent finds a fix on the default branch and concludes the report is obsolete, which is premature if the customer runs a release that predates the fix.

Make the first investigation identify the repository, the reported environment or release, and the revision being inspected. If the report does not identify the deployed revision, keep that gap visible.

Use a task brief like this:

Investigate the settings persistence report in the specified repository.
Record the revision you inspect.
Check the relevant files, comparison, and existing pull request discussion.
Separate an existing fix from evidence that the fix reached the affected user.
Before proposing a new issue, identify the remaining unanswered question.

Match the problem before matching the words#

Two reports can describe the same defect in different language, and identical titles can describe different defects. Give the agent a comparison covering the trigger, observed behavior, affected component, and revision.

An existing issue about a failed save is a candidate duplicate. Ask the agent which facts match and which are missing. If a previous fix changes a different persistence path, the new report needs its own investigation.

Keep the repository with every issue or pull request number, since a number alone is not a globally unique reference. Keep the object type too: GitHub's issue APIs can return pull requests, and GitHub documents how to tell them apart in the issue API reference.

The result should let a reviewer pick a next step:

Finding	Next step
The same behavior is already tracked and still open	Add new reproduction evidence to the existing discussion
A matching fix exists, but release status is unknown	Investigate delivery before proposing another patch
The fix is present in the affected revision, but the report still reproduces	Treat the reproduction as new evidence against the earlier conclusion
No matching issue or fix was found within the inspected scope	Propose a new issue and state the search scope

"No match found" is a scoped observation. It does not mean "this has never happened before."

Make the proposed write inspectable#

Before creating an issue, show the destination repository, title, reproduction, expected behavior, actual behavior, and references. The GitHub operation guide lists the required fields and permission names for the connection.

Keep the proposal separate from execution. A strong diagnosis does not say the agent which repository owner wants a new issue, which labels apply, or whether another person has already taken over the work.

For calls routed through Deixic, you choose which tools the agent uses and apply approval before sensitive actions finish. The action lifecycle explains how a proposed call proceeds through that decision. Calls made outside that connection stay outside those controls.

A timeout is not a reason to create the issue again#

Suppose GitHub accepts the issue, but the response never reaches the agent. The agent sees a timeout and retries, and the workflow has created the duplicate it was meant to prevent.

Treat an uncertain write as a question about the destination and inspect the target before repeating the operation. If the workflow cannot establish whether the first attempt succeeded, it should ask for resolution instead of writing again.

After a successful action, keep the created object's identifier, the repository, and the result, and pass that reference to the next agent in the handoff.

Test the awkward cases first#

Run the workflow against four cases and check that the agent picks the correct next step without creating duplicate work:

a report whose fix is merged but not released
an issue with a misleadingly similar title
a pull request returned in an issue list
a write whose response is interrupted

Review the method before saving it as a skill. Save durable instructions, such as how the team classifies a duplicate, separately from changing facts, such as whether a particular release contains the fix. Refresh those facts when the next task depends on them.

The agent should come back with: "This is already tracked. Here is the missing reproduction detail, and here is where it belongs."