WHAT: Run an adversarial interview that stress-tests a raw idea before any building - surface its load-bearing assumption, steel-man the counter-case, register kill-criteria, and end with a go/no-go verdict. WHEN: Only when explicitly invoked - "grill me on X", "interview me about X", "poke holes in this", "stress-test this idea", "is this a dead end", "red-team X", "help me decide if X is worth doing", or "break this big idea into a smaller first version." DO-NOT: Do not fire unprompted on brainstorm-y talk; do not write code or a plan doc (stop at the verdict); do not endorse the idea until a real failure mode and a concrete alternative are on the table; do not cave the moment the user pushes back.
WHAT: Build a behavioral eval that drives a small model of your choice (any pi provider) headless through the pi SDK to measure whether a pi extension / feature actually changes model behavior - does the model READ injected state, ACT on an injected directive, or pick the right memory. WHEN: You added or changed a pi extension that injects context, nudges, recalls, or steers (memory, todo, scratchpad, capture, recall, guardrails) and want evidence it works on a small model, not just on a frontier one. DO-NOT: Use for unit logic that vitest already covers (pure reducers, formatters, scorers - test those offline), for frontier-model-only behavior, or for anything that does not need a live model in the loop.
WHAT: Drive the real `pi` TUI headlessly inside a tmux pane - boot it, send turns and slash commands with `send-keys`, read the rendered screen back with `capture-pane` - to smoke-test or observe behavior that only exists in an interactive session. WHEN: You need a real `/compact`, a slash command, an overlay (`/todos`, `/scratchpad`), a keybinding, or any extension behavior that the headless SDK can't reproduce, especially against a small model. DO-NOT: Use for anything scriptable through the SDK or `pi --print` (those are faster and assert on structured events, not screen scraping) - reach here only for genuinely interactive surfaces.
Persist durable user preferences, validated approaches, project conventions, and reference pointers via the `memory` tool. Save when the user corrects your approach, expresses a preference, validates a non-obvious decision, or references an external system. Do NOT save code patterns, git history, or ephemeral task state - read the code or run `git log` instead. Applies across sessions and workspaces.
WHAT: Choose between the three notes-ish tools - `scratchpad` (turn-to-turn free-form carry-over), `todo` (a typed multi-step plan), and `memory` (durable cross-session facts) - by scope and content kind. WHEN: You are about to jot something down to remember and are unsure which tool holds it. DO-NOT: Persist ephemeral task state into `memory`, use `scratchpad` for a multi-step plan, or hand-edit any of their backing files.
WHAT: Write TypeScript under `lib/node/`, `tests/`, and `config/pi/` that passes the repo's strict `oxlint --type-aware` configuration on the first try, so the husky pre-commit hook does not reject the commit. WHEN: User asks to add or edit a `.ts` / `.spec.ts` file anywhere outside `config/pi/extensions/` (the extensions tree has a relaxed override). DO-NOT: Bypass the rules with `// oxlint-disable` instead of fixing the code.
Prompting rules for **Chenkin Noob XL (CKXL)**, a NoobAI-XL-1.1 *eps* fine-tune. Use when the user asks to generate / draw / render an anime image on a CKXL workflow (v0.2, v0.5, or near-vanilla finetune). CKXL is eps (not v-pred) and uses `artist:name` syntax with anti-furry negatives; it adds CKXL-specific quality tags (`aesthetic`, `excellent`).
Prompting rules for the OnomaAI **Illustrious-XL** SDXL anime / illustration model. Use when the user asks to generate / draw / render an anime / illustration image on an Illustrious-XL workflow (v0.1, v1.0, or a near-vanilla finetune). Illustrious takes plain Danbooru tags + natural language - no `score_N` quality tags and no `@`-prefixed artist tags. Do not use for photorealism.