Abhinand's Pi Setup: a versioned backup of a Pi coding-agent configuration you can recreate anywhere

A backup-and-restore layer for a Pi agent config

Abhinand's Pi Setup is a personal, versioned configuration for the Pi coding agent: extensions, custom themes, skills, config examples and sync tooling. The README is precise about what it is and is not: it wraps and customizes an existing Pi install, it is not a replacement installer for Pi itself, and it recommends installing the Pi CLI first, then running this setup.

The user is a Pi coding-agent user who wants their agent configuration under version control, backed up to GitHub, and reproducible on a new machine. The problem it solves is that a coding agent's setup, its extensions, themes, skills and settings, lives in a live directory and is easy to lose or hard to replicate when you move machines.

The core model the README states is clean: `~/.pi/agent` is the live Pi setup and the source of truth, while this repository is the versioned `pi-setup` copy used to back that live setup up to GitHub and recreate it anywhere. So it is a snapshot-and-restore layer around the live agent, which is a sensible pattern for any configuration you care about but that otherwise only exists on one machine. It ships no license.

Live directory as source of truth, repo as versioned copy

The design is a deliberate separation of the live runtime from its versioned backup. The README maps the live source of truth as `~/.pi/agent/extensions`, `themes`, `skills`, `settings.json` and `mcp.json`, and the versioned copy as the pi-setup repository, kept in sync from the live files by a sync tool.

That separation matters because it avoids a common mistake: treating the repository itself as the live agent. The README explicitly warns not to install this checkout as an active Pi setup, precisely because the repo is the backup, not the runtime. Confusing the two would be a way to corrupt your working configuration.

The normal flow the README documents is a clean loop: make Pi changes in `~/.pi/agent`, run the sync tool to capture them into the repo, and push to GitHub; then on another machine, clone from GitHub, install the Pi CLI, and restore into `~/.pi/agent`. That is a proper backup discipline, edit the live thing, sync to version control, restore elsewhere, applied to an agent configuration, which is exactly the kind of setup people otherwise forget to back up until they lose it.

Syncing and restoring

The two operations are sync and restore, and the README expresses them as a flow. Capturing changes is: make Pi changes in `~/.pi/agent`, run the sync tool, and the updated files land in the repo for pushing to GitHub. The README's normal flow shows this and the restore path together:

make Pi changes in ~/.pi/agent  ->  pi-setup-sync  ->  GitHub
GitHub clone on another machine ->  install Pi CLI -> ./install.sh --restore --copy-config -> ~/.pi/agent

So on a new machine you clone the repo, install the Pi CLI first (since this wraps Pi rather than installing it), and run the install script with `--restore --copy-config` to recreate your extensions, themes, skills and config into `~/.pi/agent`. The `pi-setup-sync` tool is what keeps the versioned copy current from the live files in the other direction.

The important discipline the README stresses is the order and the boundary: install the actual Pi CLI first, and do not treat this checkout as the live agent. Get those right and the setup gives you a reproducible agent configuration, which for someone who has carefully tuned their Pi extensions and skills is a real safeguard against losing that work or having to rebuild it by hand on a new machine.

The limitations: personal, Pi-specific, and no license

The honest limitation is that this is one developer's personal setup. The README frames it as a personal pi-setup, so the specific extensions, themes and skills reflect the author's preferences, and while the sync-and-restore tooling is generally useful, the bundled configuration is a starting point to adapt rather than a universal one. You would fork it and make it your own.

It is also Pi-specific and Pi-dependent: it wraps an existing Pi install, requires the Pi CLI to be installed first, and operates on `~/.pi/agent`, so it is only useful to Pi coding-agent users and does nothing for a different agent. That is by design, it is a setup for Pi, but it bounds the audience.

The most concrete limitation is legal: the repository ships no license. Under default copyright the author retains all rights, so while you can read it and follow the pattern, reusing the author's specific configuration or the tooling in your own published work is not clearly permitted until a license is added. For a personal setup that you would adapt anyway the practical impact is limited, but anyone wanting to build on it should ask the author for a license.

Against manually copying config or a dotfiles manager

The alternatives are manually copying your `~/.pi/agent` files around, or using a general dotfiles manager. Manual copying works but is error-prone and easy to forget, and it has no versioning, so you cannot see what changed or roll back. A general dotfiles manager handles versioning but is not tailored to Pi's structure and the live-versus-backup boundary the README is careful about.

This repository's difference is that it is a Pi-specific backup-and-restore pattern with dedicated sync tooling and a restore script that knows about `~/.pi/agent`, plus the explicit discipline of keeping the live directory as source of truth and the repo as the versioned copy. The cost is that it is one person's config and unlicensed. Choose manual copying only for a one-off move. Choose a general dotfiles manager if you want to version all your config together and do not need Pi-specific handling. Use this repository as a model, or a fork base, when you specifically want a versioned, GitHub-backed, restorable Pi agent configuration and value the clean sync-and-restore flow it documents.

No license, a clear flow, and where to start

The absence of a license is the first thing to note. As shipped, the repository is public to read and follow but not clearly reusable, so if you want to base your own published setup on the author's tooling, ask for a license. In practice you fork it and replace the config with your own, which is how a personal setup is meant to be used. The last push was on 2026-08-16.

Because it is configuration and scripts rather than a running service, there is no maintenance burden beyond keeping your fork's sync working as Pi evolves, and the boundary the README draws, live directory versus versioned repo, is the thing to preserve.

The concrete first step, if you are a Pi user, is to adopt the pattern rather than the author's exact config: install the Pi CLI, fork this repo, and use its sync flow to capture your own `~/.pi/agent` into version control, then test the restore on a second machine or a clean checkout with `./install.sh --restore --copy-config` to confirm it rebuilds your extensions, themes, skills and config. Heed the README's warning not to install the checkout as your active Pi setup, since the repo is the backup and `~/.pi/agent` is the live source of truth.

Editorial conclusion

Use this repository, or its pattern, if you are a Pi coding-agent user who wants your agent configuration, extensions, themes, skills and settings, versioned in GitHub and restorable on any machine: the clean sync-and-restore flow that keeps ~/.pi/agent as the source of truth and the repo as the versioned copy is its real value. It is not useful if you do not use Pi, since it wraps an existing Pi install and requires the Pi CLI first, and it ships no license, so reusing the author's specific config in your own published work is not clearly permitted. Start by installing the Pi CLI, forking the repo, capturing your own ~/.pi/agent with its sync flow, and testing the restore on a clean checkout, without treating the checkout as your live agent.

Frequently asked questions

Official sources

1. abhinand5/pi-setup on GitHub
2. Issues
3. README