最近新增
刚加入收藏的新技能，抢先试用。
decoupler
scverse
Read before any task that mentions decoupler, one of its bundled example datasets, or asks which transcription factors (TFs), pathways, or gene sets are most active, enriched, up or down in expression data - bulk RNA-seq treated vs control, single-cell cell types or clusters, condition contrasts across donors (pseudobulk), spatial transcriptomics regions or niches, and pseudotime or differentiation trajectories - with the exact 2.x workflow (dc.op networks, dc.pp preprocessing, dc.mt scoring, dc.tl ranking) that reproduces the documented results. Also covers decoupler's networks (CollecTRI, PROGENy, DoRothEA, MSigDB), supported organisms/species and ortholog translation, resource licenses, and the conventions for plotting or visualizing its results. Also read for conceptual, best-practice or multiple-choice questions about how an agent should work with decoupler.
Skill review: the default rubric
usirin
added.
writing-plans
Viqto0r
Use when a task is large enough to need more than one or two tool calls — a multi-file change, a new feature, a refactor. Breaks the work into small ordered steps with exact paths and a verification for each.
verification-before-completion
Viqto0r
Use BEFORE declaring a task done or reporting success — a feature, a bug fix, a file you generated. Forces you to run the verification you promised instead of trusting that the code looks right.
test-driven-development
Viqto0r
Use when writing or changing behaviour that can be tested — a bug fix, a new function, a parser, a formatter. Write the failing test first, watch it fail, then make it pass. Prevents tests that only pass because they were written against the finished code.
systematic-debugging
Viqto0r
Use when something is broken and the cause is not obvious — a failing test, a wrong result, a hang, a crash. Four phases: reproduce, isolate, hypothesize, fix. Prevents guessing.
brainstorming
Viqto0r
Use when the operator's request is a GOAL, not a spec — "add X", "make it better", "integrate Y" — and it is unclear what "done" means. Draws out the intent and plays it back before building.
hello-world
LightHeart-Ventures
Greet the user with a friendly, personalized "Hello, World!" — the canonical smoke-test that proves a plugin's skill reached the agent's catalog.
signoz-observability
LightHeart-Ventures
Agent-driven half of the SigNoz Observability plugin. Use when a repo has just been detected/opened and you want an OpenTelemetry instrumentation profile, or after a turn to check SigNoz for fresh exceptions in the active repo's services. Triggers on: "scan this repo for instrumentation", "any new exceptions?", "check signoz", "what services does this repo emit", "observability status". Pairs with the fork/exec scripts in bin/ (which handle the MCP-free REST path); THIS file is what YOU (the agent) follow when the signoz MCP tools are available.
hello-world
LightHeart-Ventures
Greet the user with a friendly, personalized "Hello, World!" — the canonical smoke-test that proves a plugin's skill reached the agent's catalog.
gstack
LightHeart-Ventures
Route a task to the right gstack skill (garrytan/gstack) — plan/spec/ship/review, design consultation + review, QA, iOS live-device workflows, security audit, docs, browser automation. Use when the user says "gstack", names a gstack command (/plan, /ship, /review, /spec, /qa, /cso, …), or asks which gstack skill fits a task.
code-intelligence
LightHeart-Ventures
Graph-first code discovery for this repo via the codebase-memory MCP server. Use INSTEAD OF grep/glob when finding definitions, callers, impact, data-flow, architecture, or hot paths — search_graph, trace_path, get_architecture, query_graph, get_code_snippet.
webhook-broker-flyio
LightHeart-Ventures
Deploy and configure a webhook broker on Fly.io — manage webhooks, event routing, retry logic, and observability for serverless event distribution.
aish-config-guide
LightHeart-Ventures
Comprehensive guide for configuring aish — environment, runtime settings, backend selection, credentials, MCP servers, and operator preferences.
aish_sre
LightHeart-Ventures
Site-reliability & troubleshooting playbook for aish (LightHeart-Ventures/aish), the AI-native Rust shell. Encodes hard-won lessons on the big failure classes — broken releases & ':update' (GitHub immutable releases, pre-publish footgun, tag↔Cargo.toml drift, asset-less releases, burned tags), dev vs production release channels (versioning strategy, release-dev.yml workflow, dev tag naming), cargo-build OOM in coordinator worktrees (the heavy 'local' llama.cpp feature, --no-default-features, flock serialization, jobs cap), the CI test gate (--no-default-features --locked), macOS 'zsh: killed aish' codesign kill-on-launch, runaway background coordinators (loop/turn-budget exhaustion, circuit breaker, turn-audit journals), worktree/git hygiene, command-routing surprises, and runtime/config (ANTHROPIC_API_KEY, MCP startup, modes). Includes step-by-step happy-path runbooks for cutting production (§0) and dev (§0b) releases. Read this FIRST when aish itself is misbehaving, you need to cut/tag a release, a release/CI run failed, a build got OOM-killed, or a coordinator is stuck.
search-skills
LightHeart-Ventures
Find and recommend the best skill for a task. Use when the user asks to find, search, or recommend a skill, or asks "what skill helps with…" / "find me a skill to…". Ranks INSTALLED skills by relevance, and when none fits, recommends an INSTALLABLE one from the offline registry index. This is the user-invoked, richer-UI sibling of aish's automatic per-turn skill-awareness (the [aish skill-awareness] banner) — it does not replace it.
erw-add-connector
SamuelEnrique
Use this skill when asked to add a new ISO, market, node set or other data source to the Energy Research Warehouse (ERW) price connector, for example "add PJM", "add ERCOT load zones", "add IESO prices", "pull another market", or "wire a new source into the daily refresh". Covers the function in warehouse/connectors/iso_prices.py, raw file saving, the completeness rule, table naming, the validator, coverage, the daily workflow and the session report, plus the mistakes earlier sessions made.
warm
leodearden
"Claim a warm, CoW-seeded git worktree for ad-hoc interactive work — 'put me in a warm worktree now' for work that doesn't go through /do. ONLY runs when the user explicitly types /warm — never auto-invoke it. Claims an _iact-* worktree on a task/<slug> branch via the escalation MCP's claim_warm_worktree, whose target/ build cache is seeded from the orchestrator's warm base so the first build recompiles near-zero; cold-falls-back to a plain EnterWorktree worktree (never errors) when the orchestrator/escalation MCP is unreachable or the claim fails."
unblock-low-risk
leodearden
"Autonomous, NON-INTERACTIVE unblock of a single blocked task — but ONLY when the orchestrator's at-block-time dry-run investigation labelled the fix risk_label == 'low'. This is the unattended counterpart to /unblock, built for AFK windows: the L2 escalation-watcher launches it as a sub-agent (no terminal) for task_failure/review_issues escalations whose latest metadata.dry_run_proposals[-1] is low-risk and fresh. It re-derives the fix from the proposal prose, applies it scoped to files_referenced, runs the project verify suite, and merges via the orchestrator merge queue — aborting cleanly (leaving the escalation pending for a human) on ANY doubt: non-low risk, stale proposal, scope creep, rebase conflict, verify failure, or a merge-queue result other than done. A merge the worker has already picked up and is still live at the polling ceiling is handed back to the watcher (outcome handed_off), never cancelled. It NEVER touches main directly, never --no-verify, never retries. NOT for: medium / human-review-required proposals, interactive unblocking (use /unblock), any task without a low-risk dry-run proposal, or post-merge-red-main fix-forward tasks (block reason starts with 'Post-merge unscoped type-check failed' — b3_gate.check_proposal hard-ABORTs this entire class regardless of risk_label; see task 1680)."
unblock-auto
leodearden
"Autonomous dry-run version of /unblock. Investigate a blocked orchestrator task and emit a proposed action — read-only. Use this skill when you need to automatically assess a blocked task without human interaction. Never modifies any state; only reads worktree artifacts, git history, and task metadata to produce a structured proposal for review."
team
leodearden
"Run a piece of work as an agent team — decompose it into seats, route every seat to the model tier (haiku / sonnet / opus / fable) and reasoning effort (low → max) its brief actually rewards, dispatch through the Workflow tool (or the Agent tool for small, adaptive teams), then integrate and verify the results as the lead. ALWAYS use this for: /team commands (/team --fable pre-authorises fable seats for the run), 'use an agent team', 'fan this out to agents', 'parallelise this with subagents', 'run this as a team and use cheap models where you can', 'put haiku/sonnet on the grunt work', or any request to do work with several agents at task-appropriate model and effort levels. NOT for: single-chain work you can do inline, the purpose-built multi-agent surveys (/hotspot-survey), handing a decision to a fresh context (/do), or the dark-factory orchestrator (/orchestrate)."
study
leodearden
Load a deep, discussion-ready understanding of a specific piece of code into context BEFORE reasoning about it. Use whenever the goal is comprehension and readiness rather than an immediate edit — triggers like "read the code for X in detail and get ready to discuss it", "study how X works", "get a deep understanding of X before we talk", or any time the user is about to explore a subtle aspect, do an authoritative analysis of some behaviour/logic, or design a tricky feature/change/refactor. Reach for this even when the user doesn't say "study": any request to get primed on a specific function, class, module, subsystem, or feature ahead of a hard conversation should pull this in.
spawn
leodearden
"Spawn a new Claude Code CLI session in a new terminal window with a given prompt. Use when another skill (such as escalation-watcher) needs to hand a task off to a fresh interactive Claude session running in its own terminal — for example, spawning /unblock <task> so a human can drive it. Triggers on phrases like 'spawn a claude session', 'open a new terminal with claude', 'launch /unblock in a new window'. NOT for: running arbitrary shell commands in a new terminal, or invoking Claude inside the current session (use a sub-agent for that)."
review-briefing
leodearden
"Create and maintain the review briefing — a project-specific context file that tells the /review skill what matters about a project: purpose, important scenarios, architectural decisions, conventions, and known gaps. The briefing captures durable truths that can't be inferred from code alone — not code structure (which goes stale). ALWAYS use this skill for: /review-briefing commands, creating or updating review/briefing.yaml, setting up review context for a project, when the user says 'create a review briefing' or 'update the briefing', and when /review suggests running /review-briefing because no briefing exists. Also use when the user wants to validate their existing briefing or see what's changed. This is NOT for: running the actual review (/review), implementing code, or fixing issues found during review."