Comments
Code comments and annotations
communicate
by yologdev
Write journal entries and respond to GitHub issues with an authentic voice
linear-formatting
by jcdendrite
Linear issue-comment and issue-link formatting conventions for tracker writes: issue-ID auto-linking, comment markdown support, the create/update tool-shape variance across Linear MCP server versions, the required Claude-authorship attribution prefix, real-newline formatting, and the repeated-issue-reference auto-linker drop. TRIGGER when: posting or editing a Linear issue comment or document, or writing text that references a Linear issue ID for a Linear-tracked repo. DO NOT TRIGGER when: the tracker is not Linear (e.g. Jira, GitHub Issues), or the write touches only a status/assignee field with no comment or document body.
test-conventions
by jcdendrite
Testing conventions for writing tests in any codebase. TRIGGER when: planning tests for new code, writing test infrastructure (mocks, helpers, fixtures), or discussing test strategy for new features. DO NOT TRIGGER when: the task is purely mechanical (running tests, fixing a single assertion, updating a snapshot), or evaluating/debugging an existing test suite (use test-evaluation).
code-review
by jcdendrite
"Principal-engineer review before presenting code. Also the gate on git commit. TRIGGER when: code is about to be presented, a commit is pending, or the user asks for a review. skill-review, agent-review, and ai-instruction-and-memory-files run from inside this review, never instead of it; plan-review gates separately and also fires. DO NOT TRIGGER when: a fresh code-review-markers/ entry already covers the staged diff."
respond-pr
by jcdendrite
"Respond to PR review comments on the current branch's PR. Enforces required attribution prefix. The gate matches command shape, so it fires on any branch and with no unread comments. TRIGGER when: reading or posting any PR/issue comment or review in this repo. DO NOT TRIGGER when: no comment read or post is attempted, or it only reads another repo."
read-docx-comments
by jcdendrite
Extract all comments from a .docx file (Google Docs / Word feedback) and present them grouped by document location with author and anchored text.
cloud-plan-lane
by cuioss
The complete working contract for a plan under doc/plans/ — the standalone lane that runs OUTSIDE the plan-marshall command lifecycle. Load this first, before any other action, when executing a plan from doc/plans/{epic}/. Covers skill loading, the plan directory lifecycle, the conditional build gate, the pre-PR verification sub-agent, the branch/PR/review-comment cycle, the merge gate, and the persisted run report.
family
by yologdev
Find your way home — register with the yoyo family, introduce yourself, and participate in family discussions
ext-triage-js
by cuioss
Triage extension for JavaScript findings during plan-finalize phase
docx-official
by mit-network
"A user may ask you to create, edit, or analyze the contents of a .docx file. A .docx file is essentially a ZIP archive containing XML files and other resources that you can read or edit. You have different tools and workflows available for different tasks."
doc-hunter-ts
by skyosev
Audit TypeScript code for missing inline documentation where the "why" is not obvious — obscure calculations, non-trivial business rules, surprising behavior, implicit constraints, and workarounds. Finds where a comment would save the next reader significant time. Use when: reviewing TypeScript code for long-term maintainability, onboarding new team members, auditing undocumented business logic, or preparing code for handoff.
error-mode-analysis
by jcdendrite
Produce a signal-bucketed error-mode report from a delivered body of multi-session AI-assisted work — bucket every failure by which pipeline layer caught it, correlate transcript signals with PR review comments, and split output into a private, project-identifying report and a de-identified public lessons doc. Builds on transcript-narrative and transcript-analysis. Supports a multi-window trend pass to distinguish recurring patterns from one-off noise.
ljg-explain-concept
by lijigang
Deep concept anatomist that deconstructs any concept through 8 exploration dimensions (history, dialectics, phenomenology, linguistics, formalization, existentialism, aesthetics, meta-philosophy) and compresses insights into an epiphany. Use when user asks to explain, dissect, or deeply understand a concept, term, or idea. Produces org-mode output.
annotating-task-lineage
by necatiarslan
Annotate Airflow tasks with data lineage using inlets and outlets. Use when the user wants to add lineage metadata to tasks, specify input/output datasets, or enable lineage tracking for operators without built-in OpenLineage extraction.
gitops-workflows
by ahmedasmar
GitOps deployment workflows with ArgoCD and Flux. Use for setting up GitOps (ArgoCD 3.x, Flux 2.7), designing repository structures (monorepo/polyrepo, app-of-apps), multi-cluster deployments (ApplicationSets, hub-spoke), secrets management (SOPS+age, Sealed Secrets, External Secrets Operator), progressive delivery (Argo Rollouts, Flagger), troubleshooting sync issues, and OCI artifact management. Covers latest 2024-2025 features: ArgoCD annotation-based tracking, fine-grained RBAC, Flux OCI artifacts GA, image automation, source-watcher.
explain-code-concepts
by ricardogomes
Guided concept discovery for learners who notice patterns, architectural choices, or design decisions in code and want to understand the ideas behind them. Use when a learner can read and write code but is glimpsing higher-level shapes they can't yet name or fully articulate — recurring structures across a codebase, architectural conventions, design trade-offs, or unfamiliar paradigms. Triggers on phrases like "I keep seeing this pattern", "why is the codebase structured this way", "there's a shape here I can't name", "what's the idea behind this approach", "I notice everything follows this structure", or when a learner describes a recurring pattern without knowing the concept it embodies.
learn-from-real-code
by ricardogomes
Teaches learners to extract transferable design lessons from real-world codebases through critical evaluation and systematic exploration. Use when a learner wants to study existing code to learn patterns, architecture, or design decisions—not just understand what it does. Guides through navigation, pattern recognition, critical evaluation (deliberate choice vs. compromise), and lesson extraction. Triggers on phrases like "learn from this codebase", "study how X is implemented", "understand design patterns in Y", or when a learner wants to improve by reading real code.
Devex Review
by itzikiusa
A focused single-lens code review of developer experience and API ergonomics only — the quality of the interface a change exposes to other developers and callers. Judges "is this pleasant and safe to USE?": API/function/CLI shape (easy to use right, hard to use wrong), naming clarity, error messages that say what to do next, sensible defaults, discoverability, docs/examples for new public surface, and migration/onboarding friction. Every finding cites the surface (file:line), a severity, the friction or footgun it creates for the next developer, and a concrete improvement. It deliberately does NOT check correctness (that's grill) or internal structure (that's architecture-review).
Grill
by itzikiusa
A relentless, exhaustive, adversarial code review that hunts the smallest defects. Sweeps the change in multiple passes — correctness, edge cases, error handling, concurrency, resources, security, performance, contracts, types, tests, docs, and convention-consistency — then a final "what did I miss?" pass. Every finding cites file:line, a severity down to nits, why it matters, and a concrete fix. Evidence before assertion: trace and reproduce, never hand-wave.
checking-image-bounds-transform
by christian289
"Checks and clamps mouse coordinates within transformed image bounds in WPF. Use when implementing measurement tools or annotations that should only work inside Pan/Zoom/Rotate transformed images."
metric-counting-method-verification
by jinwon-int
Before quoting a count in a report, decision, or handoff, verify the counting method against the query the system's own code uses — not against a prior session's number. Use when a metric feels inconsistent, when two documents disagree about the "same" number, when inheriting work that cites metrics, before any gate decision (pilot expand/rollback, threshold alarm, capacity call), or when a count delta ties out arithmetically (test count vs manifest total, coverage %, row counts) and you are about to treat that as proof.
fleet-task-handoff-with-constraints
by jinwon-int
Use when handing off unfinished multi-node work — mid-pilot, at session end with items outstanding, or moving a task to another node. Classify each item's approval gate, record where it may NOT run, verify each cited metric's counting method, and name prior errors so they aren't rediscovered.
nclex-multi-pr-pre-flight-gate-validation
by jinwon-int
Pre-flight validate one or many jinwon-int/nclex content PRs against the CURRENT main gate before A2A dispatch or rebase — pin each head in a detached worktree, replay the gate job's validation steps, reproduce the stale-base trap that makes an old green CI turn red on push, classify failures per tool (validate_refs, ko_terminology, ko_coverage, content_process/coverage, a2a_quorum, similarity), and emit READY / NEEDS_FIX / NEEDS_REBASE verdicts with preserved evidence. Use when triaging a batch of open nclex PRs, when a PR's merge base is weeks behind main, when a PR shows green checks but you suspect the rules moved, or before dispatching to nclex-a2a-content-pipeline.
tdd-essentials
by igor1309
Use when implementing a feature or bug fix under strict TDD rules with red, green, commit, and refactor checkpoints.