Rhiza Status

---
name: rhiza-status
description: Report this repo's rhiza state — whether the config is valid, and what was actually synced. Read-only. Add --files for a tree of managed files, or --check for upstream drift.
---

> **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:**

| half | file | question |
| --- | --- | --- |
| **config** | `.rhiza/template.yml` + repo structure | is what we'd sync *from* well-formed? |
| **sync** | `.rhiza/template.lock` | what was actually synced, and when? |

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.

```bash
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

```bash
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`.