Feedback Triage

反馈分类处理

Overview

概述

Process raw feedback into actionable, well-documented GitHub issues. Every feedback item is investigated before issue creation.

Core principle: Investigate first, issue second. Never create an issue without understanding what you're documenting.

Announce at start: "I'm using feedback-triage to investigate and create issues from this feedback."

将原始反馈转化为可执行、文档完善的GitHub问题。在创建问题之前，会对每一条反馈事项进行调查。

核心原则：先调查，再创建问题。在不了解要记录的内容之前，绝不创建问题。

开始时告知：“我正在使用feedback-triage来调查这些反馈并创建对应的问题。”

When to Use This Skill

何时使用该技能

Use this skill when you receive:

Trigger	Examples
UAT feedback	"We have bugs from UAT testing..."
User testing results	"Users reported the following issues..."
Bug reports	"Here are the errors we found..."
Stakeholder feedback	"The client wants these changes..."
QA findings	"QA discovered these problems..."
Support escalations	"Support tickets about..."
Production incidents	"These errors are occurring in prod..."
Feature requests batch	"Users have requested..."
UX review findings	"The UX review identified..."

Key indicators:

Multiple items in one message
Raw feedback that needs investigation
Error logs, curl commands, or screenshots
Requests to "create issues" from feedback
Phrases like "bugs to resolve", "issues from UAT", "feedback to triage"

当你收到以下内容时，使用本技能：

触发场景	示例
UAT反馈	"我们有来自UAT测试的bug..."
用户测试结果	"用户反馈了以下问题..."
Bug报告	"这是我们发现的错误..."
利益相关者反馈	"客户希望做出这些更改..."
QA发现	"QA发现了这些问题..."
支持工单升级	"关于...的支持工单"
生产环境事故	"生产环境中出现了这些错误..."
批量功能请求	"用户请求了..."
UX评审发现	"UX评审指出了..."

关键识别指标：

一条消息中包含多个事项
需要调查的原始反馈
错误日志、curl命令或截图
要求“根据反馈创建问题”
出现“需要修复的bug”、“来自UAT的问题”、“待分类的反馈”等表述

The Triage Protocol

分类处理流程

┌─────────────────────────────────────────────────────────────────────┐
│                      FEEDBACK RECEIVED                               │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│               STEP 0: PROJECT BOARD READINESS (GATE)                │
│  Verify GITHUB_PROJECT_NUM and GH_PROJECT_OWNER are set             │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    STEP 1: PARSE INTO ITEMS                         │
│  Identify distinct feedback items                                   │
│  Create TodoWrite entry for each item                               │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
            ┌─────────────────────────────────────────┐
            │         FOR EACH FEEDBACK ITEM          │
            └─────────────────────┬───────────────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        ▼                         ▼                         ▼
  ┌───────────┐           ┌─────────────┐           ┌─────────────┐
  │INVESTIGATE│           │  CLASSIFY   │           │   CREATE    │
  │           │──────────▶│             │──────────▶│   ISSUE     │
  │ Research  │           │ Type+Priority│          │ Best Practice│
  └───────────┘           └─────────────┘           └──────┬──────┘
                                                          │
                                                          ▼
                                                   ┌─────────────┐
                                                   │ ADD TO      │
                                                   │ PROJECT     │
                                                   │ BOARD       │
                                                   └─────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                      收到反馈                               │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│               步骤0：项目看板就绪检查（准入门槛）                │
│  验证GITHUB_PROJECT_NUM和GH_PROJECT_OWNER已配置             │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    步骤1：拆分反馈为独立事项                         │
│  识别每个独立的反馈事项                                   │
│  为每个事项创建TodoWrite条目                               │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
            ┌─────────────────────────────────────────┐
            │         针对每个反馈事项执行          │
            └─────────────────────┬───────────────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        ▼                         ▼                         ▼
  ┌───────────┐           ┌─────────────┐           ┌─────────────┐
  │调查分析│           │  分类   │           │   创建问题    │
  │           │──────────▶│             │──────────▶│   最佳实践│
  │  调研  │           │ 类型+优先级│          │          │
  └───────────┘           └─────────────┘           └──────┬──────┘
                                                          │
                                                          ▼
                                                   ┌─────────────┐
                                                   │ 添加至      │
                                                   │ 项目        │
                                                   │ 看板       │
                                                   └─────────────┘

Step 0: Project Board Readiness (GATE)

步骤0：项目看板就绪检查（准入门槛）

Before any triage, verify project board infrastructure is ready.

bash

undefined

在开始任何分类处理之前，先验证项目看板基础设施已准备就绪。

bash

undefined

Derive defaults from GITHUB_PROJECT if provided

if [ -z "$GITHUB_PROJECT_NUM" ] && [ -n "$GITHUB_PROJECT" ]; then NUM_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#./projects/([0-9]+).#\1#') if [ -n "$NUM_CANDIDATE" ] && [ "$NUM_CANDIDATE" != "$GITHUB_PROJECT" ]; then export GITHUB_PROJECT_NUM="$NUM_CANDIDATE" echo "Derived GITHUB_PROJECT_NUM=$GITHUB_PROJECT_NUM from GITHUB_PROJECT" fi fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_OWNER" ]; then export GH_PROJECT_OWNER="$GITHUB_OWNER" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_OWNER" fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_PROJECT" ]; then OWNER_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#https://github.com/(orgs|users)/([^/]+)/projects/[0-9]+#\2#') if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$GITHUB_PROJECT" ]; then export GH_PROJECT_OWNER="$OWNER_CANDIDATE" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_PROJECT" fi fi

if [ -z "$GH_PROJECT_OWNER" ]; then REMOTE_URL=$(git remote get-url origin 2>/dev/null || true) OWNER_CANDIDATE=$(echo "$REMOTE_URL" | sed -E 's#(git@|https://)github.com[:/]+([^/]+)/[^/]+(.git)?#\2#') if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$REMOTE_URL" ]; then export GH_PROJECT_OWNER="$OWNER_CANDIDATE" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from git remote" fi fi

if [ -z "$GITHUB_PROJECT_NUM" ] && [ -n "$GITHUB_PROJECT" ]; then NUM_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#./projects/([0-9]+).#\1#') if [ -n "$NUM_CANDIDATE" ] && [ "$NUM_CANDIDATE" != "$GITHUB_PROJECT" ]; then export GITHUB_PROJECT_NUM="$NUM_CANDIDATE" echo "Derived GITHUB_PROJECT_NUM=$GITHUB_PROJECT_NUM from GITHUB_PROJECT" fi fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_OWNER" ]; then export GH_PROJECT_OWNER="$GITHUB_OWNER" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_OWNER" fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_PROJECT" ]; then OWNER_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#https://github.com/(orgs|users)/([^/]+)/projects/[0-9]+#\2#') if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$GITHUB_PROJECT" ]; then export GH_PROJECT_OWNER="$OWNER_CANDIDATE" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_PROJECT" fi fi

if [ -z "$GH_PROJECT_OWNER" ]; then REMOTE_URL=$(git remote get-url origin 2>/dev/null || true) OWNER_CANDIDATE=$(echo "$REMOTE_URL" | sed -E 's#(git@|https://)github.com[:/]+([^/]+)/[^/]+(.git)?#\2#') if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$REMOTE_URL" ]; then export GH_PROJECT_OWNER="$OWNER_CANDIDATE" echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from git remote" fi fi

Verify environment variables

if [ -z "$GITHUB_PROJECT_NUM" ]; then echo "BLOCKED: GITHUB_PROJECT_NUM not set" exit 1 fi

if [ -z "$GH_PROJECT_OWNER" ]; then echo "BLOCKED: GH_PROJECT_OWNER not set" exit 1 fi

if [ -z "$GITHUB_PROJECT_NUM" ]; then echo "BLOCKED: GITHUB_PROJECT_NUM not set" exit 1 fi

if [ -z "$GH_PROJECT_OWNER" ]; then echo "BLOCKED: GH_PROJECT_OWNER not set" exit 1 fi

Verify project is accessible

gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1


**Skill:** `project-board-enforcement`

---

gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1


**技能依赖：** `project-board-enforcement`

---

Step 1: Parse Feedback into Items

步骤1：将反馈拆分为独立事项

Identify Distinct Items

识别独立事项

Read through the feedback and identify each distinct item. Look for:

Separate headings or sections
Numbered lists
Different error messages or behaviors
Distinct feature requests or changes

通读反馈内容，识别每个独立的事项。注意寻找：

独立的标题或章节
编号列表
不同的错误信息或行为描述
不同的功能请求或更改需求

Create Tracking List

创建跟踪列表

bash

undefined

bash

undefined

Use TodoWrite to track each item

Example: 3 items from UAT feedback

TodoWrite:

Investigate: Family page error (API 500)
Investigate: Terminology issue (Children vs Care Recipients)
Investigate: Cannot add care recipient (API 500)

undefined

TodoWrite:

Investigate: Family page error (API 500)
Investigate: Terminology issue (Children vs Care Recipients)
Investigate: Cannot add care recipient (API 500)

undefined

Item Summary Table

事项汇总表

Create a summary table for the user:

markdown

undefined

为用户创建一份汇总表：

markdown

undefined

Feedback Items Identified

已识别的反馈事项

#	Summary	Type (Preliminary)	Severity
1	Family page error	Bug	High
2	Terminology needs review	UX/Research	Medium
3	Cannot add care recipient	Bug	High

I will investigate each item before creating issues.

---

序号	摘要	初步类型	严重程度
1	家庭页面错误	Bug	高
2	术语需要审核	UX/调研	中
3	无法添加被照护人	Bug	高

我会在创建问题前逐一调查每个事项。

---

Step 2: Investigate Each Item

步骤2：调查每个事项

CRITICAL: Never create an issue without investigation. Understanding comes first.

关键注意事项：绝不跳过调查直接创建问题。必须先理解问题。

Investigation Protocol by Item Type

按事项类型划分的调查流程

For API Errors / Bugs

针对API错误/Bug

markdown

undefined

markdown

undefined

Investigation: [Item Title]

调查：[事项标题]

1. Error Analysis

1. 错误分析

Error code: [e.g., INTERNAL_ERROR, 500, 404]
Error message: [exact message]
Request endpoint: [URL]
Request method: [GET/POST/etc.]

错误代码：[例如：INTERNAL_ERROR, 500, 404]
错误信息：[准确信息]
请求端点：[URL]
请求方法：[GET/POST等]

2. Reproduction

2. 复现验证

Can reproduce: [Yes/No]
Reproduction steps:
1. [Step 1]
2. [Step 2]

能否复现：[是/否]
复现步骤：
1. [步骤1]
2. [步骤2]

3. Code Investigation

3. 代码调查

Relevant files: [paths]
Likely cause: [hypothesis after code review]
Related code: [functions/modules involved]

相关文件：[路径]
可能原因：[代码审查后的假设]
涉及代码：[相关函数/模块]

4. Impact Assessment

4. 影响评估

Users affected: [All/Some/Specific conditions]
Functionality blocked: [What can't users do?]
Workaround exists: [Yes/No - describe if yes]

受影响用户：[全部/部分/特定条件下的用户]
被阻塞功能：[用户无法执行哪些操作？]
是否有替代方案：[是/否 - 若有则描述]

5. Classification

5. 分类

Type: Bug
Severity: [Critical/High/Medium/Low]
Priority: [Critical/High/Medium/Low]

undefined

类型：Bug
严重程度：[Critical/高/中/低]
优先级：[Critical/高/中/低]

undefined

For UX/Feature Feedback

针对UX/功能反馈

markdown

undefined

markdown

undefined

Investigation: [Item Title]

调查：[事项标题]

1. Current Behavior

1. 当前行为

What exists now: [description]
Where it appears: [URLs/screens]
Current implementation: [code locations]

现有状态：[描述]
出现位置：[URL/页面]
当前实现：[代码位置]

2. Requested Change

2. 请求的更改

What's being asked for: [description]
User impact: [how this affects users]
Business context: [why this matters]

需求内容：[描述]
用户影响：[对用户的影响]
业务背景：[需求的重要性]

3. Scope Analysis

3. 范围分析

Files affected: [list]
Complexity: [Low/Medium/High]
Dependencies: [other features/systems]

受影响文件：[列表]
复杂度：[低/中/高]
依赖项：[其他功能/系统]

4. Design Considerations

4. 设计考虑

Options identified:
1. [Option A] - [pros/cons]
2. [Option B] - [pros/cons]
Recommendation: [if clear]
Needs: [Design input / Product decision / Research]

已识别的方案：
1. [方案A] - [优缺点]
2. [方案B] - [优缺点]
推荐方案：[若明确]
所需支持：[设计输入 / 产品决策 / 调研]

5. Classification

5. 分类

Type: Feature / Research / UX Enhancement
Priority: [Critical/High/Medium/Low]

undefined

类型：功能 / 调研 / UX优化
优先级：[Critical/高/中/低]

undefined

For Production Incidents

针对生产环境事故

markdown

undefined

markdown

undefined

Investigation: [Item Title]

调查：[事项标题]

1. Incident Details

1. 事故详情

First reported: [timestamp]
Frequency: [One-time/Intermittent/Constant]
Environment: [Production/Staging/etc.]

首次上报时间：[时间戳]
发生频率：[一次性/间歇性/持续]
环境：[生产/预发布等]

2. Error Analysis

2. 错误分析

Error logs: [key log entries]
Stack trace: [if available]
Affected service: [component/service name]

错误日志：[关键日志条目]
堆栈跟踪：[若有]
受影响服务：[组件/服务名称]

3. Impact Assessment

3. 影响评估

Users affected: [count/percentage]
Revenue impact: [if applicable]
SLA implications: [if applicable]

受影响用户：[数量/比例]
收入影响：[若适用]
SLA影响：[若适用]

4. Root Cause Analysis

4. 根本原因分析

Hypothesis: [likely cause]
Evidence: [supporting data]
Related changes: [recent deployments/changes]

假设：[可能原因]
证据：[支持数据]
相关变更：[近期部署/变更]

5. Classification

5. 分类

Type: Bug
Severity: Critical / High
Priority: Critical / High

undefined

类型：Bug
严重程度：Critical / 高
优先级：Critical / 高

undefined

Investigation Checklist

调查检查清单

针对每个事项，验证以下内容：

已理解错误/行为
已审查代码（若适用）
已评估范围
已评估影响
已确定类型（Bug/功能/调研等）
已确定优先级
已准备好创建问题

Step 3: Classify Each Item

步骤3：对每个事项进行分类

Type Classification

类型分类

Type	When to Use	Project Board Type
Bug	Something broken, not working as designed	Bug
Feature	New capability, clear requirements	Feature
Research	Needs exploration, design thinking, options analysis	Research
Spike	Time-boxed technical investigation	Spike
Chore	Maintenance, cleanup, non-user-facing	Chore
UX Enhancement	Improving existing user experience	Feature

类型	使用场景	项目看板类型
Bug	功能损坏，未按设计工作	Bug
功能	新功能，需求明确	Feature
调研	需要探索、设计思考、方案分析	Research
技术探索	时间盒限制的技术调研	Spike
维护任务	维护、清理、非用户可见的任务	Chore
UX优化	改进现有用户体验	Feature

Priority Classification

优先级分类

Priority	Criteria	Response
Critical	Production down, data loss, security breach	Immediate
High	Major feature broken, significant user impact, blocking	This sprint
Medium	Feature degraded, workaround exists, important but not blocking	Next sprint
Low	Minor issue, cosmetic, nice-to-have	Backlog

优先级	判定标准	响应要求
Critical	生产环境宕机、数据丢失、安全漏洞	立即处理
高	主要功能损坏、用户影响大、阻塞工作	本迭代处理
中	功能降级、有替代方案、重要但不阻塞	下一迭代处理
低	小问题、 cosmetic问题、锦上添花的功能	放入待办列表

Severity vs Priority

严重程度 vs 优先级

Severity = How bad is the problem? (Technical assessment)
Priority = How soon should we fix it? (Business decision)

A low-severity bug affecting a VIP customer may be high priority. A high-severity bug on a deprecated feature may be low priority.

严重程度 = 问题的严重程度？（技术评估）
优先级 = 我们需要多快修复？（业务决策）

影响VIP客户的低严重程度Bug可能优先级为高。已弃用功能上的高严重程度Bug可能优先级为低。

Step 4: Create Well-Formed Issues

步骤4：创建格式规范的问题

Issue Template: Bug

Bug问题模板

bash

gh issue create \
  --title "[Bug] [Concise description of the problem]" \
  --body "## Summary

[One-sentence description of the bug]

bash

gh issue create \
  --title "[Bug] [问题的简洁描述]" \
  --body "## 摘要

[Bug的一句话描述]

Environment

环境

URL: [affected URL]
Environment: [Production/Staging/Local]
Browser/Client: [if relevant]

URL: [受影响的URL]
环境: [生产/预发布/本地]
浏览器/客户端: [若相关]

Steps to Reproduce

复现步骤

[Step 1]
[Step 2]
[Step 3]

[步骤1]
[步骤2]
[步骤3]

Expected Behavior

预期行为

[What should happen]

[应该出现的结果]

Actual Behavior

实际行为

[What actually happens]

[实际出现的结果]

Error Details

错误详情

``` [Error message, status code, or log output] ```

``` [错误信息、状态码或日志输出] ```

Investigation Findings

调查结果

Code Analysis

代码分析

Affected files: [list of files]
Likely cause: [hypothesis]
Related code: [functions/modules]

受影响文件: [文件列表]
可能原因: [假设]
相关代码: [函数/模块]

Impact

影响

Users affected: [scope]
Functionality blocked: [what can't users do]
Workaround: [if any]

受影响用户: [范围]
被阻塞功能: [用户无法执行的操作]
替代方案: [若有]

Acceptance Criteria

验收标准

Error no longer occurs
[Specific behavior restored]
Tests added to prevent regression

错误不再出现
[特定功能恢复]
添加测试防止回归

Technical Notes

技术说明

[Any additional technical context from investigation]

Source: UAT Feedback / User Report / Support Ticket Reported: [DATE]"

undefined

[调查得到的其他技术背景]

来源: UAT反馈 / 用户报告 / 支持工单 上报时间: [日期]"

undefined

Issue Template: Feature / UX Enhancement

功能/UX优化问题模板

bash

gh issue create \
  --title "[Feature] [Clear description of the feature]" \
  --body "## Summary

[One-sentence description of what this feature does]

bash

gh issue create \
  --title "[Feature] [功能的清晰描述]" \
  --body "## 摘要

[功能的一句话描述]

Background

背景

[Why this is needed - user feedback, business requirement, etc.]

[需求原因 - 用户反馈、业务要求等]

Current Behavior

当前行为

[What exists today, if anything]

[现有功能（若有）]

Proposed Behavior

提议的行为

[What should happen after implementation]

[实现后应出现的结果]

User Story

用户故事

As a [type of user], I want [goal] so that [benefit].

作为[用户类型]，我希望[目标]，以便[收益]。

Investigation Findings

调查结果

Scope Analysis

范围分析

Files affected: [list]
Complexity: [Low/Medium/High]
Dependencies: [related features/systems]

受影响文件: [列表]
复杂度: [低/中/高]
依赖项: [相关功能/系统]

Design Considerations

设计考虑

[Options considered, recommendations, questions]

[考虑的方案、建议、问题]

Acceptance Criteria

验收标准

[Specific, verifiable criterion 1]
[Specific, verifiable criterion 2]
[Specific, verifiable criterion 3]

[具体、可验证的标准1]
[具体、可验证的标准2]
[具体、可验证的标准3]

Out of Scope

范围外内容

[What this issue will NOT address]

[本问题不解决的内容]

Technical Notes

技术说明

[Implementation hints, patterns to follow, etc.]

Source: UAT Feedback / User Request / Stakeholder Input Requested: [DATE]"

undefined

[实现提示、遵循的模式等]

来源: UAT反馈 / 用户请求 / 利益相关者输入 请求时间: [日期]"

undefined

Issue Template: Research / Spike

调研/技术探索问题模板

bash

gh issue create \
  --title "[Research] [What needs to be understood]" \
  --body "## Summary

[One-sentence description of what needs to be researched]

bash

gh issue create \
  --title "[Research] [需要调研的内容]" \
  --body "## 摘要

[需要调研内容的一句话描述]

Background

背景

[Why this research is needed]

[调研的必要性]

Questions to Answer

需要解答的问题

[Question 1]
[Question 2]
[Question 3]

[问题1]
[问题2]
[问题3]

Investigation Context

调查背景

[What was discovered during initial triage that prompted this research]

[初始分类处理中发现的、促使本次调研的内容]

Scope

范围

In Scope

范围内

[Topic 1]
[Topic 2]

[主题1]
[主题2]

Out of Scope

范围外

[Not covering X]

[不涉及X]

Deliverables

交付物

Document with findings
Recommendations for next steps
[Specific output, e.g., design options, architecture diagram]

包含调研结果的文档
下一步建议
[特定输出，如设计方案、架构图]

Time Box

时间盒

[Suggested time limit: e.g., 4 hours, 1 day]

[建议的时间限制：如4小时、1天]

Acceptance Criteria

验收标准

All questions answered with evidence
Recommendations documented
Next steps identified (issues to create)

Source: UAT Feedback / Triage Investigation Created: [DATE]"

---

所有问题都有证据支持的答案
建议已记录
已确定下一步（要创建的问题）

来源: UAT反馈 / 分类处理调研 创建时间: [日期]"

---

Step 5: Add to Project Board (MANDATORY)

步骤5：添加至项目看板（必填）

Every issue MUST be added to the project board with correct fields.

bash

undefined

每个问题都必须添加到项目看板，并设置正确的字段。

bash

undefined

After creating issue, add to project

ISSUE_URL=$(gh issue view [ISSUE_NUMBER] --json url -q '.url') gh project item-add "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --url "$ISSUE_URL"

Get item ID

ITEM_ID=$(gh project item-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r ".items[] | select(.content.number == [ISSUE_NUMBER]) | .id")

Get field IDs

PROJECT_ID=$(gh project list --owner "$GH_PROJECT_OWNER" --format json |
jq -r ".projects[] | select(.number == $GITHUB_PROJECT_NUM) | .id")

STATUS_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r '.fields[] | select(.name == "Status") | .id')

TYPE_FIELD_NAME="Type" if ! gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -e '.fields[] | select(.name == "Type")' >/dev/null 2>&1; then if gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -e '.fields[] | select(.name == "Issue Type")' >/dev/null 2>&1; then TYPE_FIELD_NAME="Issue Type" fi fi

TYPE_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r --arg type_field "$TYPE_FIELD_NAME" '.fields[] | select(.name == $type_field) | .id')

PRIORITY_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r '.fields[] | select(.name == "Priority") | .id')

PROJECT_ID=$(gh project list --owner "$GH_PROJECT_OWNER" --format json |
jq -r ".projects[] | select(.number == $GITHUB_PROJECT_NUM) | .id")

STATUS_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r '.fields[] | select(.name == "Status") | .id')

TYPE_FIELD_NAME="Type" if ! gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -e '.fields[] | select(.name == "Type")' >/dev/null 2>&1; then if gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -e '.fields[] | select(.name == "Issue Type")' >/dev/null 2>&1; then TYPE_FIELD_NAME="Issue Type" fi fi

TYPE_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r --arg type_field "$TYPE_FIELD_NAME" '.fields[] | select(.name == $type_field) | .id')

PRIORITY_FIELD_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r '.fields[] | select(.name == "Priority") | .id')

Set Status = Ready (or Backlog for lower priority)

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$STATUS_FIELD_ID" --single-select-option-id "$READY_OPTION_ID"

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$STATUS_FIELD_ID" --single-select-option-id "$READY_OPTION_ID"

Set Type (Bug, Feature, Research, etc.)

TYPE_OPTION_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r --arg type_field "$TYPE_FIELD_NAME" --arg type_value "[TYPE]" '.fields[] | select(.name == $type_field) | .options[] | select(.name == $type_value) | .id')

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$TYPE_FIELD_ID" --single-select-option-id "$TYPE_OPTION_ID"

TYPE_OPTION_ID=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER"
--format json | jq -r --arg type_field "$TYPE_FIELD_NAME" --arg type_value "[TYPE]" '.fields[] | select(.name == $type_field) | .options[] | select(.name == $type_value) | .id')

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$TYPE_FIELD_ID" --single-select-option-id "$TYPE_OPTION_ID"

Set Priority

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$PRIORITY_FIELD_ID" --single-select-option-id "$PRIORITY_OPTION_ID"

gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID"
--field-id "$PRIORITY_FIELD_ID" --single-select-option-id "$PRIORITY_OPTION_ID"

Verify

echo "Issue #[ISSUE_NUMBER] added to project with Status=Ready, Type=[TYPE], Priority=[PRIORITY]"


**Skill:** `project-board-enforcement`

---

echo "Issue #[ISSUE_NUMBER] added to project with Status=Ready, Type=[TYPE], Priority=[PRIORITY]"


**技能依赖：** `project-board-enforcement`

---

Step 6: Summary Report

步骤6：汇总报告

After all items are triaged, provide a summary:

markdown

undefined

所有事项分类处理完成后，提供一份汇总报告：

markdown

undefined

Triage Complete

分类处理完成

Issues Created

已创建的问题

#	Issue	Type	Priority	Status
1	#123 - Family page API error	Bug	High	Ready
2	#124 - Kin Circle terminology research	Research	Medium	Ready
3	#125 - Cannot add care recipient	Bug	High	Ready

序号	问题	类型	优先级	状态
1	#123 - 家庭页面API错误	Bug	高	就绪
2	#124 - Kin Circle术语调研	调研	中	就绪
3	#125 - 无法添加被照护人	Bug	高	就绪

Project Board Status

项目看板状态

All issues added to project board with correct fields.

所有问题已添加到项目看板，并设置了正确的字段。

Recommended Order

Next Steps

下一步

Assign issues to developers
Begin work using
```
issue-driven-development
```
Or request immediate resolution

---

将问题分配给开发人员
使用
```
issue-driven-development
```
开始处理
或请求立即解决

---

Example: Processing UAT Feedback

示例：处理UAT反馈

Input Received

收到的输入

markdown

We have some bugs to resolve from UAT.

markdown

我们有一些来自UAT的bug需要修复。

Family Page has error

家庭页面出现错误

https://stage.kin.life/family

Displays: Something went wrong on our end. [curl command and error response]

https://stage.kin.life/family

显示：Something went wrong on our end. [curl command and error response]

Family Page refers to "Children" - not Care Recipients

家庭页面使用“Children”而非“Care Recipients”

Need better terminology, research required.

需要更合适的术语，需进行调研。

Family Page unable to add care recipient

家庭页面无法添加被照护人

[curl command and error response]

undefined

[curl command and error response]

undefined

Triage Process

分类处理流程

Step 1: Parse into items

Item 1: Family page 500 error on load
Item 2: Terminology issue (Children vs Care Recipients)
Item 3: Cannot add care recipient (500 error)

Step 2: Investigate each

Item 1 Investigation:

API endpoint:
```
/api/v1/children?limit=50
```
Error:
```
INTERNAL_ERROR
```
Code review: Check children service, database queries
Impact: Users cannot view family page at all

Item 2 Investigation:

Current: Hardcoded "Children" but button says "care recipient"
Request: More inclusive language for diverse care relationships
Scope: UI changes, possibly data model changes
Needs: UX research, product decision

Item 3 Investigation:

API endpoint:
```
POST /api/v1/children
```
Payload: Valid care recipient data
Error:
```
INTERNAL_ERROR
```
Code review: Check creation endpoint, validation, database writes
Impact: Users cannot add any care recipients

Step 3: Classify

Item	Type	Priority	Reasoning
1	Bug	High	Core functionality broken
2	Research	Medium	UX improvement, not blocking
3	Bug	High	Core functionality broken

Step 4: Create issues (using templates above)

Step 5: Add to project board (with Type, Priority, Status)

Step 6: Summary report (as shown above)

步骤1：拆分为事项

事项1：家庭页面加载时出现500错误
事项2：术语问题（Children vs Care Recipients）
事项3：无法添加被照护人（500错误）

步骤2：逐一调查

事项1调查结果:

API端点:
```
/api/v1/children?limit=50
```
错误:
```
INTERNAL_ERROR
```
代码审查: 检查children服务、数据库查询
影响: 用户完全无法查看家庭页面

事项2调查结果:

当前状态: 硬编码使用“Children”，但按钮显示“care recipient”
请求: 为多样化的照护关系使用更具包容性的术语
范围: UI更改，可能涉及数据模型更改
需求: UX调研、产品决策

事项3调查结果:

API端点:
```
POST /api/v1/children
```
请求负载: 有效的被照护人数据
错误:
```
INTERNAL_ERROR
```
代码审查: 检查创建端点、验证逻辑、数据库写入
影响: 用户无法添加任何被照护人

步骤3：分类

事项	类型	优先级	理由
1	Bug	高	核心功能损坏
2	调研	中	UX优化，不阻塞业务
3	Bug	高	核心功能损坏

步骤4：创建问题（使用上述模板）

步骤5：添加到项目看板（设置类型、优先级、状态）

步骤6：汇总报告（如上所示）

Best Practices for Issue Quality

问题质量最佳实践

Title Conventions

标题规范

Type	Format	Example
Bug	`[Bug] <What is broken>`	`[Bug] Family page returns 500 error`
Feature	`[Feature] <What it does>`	`[Feature] Add person to Kin Circle`
Research	`[Research] <What to investigate>`	`[Research] Inclusive terminology for care relationships`
Spike	`[Spike] <Technical question>`	`[Spike] Evaluate API caching strategies`

类型	格式	示例
Bug	`[Bug] <损坏的功能>`	`[Bug] 家庭页面返回500错误`
功能	`[Feature] <功能描述>`	`[Feature] 添加人员到Kin Circle`
调研	`[Research] <调研内容>`	`[Research] 照护关系的包容性术语`
技术探索	`[Spike] <技术问题>`	`[Spike] 评估API缓存策略`

Acceptance Criteria Quality

验收标准质量

Good criteria are:

Specific and verifiable
Written as checkboxes
Focused on behavior, not implementation
Testable

Bad:

Fix the bug
Make it work

Good:

GET
```
/api/v1/children
```
returns 200 with valid data
Family page displays list of care recipients
Error state shows user-friendly message with retry option

好的标准应具备：

具体且可验证
以复选框形式呈现
关注行为而非实现
可测试

不好的示例：

修复bug
让它正常工作

好的示例：

GET
```
/api/v1/children
```
返回200和有效数据
家庭页面显示被照护人列表
错误状态显示友好的提示信息和重试选项

Investigation Documentation

调查文档

Always document:

What you found
Where you looked
What the likely cause is
What the impact is

This saves time when implementation begins.

始终记录：

你的发现
你查看的位置
可能的原因
影响范围

这会为后续的实现工作节省时间。

Handling Unclear Feedback

处理不明确的反馈

When Feedback is Vague

当反馈模糊时

If feedback lacks detail:

Ask clarifying questions before creating issue
Create Research issue to gather more information
Document what IS known in the issue

如果反馈缺少细节：

在创建问题前提出澄清问题
创建调研问题以收集更多信息
在问题中记录已知的内容

Clarification Template

澄清模板

markdown

Before I create issues for this feedback, I need clarification:

1. **[Item 1]:** [Question about scope/expected behavior/reproduction]
2. **[Item 2]:** [Question about priority/business context]

Once clarified, I'll complete the investigation and create properly-formed issues.

markdown

在为这些反馈创建问题之前，我需要以下澄清：

1. **[事项1]:** [关于范围/预期行为/复现步骤的问题]
2. **[事项2]:** [关于优先级/业务背景的问题]

得到澄清后，我会完成调查并创建格式规范的问题。

When to Create Research Issues

何时创建调研问题

Create a Research issue instead of Bug/Feature when:

Requirements are unclear
Multiple solutions exist
Design decisions needed
User research required
Technical feasibility unknown

当出现以下情况时，创建调研问题而非Bug/功能问题：

需求不明确
存在多个解决方案
需要做出设计决策
需要用户调研
技术可行性未知

Integration with Other Skills

与其他技能的集成

This skill flows TO:

本技能可流向：

Skill	When
`issue-driven-development`	After issues created, to begin resolution
`issue-decomposition`	If a feedback item is too large for one issue
`epic-management`	If feedback items should be grouped as epic

技能	时机
`issue-driven-development`	创建问题后，开始解决问题时
`issue-decomposition`	若反馈事项过大，无法用单个问题覆盖时
`epic-management`	若反馈事项应组合为史诗时

This skill uses:

本技能依赖：

Skill	For
`project-board-enforcement`	Adding issues to project board
`pre-work-research`	Investigation patterns
`issue-prerequisite`	Issue quality standards

技能	用途
`project-board-enforcement`	将问题添加到项目看板
`pre-work-research`	调研模式
`issue-prerequisite`	问题质量标准

Memory Integration

记忆集成

Store triage sessions in knowledge graph:

bash

mcp__memory__create_entities([{
  "name": "Triage-[DATE]-[SOURCE]",
  "entityType": "FeedbackTriage",
  "observations": [
    "Source: UAT / User Report / etc.",
    "Date: [DATE]",
    "Items received: [COUNT]",
    "Issues created: #X, #Y, #Z",
    "Types: [Bug: N, Feature: N, Research: N]",
    "High priority: [COUNT]"
  ]
}])

将分类处理会话存储到知识图谱：

bash

mcp__memory__create_entities([{
  "name": "Triage-[DATE]-[SOURCE]",
  "entityType": "FeedbackTriage",
  "observations": [
    "Source: UAT / User Report / etc.",
    "Date: [DATE]",
    "Items received: [COUNT]",
    "Issues created: #X, #Y, #Z",
    "Types: [Bug: N, Feature: N, Research: N]",
    "High priority: [COUNT]"
  ]
}])

Checklist

检查清单

Before Starting Triage

开始分类处理前

Project board readiness verified (GITHUB_PROJECT_NUM, GH_PROJECT_OWNER)
Feedback source identified
All items parsed and listed

已验证项目看板就绪（GITHUB_PROJECT_NUM, GH_PROJECT_OWNER）
已识别反馈来源
已拆分并列出所有事项

For Each Item

针对每个事项

After All Items

所有事项处理完成后

Summary report provided
All issues in project board verified
Recommended priority order given
Memory updated
Ready for resolution (if requested)

Gate: No issue is created without investigation. No issue is left outside the project board.

已提供汇总报告
已验证所有问题都在项目看板中
已给出推荐的处理顺序
已更新记忆
已准备好开始解决问题（若有请求）

准入门槛：没有经过调查的问题不能创建。没有问题会被留在项目看板之外。

Proceeding to Resolution

进入问题解决阶段

If the user requests resolution after triage:

markdown

Issues have been created and prioritized.

**To resolve these issues:**

1. I will work through them using `issue-driven-development`
2. Starting with highest priority: #[N]
3. Each issue will follow the full development process

Shall I proceed with resolution, or should these be assigned for later work?

If proceeding, invoke

issue-driven-development

for each issue in priority order.

如果用户在分类处理后请求解决问题：

markdown

问题已创建并完成优先级排序。

**解决这些问题的方式：**

1. 我会使用`issue-driven-development`来处理它们
2. 从最高优先级的问题开始：#N
3. 每个问题都会遵循完整的开发流程

我是否应该开始解决这些问题，还是将它们分配给后续工作？

如果继续，按优先级顺序为每个问题调用

issue-driven-development

技能。

feedback-triage

Original

Translation

Feedback Triage

反馈分类处理

Overview

概述

When to Use This Skill

何时使用该技能

The Triage Protocol

分类处理流程

Step 0: Project Board Readiness (GATE)

步骤0：项目看板就绪检查（准入门槛）

Derive defaults from GITHUB_PROJECT if provided

Derive defaults from GITHUB_PROJECT if provided

Verify environment variables

Verify environment variables

Verify project is accessible

Verify project is accessible

Step 1: Parse Feedback into Items

步骤1：将反馈拆分为独立事项

Identify Distinct Items

识别独立事项

Create Tracking List

创建跟踪列表

Use TodoWrite to track each item

Use TodoWrite to track each item

Example: 3 items from UAT feedback

Example: 3 items from UAT feedback

Item Summary Table

事项汇总表

Feedback Items Identified

已识别的反馈事项

Step 2: Investigate Each Item

步骤2：调查每个事项

Investigation Protocol by Item Type

按事项类型划分的调查流程

For API Errors / Bugs

针对API错误/Bug

Investigation: [Item Title]

调查：[事项标题]

1. Error Analysis

1. 错误分析

2. Reproduction

2. 复现验证

3. Code Investigation

3. 代码调查

4. Impact Assessment

4. 影响评估

5. Classification

5. 分类

For UX/Feature Feedback

针对UX/功能反馈

Investigation: [Item Title]

调查：[事项标题]

1. Current Behavior

1. 当前行为

2. Requested Change

2. 请求的更改

3. Scope Analysis

3. 范围分析

4. Design Considerations

4. 设计考虑

5. Classification

5. 分类

For Production Incidents

针对生产环境事故

Investigation: [Item Title]

调查：[事项标题]

1. Incident Details

1. 事故详情

2. Error Analysis

2. 错误分析

3. Impact Assessment

3. 影响评估

4. Root Cause Analysis

4. 根本原因分析

5. Classification

5. 分类

Investigation Checklist