Lesson 12 — Further Reading
The Rhiza repos contain detailed documentation beyond what fits in this curriculum. This lesson maps that material by topic so you can go deeper on whatever is most relevant to you.
Every link below was checked against the current main of each repo. Rhiza's own documentation moved into topic folders (docs/guides/, docs/reference/, docs/development/, docs/ops/) — if you have older bookmarks to flat docs/*.md paths, they will 404.
Getting started and command usage
The primary interface is the rhiza plugin shipped by rhiza-claude, documented on its docs site — a page per command.
Core reference
These live in rhiza/docs/.
Customisation and extension
| Document |
Repo |
What it covers |
| guides/CUSTOMIZATION.md |
rhiza |
local.mk, local-setup.sh, [tool.rhiza-task], .rhiza/.env — the full menu of extension points, rewritten for the retired make layer |
| guides/EXTENDING_RHIZA.md |
rhiza |
Comprehensive worked examples for extending Rhiza-based projects — patterns and best practices |
| guides/DEMO.md |
rhiza |
A guided walkthrough of the template in action |
Bundle-specific documentation
Command reference
Each command has a dedicated page on the rhiza-claude docs site. The ten below are the complete set as of v0.13.0. Note the URL path: since v0.7.0 the commands ship as skills, and the docs moved from /commands/ to /skills/ with them — old bookmarks will 404.
| Document |
Command |
What it covers |
| init |
/rhiza:init |
Make a folder rhiza-managed: write the pointer, add a Python/Rust/Go skeleton and license, open PR #1. Syncs nothing |
| update |
/rhiza:update |
Bump the ref, sync the template, resolve conflicts upstream-side, and open a PR of template-owned files |
| quality |
/rhiza:quality |
Run the code-quality gates and score the repo; optionally file findings as issues. Degrades to a design-led assessment on an unmanaged repo rather than refusing |
| docs |
/rhiza:docs |
Write or refresh README.md, CLAUDE.md, and mkdocs.yml, preserving hand-written prose |
| release |
/rhiza:release |
Offer the legal next versions as a table, bump every declared location, regenerate CHANGELOG.md, and open a release PR; run it again after the merge to tag |
| status |
/rhiza:status |
Validate the config and report the lock; --files for a tree, --check for whether you are behind |
| remote |
/rhiza:remote |
Read CI on the origin for the open pull/merge requests, reproduce the red ones locally, and push fixes to their branches |
| completions |
/rhiza:completions |
Install shell completions for the tasks the repo's pinned rhiza-task exposes |
| detach |
/rhiza:detach |
Delete every file the lock records and the lock itself; destructive, prompts unless --force |
| maffay |
/rhiza:maffay |
A bonmot from a random Peter Maffay song |
Renamed and retired commands. /rhiza:uninstall became /rhiza:detach in v0.7.0. /rhiza:validate is now part of /rhiza:status, and /rhiza:revisit was renamed /rhiza:docs. /rhiza:stats, /rhiza:repos and /rhiza:new are gone. The version-matrix and coverage-badge logic that used to be user-run rhiza-tools commands lives inside the template's reusable CI workflows (rhiza_ci.yml), so there is nothing to invoke by hand.
The task runner and the checks
Both are pip-installable packages rather than synced files, so their documentation lives with them rather than in the template.
| Document |
Repo |
What it covers |
| rhiza-task README |
rhiza-task |
The task registry, [tool.rhiza-task] settings and their resolution order, and how a repo adds a task of its own through an entry point |
| pytest-rhiza README |
pytest-rhiza |
The conformance checks the rhiza-test gate runs, and why they became a dependency instead of a synced folder |
| ADR-0011 |
rhiza |
The decision behind both, including the amendment that moved the Makefile shim back into core |
rhiza-hooks reference
| Document |
What it covers |
| rhiza-hooks docs site |
The hooks, rendered and searchable |
| API reference |
A page per hook — config, Makefile-target, workflow-task, per-language version-consistency, bumpversion, template-bundle, managed-file, test-layout, licence-metadata and README-help checks — plus the shared internals |
| rhiza-hooks README |
Installing the hooks and wiring them into .pre-commit-config.yaml |
Operations and security
Design decisions
Rhiza records its architectural decisions as ADRs, in docs/adr/. They are the best available answer to "why is it like this?" — including several questions this curriculum raises.
| ADR |
What it decides |
| 0002 |
Use uv for Python package management — the background to Lesson 2 |
| 0004 |
Adopt a modular Makefile architecture — superseded by 0011, kept because the problem it names recurs |
| 0005 |
Separate the template from the CLI — the decision that eventually led to rhiza-claude |
| 0006 |
Organise templates into bundles — the model taught in Lesson 5 |
| 0010 |
The layered bundle and profile model |
| 0011 |
Replace the synced make layer with a pinned CLI — the v1.4.0 change behind Lessons 5, 10 and 11, and the best single explanation of why a template should distribute config but not code |
Cross-repo testing
| Document |
Repo |
What it covers |
| README.md |
rhiza-brainbug |
The cross-repo test harness: how polling detects upstream commits and dispatches brainbug test runs |
Day-to-day operations
Rhiza once shipped a .rhiza/docs/ set — WORKFLOWS.md, RELEASING.md, TOKEN_SETUP.md, PRIVATE_PACKAGES.md — into every managed project. That folder is gone; the material that survived is in the template's own docs/ tree, and the release mechanics are now the /rhiza:release command's business rather than a document you follow by hand.
Contributing to Rhiza
A rhiza-managed repo keeps its contributor guide under .rhiza/, alongside the rest of its managed files. rhiza-claude and rhiza-task are not managed repos — a plugin marketplace and a published package respectively — so theirs sit at the root.
Back to: Lesson 11 — The Rhiza Ecosystem | README