| name | reflex-init |
| description | Use this whenever the user runs /reflex:reflex-init or asks to set up, seed, bootstrap, or extend reflex rules for the current project. Proposes a handful of candidate rules for .reflex/reflex.json based on what the project appears to care about, then lets the user pick which to keep. |
| argument-hint | [extra guidance] |
Seed reflex rules for this project
The goal is a .reflex/reflex.json whose rules actually help the next agent working in this repo — not a generic checklist. Quality of the patterns and messages is the product.
Steps
- Read
${CLAUDE_PLUGIN_ROOT}/reflex-format.md. Everything you propose must conform to that schema.
- Read
.reflex/reflex.json if it exists. Don't propose duplicates of rules already present; you may suggest refinements if an existing rule looks clearly broken.
- Explore the project deeply before proposing anything. Launch an Explore subagent with thoroughness
"medium" to survey the codebase: agent-instruction docs (CLAUDE.md, AGENTS.md, README.md, subdirectory CLAUDE.md files), directory structure, sensitive paths, scripts, and any signals about how the team wants agents to behave. If the user passed $ARGUMENTS, include it in the agent prompt as a strong steer. Wait for the agent to return before continuing.
- Propose at most 5 candidate rules. Prefer rules that save the agent from a realistic, repeated mistake in this project over generic best-practice rules. A mix of gentle
proceed reminders and stricter pause / reject guardrails usually serves better than five of the same kind.
- Use
AskUserQuestion (multi-select) to let the user pick which rules to add. Include these non-rule options:
"Propose different candidates" — if chosen, re-run step 4 from a different angle (look somewhere else, lean on a different signal)."None — I'll write my own" — exit without changes.
- Merge the selected rules into
.reflex/reflex.json. Create the file and .reflex/ directory if they don't exist. Preserve any pre-existing rules and keep "version": 0. Close with a one-line summary of what changed.
Why this shape
Generic guardrails that don't match anything real are worse than no rule: they add noise every session. Steps 3 and 4 exist to keep proposals grounded in project-specific signal instead of recognizable directory names.
