Comments
Code comments and annotations
docx
by Memento-Teams
"Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of \"Word doc\", \"word document\", \".docx\", or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a \"report\", \"memo\", \"letter\", \"template\", or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation."
github-issue-creator
by EdanStarfire
Create well-structured GitHub issues focused on user problems and outcomes, not implementation. Use when user reports bugs or requests features to ensure clear, testable requirements without premature implementation details.
github-issue-reader
by EdanStarfire
Fetch and analyze GitHub issue details including comments, metadata, and discussion context. Use when user mentions issue numbers, URLs, or you need to understand implementation requirements from a GitHub issue.
technical-writing
by Logos-Liber
Technical writing principles and best practices for creating clear, accurate documentation
git-workflow
by AlexanderMattTurner
The mechanics of committing, pushing, and resolving merge conflicts in this repo. Activate before you commit or push, when a PR reports a merge conflict or a dirty mergeable_state, when a merge-conflict label or an auto-resolve bot comment arrives, when you must audit a bot's merge resolution or answer a merge-delta finding thread, when you are about to push work that belongs to an already-open PR, and when you are tempted to re-run the suite locally after a push. The load-bearing rule is that a conflict belongs to the auto-resolve workflow, not to you.
pr-creation
by AlexanderMattTurner
Creates high-quality pull requests with an iterative compress-critique-fix loop before submission. Activate this skill whenever you are asked to create, open, submit, or push a pull request, OR whenever a new feature, fix, or refactor is complete and ready to ship. Also activate when the user says "make a PR", "open a PR", "submit this for review", "push and create a PR", "I'm done, create the PR", "the feature is done", "I'm finished", or any variation of completing work / requesting a pull request. Also activate to update, fix, or add to an existing PR — "update the PR", "fix the PR", "add this to the PR" (see "Updating an existing PR"). Always activate before opening or editing a PR, whatever the route — CLI or API tool.
writing-tests
by AlexanderMattTurner
How to write, change, or review tests in this repo — the load-bearing rule is test real behavior, not source text. Also covers non-vacuity (prove the test can fail: red-on-old → green-on-new), e2e tests that secretly stub the component they name, drift guards as a design smell to name rather than launder, SSOT contract tests that must move with their data, covering enumerated sets member-by-member, fuzzing parser/Unicode logic, hostile-pre-state filesystem tests, stubs that must drain stdin, checks that must prove the subject ran before judging its output, probes that must not perturb the state they read, failure-signature lists that must carve out your own guards' refusals, the Python test idioms (repo-root discovery, exec()-ing a module's main, from future import annotations) that bite under pytest-xdist, and the c8 / kcov / mutation coverage floors. Activate whenever the user asks to write, add, fix, refactor, strengthen, or review tests ("write a test", "add tests", "test this", "regression test", "cover this", "why didn't this test catch it"), or when a coding task's last step is testing the change you just made.
pr-code-review
by Arctuition
Perform GitHub pull request code reviews using the gh CLI. Use when asked to review a PR, inspect PR diffs, leave inline review comments on specific lines, or produce a severity-based summary (high/medium/low) of findings.
audit-prep-assistant
by runkids
Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments).
imaging-data-commons
by ImagingDataCommons
Query and download public cancer imaging data from NCI Imaging Data Commons using idc-index. Invoke for any question about IDC collections, cancer imaging datasets, DICOM data access, radiology (CT, MR, PET) or pathology AI training sets, metadata queries, visualization, or license checks — even when the user doesn't explicitly mention "IDC". No authentication required.
database-design
by Leavesfly
数据库设计规范与优化指南
ci-drift
by dwarvesf
Use for the whole-estate CI audit, "audit the CI", "are the runners clean", "check the release pipeline", "ci drift", "stale workflows / secrets / runners", or a scheduled CI-audit cadence run. NOT for one failing run (/kit:debug), NOT for doc prose (doc-drift).
defect-to-guard
by AlexanderMattTurner
Turn a defect class into a well-designed guard PROPOSAL (and, once a human promotes it, a well-built guard). Activate when writing a ## Proposed guards entry after fixing a bug, and when a human has explicitly approved implementing a lint, pre-commit hook, CI check, assertion, or ratchet — never to ship a guard inside a fix PR. Covers naming the defect CLASS rather than the instance, checking whether an existing guard should have fired (a gap in it is itself a bug), preferring a check that iterates the SSOT over a per-case assertion, naming the guard's HOME (this repo, or the shared ci-truth-serum pack) and what belongs in each, the inert-feature class that only a behavior-driving smoke test can catch, writing a repo-local checks/*.py line lint and dogfooding it against the real tree before shipping, the WATCHED-SURFACE question (when this goes red, who actually sees it?), the vacuous-green failure mode, and why mutation testing runs on CI and never locally.
ci-triage
by AlexanderMattTurner
How to respond when a CI check goes red, a PR check fails, a test is flaky, a job times out, or a webhook reports a failing status — plus how to read GitHub check state at all (gh locally vs mcp__github__* on the web, and why one page of get_check_runs never proves "all green"). Activate whenever a check is red or cancelled, a workflow run failed, a shard timed out, a test is intermittent, you are about to claim a PR is green or mergeable, you are about to re-run a job, or you need a failing job's log. Also activate before dispatching an expensive/live-fire workflow to verify a fix. The load-bearing rule is that a red check is a bug you have not diagnosed yet — "flake", "pre-existing", "unrelated", and "infra" are conclusions you must earn by reading the log, never opening assumptions, and never a licence to re-run.
observability
by akaszubski
"Structured logging, debugging (pdb/ipdb), profiling (cProfile/line_profiler), and performance monitoring. Use when adding logging, debugging issues, or optimizing performance. TRIGGER when: logging, debug, profiling, performance monitoring, metrics, stack trace. DO NOT TRIGGER when: feature implementation, testing, documentation, config changes."
code-review
by 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."
fix-pr
by griffinwork40
"One-verb pipeline for the operator's highest-frequency manual loop: fetch a PR's unresolved reviewer feedback (inline review comments, review-summary bodies, and issue-level conversation comments) and failing CI checks, triage each issue via parallel read-only probes, fix the validated items in an isolated managed worktree via a budget-bounded subagent, verify with the project's test gates, and push the fix back to the PR branch. Replaces the retyped recipe 'send a subagent in a worktree to fix <PR feedback>, then push.' Use when a PR has review comments or red CI that needs addressing — e.g. 'fix pr 286', 'address the review on #215', 'CI is red on the worktree-sweep PR'. Never force-pushes, never touches main, fails closed on missing gh auth or un-pushable fork PRs."
gh-pr-comments
by yotamleo-org
List/show review threads on a specific PR ("what comments are on PR 97"). Needs PR number. Not Jira or issue comments.
support-responder
by aibangjuxin
You are a patient, empathetic, and knowledgeable Support Responder. You are an expert on the product and can clearly explain complex features in simple terms. Your primary goal is to solve the customer's problem quickly and leave them feeling heard, valued, and satisfied.
review
by griffinwork40
"Dispatches parallel dimension agents across a diff, PR (URL or number), commit SHA, branch, staged changes, or patch file — covering security, correctness, api-compat, test-coverage, and perf-observability — synthesizes findings by severity, and emits a merge recommendation. Use when changes are ready for review before merge. Read-only: this skill analyzes and reports only — it never edits files, commits, pushes, comments on a PR, or modifies the PR description."
principle-explain-the-number
by yotamleo-org
"Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think."
roadmap-clips
by yotamleo-org
Use when the operator wants a cross-source roadmap from the luna vault — writes a 60-Maps/ note. Proposals only.
correct
by yotamleo-org
"Find the mistakes agents keep repeating in this repo and make each one impossible. Try architecture first, then types, then a lint whose error names the fix, then a test, and write docs last. Prove each check fails on a real past mistake. Repeat this each time the operator corrects you. Use for /correct."
turn-this-feature-into-a-blog-post
by GhostScientist
Generates a technical blog post from code implementation. Use when asked to write a blog post about a feature, explain an implementation for a blog, document code as a blog article, or create technical content from source code. Triggers on phrases like "write a blog post about", "turn this into a blog", "create a technical article", or "explain this for a blog".