Most sprint overhead is not the coding. It is the admin around it: dragging cards between columns, chasing which issue a pull request actually closed, writing the standup update nobody read, and reconciling the board against reality every Monday. For a Sydney team of six developers, that housekeeping quietly burns a few hours a week per person.
GitHub Projects gives you the board and the data model. Claude Code gives you an agent that can read that data, reason about it, and act on it through the GitHub CLI and API. Wire the two together and a large share of sprint bookkeeping stops needing a human. This is a practical guide to what that looks like, where it works, and where you should keep a person in the loop.
What Claude Code can touch in GitHub Projects
Claude Code runs in your terminal with access to the gh CLI and the GitHub GraphQL API. GitHub Projects (the newer Projects v2) is built on that GraphQL API, so anything the API exposes, Claude Code can drive. In practice that covers the moving parts of a sprint:
Read the board. List items, their status, assignees, labels, linked issues and pull requests, and custom fields like story points or priority.
Move cards. Change an item Status field so an issue jumps from To Do to In Progress to Done based on real signals rather than memory.
Link work. Match an open pull request to the issue it resolves, add it to the sprint, and flag issues that have no PR and no recent activity.
Triage inbound. Read a new bug report, apply labels, set priority, and drop it into the right column with a short summary comment.
Report. Produce a standup digest or an end-of-sprint summary straight from the board state, not from what people remember.
None of this needs a bespoke integration. It is the gh CLI, a few GraphQL queries, and Claude Code deciding what to run. You describe the outcome in plain English and review the commands before they execute.
A sprint loop that runs itself
The useful pattern is a small set of scheduled jobs, each doing one thing well, with Claude Code as the reasoning step in the middle. Here is a loop we have set up for Australian teams.
Morning triage
A scheduled job wakes at 8am, asks Claude Code to read every issue opened in the last day, and for each one summarises it in two lines, guesses a priority, applies labels, and places it in the backlog column. Anything that looks like a production incident gets flagged for a person immediately rather than filed quietly.
Status from signals
Twice a day, Claude Code cross-checks the board against Git. If a branch has commits and an open pull request, its issue should not still be sitting in To Do. If a PR merged, the linked issue should be Done. Claude Code proposes the moves, and once you trust it, applies them. The board stops drifting from what the code actually says.
Standup without the meeting
Instead of a live standup, a job posts a written digest to your chat channel: what moved, what is blocked, which issues have gone three days without activity, and where the sprint sits against its burndown. People read it in a minute and only meet when something is genuinely stuck.
Each of these is a short prompt plus a schedule. The building block is the same nightly-agent idea covered in our guide to running Claude Code on a schedule, pointed at the Projects API instead of your test suite.
Guardrails for Australian teams
Automation on a code board is low risk compared with automation that touches customers, but a few rules keep it safe.
Keep merges human. Let Claude Code open, label, and summarise pull requests, but a person approves the merge. The cost of a wrong auto-merge dwarfs the minutes it saves.
Mind what leaves your repo. If issues contain customer data, check your obligations under the Privacy Act 1988 before piping issue text into any external service, and keep that content inside tools you control.
Scope the token. Give the automation a GitHub token with access to the one project and the repos it needs, not your whole organisation.
Log every action. Every status change and comment Claude Code makes should be traceable, so you can audit the board history like any other change.
The economics are plain. Claude Code usage for a small team sits in the low hundreds of dollars a month in AUD, call it $200 to $400 depending on volume. If it gives six developers back two hours a week each of board admin, at a blended $120 per hour that is more than $6,000 a month of recovered engineering time. The automation pays for itself many times over inside the first fortnight.
The point is not to remove people from the sprint. It is to remove the clerical work that sits between them and the actual build, so the board reflects reality without anyone maintaining it by hand.
If you want help wiring Claude Code into your GitHub Projects board and your delivery process, we do exactly this for Australian teams. Book a short brainstorm and we will map the first two jobs worth automating.
