菜单
Triage stale GitHub issues. Use when asked to review old, inactive, least-recently-updated, obsolete, already-done, or closeable issues; research whether they are still relevant; comment with a short summary; and close issues that are clearly done or no longer needed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Comprehensive knowledge of Fedi's testing infrastructure for UI code (utilities, mock builders, conventions, and patterns) — use this when reading, writing or running unit/integration/e2e tests
Use when changing, adding, or consuming Fedi remote feature flags across the bridge runtime and web API. Covers crates/runtime/src/features.rs, ui/web/src/pages/api/features.ts, TypeScript bindings, local testing, and selector usage.
Pre-submit checklist for PRs that change Rust or bridge code (`crates/`) in the Fedi project. Use before opening or updating a Rust or bridge PR to run the right local checks and structure the description. Not for UI (`ui/`), docs, or config-only changes, which have their own conventions.
Review a UI pull request or diff in the `ui/` workspace (web, native, shared `common`) for regressions and scope creep, weighing each finding by cost and blocking only on a named cost. Use whenever asked to review a UI or frontend PR or diff, or to check a web or native change before merge, even if the user does not say "code review". Not for Rust, bridge, or infra changes.
Review Dependabot PRs updating GitHub Actions workflows/actions, with a security-focused upstream diff check before commenting.
Review Dependabot PRs updating Rust/Cargo crates with a security-focused crates.io tarball diff before commenting.
| name | github-stale-issues-triage |
| description | Triage stale GitHub issues. Use when asked to review old, inactive, least-recently-updated, obsolete, already-done, or closeable issues; research whether they are still relevant; comment with a short summary; and close issues that are clearly done or no longer needed. |
Use this when asked to look through old open issues and decide whether they are still relevant.
First identify the exact issues under consideration. Usually this means the least-recently updated open issues, optionally limited by the user's requested count or age cutoff.
For each issue, one by one:
Always post a short issue comment with what you checked and your judgment, even when leaving the issue open. This intentionally bumps stale issues with useful triage context. Keep the comment concise, polite, and single-purpose. When acting on behalf of the user, use the current agent's normal attribution prefix for GitHub comments.
Close only when the conclusion is clear. Otherwise, comment without changing labels or assignees unless the user explicitly asked for that.
Report back with a short table: issue, decision, action taken, rationale.
