- Home
- Skills
- Basedhardware
- Omi
- Issue Triage
issue-triage_skill
7.6k
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill basedhardware/omi --skill issue-triage- SKILL.md3.8 KB
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
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.