skills
skills には chengyongru から収集した 16 個の skills があり、リポジトリ単位の職業カバレッジとサイト内 skill 詳細ページを表示します。
このリポジトリの skills
Use when the user wants to inspect, classify, add, remove, replace, synchronize, or verify labels on a GitHub pull request; require evidence-backed current impact for bug, security, severity, and priority classifications, preserve unrelated labels, plan changes before applying them, and use the bundled REST-based helper for authorized mutations
Use when the user wants a maintainer-quality review of a GitHub PR, actionable findings, blocker or closure recommendations, or explicitly authorized COMMENT-only GitHub feedback; gate deep review on supported-path reachability and evidenced net value, report close/no-merge directly for unreachable or valueless changes, never approve PRs, and use pr-worktree for isolated local checkout
Use when the user explicitly wants to modify an existing GitHub PR as a maintainer and push focused fixes to its head branch; establish the confirmed issue, protected contract, minimal change cone, and verification evidence first; use pr-worktree so the current workspace is not disturbed
Safely rebase an existing GitHub pull request branch onto the latest base branch, resolve conflicts while preserving the PR's intent, rerun focused verification, and optionally update the remote PR branch. Use when the user asks to rebase, sync, refresh, or bring a PR up to date with main or another base branch, especially before merge or after the base branch changed.
Rewrite and polish Chinese technical writing through selective, comparative edits and relevant references, including author-approved samples, before/after pairs, voice profiles, factual sources, and platform examples. Use when the user asks to rewrite, polish, 润色, 改写, 提升吸引力, match their voice or 文风, improve readability, flow, rhythm, viewpoint, or narrative, while preserving facts, narrative ownership, author perspective, and technical substance.
Capture, incubate, and review verifiable content fragments from daily engineering work — debugging findings, experiments, tool comparisons, pitfalls — for future social posts. Use when the user says to save/log/capture a material or experience fragment, asks what content is ready to write, or wants to review accumulated material fragments by topic or maturity.
Draft publishable content from material fragments or raw input into platform-appropriate copy — tweets, HN posts, long-form articles, or blog posts. Use when the user wants to write/draft/compose a tweet, HN post, blog post, or any social content; or when material review produces a draft frame ready for final copy. Triggers: draft, write a tweet, 写推文, draft a post, compose content, 成稿.
Use when any GitHub PR workflow needs to checkout, inspect, review, test, or modify a PR locally without disturbing the current workspace; drive isolated review/fix worktree preparation, status checks, and safe cleanup through the bundled deterministic helper
Save, update, link, or delete an idea, task candidate, PR, issue, project thought, conversation insight, or outcome in the user's Markdown idea directory. Use when the user invokes $idea-capture, says to remember/save/capture/log an idea, says an existing idea is done, dropped, duplicate, or reopened, or asks to delete/remove/clean a completed or unwanted idea.
Choose one concrete next action from the user's Markdown idea directory. Use when the user invokes $idea-next or asks what to do next, what to work on now, which idea/PR/project to advance, or how to break choice paralysis using previously captured ideas.
Use when the user wants to quickly understand a complex PR, issue, article, document, web link, discussion, spec, changelog, or unfamiliar topic in plain language; produce a concise decision brief that explains what it is, why it matters, what changed or is being claimed, the main risks, and the next useful action. Match the user's language. For GitHub PRs, use pr-worktree first for isolated local checkout before reading diffs.
Verify nanobot WebUI changes from a user perspective. Use when working in the nanobot repository after WebUI routing, settings, chat, sidebar, or gateway-facing changes; when the user mentions validating nanobot WebUI with $verify, Playwright, headless browser, gateway, websocket port, refresh persistence, or black-box UI checks; or when a PR needs evidence that the built WebUI works through the real gateway.
Cleanup-only code review and refactor workflow for recent or targeted changes. Use when the user asks to simplify, reduce duplication, remove unnecessary complexity, improve reuse, tighten abstractions, or run a Claude Code style /simplify pass after implementation. Applies safe behavior-preserving fixes and does not hunt for correctness bugs.
Structured black-box functional verification after code changes. Use when asked to verify, validate, smoke-test, or evidence-check completed changes before merge/push/release, including explicit $verify requests. Collect diff context, classify user-facing surfaces, write a concrete verification plan, run tests through public interfaces such as APIs, CLIs, web UIs, and package consumers, capture command/output evidence, and report PASS/WARN/FAIL with limitations.
Design controlled experiments to compare two implementations or validate a hypothesis. Use when the user wants to A/B test, compare alternatives, run a benchmark shootout, or verify that a change causes a specific effect. Generates a formal experiment spec across two isolated worktrees. Does NOT execute experiments — user reviews the plan then runs it.
Turn improvement ideas into formal, auditable experiment plans with isolated worktrees. Use when the user wants to improve, optimize, experiment with, compare, or validate a hypothesis about any codebase behavior. Generates a formal experiment spec and creates an isolated worktree. Does NOT execute experiments — user reviews the plan then runs it.