sidekitten is a coding agent sidekick for Claude Code: a plugin that scopes work and builds one reviewable slice at a time.
You decide scope and architecture before coding starts, then review small changes that extend a working path through the system.
Don't give an agent the whole ball of yarn.
Long plans and parallel agent work can produce a lot of code before you have much working behavior to judge. It can be difficult to see how the pieces fit together, even with green tests, or where shortcuts will surface later.
sidekitten turns a scoped plan into small, dependency-ordered issues. Each behavior-changing issue extends a working end-to-end path and includes something you can run and review before moving on.
The goal isn't less agent autonomy. It's to make that autonomy easier to follow, verify, and maintain.
In Claude Code, add the sidekitten marketplace and install the plugin:
/plugin marketplace add gustinio/sidekitten
/plugin install sidekitten@sidekitten
Manual install
Prefer to inspect or copy the skills directly?
Clone sidekitten:
git clone https://github.com/gustinio/sidekitten.git
cd sidekittenCopy the skills to your Claude Code user directory:
mkdir -p ~/.claude/skills
cp -r skills/* ~/.claude/skills/The skills will be available across your Claude Code projects.
Copy the whole skills/ folder, including _shared, which holds the reference files every skill reads.
Start a new Claude Code session afterwards if a skill is not recognized.
To make the skills available only inside a specific project:
mkdir -p /path/to/your-project/.claude/skills
cp -r skills/* /path/to/your-project/.claude/skills/Replace /path/to/your-project with the path to the project where you want to use sidekitten.
Copy the whole skills/ folder, including _shared, and start a new Claude Code session afterwards if a skill is not recognized.
With a manual install, invoke skills without the sidekitten: prefix, such as /scope-feature.
Have an existing project and a feature you want to build?
Run:
/sidekitten:scope-feature
Describe the feature. sidekitten explores the existing project, confirms the important decisions with you, and proposes a dependency-ordered set of issues.
Review the proposed scope and approve the issue set. Then run:
/sidekitten:ship-next
sidekitten takes the next ready issue, implements it, reviews the change, runs its demo when applicable, and prepares the PR or MR.
Review and merge it, then run /sidekitten:ship-next again.
scope → approve issues → ship one → review → merge → repeat
Each behavior-changing issue should leave you with something new you can run and observe through the real system.
Starting a project from scratch instead? Use /sidekitten:scope-project.
Only want agent documentation for an existing repository? Use /sidekitten:scope-docs.
| Command | Use it when | Outcome |
|---|---|---|
/sidekitten:scope-project |
Starting a project or documenting an existing repo | Interviews you, writes project documents, reviews the plan, and proposes issues for your approval. |
/sidekitten:scope-feature |
Adding a feature to an existing project | Scopes the feature and proposes issues for your approval. |
/sidekitten:scope-docs |
An existing repo only needs agent instructions | Writes AGENTS.md and optionally minimal architecture or README documentation; stops without planning issues. |
/sidekitten:ship-next |
Approved issues exist, including after a merge | Implements and reviews a ready issue, then prepares its PR or MR content. |
You approve the issue set before creation.
sidekitten handles one issue per /sidekitten:ship-next run, even when several independent issues are ready.
sidekitten checks the change and prepares a PR, but never merges it. Those checks do not guarantee correctness, so your team can have a person or an agent review and merge the PR.
I prefer human review on each PR so engineers stay informed about the architecture and what ships; delegating review takes less human effort but can leave the team with less context.
Skills run by each command
On a passing path, the skills run in this order:
scope-project
→ review-plan
→ plan-to-issues
→ your issue-set approval
→ issues created
scope-feature
→ review-plan if it extends an existing plan
→ plan-to-issues
→ your issue-set approval
→ issues created
scope-docs
→ agent documentation only
ship-next
→ implement-issue
→ review-change
→ create-pr
→ PR review and merge outside sidekitten
review-plan checks readiness before issue creation.
plan-to-issues proposes small, dependency-ordered issues and creates only the set you approve.
implement-issue builds one approved issue.
review-change separately inspects the diff and reruns its demo when one applies.
create-pr prepares PR or MR content and, when a remote is available, asks whether to push and which branch to target.
You can also invoke the underlying skills directly:
/sidekitten:review-planafter editing a plan/sidekitten:implement-issue <n>for a specific issue/sidekitten:review-changefor a separate review/sidekitten:create-prfor a verified branch kept local
pressure-test is independent of the workflow above. Run /sidekitten:pressure-test directly to challenge a document, table, or decision for gaps and contradictions.
With a GitHub origin and working gh authentication, sidekitten uses GitHub Issues and can open a PR after you confirm the action and target branch, even when the issue branch was already pushed.
Without that setup, scoping offers local issue files under:
.sidekitten/issues/
Before writing them, sidekitten checks that .sidekitten/ is ignored and asks to add and commit the rule to the project's .gitignore if needed.
Local issue mode is designed for one persistent checkout. The approved issues, dependencies, and status are not shared through Git, so a teammate or fresh clone cannot continue the plan unless .sidekitten/ is deliberately transferred.
Use GitHub Issues when the issue set needs to be shared across checkouts.
Local mode can still push a branch to a configured remote after your confirmation and gives you copyable PR or MR text, but you open it yourself.
See the local issue format for details.
For a new directory, /sidekitten:scope-project initializes Git, asks you to review the generated files and approve an initial commit, then proposes issues.
For an existing repository, sidekitten asks you to approve a commit of the reviewed planning documents before proposing issues. This ensures issue branches start from the committed scope you approved.
It proposes one issue set covering every phase of the approved plan, accounting for pipeline issues that already cover some work.
Before the first issue branch, sidekitten may ask you to commit a .gitignore rule for its local progress files if the base branch does not already have one.
During /sidekitten:scope-project, you also choose the CI host. The bundled GitHub Actions workflow is generated only if you choose GitHub Actions.
Thanks go to the maintainers of structured agent workflows such as Superpowers and Spec Kit for ideas that helped shape sidekitten, and to Matt Pocock, whose grill-me skill inspired the interview step.
The tracer bullet and vertical slicing ideas in The Pragmatic Programmer inspired the requirement for a working end-to-end path.
sidekitten aims for more concise, clearly structured agent docs, approved issues that add runnable end-to-end behavior, and a separate demo check before PR handoff.
This workflow will improve by meeting more real projects.
If you have feedback or ideas for improving any part of sidekitten, please open an issue.
PRs are welcome too. Please keep changes consistent with sidekitten's workflow and follow the writing style for prose.
sidekitten is licensed under MIT; see LICENSE.