pi-configs

Use structured GitHub tools for pull requests, local code review, review/comment CRUD, issues, and CI. Trigger for GitHub PR/issue inspection or mutation, reviewing a PR, posting or editing comments/reviews, and checking or waiting for CI. Clone or fetch repositories and review locally; never review from an API diff.

Pick which model a subagent should run on, for pi model routing. Use when deciding which model to assign a task to, choosing a model for a subagent, forming a cross-family review quorum, or evaluating whether a model's benchmark claims are trustworthy. Triggers on "which model", "pick a model", "choose a model", "model for this task", "model routing", "subagent model", "model quorum", "beats GPT-5.5", "GPT-5.6", or any model-selection decision. Encodes Matt's defaults (GLM 5.2 default, open-weight bias, cross-family quorums, Fable as a conscious juggernaut, M3 never for coding, GPT-5.6 Sol needs verification gates) and the neutral-eval skepticism every model in the guide failed.

Audit prose for AI-sounding, synthetic, formulaic, or generic writing and revise it without making unsupported authorship claims. Use when asked whether text sounds AI-generated, to find AI writing tells, to humanize or de-slop prose, to compare writing against a personal voice, or to review drafts for canned language, rhetorical templates, mechanical structure, and weak grounding.

Autonomous measurement-driven optimization loop for performance, memory, latency, or binary-size work on real codebases. Generalizes the autoresearch pattern beyond ML into "anything you can build, run, and measure." Treats each change as a falsifiable hypothesis: commit before running, measure after, keep only what improves the primary metric, revert on discard. Use when the user wants to reduce memory/RSS/CPU/binary size, optimize a hot path, hit a latency target, or generally "make X faster/lighter" through iterative experimentation rather than a single rewrite. Triggers on "optimize", "reduce memory", "lower RSS", "make it lighter", "profile and improve", "research loop", "autoresearch", or when a measurable metric and a keep/discard discipline are needed. Do NOT use for bug diagnosis (use hypothesis-driven / systematic-debugging) or greenfield feature work.

The "What Would Matt Do?" operating cycle — apply Matt-calibrated judgment to any non-trivial work before it ships. Use when reviewing/critiquing a PR, issue, plan, or architecture; making a design or scoping decision; delegating to subagents; or pressure-testing your own output for quality. Triggers on "apply WWMD", "what would Matt do", "review this", "critique this", "is this the right approach", or any moment that needs taste + verification rather than just completion. Encodes the lens (prescribed questions + a wildcard), the panel → verify-gate → synthesis recipe, the with-teeth rule, and escalate-only-on-walls.

Write correct, idiomatic Zig 0.15 code. Use when writing new Zig code, editing existing Zig files, debugging Zig compilation errors, reviewing Zig code, or working with build.zig files. Triggers on any task involving .zig files. Critical: LLM training data contains outdated Zig patterns (0.11-0.13) that will produce broken code — this skill provides the current 0.15 patterns.

Write correct, idiomatic Zig 0.15 code. Use when writing new Zig code, editing existing Zig files, debugging Zig compilation errors, reviewing Zig code, or working with build.zig files. Triggers on any task involving .zig files. Critical: LLM training data contains outdated Zig patterns (0.11-0.13) that will produce broken code — this skill provides the current 0.15 patterns.

Use OrbStack on Matt's Mac for Docker/Compose, Linux machines, isolated sandboxes, Kubernetes, networking/domains, file access, SSH, and troubleshooting. Trigger when working with OrbStack-specific commands (`orb`, `orbctl`, `mac`), `.orb.local` domains, OrbStack Docker context/socket behavior, OrbStack machines, isolated machines for untrusted code, or Kubernetes under OrbStack.

Autonomous project-scoped improvement loop for agent behavior, prompts, skills, docs, tests, and workflow. Use at the end of work, after a messy session, when asked to self-improve/reflect/retro, or when pairing with WWMD to turn judgment gaps into concrete repo-local changes. Runs without approval unless it hits an explicit wall.

Use ast-grep for structural code search and safe mechanical refactoring. Trigger when editing code where syntax-aware search or replacement could help: API migrations, call-site updates, import rewrites, constrained renames, repetitive boilerplate changes, auditing patterns across a repo, or before writing ad hoc Python/sed/regex scripts to modify source code. Prefer ast-grep when available over text grep or custom scripts for code-aware rewrites.

Write and edit Nushell (.nu) scripts as a replacement for non-trivial bash scripts. Use when the task involves writing a shell script with logic, data manipulation, structured output, or anything beyond a few simple command invocations. Nushell is the preferred scripting language for complex automation; bash is fine for trivial one-liners and shellHooks. Triggers on: .nu files, requests to 'write a script', or when a bash script is getting complex. Also applies when adding nushell to a nix devshell.

Comprehensive Zig code review across all quality dimensions. Triggers on /zig-review. Runs 7 parallel specialized agents (each on a different model), then a cross-family second-opinion agent on the aggregated result. Always operates on the full branch diff against main. Report-only: never makes changes.

Non-interactive memory curation. Reads each memory file, fact-checks where possible, consolidates, and overwrites. Designed to run via `pi --print --no-extensions --skill`. Logs results to curation.log.

Draft Slack messages in Matt's voice and style. Use when asked to "write a Slack message", "help me respond to this", "write this as me", "draft a reply", or any request to compose or rewrite a Slack message. Writes in a casual, dry, direct style with no bullet points, no filler, and no corporate polish.

Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.

Work within Nix flake-based devShells. Use when working in any project that has a flake.nix, when commands fail due to missing tools, when dependencies need to be added or removed, or when setting up a development environment. Triggers on flake.nix presence, missing command errors, or dependency management tasks. IMPORTANT — always prefer the devShell over installing tools globally or via pip/npm/brew.