03 / 10 · Day one

Your first ticket

A thirty-minute path from "I have access" to "I shipped." The goal is not depth — it's getting one ticket through the loop so you have a personal proof of life.

Before you start

You need:

Pick a small ticket — ideally a 1–2 point bug or UX tweak. Avoid a multi-file refactor for your first run.

Step 1 — open a workspace

In Conductor, click + New Workspace on the repo. Accept the suggested city name. Conductor clones the repo, runs setup_script, and opens a Claude session pointed at the new workspace. Wait for the setup log to go green.

Step 2 — start the loop

> /chowly:implement_jira TEAM-XXXXX

Replace TEAM-XXXXX with your ticket. Claude will pull the ticket, rename your branch to feature/TEAM-XXXXX_short_description, transition the ticket to In Progress, and present an implementation plan.

You don't need to type anything yet.

Step 3 — read the plan

This is the most important moment in the loop. The plan is your one chance to redirect cheaply. Three responses are typical:

Real example from a production session: "use option B for now although alt might be blank most of the time" — names the chosen option, acknowledges the trade-off, gives Claude permission to proceed. That's the pattern.

Step 4 — let it execute

Claude implements. Don't interrupt unless you see something genuinely wrong (wrong file, wrong abstraction). Watch git diff if you want to see what's happening.

Step 5 — verify

For UI changes:

> Validate using browser MCP. Running at http://localhost:3000/admin

For backend:

> Run the relevant specs

Step 6 — write missing specs

> /chowly:write_specs

The Automation Testing Engineer agent diffs your branch, identifies uncovered code, writes specs, and runs them. If they fail, it iterates.

Step 7 — clean up

> /chowly:cleanup

The Senior Engineering Mentor agent reviews for DRY, SRP, verbosity, and conventions. It presents findings as a table before changing anything. Approve, and it refactors.

Step 8 — code review

> /chowly:code_review

Reads CODE_REVIEW.md, runs through your diff, writes a markdown review to tmp/<date>-CODE-REVIEW.md. Treat as a peer-review draft — fix what's real, push back on what isn't.

Step 9 — open the PR

> Create a PR. Set the reviewer on the PR to match the Jira ticket reviewer. Move the Jira ticket to "In Review".

Claude pushes the branch, opens the PR against development, reads the Jira reviewer field, sets the GitHub reviewer, and transitions the ticket. Done.

Step 10 — done

You're out. Total typing: probably 5–10 user messages. When the PR merges, archive the workspace in Conductor.

What just happened. You used Conductor for a clean workspace, a slash command to kick off a structured flow, the Software Engineer agent as the planner, the Atlassian MCP for ticket I/O, the Automation Testing Engineer agent for specs, the Senior Engineering Mentor agent for cleanup, the chowly:code_review command for self-review, and gh for the PR. Six tools, each doing one thing well. The next pages walk through each.