Comentaris
Comentaris i anotacions del codi
quick-view
rohunvora
Generate minimal HTML pages to review Claude Code output in a browser. Use when terminal output is hard to read, when reviewing lists/tables/drafts, or when user says "show me", "make this reviewable", "quick view", or "open as webpage". Produces unstyled semantic HTML only. For granular feedback with inline comments, see the comment-mode skill.
comment-mode
rohunvora
Granular feedback on drafts without rewriting. Generates highlighted HTML with click-to-reveal inline comments. Use when user says "comment on this", "leave comments on", "give feedback on", or asks for feedback on a draft. Supports multiple lenses—editor feedback, POV simulation ("as brian would react"), or focused angles ("word choice only", "weak arguments"). A granular alternative to rewrites that lets users review feedback incrementally without losing their voice.
swift-study
ITlearning
Interactive Swift/iOS tutor with two modes. Classic explains first, Mastery uses a predict-first Core Loop with gates.
generate-terraform-provider
speakeasy-api
Use when generating a Terraform provider from an OpenAPI spec with Speakeasy. Covers entity annotations, CRUD mapping, type inference, workflow configuration, and publishing. Triggers on "terraform provider", "generate terraform", "create terraform provider", "CRUD mapping", "x-speakeasy-entity", "terraform resource", "terraform registry".
wide-events
front-depiction
Conceptual guide to wide events (canonical log lines) for observability. Use when thinking about instrumentation strategy, span annotations, or designing what context to capture.
blooms-taxonomy
reggiechan74
This skill should be used when the user asks to "write learning objectives", "create measurable learning outcomes", "select action verbs for objectives", "what cognitive levels should I target", "how to scaffold learning", "write course objectives", "make objectives more specific", or references Bloom's taxonomy. Also relevant when users say "my objectives aren't measurable", "how do I assess what students learned", or "progression from basic to advanced skills". Provides comprehensive guidance on applying Bloom's taxonomy to create measurable, appropriately-leveled learning objectives for intensive workshops.
documentation-router
Zpankz
Routes documentation and explanation tasks. Triggers on document, explain, readme, api-docs, changelog, guide, comment, describe, write-docs.
mongodb-query-and-index-optimize
romiluz13
MongoDB query optimization and indexing strategies. Use when writing queries, creating indexes, building aggregation pipelines, or debugging slow operations. Triggers on "slow query", "create index", "optimize query", "aggregation pipeline", "explain output", "COLLSCAN", "ESR rule", "compound index", "partial index", "TTL index", "text search", "geospatial", "$indexStats", "profiler".
four-risks
breethomas
Run Marty Cagan's Four Risks assessment on an issue (value, usability, feasibility, viability). Use when evaluating features before building.
postgresql
jgamaraalv
"PostgreSQL 16+ reference for writing queries, designing schemas, managing indexes, and optimizing performance. Use when: (1) writing SQL queries (SELECT, INSERT, UPDATE, DELETE, CTEs, window functions, subqueries), (2) designing or altering table schemas (CREATE TABLE, constraints, sequences, data types), (3) choosing or creating indexes (B-tree, GIN, GiST, BRIN, partial, expression), (4) managing transactions and isolation levels (BEGIN/COMMIT, savepoints, MVCC), (5) working with JSONB data and jsonpath, (6) analyzing query performance with EXPLAIN ANALYZE, or (7) using the psql CLI."
cross-domain-thinking-toolbox
hexbee
"Apply 25 professional mental models to solve complex problems. Use when: (1) facing multi-faceted challenges that require diverse perspectives, (2) stuck in single-minded approaches, (3) need innovative solutions, (4) making major decisions with multiple stakeholders, (5) understanding complex human behavior, or (6) seeking to break cognitive biases and adopt alternative viewpoints."
review-panel
yschiang
Use when a change needs an independent review that should not rest on one reviewer's blind spots, such as the whole-change review (G2) of a feature's pull requests or the per-task review of a high-risk task. Recommended, not required; the Engineer may choose a single reviewer. Not for fixing findings (plan-to-code) or running the gates (to-pr).
pr-review-response
ttokit
"Handles PR review comments through analyze-confirm-execute workflow. Analyzes comment validity, confirms response approach with user, executes code changes, and replies to reviewers. Use when responding to PR review comments, addressing feedback, handling code review, replying to reviewers, or managing review threads."
feature-to-spec
yschiang
Use when a feature chosen on the roadmap needs its OpenSpec change, spec and ticket before engineering starts, or when the spec of an existing feature must change, whether still in preparation, blocked on scope inside the feature loop, or sent back because the requirement changed. Used by the Project Lead or the Engineer. Not for project-level planning or close-out (project-lead), and not for design and plan (spec-to-plan), implementation (plan-to-code) or pull requests and gates (to-pr).
plan-to-code
yschiang
Use when a feature's plan (design.md and tasks.md) has its start-of-work approval and its tasks must be implemented, or when review findings, a failed gate or an acceptor's rejection send fixes back to a feature's tasks. Used by the Engineer or the coordinator of the feature loop. Not for writing the plan (spec-to-plan) or opening pull requests (to-pr).
canvas-feedback-template
vishalsachdev
Generate learning science-backed feedback templates for Canvas assignments. Use when educators need feedback templates for grading, want to create rubric comments, need encouraging feedback language aligned with Pillar 3 principles (targeted, encouraging, immediate), or want to set up SpeedGrader comment libraries. Works with canvas-mcp for bulk grading.
to-pr
yschiang
Use when every task of a feature has passed its per-task review and the feature needs its pull requests, an independent whole-change review and CI before the acceptor sees it, or when open pull requests must be verified again after new commits. Not for implementing tasks (plan-to-code) or for recording acceptance (project-lead).
loachbot-github-issue
RobLoach
Autonomous GitHub Issue Fixer agent called LoachBot. Picks the single most-recently-updated GitHub issue created by and assigned to you, implements a fix in a Pull Request, then unassigns the issue. Use when the user wants to work through issues assigned to them, or asks to "run LoachBot Issues", including repeated runs like "run LoachBot Issues six times" or "until there aren't any left".
loachbot-github-pr
RobLoach
Autonomous GitHub Pull Request Fixer agent called LoachBot. Scans GitHub for your own draft Pull Requests, addresses your review comments, then marks the Pull Request ready for review. Use when the user wants to address feedback on their draft pull requests, or asks to "run LoachBot Pull Requests", including repeated runs like "until there aren't any left".
spec-to-plan
yschiang
Use when a feature's handoff package is ready and its design and implementation plan must be written before work starts, or when a plan was sent back at the start-of-work approval. Used by the Engineer or the coordinator of the feature loop. Not for writing the spec (feature-to-spec) or for implementing tasks (plan-to-code).
loachbot-gitlab-review
RobLoach
Autonomous drupal.org merge request reviewer called LoachBot. Reviews one merge request against the issue it claims to fix and against Drupal's own standards, posts its findings as resolvable inline threads, and moves the issue to needs-work. Use when the user wants a review of a drupal.org merge request, asks what is wrong with one or how to improve it, or asks to "run LoachBot Review", including repeated runs like "review the next three".
receiving-code-review
yschiang
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
project-lead
yschiang
Use when starting or importing a Loop Engineering project, when its roadmap must be planned, re-cut or re-confirmed, when new evidence breaks an accepted requirement, when a feature's PR Pass needs the acceptor's decision recorded, or when a feature was accepted and needs close-out. Not for preparing a single feature's spec (feature-to-spec), and not for design and plan (spec-to-plan), implementation (plan-to-code) or pull requests and gates (to-pr).
leetcode-helper
Zephyrex21
Expert LeetCode problem solver for optimized C++ coding interview solutions. Use when: the user pastes a LeetCode problem, asks for an optimized algorithm, wants C++ LeetCode code, needs a dry run, asks for line-by-line explanation, wants a hint before the solution, wants brute force to optimized progression, wants pattern recognition, C++ pitfall warnings, interview tips, or wants help understanding data structures and algorithms for coding interviews.