GITHUB AGENT SKILLS / 技能收录
给你的 AI 助手
装上专业技能
我们从 GitHub 持续收录、审核并分类优质的 Agent Skills，按职业与使用场景整理，复制一行命令即可安装到 Claude Code、Cursor 等智能体。
按职业浏览 Agent Skills
为不同岗位挑选的高频技能
按使用场景浏览 Agent Skills
从你要完成的任务出发
按创作者浏览 Agent Skills
按 GitHub Stars 排序的优秀创作者
Microsoft
@microsoft
openclaw
@openclaw
OpenAI
@openai
The Apache Software Foundation
@apache
GitHub
@github
Anthropic
@anthropics
AutoGPT
@Significant-Gravitas
Garry Tan
@garrytan全部 Skills 196628
regen
暂无简介
prose-lint
暂无简介
make-release
暂无简介
ci
暂无简介
to-tickets
Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs/plans/<feature>.md`, from /to-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers /to-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.
to-seams
Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — "record a seam for X", "we agreed on this schema, seam it", "add a seam so Y can build against Z's new field". Halts for approval before writing either file.
to-roadmap
Prioritises settled features into a Now / Next / Later kanban board, rendered as a self-contained ./ideas/roadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via /to-prd -> /to-plan -> /to-tickets. Boards the features in ./docs/approach.md, or the "## Accepted ideas" in ./ideas/CONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.
to-prd
Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs/prds/<feature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (/to-prd -> /to-plan -> /to-tickets).
to-plan
Turns one feature's PRD into a skimmable plan in docs/plans/<feature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:<slug> label. No code, branch or PR; the user's review of the file is the gate. Use for "plan this feature", "write the contract", "what are the types". One feature per run. Slash-only.
ticket-tracker
Use when the request is about the *current state* of GitHub issues rather than creating new ones: "where are my tickets", "show the board", "what's in progress", "what's ready to pick up", "move issue N to in-review", "mark N done", "update the ticket status". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; ./ideas/roadmap.html is the feature-level one. To file new tickets, use /to-tickets, file-issue for a single ad-hoc one, or /sweep for a batch of small fixes.
squash-pr
Check PR has no new review feedback, squash merge to the PR's target branch, then update that local branch.
sweep
Turn a pile of small fixes into a batch /fleet can dispatch. Takes the open `inbox` issues and any items pasted with the command, explores them in one pass, rejects anything too big for a small fix and takes it out of the inbox, merges items that touch the same files into one ticket, and files the tickets under one dated `sweep-YYYY-MM-DD` label. Use for "sweep the inbox", "batch these fixes", "turn these into tickets and fleet them". For one ad-hoc ticket, use file-issue; for a feature, use /to-tickets.
pr
Write a pull request's title and body and open it as a draft. Use whenever a PR is about to be opened or its description written: 'open a PR', 'raise a PR', 'create the pull request', 'write the PR body', 'gh pr create', or when a ticket or /implement run finishes with a PR for review. Produces a short, visual-first body (Summary, Evidence, Merge Danger, Closes lines) built for a reviewer deciding whether to merge agent-written work. Not for /fleet reconcile's feature-branch PR into main, which only lists tickets already reviewed on their own PRs.
implement
Implement a ticket or spec end to end. Invoke ONLY when the user types /implement, or a dispatch prompt explicitly says to run implement for a named issue. Never invoke it on your own initiative, for ad hoc coding requests, or because a task looks like implementation work.
ideate
Use whenever the user asks what to build next in this project: "what should I build next?", "any ideas for this project?", "what's missing?", "help me find gaps", "where could this go?", "what are competitors doing?", "where could we differentiate?", "how do I grow this?". Trigger for roadmap ideation, product discovery, gap analysis and competitive positioning in a codebase, even when the user never says "ideate". Inventories what the code already does, scans the real market, and produces a portfolio of 6–10 evidence-backed ideas (mostly deepening what exists, some net-new), each of which later runs /to-prd on its own. For "which skill should I run next?" use artifact-scan.
fleet
Run a batch of tickets through parallel worktrees, wave by wave. Two subcommands: `/fleet dispatch <label>` fans /implement out across the ready tickets carrying that feature label, one subagent per ticket, all in parallel off the feature branch; `/fleet land <label>` prepares the wave's PRs (drafts included) so the user can merge them in order without conflicts, fixing red CI and conflicts with one subagent per PR, and never merges; `/fleet reconcile <label>` runs after a wave has merged, closes the done tickets, promotes the newly unblocked ones from backlog to ready, writes the handoff for the next dispatch, and opens the feature's PR into main once no tickets are left. A /sweep's `sweep-YYYY-MM-DD` label works as a feature label. Use for "fan out these tickets", "implement these issues in parallel", "for each ready ticket create a worktree and delegate to a subagent", "reconcile the wave", "reconcile the feature", "what's unblocked now", "close out the merged tickets", "set up the next wave". For a single ticket, use /implement directly.
fix-ci
Fix failing GitHub Actions CI on pull requests fast: read the failed job logs, make the smallest fix, run one cheap local check, push, and let GitHub CI be the judge while it watches in the background. Takes an optional target: a run or job URL/ID (fix only that run's failures), a PR number/URL (fix every failing check on it), or nothing (the PRs in the conversation, else the current branch's PR). Handles stacked PRs by fixing the base first and rebasing dependents. Use whenever the user says "fix ci", "ci is failing", "checks failed", "the build is red", "fix the failing PRs", "both prs fail ci", pastes a GitHub Actions run link, or otherwise asks to get red checks green, even without saying "CI". Not for writing new CI workflows.
file-issue
Files ONE ad-hoc GitHub issue for this repo and prints its URL. Use when the user says "file an issue", "open a ticket for this", "make an issue so we can /implement it later", "log this as a ticket", "park this in the tracker", or when a conversation surfaces a concrete follow-up (a bug spotted mid-task, a refactor out of scope, a TODO worth tracking) and the user wants it captured rather than done now. Also the instant capture for small fixes: "inbox: …", "inbox this", "add to the inbox" files a bare `inbox` issue for /sweep to batch later. The singular sibling of /to-tickets: no plan, no slicing, no feature label. For a bug that needs root-cause investigation first, use triage-issue; for breaking a whole feature into tickets, use /to-tickets.