home / skills / basedhardware / omi / issue-triage

issue-triage skill

/.cursor/skills/issue-triage

This skill analyzes GitHub issues, scores priority, maps to Omi layers, and suggests lanes to streamline triage and resolution.

npx playbooks add skill basedhardware/omi --skill issue-triage

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.8 KB
---
name: issue-triage
description: "Automate issue triage using ISSUE_TRIAGE_GUIDE.MD. Use when analyzing GitHub issues. Scores issues using triage formula, assigns priority levels, suggests lane assignment, and maps to Omi layers."
---

# Issue Triage Skill

Automate GitHub issue triage using the Omi Issue Triage Guide.

## When to Use

Use this skill when:
- Analyzing GitHub issues
- When user requests issue triage
- When reviewing new issues
- When prioritizing issues
- When assigning issues to lanes

## Capabilities

### 1. Score Issues

Calculate priority score using the triage formula from `ISSUE_TRIAGE_GUIDE.MD`:

**Priority Score = (Core Layer Weight × Failure Severity) + Trust Impact + Frequency + Maintenance Leverage - Cost & Risk**

### 2. Map to Omi Layers

Identify which primary layer the issue affects:
- **Capture** (Weight: 5): Audio recording, device pairing, permissions, battery
- **Understand** (Weight: 4): Speech-to-text, language detection, diarization
- **Memory** (Weight: 4): Memory creation, syncing, storage, metadata
- **Intelligence** (Weight: 3): Summaries, insights, action items
- **Retrieval / Action** (Weight: 3): Search, asking Omi, tasks, exports
- **UX / Polish** (Weight: 1): UI layout, animations, wording
- **Docs / Tooling** (Weight: 1): Documentation, examples, tooling

### 3. Evaluate Scoring Factors

Assess each factor (1-5 scale):

**Failure Severity**:
- 5: Completely broken
- 4: Frequently fails
- 3: Partially degraded
- 2: Minor annoyance
- 1: Cosmetic

**Trust Impact**:
- 5: Data loss or missing memories
- 4: Incorrect or corrupted memories
- 3: Inconsistent behavior
- 2: Confusing but recoverable
- 1: No trust impact

**Frequency**:
- 5: Happens daily
- 4: Weekly
- 3: Regular but situational
- 2: Rare
- 1: Edge case

**Maintenance Leverage**:
- 5: Eliminates a class of bugs
- 4: Improves observability or stability
- 3: Neutral
- 2: Adds complexity
- 1: Increases long-term maintenance burden

**Cost & Risk** (subtracted):
- 5: Cross-device + backend + firmware
- 4: Core pipeline change
- 3: Moderate
- 2: Small
- 1: Trivial

### 4. Assign Priority Levels

Based on score:
- **>= 30**: P0 - Existential / must fix immediately
- **22-29**: P1 - Critical
- **14-21**: P2 - Important
- **< 14**: P3 - Backlog

### 5. Suggest Lane Assignment

Assign to appropriate lane:
- **Maintainer Now**: High-risk, cross-system, or architectural changes
- **Community Ready**: Clear scope, safe changes, suitable for contributors
- **Needs Info**: Missing repro steps, logs, versions, or clarity
- **Park**: Out of scope or low leverage

## Triage Rules

Follow these principles:
- Issues are signals, not commands
- Popularity does not determine urgency
- Data loss outranks feature requests
- Capture failures outrank intelligence improvements
- Memory-first principle: If Omi fails to capture or preserve memory, nothing else matters

## Workflow

1. **Read Issue**: Analyze issue description, labels, comments
2. **Map to Layer**: Identify primary Omi layer affected
3. **Evaluate Factors**: Score each factor (1-5)
4. **Calculate Score**: Apply triage formula
5. **Assign Priority**: Map score to priority level (P0-P3)
6. **Suggest Lane**: Recommend lane assignment
7. **Report**: Provide triage summary with reasoning

## Example Triage

**Issue**: Recording stops unexpectedly

**Analysis**:
- Layer: Capture (5)
- Severity: 5 (Completely broken)
- Trust Impact: 5 (Data loss - missing recordings)
- Frequency: 4 (Weekly)
- Leverage: 4 (Improves stability)
- Cost: 3 (Moderate)

**Score**: (5 × 5) + 5 + 4 + 4 - 3 = 35 → **P0**

**Lane**: Maintainer Now (high-risk, affects core functionality)

## Related Resources

### Documentation
- `ISSUE_TRIAGE_GUIDE.MD` - Complete triage guide and formula

### Rules
- `.cursor/rules/omi-specific-patterns.mdc` - Omi architecture and priorities

### Commands
- `/auto-triage` - Automatically triage an issue

Overview

This skill automates GitHub issue triage for the Omi wearable platform using a formal triage formula. It scores issues, assigns priority levels (P0–P3), maps issues to Omi layers, and recommends lane assignments with concise reasoning. The output helps maintainers and contributors decide next steps quickly.

How this skill works

The skill reads an issue’s title, description, labels, and comments, then identifies the primary Omi layer affected (Capture, Understand, Memory, Intelligence, Retrieval/Action, UX/Polish, Docs/Tooling). It evaluates five scoring factors on a 1–5 scale (Failure Severity, Trust Impact, Frequency, Maintenance Leverage, Cost & Risk), applies the triage formula, and maps the numeric result to a priority level. Finally, it recommends a lane (Maintainer Now, Community Ready, Needs Info, Park) and provides a short rationale for each decision.

When to use it

  • When reviewing newly opened GitHub issues for the Omi project
  • When a contributor asks for triage or prioritization guidance
  • During sprint planning to prioritize backlog items
  • When determining whether an issue requires immediate maintainer attention
  • When deciding if an issue is suitable for community contribution

Best practices

  • Score factors conservatively and document the reasoning for each factor
  • Prioritize capture and memory failures over lower-layer regressions due to data-loss risk
  • Prefer clear, actionable lane suggestions and list missing info when recommending Needs Info
  • Use the triage output as guidance, not an absolute command—reassess with new evidence
  • Include repro steps, logs, environment, and sample data to move an issue from Needs Info to Community Ready

Example use cases

  • Recording stops unexpectedly — maps to Capture, likely high severity and trust impact → P0, Maintainer Now
  • Transcription accuracy drops for a specific language — maps to Understand, moderate severity and frequency → P2/P1, Community Ready if scoped
  • Memory sync delays reported by multiple users — maps to Memory, trust impact and frequency weigh heavy → P1, Maintainer Now or High Priority
  • UI wording inconsistency on settings screen — maps to UX/Polish, low severity and low cost → P3, Park or Community Ready
  • Docs missing setup steps for pairing — maps to Docs/Tooling, low severity but high leverage for contributors → P3 or P2, Community Ready

FAQ

How is the priority score calculated?

Priority Score = (Core Layer Weight × Failure Severity) + Trust Impact + Frequency + Maintenance Leverage - Cost & Risk. Weights depend on the mapped Omi layer.

What if an issue touches multiple layers?

Identify the primary layer that most directly affects user outcomes. Note secondary layers in the rationale and adjust maintenance leverage or cost if cross-layer work increases complexity.