菜单
Draft GitHub issue titles and bodies for this repository using `.github/ISSUE_TEMPLATE` form definitions. Use when opening or preparing a GitHub issue or feature request (e.g. "open an issue", "機能要望").
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Periodic code health checkup for design drift not caught by CI. Use at version bumps or when asked for a code health check / 健康診断 / 健診. Audits logged advisory deviations and runs a deepen-modules pass.
Perform a project release: bump the semver `version` in package.json, summarize changes since the last release, and hand off to the health-checkup. Use when cutting a release, bumping the project version, or asked to "version up".
Project coding conventions and architecture constraints. Use when implementing, creating, or modifying components and modules (e.g. "create a component", "implement this feature").
Create a PR aligned with the AI-led workflow: summary, design (when relevant), impact and risks. Use when creating a pull request, opening a PR, pushing for review, or completing implementation of an issue.
Triage GitHub PR review feedback (top-level, inline, threads); implement agreed items; escalate disagreements or questions. Includes lint/test checks, per-thread replies with commit SHA, and a chat summary. Use when fixing review feedback on an open PR—not for greenfield implementation only.
Propose codifying reusable lessons from trial-and-error or explicit user requests into lint, rules, or skills. Use near task completion after failed first attempts, or when the user asks to "make it a rule" or "leave a lesson". NOT for empirically testing instructions on fresh agents (tune-prompt) or drafting a new skill without a lesson to codify.
| name | create-github-issue |
| description | Draft GitHub issue titles and bodies for this repository using `.github/ISSUE_TEMPLATE` form definitions. Use when opening or preparing a GitHub issue or feature request (e.g. "open an issue", "機能要望"). |
Repository YAML templates are the source of truth. Before drafting, read *.yml under .github/ISSUE_TEMPLATE/ for field names, required fields, and placeholders. Same process when templates are added.
Section headings in issue bodies must match the template label values exactly. Write prose inside sections in English by default, unless the user explicitly requests another language.
Current labels for feature requests:
| Template field | Heading in body |
|---|---|
background | ## Background & purpose |
requirements | ## Requirements & details |
acceptance_criteria | ## Acceptance criteria |
feature_request.yml)| Item | Rule |
|---|---|
| Title | Short, descriptive; no prefix required |
| Labels | Template has labels: []; do not add labels unless the user asks |
| Body | Use the heading order below |
## Background & purpose
(Required. Background and purpose per the template.)
## Requirements & details
(Required. Bullet list is fine; be specific about desired behavior.)
## Acceptance criteria
(Optional. Verifiable done criteria; checklist preferred.)
*.yml under .github/ISSUE_TEMPLATE/.gh issue create --title "..." --body "..." or --body-file for multiline bodies.- [ ] checkboxes work well)