Comments
Code comments and annotations
seuratmap2ref
by pwwang
Map query single-cell datasets to high-quality reference atlases using Seurat's reference mapping workflow. Performs label transfer, UMAP projection, and integration with reference annotations without modifying query expression data. Enables transfer learning from curated atlases like Azimuth PBMC or custom tissue-specific references.
by AutumnsGrove
"Comprehensive PDF manipulation, extraction, and generation with support for text extraction, form filling, merging, splitting, annotations, and creation. Use when working with .pdf files for: (1) Extracting text and tables, (2) Filling PDF forms, (3) Merging/splitting PDFs, (4) Creating PDFs programmatically, (5) Adding watermarks/annotations, (6) PDF metadata management"
bilibili-live-comments
by LIghtJUNction
Use when reading, polling, or sending Bilibili live-room comments/danmu. Uses public APIs for reading when possible and .env BILI_COOKIE for authenticated send.
code-explanation
by joaquimscosta
Explains complex code through clear narratives, visual diagrams, and step-by-step breakdowns. Use when user asks to explain code, understand algorithms, analyze design patterns, wants code walkthroughs, or mentions "explain this code", "how does this work", "code breakdown", or "understand this function".
address-review
by gopherguides
"Address pull request review feedback from humans or bots. Use when existing comments, requested changes, unresolved review threads, or CodeRabbit/codex review findings need code fixes, verification, push updates, and thread resolution. SKIP fresh code-review requests with no existing feedback; use review-deep."
explain
by gopherguides
"Explains targeted Go files, functions, or packages with focused diagrams and idiom analysis. Use when understanding existing Go code; do not use when implementation or refactoring is requested."
go-code-review
by gopherguides
WHEN: User wants an automated first-pass code review on a PR, diff, or set of changes. Also when asked "review this PR", "review my changes", or "what do you think of this code?" WHEN NOT: Full project audits (use go-code-audit), or when user just wants linting (use go-lint-audit).
review-deep
by gopherguides
"Deep-review a PR or branch with issue and repo context, then fix and commit actionable findings; PR-backed runs push new review commits by default. Use for 'review my changes', 'check this PR', or post-implementation quality/spec review requests. SKIP existing human/bot review comments that need replies/thread resolution; use address-review."
check-comments
by dykyi-roman
Analyzes PHP code for comment quality issues. Detects missing PHPDoc, outdated comments, commented-out code, opportunities for self-documenting code.
executing-plans
by daniel-ospina
Use when you have a written implementation plan to execute in a separate session with review checkpoints
caveman
by sibulus13
Ultra-concise response style — one sentence max, direct answers
implement
by chpy04
Take one GitHub issue from backlog to an open PR in a single unattended pass, or, for a plan-first issue, to an approved plan on the Excalidraw board first. Invoked by hand as /implement <issue-number>; it takes exactly one issue number and never scans the issue list. You are the orchestrator — you delegate planning, building and verification to the planner, implementer and verifier subagents, judge their output, and open the PR. Never merges.
tiktok-sync
by sibulus13
Post-review playbook for @chase.ride. For each reel in the Notion Motorcycle Content Bank that is "In progress" and was posted at least 24 h ago, match it to the TikTok post, write its metrics (views/likes/comments/saves/shares, watch time, % watched full, new followers), the per-second retention curve and the views-by-hour curve into the row, score it against the account's own history, and propose 3 simple tests for the next posts. Runs on a schedule (daily 21:30 PT) or by hand. Triggers "/tiktok-sync", "sync my reel metrics", "review my latest reel", "has my reel been posted".
plan-review
by daniel-ospina
Review-fix cycle for implementation plans. Sits between writing-plans and executing-plans. Launches proportional parallel reviewers, merges issues, fixes with research, and loops until clean or convergence. Invoked by writing-plans after saving the plan doc.
squig
by musterd-io
Wireframe with the team on one Squig canvas. Use when a member wants a page, a layout, a wireframe, or a change to the shared drawing before any production code.
tech-debt
by SneakKestrel16
"Track, categorize and prioritize technical debt across the codebase — scans for debt indicators, maintains a register."
addressReview
by jthorare
Address PR review comments by spawning domain-specific implementation agents in parallel. Reads from ~/.agentic-workflow/<repo-slug>/reviews/<pr>.json as source of truth, merges any new human GitHub comments, implements fixes, and updates the state file. Can be re-run to continue the review loop.
dated-and-falsifiable
by musterd-io
A belief carries the date it was observed and the observation that would overturn it — plus the twelve named ways a green check or a quiet instrument lies to you, each with a repair. Use when writing down what you learned, when a check passes and you are about to believe it, when a tool reports nothing, or when a team keeps re-discovering the same thing.
Dep Cascade Dedup
by OmniNode-ai
Post-release hook that closes superseded automated dependency-bump PRs across all repos, preventing stale Dependabot/Renovate PRs from accumulating after a release
failure-taxonomy
by maragudk
Build a structured taxonomy of failure modes from open-coded trace annotations. Use this skill whenever the user has freeform annotations from reviewing LLM traces and wants to cluster them into a coherent, non-overlapping set of binary failure categories (axial coding). Also use when the user mentions "failure modes", "error taxonomy", "axial coding", "cluster annotations", "categorize errors", "failure analysis", or wants to go from raw observation notes to structured evaluation criteria. This skill covers the full pipeline: grouping open codes, defining failure modes, re-labeling traces, and quantifying error rates.
triage-pr-reviews
by k1LoW
Triages unresolved PR review comments using gh-pr-reviews. Analyzes code context and classifies each comment as Agree / Partially Agree / Disagree. Use when the user wants to triage, review, or analyze unresolved PR comments.
arkts-static-spec
by openharmonyinsight
ArkTS (Extended TypeScript) static language specification reference for OpenHarmony. Comprehensive guide covering syntax, types, classes, expressions, statements, generics, modules, annotations, and advanced features. Use when: (1) Writing or analyzing ArkTS code (.ets files), (2) Understanding ArkTS type system and type checking, (3) Implementing ArkTS language features, (4) Debugging ArkTS compilation issues, (5) Creating ArkTS developer tools or compilers, (6) Validating ArkTS code compliance, (7) Migrating from TypeScript to ArkTS. Provides detailed language rules from the official specification including lexical structure, type system, OOP features, runtime semantics, and TypeScript migration guide.
documentation-guide
by akaszubski
"Documentation standards enforcing Keep a Changelog format, README structure, ADR templates, and Google-style docstrings. Use when writing CHANGELOG entries, updating READMEs, or documenting APIs. TRIGGER when: changelog, readme, documentation, docstring, ADR, API docs. DO NOT TRIGGER when: code-only changes, test files, config updates without API changes."
library-design-patterns
by akaszubski
"Two-tier design, progressive enhancement, non-blocking patterns, and security-first architecture for Python libraries. Use when creating or refactoring Python libraries. TRIGGER when: library design, module architecture, reusable component, two-tier. DO NOT TRIGGER when: simple scripts, config files, documentation-only changes."