What an agent reads

An agent can only be as good as what it is given. This page lists everything an agent reads before it starts on a ticket, and explains the parts that are easy to miss: the repository's own instructions, attachments, earlier attempts at the same ticket, and projects that work together.

The run screen shows everything the agent was given for that run. When a run does something unexpected, look there first. Most surprises turn out to be something the agent was told, or something nobody told it.

#What the agent is given

Every item below is optional. A ticket with no criteria, no comments and no attachments still runs; the empty parts are simply left out.

1. The agent's own instructions, plus the shared rules every agent follows.
2. The repository's instructions. Many repositories explain how to work on them. The agent is told to read and follow them.
3. Other repositories in the work, when the project is linked to others (see below).
4. The ticket: title and description.
5. Your instruction, if you wrote one when assigning, or the review comments it is answering.
6. Earlier attempts at this ticket: what each was asked and what it reported.
7. The acceptance criteria, both plain and technical.
8. The conversation: the recent comments on the ticket, newest first when the thread is long.
9. Attachments it can read.
10. The project: the goal, the ticket's outcome, the specs and every note.
11. The agent's knowledge that is relevant to this ticket.
12. Skills the agent or project has been given.
13. What it may do on this run, and how to report back.

#The repository's own instructions

Many teams already keep instructions for AI coding tools in their repositories, such as a CLAUDE.md or AGENTS.md file. Jarvis finds these and tells every agent to follow them over its own habits.

If your repository has none, writing one is the most useful thing you can do for agent work on it. It travels with the code, so it stays right as the code changes.

#Attachments

Agents can read PDFs and images attached to the ticket or its comments. Other file types are kept on the ticket for people.

The Read the attachments option on the assign dialog is on by default. Untick it when a run does not need them. The run screen notes when a ticket with attachments ran without them.

#The conversation and earlier attempts

A ticket is corrected in its comments far more often than in its description. "Actually, only for logged-in users" three days later is exactly what an agent needs, so the recent conversation is always included, whether it was written here or came from Jira.

Earlier attempts at the same ticket are included too. After you request changes and assign the ticket again, the new run knows what was tried before.

#Projects that work together

A ticket rarely stops at one repository. The app and its API, a website and a shared library: a change to one often needs a change to the other. On the project form, Linked repositories lists the other projects this project's agent work should include.

When a project has links:

• The agent works in all of them at once, on the same branch name, and knows which is which.
• Each linked project's specs and notes are included beside its code.
• The approval screen shows the changes for each repository separately. If one could not be opened, the screen says so, so you know before you approve.
• Approval applies to all of them together.

#Who leads

The ticket's own project leads. Its agent, its settings and its staging site are the ones used. A linked project contributes its code and its notes, nothing else.

#Links go one way

Linking the API into the app project means the app's tickets include both. It does not mean the API's tickets include the app. Each project says what its own tickets include, so the project you file a ticket against decides how much of the system the agent can change.

The assign dialog and the project page both show which repositories a run will include, with the lead marked.

#What an agent does not see

• Other tickets, unless they are mentioned in the description or the conversation.
• Notes and specs of projects that are not linked.
• Passwords, keys or tokens. Agents are never given them.
• Anything on your screen. If it matters, put it in the ticket.

#Making agent work better

• Read what it was given. Open a recent run and read what the agent was given. Gaps are usually obvious.
• Move repeated corrections upstream. If you write the same review comment twice, it belongs in a project note, the repository's own instructions, or the agent's knowledge.
• Keep the description current. When the conversation changes the scope, edit the description too.

Next: How Jarvis keeps work safe.