en un clic
dot.nix
dot.nix contient 9 skills collectées depuis TophC7, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
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.
How to author, edit, and validate Sworm's per-project task config at `.sworm/tasks.json`. Use this skill whenever the user asks to add, edit, rename, remove, or troubleshoot a Sworm task; whenever they mention `tasks.json`, `.sworm/tasks.json`, the task launcher, the title-bar task menu, the command palette's task entries, or task tabs; and whenever they describe wanting to wire up a reusable terminal command (build, dev server, lint, typecheck, test) for the project. Also trigger when the user is starting a new Sworm project and needs a tasks file scaffolded.