Why I moved my PM automations from Claude Code into Linear

For a while I’ve been using Claude Code to check whether our PM process is actually running the way it’s supposed to. When a cycle closes, something should look at what carried over and what got added halfway through. Projects drift, target dates slide without anyone writing down why, and the on-call rotation surfaces the same kinds of requests week after week without anyone connecting them. None of that is hard to check for one project. The hard part is seeing it across all of them, every week, and there isn’t a good way to do that by hand.

This isn’t the judgment part of the job. Deciding what to build, what to cut, and what a slipping project actually means still belongs to people. It’s the upkeep underneath that, the part that keeps the system healthy and flowing so those decisions get made well.

The first version was a set of skills that called the Linear API directly, split up by cycles, projects, and on-call. Some of them I ran by hand when I remembered to, and others ran on a Claude Code routine. It worked, but either way it was a personal tool. The skills were mine, the routines were mine, and if I didn’t run them or set them up, nothing happened. If someone wanted to change what the cycle review looked for, they had to ask me. It was never going to become how the team worked, it was just a thing I had.

Linear shipped Loops in July, recurring workflows for their agent that run on a schedule or when something happens in the workspace. The first version was aimed at things like bug triage and routing requests. The September 14 update is the one that got my attention. Loops can now trigger when a cycle starts or completes, when a project’s status, owner, or target date changes, and when issues change. They can also edit Linear docs and post to Slack. That covered most of what I was doing, and I wanted to try it. It also seemed easier to run it right next to the work instead of reaching in from outside.

Moving over was about as easy as I expected, mostly because nothing about it was locked into Claude Code. The logic was prompts and context, not infrastructure, so it could go wherever made the most sense. I didn’t write a spec. I told Claude what I’d been doing, which skills I had and what each one looked at, and asked it to give me something to seed the Linear agent with. That was enough to get the loops set up. Most of what makes automations like these work lives in your head and your config, and asking an agent to write it down is cheap.

Now anyone on the team can see the loops, see when they run, and change them. It went from my thing to a team sport.

How I set them up

The loops do more than report. They nudge people and update projects and issues directly, but only the upkeep: goals, owners, specs, and dates. What to build and what to cut stays with people. The project loop runs weekly and makes sure every project has a clear goal and an owner, that the spec stays current when the work or the comments underneath it move, and that slipping dates get called out. The cycle loop runs on a schedule just before each cycle starts, so carryover and loose ends get sorted out before the cycle instead of after.

The on-call loop runs every day. It gives whoever is on call a pulse on what came in that day, checks that support escalations are turning into Linear issues and getting closed in a reasonable time, and helps them see what they triaged from a step back so they can prioritize and pick up cleanly the next day. Once a week, a separate loop goes back through everything on-call handled and looks for patterns, like the same kind of ticket coming in over and over or one part of the product that keeps generating work. That one is less about keeping the queue moving and more about what the queue is telling you, whether that’s something to fix in the product or something to change about the process.

Out of the box, a loop runs and that’s it. I added a few things on top that don’t come built in.

Every run writes a dated entry to a Linear doc for that loop, saying what it did and why, so each doc becomes a running record of the loop itself. When an agent is changing things in your workspace, you want to be able to see what it touched and when.

That record also means each run starts with context from where the last one left off. The most practical effect is that it doesn’t over-nudge. If it already asked someone to fill in a project’s goal last week, it knows that, and it doesn’t ask the same way again this week. The goal is to keep things healthy and flowing, not to become the bot everyone mutes.

Each entry also ends with a short self-review, what the agent learned that run and what it would do better next time. The next run picks that up along with everything else, so the loop has a way to get better at its job instead of repeating the same run forever.

What I don’t know yet

It’s early, and nothing surprising has come out of these yet. That’s mostly expected, since a record like this only pays off once there are enough entries to compare. I’ll know in a few weeks whether the look-backs catch things a person wouldn’t have. Same with the self-review. I can see it writing the notes, but it’s too soon to tell whether later runs are actually better for them.

It also isn’t a replacement for everything the skills did. With Claude Code I could go back and forth, ask follow-up questions, and dig into something odd. Loops are better at the recurring grunt work, at least for now. And they aren’t free: they’re on Linear’s Business and Enterprise plans and run on AI credits, so it’s worth being picky about which ones earn a spot.

The bigger lesson

There’s a common take right now that tools like Claude Code are eating everything, and that any product adding its own agent features is already behind. My experience was the opposite. The projects, cycles, and issues are in Linear, the team is in Linear, and once Linear had the pieces, it made more sense for the automation to live there, as close to the work as possible, than to reach in from my setup.

I think that’s the product lesson, and it cuts against the fear of being late. If you own the place where the work happens and you build a decent on-ramp, people will move in, as long as moving in is easy. This was easy.