Comentaris
Comentaris i anotacions del codi
address-review
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
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
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
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
dykyi-roman
Analyzes PHP code for comment quality issues. Detects missing PHPDoc, outdated comments, commented-out code, opportunities for self-documenting code.
executing-plans
daniel-ospina
Use when you have a written implementation plan to execute in a separate session with review checkpoints
caveman
sibulus13
Ultra-concise response style — one sentence max, direct answers
implement
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
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
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
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
SneakKestrel16
"Track, categorize and prioritize technical debt across the codebase — scans for debt indicators, maintains a register."
addressReview
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
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
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
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
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
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
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
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."
testing-guide
akaszubski
"GenAI-first testing with structural assertions, congruence validation, and tier-based test structure. Use when writing tests, setting up test infrastructure, or validating coverage. TRIGGER when: test, pytest, coverage, TDD, test patterns, congruence, validation. DO NOT TRIGGER when: production code implementation, documentation, config-only changes."
skill-integration
akaszubski
"Patterns for agent skill discovery, referencing, and composition using progressive disclosure architecture. Use when building agents, composing skills, or optimizing context usage. TRIGGER when: skill discovery, agent integration, skill composition, progressive disclosure. DO NOT TRIGGER when: implementing features, writing tests, documentation-only changes."
refactoring-patterns
akaszubski
"Safe refactoring techniques — extract, inline, rename, move, simplify conditionals, and decompose functions. Use when restructuring code without changing behavior. TRIGGER when: refactor, extract method, rename, inline, simplify, decompose, clean up, code smell. DO NOT TRIGGER when: adding features, fixing bugs, writing tests, documentation."
code-review
akaszubski
"10-point code review checklist covering correctness, tests, error handling, type hints, naming, security, and performance. Use when reviewing PRs or evaluating code quality. TRIGGER when: code review, PR review, review checklist, code quality check. DO NOT TRIGGER when: writing new code, debugging, refactoring without review context."