I build and maintain Pi extensions — local-first tooling for the Pi coding agent. Most of my AI time goes into implementation, review and release engineering for those projects: the agent writes, I review and own the release.
What I use AI for
- Implementing features and fixes in a Pi extension repository, one reviewable slice at a time.
- Reviewing changes: a second pass over the diff, test output and docs before I accept them.
- Release engineering: version statements, changelog, packaging checks and a tagged publish.
- Documentation and audits: keeping a roadmap, ADRs and the README consistent with what shipped.
Agents & harnesses
- Pi (current): my main coding agent, running in the terminal with extensions added as packages.
- Codex (installed): available as a second CLI harness, not my default.
How I customise my agents
- Written agent rules (current): a global
AGENTS.mdsets instruction precedence, git discipline, verification and privacy rules, and each repository adds its ownAGENTS.mdwith that project's invariants. These are instructions I wrote for the agent, not a claim about what it always does.
Everyday tools around the agent
- herdr (current): the terminal workspace I run agents in, instead of tmux.
- Alacritty + zsh (current): the terminal and shell around it.
- Neovim (current): reading and editing outside the agent.
- GitHub CLI (current): pull requests, releases and repository metadata.
Extensions I run in the agent
- pi-subagents (current): delegating a bounded task to a child agent and waiting on the result.
- pi-lens (current): LSP diagnostics, symbol search and structural search while editing.
- Superpowers (current): the skill chain I use for feature work — brainstorm, plan, tests first, review.
- context-mode (current): running code and indexing local files in a sandbox so large outputs stay out of the conversation.
- pi-rtk-optimizer and pi-toon (current): compacting command output and shaping what enters context.
- pi-permission-system (current): the permission gate on tool calls.
- pi-goal and rpiv-todo (current): goal contracts and task tracking for longer runs.
- Pi Session Inspector (current, my project): session analytics for token usage, cost, models, tools and subagents — the observability layer I built and use.
- pi-usage, pi-tool-stats and pi-token-count (current): usage, tool and token counters.
- pi-pr-review (current): a review pass over a pull request.
- pi-web-access and pi-mcp-adapter (current): web research and MCP connections.
Skills
Personal
- graphify (current): building a local knowledge graph over a repository before larger changes.
Shared
- context7-mcp and find-docs (current): current library and API documentation.
- hf-cli (current): Hugging Face Hub work.
From installed packs
- Skills from superpowers, ponytail, pi-subagents, pi-lens, context-mode and pi-mcp-adapter.
Connections & context
- MCP gateway (current): connections reach the agent through one adapter registration instead of one integration per service. Endpoints and credentials stay local.
- mysetup (current): maintains this page.
What runs where
- Windows host (current): the desktop I work at.
- WSL2 Ubuntu (current): where the agent, terminals and repositories run — 16 CPUs, 47 GB RAM.
How I work
- I start from the project's roadmap and ADRs, then cut the work into small independently reviewable pull requests rather than one long branch.
- Before anything counts as done I want the evidence: the focused test on the changed behaviour, the full suite, typecheck, lint and the packaging check.
- Changes land through a pull request with the required CI checks green; release steps — version bump, changelog, tag, publish — are separate and explicit.
- When work touches durable docs, the agent audits the tree for statements that no longer match what shipped, instead of fixing only the file I remembered.