Reference for creating and configuring OCI container stacks using the mix.nix oci-stacks NixOS module. Use when writing virtualisation.oci-stacks definitions, Docker container orchestration in NixOS, or working with container networking/systemd integration.
Project-agnostic adversarial code review. Reads the project's conventions first (CLAUDE.md, AGENTS.md, comment-style, manifest), then dispatches a six-scope swarm of agents in parallel — Architecture Fit, Reuse, Idiom Compliance, Quality, Efficiency, Comment Style — and collapses all findings into a single severity- sorted card list. Use when users ask to "critically review", "critique", "find issues in", "what's wrong with", or "review this PR / diff / code". Severity tiers: Blocking, Required, Suggestion.
Review changed files for reuse, quality, and efficiency, then fix issues found.
Toph's code commenting conventions and label system. Use whenever writing, reviewing, or generating code in any language — JavaScript, TypeScript, Svelte, Rust, Python, Go, Java, Nix, CSS, shell, fish, yuck, anything. Governs how comments are formatted and labeled. Trigger for any code generation, review, refactor, or file creation. Even when the user doesn't mention comments explicitly, follow these conventions.
Create a conventional commit from currently staged git changes. Use when the user wants to commit staged work without modifying files. Inspect the staged diff, write an appropriate conventional commit message, attempt the commit once, and stop immediately if it fails.
Expert Fish shell configuration including config files, functions, abbreviations, prompts, environment variables, and scripting. Use when setting up Fish, creating aliases/functions, writing Fish scripts, configuring prompts, or migrating from bash. Keywords: fish shell, fish config, alias, abbr, function, prompt, fish script, config.fish, autoload.
NeoForge 1.21.1 API and modding reference database. Consult this when working in a NeoForge project and you're uncertain about API specifics, method signatures, registration patterns, correct class names, JSON formats, or NeoForge-patched behaviors. Also consult when the user explicitly asks you to check the NeoForge docs. This is not needed for general knowledge you're already confident about -- only when you'd benefit from verifying details against the official documentation.
Create a pull request from the current branch's committed and pushed changes. Use when the user wants to open a PR without modifying files. Inspect the branch, commits, and diff against main, push the branch if needed, create the PR once with a concise title and summary, and return the PR URL.