For developers

octo — set a repo up, turn issues into pull requests, watch CI, merge, and cut a release.

octo is the other half: the GitHub side, for the person who reviews what the makers send and lands it.

/plugin install octo@kaeru-plugins

Setting a repo up

`/octo:init` — a repo from nothing

git init, first commit, creates the GitHub repository, pushes, and offers to scaffold the issue-driven templates. For a folder that is not a repo yet.

`/octo:setup` — the templates, in an existing repo

Writes the issue templates, the pull request template, and optionally the Actions that open a pull request from an issue automatically. Run it in a repo that already exists.

There is also a setup-cicd skill for a repo with no .github at all, which scaffolds the whole flow rather than only the templates.

`/kaeru:setup` — the map, for the makers

From the other plugin, but this is the developer's job: it writes .kaeru/where.md so the maker's edit commands know where text, images and colours live in this particular project. One command, once per repo, before you hand it to anybody.

`/octo:whoami` and `/octo:config`

Who am I acting as — git identity, GitHub account, current repo and branch — and the one that fixes it when the answer is wrong. Worth running first on a new machine, and the first thing to check when a gh command 403s while git push works.

The daily loop

Command	What it does
create-issue (skill)	Opens an issue from the repo's own template, with the fields filled in from the conversation
`/octo:create-pr`	Issue → branch → pull request in one shot, and leaves you on the branch ready to work. The fallback for when the repo's auto-PR Action cannot run
`/octo:fill-pr`	Writes the pull request description from the actual changes, following the repo's template — before review
`/octo:checks`	CI status for a pull request, or the latest runs. Re-runs them
`/octo:merge`	Merges a reviewed pull request — after verifying CI is green and it is approved
`/octo:cleanup`	Lists and deletes branches whose pull requests are already merged
`/octo:release`	Cuts a release through the repo's flow, and drafts the notes in plain language for the people who use the thing

> /octo:checks 48

  PR #48 · change the homepage heading

    lint ........... ✅ passed    12s
    typecheck ...... ✅ passed    31s
    test ........... ✅ passed  1m04s
    build .......... ⏳ running

  Approved by you. Mergeable, no conflicts.
  Ready to land once the build finishes: /octo:merge 48

Reviewing what a maker sent

The pull request is written for the person who approves it: one sentence on what changed, the page to look at, before and after, anything they flagged as uncertain, and the technical detail folded into a <details> block for you.

Two things worth doing on your side, which the maker is not expected to do:

Merge it with the latest main and walk the feature, rather than reading the diff alone. Two changes that are each fine can still be wrong together.
Look at the section where they said what they were unsure about. That is the part they want your judgement on, and it is usually the part worth your attention.

Coming later

An /octo:sanity command is planned to automate the reviewer's side of this — a worktree per pull request, the combined-merge test, before-and-after screenshots — along with a portal where makers see every review in one place instead of a PDF per round.

Maintaining the plugins themselves

/octo:sync-templates syncs the repo's canonical .github templates into octo's bundled assets, so /octo:setup keeps scaffolding the current version rather than last quarter's.

One rule if you edit a plugin: bump the version in plugin.json in the same commit. claude plugin update compares versions and stops at "already at the latest version" when it matches, and there is no force flag — so a change published without a bump reaches nobody, however often they update. CI enforces it.

On this page