I use pi, a terminal-based coding agent, for my work at Vitalize. This is my personal setup, rather than a standard across the team. I like being able to extend it with ordinary TypeScript. An extension can add a tool, describe when to use it, and make it available to the agent alongside its built-in tools for reading and editing code.

That’s useful because I have preferences about the work surrounding a code change, too. How do I want to start a task? What belongs in a pull request? What do I want to look at before sending it for review? I’ve been turning some of those preferences into small tools.

There’s a mixture of code and instructions behind these tools. Predictable operations, like checking repository state, can be handled programmatically. Work that needs interpretation, like explaining a diff, comes back to the model with the relevant context. I can adjust either part as I use it.

One tool handles starting work on a Linear issue. It ensures that the checkout is clean, pulls the latest upstream, then creates a feature branch with the name supplied by Linear, linking it back to the issue. It stops there, leaving me room to work through the plan before asking for an implementation.

Another handles creating a pull request. It gathers the current diff and repository context for the agent to write the title and description, then opens a draft PR. The description follows a format I’ve chosen: background, approach, changes, and validation, with a link back to the issue.

Before marking the draft ready, I do my initial review in GitHub using its built-in PR review feature. I like using the same tool to review my own work that I use to review my peers’ work.

In parallel, I have the agent do a goal-oriented review. It compares the implementation with the original problem and acceptance criteria, looking for gaps between what we set out to do and what the code actually does. That gives me another pass over the work to help catch things I might miss.

After I mark the draft ready for review, feedback comes in from human and automated reviewers. A separate tool brings their comments and the check results into the agent session, where I can group related feedback and work through the changes conversationally.

I built these tools to help me keep several tasks moving and spend more time on planning and design. Engineering can feel jagged when I’m repeatedly switching between high-level reasoning and implementation details. I enjoy being able to spend longer stretches of time planning, followed by longer stretches reviewing and modifying code.