菜单
Triage a feature request issue into intent, problem statement, scope, and acceptance criteria. Use when a GitHub issue or similar request needs a concise feature-analysis reply without implementation planning.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/hugoduncan/psi --skill issue-feature-triage命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Create or refine a task design. Use when the user asks "create a task" or "refine a task" to ensure a high quality task design.
Resolve ambiguous references in user requests into concrete entities, project-specific terms, and project paths before acting. Use when a request contains pronouns, deixis, aliases, shorthand, informal names, or path-like references that may map to project concepts or files.
Triage a GitHub bug issue by attempting reproduction in an issue-specific worktree, then shape either a precise request for more information or a concrete reproduction handoff into bug-fix execution.
基于 SOC 职业分类
正在显示 SKILL.md
| name | issue-feature-triage |
| description | Triage a feature request issue into intent, problem statement, scope, and acceptance criteria. Use when a GitHub issue or similar request needs a concise feature-analysis reply without implementation planning. |
| advertise | false |
A good feature triage will answer the following:
What is the request's intent? This is important because it captures what the requester is trying to achieve and provides the top-level orientation for the analysis.
What is the problem statement? An explicit problem statement clarifies what gap, pain, or missing capability the request is trying to address.
What is the scope? This prevents overreach during triage. It should identify what belongs inside the requested feature surface and what adjacent ideas are out of scope for this request.
What are the acceptance criteria? This should make clear what outcomes would demonstrate that the request has been satisfied from the user's point of view.
What closely related functionality already exists? Add a terse summary at the end of the triage that identifies nearby existing behaviour, features, or capabilities that overlap with or contextualize the request. This summary should stay brief and informational. It should not turn into implementation planning.
The triage should stay grounded in the issue as written. It should not invent implementation details, code changes, or delivery plans.
The level of detail should reflect the size and clarity of the request.
