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."

When to Use This Skill

Use this skill when you receive:

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"

The Triage Protocol

Flow: Verify project board → Parse items → For each: Investigate → Classify → Create issue → Add to project board

Step 0: Project Board Readiness (GATE)

Before any triage, verify project board infrastructure is ready.

# 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

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

Skill: project-board-enforcement

Step 1: Parse Feedback into Items

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

# 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)

Item Summary Table

Create a summary table for the user:

## 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.

Step 2: Investigate Each Item

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

Investigation Protocol by Item Type

#### For API Errors / Bugs

## Investigation: [Item Title]

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

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

### 3. Code Investigation
- Relevant files: [paths]
- Likely cause: [hypothesis after code review]
- Related code: [functions/modules involved]

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

### 5. Classification
- Type: Bug
- Severity: [Critical/High/Medium/Low]
- Priority: [Critical/High/Medium/Low]

#### For UX/Feature Feedback

## Investigation: [Item Title]

### 1. Current Behavior
- What exists now: [description]
- Where it appears: [URLs/screens]
- Current implementation: [code locations]

### 2. Requested Change
- What's being asked for: [description]
- User impact: [how this affects users]
- Business context: [why this matters]

### 3. Scope Analysis
- Files affected: [list]
- Complexity: [Low/Medium/High]
- Dependencies: [other features/systems]

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

### 5. Classification
- Type: Feature / Research / UX Enhancement
- Priority: [Critical/High/Medium/Low]

#### For Production Incidents

## Investigation: [Item Title]

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

### 2. Error Analysis
- Error logs: [key log entries]
- Stack trace: [if available]
- Affected service: [component/service name]

### 3. Impact Assessment
- Users affected: [count/percentage]
- Revenue impact: [if applicable]
- SLA implications: [if applicable]

### 4. Root Cause Analysis
- Hypothesis: [likely cause]
- Evidence: [supporting data]
- Related changes: [recent deployments/changes]

### 5. Classification
- Type: Bug
- Severity: Critical / High
- Priority: Critical / High

Investigation Checklist

For each item, verify:

• [ ] Error/behavior understood
• [ ] Code reviewed (if applicable)
• [ ] Scope assessed
• [ ] Impact evaluated
• [ ] Type determined (Bug/Feature/Research/etc.)
• [ ] Priority determined
• [ ] Ready to create issue

Step 3: Classify Each Item

Type Classification

Priority Classification

Severity vs Priority

• 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.

Step 4: Create Well-Formed Issues

Issue Templates

Bug: [Bug] <description> - Include: Summary, Environment, Steps to Reproduce, Expected/Actual Behavior, Error Details, Investigation Findings (files, cause, impact), Acceptance Criteria, Source.

Feature: [Feature] <description> - Include: Summary, Background, Current/Proposed Behavior, User Story, Scope Analysis (files, complexity), Acceptance Criteria, Out of Scope.

Research: [Research] <topic> - Include: Summary, Background, Questions to Answer, Scope, Time Box, Deliverables, Acceptance Criteria.

Use gh issue create --title "[Type] ..." --body "..." with appropriate sections from above.

Step 5: Add to Project Board (MANDATORY)

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

Use project-board-enforcement skill functions:

1. add_issue_to_project - Add issue to project
2. set_project_status - Set Status (Ready/Backlog)
3. set_project_type - Set Type (Bug/Feature/Research)
4. Set Priority field

Skill: project-board-enforcement

Step 6: Summary Report

After all items are triaged, provide a summary:

## 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 |

### Project Board Status
All issues added to project board with correct fields.

### Recommended Order
1. **#123** - Blocking user access to family page
2. **#125** - Blocking care recipient management
3. **#124** - UX research can proceed in parallel

### Next Steps
- [ ] Assign issues to developers
- [ ] Begin work using `issue-driven-development`
- [ ] Or request immediate resolution

Best Practices

Title formats: [Bug] <what's broken>, [Feature] <what it does>, [Research] <what to investigate>, [Spike] <technical question>

Good acceptance criteria: Specific, verifiable, behavior-focused, testable checkboxes.

If feedback is vague: Ask clarifying questions OR create Research issue. Document what IS known.

Integration with Other Skills

This skill flows TO:

This skill uses:

Memory Integration

Store triage sessions in knowledge graph:

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

For Each Item

• [ ] Investigation complete (not skipped)
• [ ] Error/behavior understood
• [ ] Code reviewed (for bugs)
• [ ] Scope assessed
• [ ] Impact evaluated
• [ ] Type classified (Bug/Feature/Research/etc.)
• [ ] Priority assigned
• [ ] Issue created with full template
• [ ] Added to project board
• [ ] Status field set (Ready or Backlog)
• [ ] Type field set
• [ ] Priority field set

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:

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.