02 / 10 · The mental model

The loop

One diagram. Internalize it and the rest of this handbook is just elaborations.

The shape

Jira ticket→ /implement_jira→ Plan → Approve→ Execute→ /write_specs · /cleanup→ /code_review · /request_review

The highlighted step — "Plan → Approve" — is the only one that cannot be delegated. Everything else, Claude does.

The one paragraph

You frame the work (a Jira ticket). Claude pulls context (the code, the ticket, the related tickets) and proposes a plan. You approve or redirect — this is where your judgment lives. Claude executes, runs tests, fixes failures, cleans up, self-reviews. It opens the PR with the right metadata. A human reviewer takes it from there.

The five things to internalize

1. Plan-first is non-negotiable

The single biggest difference between successful sessions and failed ones is whether the agent planned before doing. Skip planning and you lose the chance to redirect cheaply, the record of intent, and Claude's own scaffolding for the work. The slash commands enforce planning. Don't work around them.

2. Workspaces are cheap; reuse is expensive

Conductor lets you spin up a workspace per ticket. Use that. Don't try to do three tickets in one workspace — branches collide, context bleeds, scopes conflate.

3. The right agent for the right job

The default Claude is a generalist. The named agents (Software Engineer, Senior Engineering Mentor, Documenter, Jirid) are specialists. Specialists outperform generalists on their domain. Use them. (More on page 4.)

4. Skills act, agents think

A common confusion. Roughly: a skill is a tool Claude can call (e.g., "look up a Jira ticket"). An agent is a persona that frames how to think about a problem (e.g., "you are a senior engineer; plan before you do"). The slash commands compose both for you.

5. Short user messages are a feature

The user messages in productive sessions are mostly two words: "Approved", "yes", "ok", "Create a PR", "fix it", "continue". The user is steering, not driving. Long messages happen at three moments: initial scoping, redirects, clarifications. Otherwise, less is more.

The shape of a bad session

For contrast — when a session does not work, it usually looks like this:

> "hey can you look at this bug, I think it's in the campaigns code"
[no plan, no ticket pulled, no branch rename]
> "actually try the other approach"
[10 minutes later: still grepping]
> "wait it should be in the email service"
[edits applied to wrong file]
> "let me give you more context: …"
[4000 tokens later, context window 70% full]

What's wrong: no ticket, no plan, no branch convention, no agent specialization, no verification step. The user is feeding context one chunk at a time instead of letting the agent pull it.

If you find yourself in this shape, abort. Open a Conductor workspace, write a real ticket, start with /implement_jira.