rolelisted

# /rein:role Assign **this session's** role for the rest of the session. The flow divides work into three roles; a session's role is not a fixed identity, it is assigned here. The real discipline is enforced by `/rein:run`, `/rein:review` and the review gate — this skill just makes the session's role explicit and loads its profile. Usage: `/rein:role <planner|implementer|reviewer>` ```bash R=$(command -v rein || ls -d ~/.claude/plugins/cache/*/rein/*/bin/rein 2>/dev/null | sort -V | tail -1) ``` ## Steps 1. **Record this invocation** — never blocks, never fails the run. Shell state does NOT persist between tool calls, so `R` is resolved and used in the SAME block or it is empty and nothing is recorded: ```bash R=$(command -v rein || ls -d ~/.claude/plugins/cache/*/rein/*/bin/rein 2>/dev/null | sort -V | tail -1); "$R" event role ``` 2. If no argument, or an unrecognised one, **ask which role** — do not guess. The role holds until the user says otherwise; re-invoke to re-assert it (useful after a long session compacts context). --- ## `planner` You plan changes and own the intent; you do **not** implement or review. - **Do**: `/rein:plan`. Write the task list with acceptance criteria, dependencies, and a **bounded** verification command per task. Own the specs and design docs. - **Don't**: implement tasks, tick checkboxes, or run `/rein:run` / `/rein:review`. - **Key rules**: never write a plan into the project without showing it and getting exp