jebel-quant/rhiza-claude/rhiza-status

**Portable copy of plugin/skills/status/SKILL.md, generated by

plugin/scripts/build_bundle.py. Edit the source and run make bundle —

an edit here is overwritten.**

- `${RHIZA_ROOT}` is your rhiza-claude checkout. Export it, or

substitute the path wherever it appears. Any remark below about the

variable being empty in a source checkout is Claude Code's spelling of the

same idea — ${RHIZA_ROOT} replaces it, and the repo-relative fallbacks do

not apply, because you are working in the user's repo, not in this one.

- `/rhiza:<name>` names another skill in this bundle, rhiza-<name>.

Invoke it however your client invokes skills.

- Tools. Read, Edit and Write read and write files; Grep and

Glob search; Bash is a shell in the user's repo. Use your equivalents.

- `AskUserQuestion` is a multiple-choice question put to the user. With no

such tool, ask in plain text, number the options, and wait for a reply:

where the procedure says nothing is created without an explicit selection,

that holds however the question was asked.

- Arguments: [path to a repo root] (optional; defaults to the current repo).

The text below writes $ARGUMENTS for what the user passed;

substitute it yourself if your client does not.

- Runs: uv. Nothing here enforces that list, where the

plugin's frontmatter did — your client has to permit them.

You are running /status in the current working directory's repo.

A repo's rhiza state has two halves, and this reports both:

They can disagree in both directions, which is why reporting one without the other misleads: a freshly /init-ed repo has a valid config and no lock at all, and a long-synced repo can have a lock alongside a config someone has since broken by hand.

This command is a thin wrapper around two bundled scripts — plugin/scripts/validate.py and plugin/scripts/status.py, both deterministic and stdlib-only (no rhiza CLI, no PyYAML). Do not re-implement the parsing or gather fields yourself; run them and relay the output.

Purely descriptive: it reports; it does not score, fix, or file anything.

Argument (optional): $ARGUMENTS — a path to the repo root to inspect; default is the current directory.

1. Validate the config

${RHIZA_ROOT}/plugin resolves at runtime (keep the quotes); in a source checkout it's empty, so fall back to the repo-relative path.

uv run --python 3.12 --no-project python "${RHIZA_ROOT}/plugin/scripts/validate.py" $ARGUMENTS

It checks more than the file: that the target is a git repo, that it has the expected language-specific structure (a pyproject.toml is required for Python), that template.yml exists and parses, and that its fields are present and well-typed. It exits non-zero on any of those failing — that's its contract as a gate, so it stays usable in CI. Here, treat a failure as a finding to report, not a reason to stop: still run step 2, because a broken config alongside a good lock is exactly the situation worth surfacing. Lead the report with the validation failure.

If there's no template.yml at all, the repo isn't rhiza-managed. Say so and point at /rhiza:init; skip step 2.

2. Report the sync state

uv run --python 3.12 --no-project python "${RHIZA_ROOT}/plugin/scripts/status.py" $ARGUMENTS

Flags, added only when the user asks for them:

• --json — machine-readable; the default is the human summary. (Its files array

is always present, so --json and --files don't combine usefully.)

• --files (alias --tree) — list the managed files as a directory tree beneath the

summary. This is the view the retired /rhiza:tree gave.

• --check — compare the pinned ref to the latest upstream release via

git ls-remote --tags (no gh, no auth) and print an Update line, e.g. v1.0.0 → v1.2.0 (2 releases behind) — run /update, or up to date. The only part of this command that touches the network; a git or network failure is reported, never fatal.

3. If a script can't run

If uv is missing, or a script isn't found at either path, report that plainly and stop — don't hand-roll the status or the validation as a substitute.

4. Relay the results

Show each script's output as-is; both are already formatted. Then, at most one short line tying the two halves together — whether the config is sound and how fresh the sync looks. No scores, no recommendations.

Two non-error states worth naming explicitly rather than reporting as failures:

• `No template.lock found` — the repo is configured but never synced. Point at

/update, which performs the first sync.

• Config valid, lock present, `--check` says behind — normal; that's what

/update is for.

For an assessment rather than a report, point the user at /quality.