Home / Guides & Tutorials / The AI Coding Workflow That Ships: From …

CHAPTER 5 OF 7 · 10 min · 2 COPYABLE ASSETS

How to prime Claude Code with codebase context (PIV loop step one)

Start every implementation fresh: /prime loads the ticket, codebase patterns, and git history, then subagents research without flooding your context window.

TL;DW

Every ticket starts a brand-new Claude Code session. The developer picking up work has no memory of the planning conversation, and that is by design. The /prime command rebuilds exactly the context needed: it pulls the JIRA ticket through the MCP server, studies the codebase and recent git commits, and reports a summary. From there you explore solutions freely, spinning up subagents for research so that a hundred thousand tokens of codebase reading collapses into a few thousand tokens of summary for your main agent.

Watch: FULL Guide to Becoming a Principled Agentic Engineer (Build Anything with AI)

▶ Watch this chapter on YouTube from 38:44

Lesson · 9 parts

The loop's first step mirrors the PRD phase: explore the solution before structuring anything. But the input is now a single ticket the developer picked up, self-assigned through the JIRA MCP if you like. One artifact in, one implementation out. That is the shape of every cycle from here.

Planning has two layers, and confusing them is what sinks most AI-coding attempts. Layer one, the PRD, stayed at features-and-requirements altitude. Layer two, this ticket, is where you analyze the codebase, the documentation, and exactly which files must change. The two-step order matters: you arrive here already carrying validated business context.

Cole starts a brand-new conversation and role-plays the reality: the developer picking up this ticket was not in the planning session and has none of that context. That is not a problem to fix. It is the design. Context gets rebuilt deliberately, not inherited accidentally.

The prime command walks the agent through understanding the codebase through the lens of the ticket. It loads external context (the JIRA issue, Confluence pages), studies features and app routes, and reads recent git commits. Cole: 'I love using git as long-term memory for my coding agents.' What you shipped recently predicts the patterns you should follow next.

The argument is a comma-separated list of ticket IDs, so one prime call can load a small cluster of related work. What it reads is fully yours to tune: which directories count as core, how many recent commits matter, whether Confluence pages join the sweep. Cole's version is a starting point, and he expects you to specialize it per codebase.

A good smell test after priming: the agent should be able to summarize your app's structure and name the files the ticket will likely touch. If it cannot, the command is loading the wrong things. If it rambles for pages, it is loading too much.

Prime against one or more tickets

/prime AT-23

Under Ctrl+O you see the sequence: list accessible Atlassian resources, fetch the specific issue, then a burst of parallel file reads and git-log checks. Everything the agent needs, gathered in one orchestrated sweep. And every step of that sweep is text in the prime command you can edit.

You do not want half the agent's context spent on research before work begins. Load the core files and recent history, no more. The tuning knob is the command itself. If priming pulls too much, change what it reads. Your process, your codebase, your lever.

Primed on ticket AT-23, the projection page, the agent checks JIRA state and reports blockers: AT-22, the QR-code ticket, has to land first. That dependency mapping was built into /create-stories. Cole pivots the session to AT-22 on the spot. Unstructured gear-shifts are exactly what this phase is for.

Exploration here is deliberately free-form. Cole does not even use a command. He speech-to-texts a quick instruction spinning up subagents: sub-processes that each research part of the codebase and report back only a summary to the main agent.

When to reach for subagents versus letting the main agent read directly: direct reads win for one or two known files, because a subagent round trip adds overhead. Subagents win the moment the question is open-ended (where does voting state live, what patterns do our components follow, which library handles QR rendering), because the research would otherwise flood your working context.

Three parallel subagents is Cole's typical shape for a feature exploration. Each one burns its own context freely and returns a few hundred words. Your main session stays clean for the decisions that follow.

The exploration prompt

Let's build AT-22. Spin up a few subagents to research the codebase and help me ideate on how to build this feature into our app.

One research pass loaded 32,000 tokens. The whole exploration burned over 100,000, yet only a few thousand tokens of summary returned to the main agent. That is the strategy. Yes, million-token windows exist now. 'Just because you can fit a million tokens into a large language model does not mean that you should.' Models get overwhelmed just like people. Manage context; do not hoard it.

Study notes

Part 1 of 9 · 38:44 to 39:39

The PIV loop starts with a ticket, not a prompt

Concept The PIV loop begins the way Phase 1 did, with exploration, but the input is now a single ticket picked up from the tracker. If you are joining here: PIV stands for Plan, Implement, Validate, the cycle every piece of work travels from now on.

Why it matters One artifact in, one implementation out is the loop's contract, and it is worth defending. Hold to it and any developer or agent can run any ticket interchangeably. Break it, and work becomes personal folklore that leaves when its owner takes a vacation.

Do this

Have your ticket ID ready. The artifact is the input.

Part 2 of 9 · 39:39 to 40:44

Layer two: now we open the codebase

Concept Layer two opens everything layer one banned: the codebase, the documentation, the exact files that must change. Same two-layer idea from chapter two, now experienced from the developer's side of the handoff. Requirements arrive settled; implementation questions are finally in scope.

Why it matters The ordering is the payoff: you arrive at the technical layer carrying validated business context, so deep work starts aligned. Teams that plan only at ticket level rediscover business questions mid-implementation, which is the most expensive possible place to ask them.

Do this

Say which layer you are in: ticket level now, so codebase detail is allowed.

Part 3 of 9 · 40:44 to 41:46

Open a fresh session. Always

Concept The fresh session is a rule, not a preference. The developer picking up this ticket was never in the planning chat, so the workflow assumes zero inherited context and rebuilds everything from artifacts. Deliberate context, rebuilt on demand, is the system's answer to memory.

Pitfall Continuing in the planning session feels efficient and is not. It drags rejected options, dead ends, and stale assumptions into the implementation's reasoning. Close the window. If the plan cannot survive a fresh session, the plan was not finished, and better to learn that now.

Do this

Close your planning session.
Start a brand-new Claude Code conversation for this ticket.

Part 4 of 9 · 41:46 to 42:50

Run /prime: rebuild exactly the context you need

Concept /prime is the context rebuilder: it pulls the ticket through the MCP server, studies the app's features and routes, and reads recent git history, all through the lens of the work at hand. One command replaces the hour of orientation a new contributor would need.

Why it matters Git-as-memory is the underrated half of priming: recent commits show the patterns your codebase actually follows, which beats any style document that has drifted from reality. An agent that reads last week's commits writes this week's code in the same accent.

Do this

Copy the /prime command from the lesson panel with your ticket ID.
Read the returned summary fully before continuing.

Part 5 of 9 · 42:50 to 44:17

Watch it load: MCP pull plus parallel reads

Concept The command accepts a comma-separated list of ticket IDs, so one prime call can load a cluster of related work. What it reads is configuration you own: which directories count as core, how many commits matter, whether Confluence pages join the sweep. Tune it per repository.

Concept Under Ctrl+O the sweep is fully visible: resource listing, the specific issue fetch, then a burst of parallel file reads and git-log checks. One orchestrated pass, instead of twenty ad-hoc questions scattered across the session later when they are harder to answer.

Try it Run the smell test on your own prime output the first time you use it: ask the agent to summarize the app and name the files this ticket will likely touch. A crisp answer means you primed well. Rambling means the command loads too much. Blankness means too little.

Do this

Press Ctrl+O and watch the MCP fetch plus the parallel file reads.

Part 6 of 9 · 44:17 to 45:02

Do not flood the context window

Pitfall Research must not eat the window before work begins. If priming consumes half your context, every later decision gets made with less room to think, and quality decays in ways that are hard to attribute. Trim what the command reads instead of accepting the default.

Concept Treat the prime command as a dial you set per repository: core files and recent history in, everything else out. There is no universal correct setting, only your codebase's setting, and finding it takes two or three runs of the smell test above.

Do this

Check the token count after priming.
If research ate half your window, trim what the prime command reads.

Part 7 of 9 · 45:02 to 46:06

Live teaching moment: the agent catches a blocker

Concept The blocker catch is dependency mapping paying off at exactly the right moment: create-stories recorded that the QR ticket must land before the projection page, and the primed agent checks tracker state before proceeding rather than charging into work that cannot ship.

Why it matters Cole pivots to the blocking ticket without ceremony, and that flexibility is the point of having an exploration phase at all: nothing is sacred yet, so course-correcting costs nothing. Respect computed dependency order; it exists because someone, or something, already thought about sequencing.

Do this

If the agent reports blockers, switch to the blocking ticket like Cole does.
Do not fight the dependency order.

Part 8 of 9 · 46:06 to 47:14

Research with subagents

Concept Subagents are research workers with their own context windows: each reads a slice of the codebase and returns only a summary to the main session. The expensive reading happens off to the side; the decisions happen in a clean room.

Example The prompt is deliberately unstructured, 'spin up a few subagents to research the codebase and help me ideate', and three parallel workers is a sensible default split: one on data flow, one on UI patterns, one on the feature's nearest neighbors in the code.

Concept Choosing the tool: direct reads win for one or two known files, because a subagent round trip adds overhead. Subagents win the moment the question is open-ended, like where does voting state live, because open-ended research is exactly what floods a working context.

Do this

Paste the exploration prompt from the lesson panel, adjusted to your ticket.
Let all subagents finish before reading the synthesis.

Part 9 of 9 · 47:14 to 49:06

Why subagents beat a bigger context window

Why it matters The arithmetic makes the whole argument: one hundred thousand tokens spent researching, a few thousand returned as findings. You bought the knowledge without carrying the reading. That ratio, purchased comprehension per token of working memory, is the entire economics of subagents.

Concept 'Just because you can fit a million tokens into a large language model does not mean that you should.' Capacity is not advice. Models reason worse as their windows fill, the same way people skim rather than read a four-hundred-page binder. Deliberate context beats maximal context, always.

Concept With the summaries back, the session sits at the exploration stage of the diagram: questions flow in both directions, assumptions get removed, and only then does structure begin. The next chapter converts exactly this exploration into the plan artifact an implementer can execute.

Try it Track your own numbers the next time you research with subagents: tokens consumed versus tokens returned to the main agent. That single ratio tells you whether your subagent prompts are producing summaries or dumps, and it is the fastest way to tune them.

Do this

Compare tokens used versus tokens returned in your own run.
That gap is the context you saved for implementation decisions.

Key terms

Context window: The bounded working memory an agent reasons over; overfilling it degrades output quality.
Subagent: A helper agent with its own context that researches a slice of the problem and returns only a summary.
Priming: Rebuilding a fresh session's context from artifacts: the ticket, the codebase, recent git history.
Blocker: A ticket that must be completed before another can start.

Key takeaways

Two planning layers: project-level (the PRD) stays high-level, while ticket-level digs into files, architecture, and docs.
Git history is long-term memory. Recent commits teach the agent the patterns your codebase actually follows.
/prime is a starting point. Tune how much context it loads for your codebase; the command is the lever.
Subagents burn 100k tokens on research and hand back a few thousand. That is the point.

Watch out

When the agent flags a blocker dependency (here, the QR ticket had to precede the projection page), believe it. That dependency mapping came from /create-stories and it is usually right.
A 1M-token context window is not a license to fill it. Models get overwhelmed exactly like people; summaries beat raw dumps.

Check your understanding

Why start implementation planning in a brand-new session with no memory of the PRD work?

Because context should be rebuilt deliberately (via /prime and the ticket artifact), not inherited accidentally. The developer picking up a ticket never has the planning conversation anyway, and fresh context keeps the agent focused.

What did the subagent research cost in tokens, and what came back?

Over 100,000 tokens consumed across the subagents, with only a few thousand tokens of summarized findings returned to the main agent. Research is delegated precisely so the main context stays clean.

01 38:44 Concept The PIV loop starts with a ticket, not a prompt ▾

02 39:39 Concept Layer two: now we open the codebase ▾

03 40:44 Step Open a fresh session. Always ▾

04 41:46 Step Run /prime: rebuild exactly the context you need ▾

05 42:50 Step Watch it load: MCP pull plus parallel reads ▾

06 44:17 Watch out Do not flood the context window ▾

07 45:02 Note Live teaching moment: the agent catches a blocker ▾

08 46:06 Step Research with subagents ▾

09 47:14 Concept Why subagents beat a bigger context window ▾