mode

The user wants to set the pi-delegate mode to: $ARGUMENTS

If $ARGUMENTS is empty, just show the current mode and policy — do nothing else:

node "${CLAUDE_PLUGIN_ROOT}/bin/pi-mode"

For off and soft, set it directly and report the result:

node "${CLAUDE_PLUGIN_ROOT}/bin/pi-mode" <mode>

What the three modes do:

• off — no intervention at all. Suitable for a project pi should never touch.
• soft — nudges when existing product code is touched (default).
• strict — blocks edits to existing product code, requiring pi_dispatch instead.

The mode is recorded against the project root and applied by the project root of the file being edited — not by wherever the session happens to be sitting. A strict project therefore stays strict when edited from another project's session, or from one of its own subdirectories. Report the path the command prints, so the user can see which project the mode actually landed on.

Setting strict: survey the project first

strict is the mode with teeth, so it needs to know what to protect. Without a policy it falls back to a built-in heuristic that only fits one shape — a src/ directory holding .ts/.tsx/.js/.jsx/.mjs/.svelte/.py. On a Go, Rust, Elixir, or <pkg>/-layout Python tree that heuristic protects nothing, and says nothing about it: strict looks switched on and is not. So work out this project's real answer.

1. Look at the project. Read the manifest (go.mod, Cargo.toml, pyproject.toml, package.json, mix.exs, …) and list the top-level directories. You are answering one question: which paths hold product source that should be written by pi rather than by hand?

Typical answers, as a starting point and not a lookup table — the repo in front of you wins over any of them:

Layout	Usually protect
Node / TS	src/**
Go	internal/**, cmd/**, pkg/**
Rust	src/**/*.rs
Python (<pkg>/)	<pkg>/**/*.py
Elixir	lib/**

Test files are NOT an exception. Do not put them in allow. They are the single biggest block of characters in most repos, and dispatching them is the plugin's whole premise — the skill's rule is structural, not about judgment: is this a character that gets committed? then pi writes it, implementation and tests alike. Exempting tests looks reasonable ("the test is the spec, so I should write it") and quietly hands the largest share of the work straight back to hand-typing. That is the exact leak strict exists to close: with a written rule in place and no enforcement, roughly 80% of committed characters were still typed by the main model.

If you want to fix the contract before pi implements it, the contract belongs in the task book — prose you write, not a file that gets committed. And an acceptance test you run yourself to judge the result is fine too, because it is a throwaway you never commit. What must not happen is src/**/*.test.ts landing in the repo from your own keyboard.

allow is for things that are not hand-written source at all: generated code (*.pb.go, *_pb2.py, src/generated/**, snapshots) and framework shells that are config in disguise (src/app.d.ts, src/app.html, a vitest setup file). Getting these wrong is what makes someone switch strict off entirely rather than live with it.

Paths that are simply outside the protected globs — docs, config, migrations you hand-write by policy, fixtures, scripts — need no allow entry at all; they were never protected.

2. Show the user what you propose, and why. List the protect globs and the allow globs, each with a one-line reason, and name anything you were unsure about. Patterns are relative to the project root; ** crosses directories, * stays inside one segment, and a trailing / means "everything under here".

3. Wait for their answer. Do not write the policy until they approve it. They may edit the lists — use what they say, not what you proposed. This confirmation step is the whole reason this is safe: otherwise the model editing the files is also the model deciding which files it may edit.