amarbel-llc
OrganizationNix monorepo aggregating dotfiles, system packages, devshells, plugins, and 30+ project repos; published to FlakeHub
Categories
Indexed Skills (37)
file-issue
File a GitHub issue for later triage
fix-issue
Fix a GitHub issue with test-first workflow
loose-ends
Surface deferred work, in-diff TODOs, and adjacent-improvement candidates before `spinclass merge-this-session`. Use when the user asks "any loose ends?", "any followups?", "anything left?", or right before a merge.
doc-drift
Surface drift between the pending diff and the repo's orientation docs --- AGENTS.md (or legacy CLAUDE.md), README.md, and the GitHub repository description --- before `spinclass merge-this-session`. Use when the user asks "are the docs still accurate?", "did this change the README?", "check for doc drift", or right before a merge.
claude-code-plugin-specification
Use when the user asks about "Claude Code plugin", "plugin.json schema", "plugin manifest", "SKILL.md format", "agent frontmatter", "hook events", "plugin marketplace", "marketplace.json", "plugin structure", "LSP plugin", "plugin hooks", "plugin distribution", or needs to verify plugin conformance, understand plugin component schemas, check hook event behavior, or look up Claude Code plugin specification details. Also applies when building or debugging Claude Code plugins and needing authoritative spec details.
mcp-context-saving
This skill should be used when the user asks to "add context-saving", "add pagination", "add truncation", "limit output size", "add offset and limit", "reduce token usage", "add head and tail parameters", "limit results", or mentions unbounded output, large responses, PaginationInfo, TruncationInfo, output size management, or token waste in MCP server tools. Also applies when an MCP tool's output is too long, agent token usage is too high, or MCP responses need size limits.
creating-packages
This skill should be used when the user asks to "add purse-first support", "turn an MCP into a package", "create a package manifest", "add generate-plugin command", "register with purse-first marketplace", "add skills to a package", "bundle skills in a package", "make this available as a Claude Code tool", "distribute this MCP server", "share this CLI with Claude", "set up plugin.json", "ship this as a package", or wants to package an MCP server, CLI, or skill set for distribution via purse-first. Also applies when working in a repo that has a `.claude-plugin/` directory, editing a `plugin.json` or `mappings.json`, or modifying a `flake.nix` that uses `mkMarketplace` or references purse-first as a flake input.
downstream-rust-consuming-purse-first-libraries
This skill should be used when the user asks to "add mcp-server dependency", "depend on rust-mcp", "consume rust-mcp", "build a Rust MCP server outside purse-first", "migrate from amarbel-llc/rust-mcp", or is building a Rust project that depends on purse-first libraries (like mcp-server) from a separate repository. Also applies when encountering dependency resolution questions about git deps vs path deps vs flake inputs for Rust crates across repo boundaries, or when a Rust MCP server needs to work both with and without Nix.
mcp-specification-reference
Use when the user asks about "MCP protocol version", "MCP spec", "protocol negotiation", "MCP capabilities", "MCP transport", "MCP lifecycle", "MCP schema", "initialize handshake", or needs to verify MCP server conformance, understand version differences, check required methods, or look up MCP protocol behavior. Also applies when building or debugging MCP servers and needing authoritative spec details.
purse-first-overview
This skill should be used when the user asks "what is purse-first", "how do packages work", "how does the marketplace work", "getting started with purse-first", "explain purse-first", or is working in a repository that contains a `.claude-plugin/` directory, a `share/purse-first/` output path, a `flake.nix` that uses `mkMarketplace`, or any flake input referencing purse-first. Also applies when the user mentions purse-first without a specific task, wants to understand the package framework, or asks about the relationship between MCP servers, skills, and packages.
using-packages
This skill should be used when the user asks "how do purse-first hooks work", "why is my tool being denied", "how to customize mappings", "troubleshoot package discovery", "how does tool routing work", "how do I override a mapping", "debug purse-first", or is experiencing unexpected tool denials, mapping conflicts, or package discovery failures. Also applies when working with `.purse-first/` project-local overrides, `$XDG_STATE_HOME/purse-first/` user overrides, or `purse-first install` and `purse-first hook` commands.
fdr
Use when the user asks to "create a feature record", "document a feature", "add a feature design record", "record feature design", mentions "FDR", "feature record", "feature design", or is working in a docs/features/ directory. Also applies when a user-facing feature has been implemented and its design intent, interface, and limitations should be documented for future reference.
adr
Use when the user asks to "create an ADR", "add a decision record", "document architecture decision", "record a design decision", mentions "MADR", "decision log", "architecture decision record", or is working in a docs/decisions/ directory. Also applies when making significant architectural choices, technology selections, or trade-off evaluations that should be documented for future reference.
rfc
Use when the user asks to "create an RFC", "write a spec", "specify an interface", "document a protocol", "add an interface spec", mentions "RFC", "specification", "wire format", "API contract", or is working in a docs/rfcs/ directory. Also applies when defining interfaces, protocols, file formats, or API contracts where precision and normative language (MUST/SHOULD/MAY) matter.
adr
Use when the user asks to "create an ADR", "add a decision record", "document architecture decision", "record a design decision", mentions "MADR", "decision log", "architecture decision record", or is working in a docs/decisions/ directory. Also applies when making significant architectural choices, technology selections, or trade-off evaluations that should be documented for future reference.
fdr
Use when the user asks to "create a feature record", "document a feature", "add a feature design record", "record feature design", mentions "FDR", "feature record", "feature design", or is working in a docs/features/ directory. Also applies when a user-facing feature has been implemented and its design intent, interface, and limitations should be documented for future reference.
rfc
Use when the user asks to "create an RFC", "write a spec", "specify an interface", "document a protocol", "add an interface spec", mentions "RFC", "specification", "wire format", "API contract", or is working in a docs/rfcs/ directory. Also applies when defining interfaces, protocols, file formats, or API contracts where precision and normative language (MUST/SHOULD/MAY) matter.
cross-repo-todo-triage
Use when consolidating, prioritizing, or auditing TODO items across multiple repositories in a monorepo, or when checking which TODOs may already be completed
wiring-bats-tests
Use when adding bats integration tests to a Go/Rust/CLI repo, migrating Go subprocess tests to bats, or extending an existing zz-tests_bats setup with new tags, fixtures, or lanes
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
sandcastle
This skill should be used when the user asks to "sandbox a command", "isolate a process", "run in a sandbox", "restrict filesystem access", "restrict network access", "add sandcastle", "use sandcastle", "wrap with sandcastle", "add sandbox to tests", "isolate tests with sandcastle", "set up sandcastle config", "add sandcastle to flake", or mentions sandcastle, bubblewrap isolation, sandbox-runtime, command sandboxing in a Nix project, or preventing tests from accessing secrets.
using-superpowers
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.