Seam triage

Investigate and triage bugs and tasks in a Seam session. Read descriptions, explore the codebase, determine root causes, update tasks with findings, propose priority adjustments, and close duplicates. Keywords: seam, triage, investigate, bug, root cause, diagnose, priority.From its SKILL.md

Install

npx -y skills add tacklines/seam --skill seam-triage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.8 KB, as published. Nobody here has run it

Seam-Triage: Bug/Task Investigation & Triage

You are running Seam-Triage — the investigation skill for reviewing open bugs and tasks in a Seam session. For each item, you investigate the codebase, determine root cause or feasibility, update the task with findings, and propose priority adjustments. Filter: $ARGUMENTS

When to Use

When a Seam session has accumulated bugs that need investigation
When you want to assess the feasibility and scope of open feature requests
When the backlog has untriaged items (no root cause, unclear priority)
After a dogfooding session that generated bug reports

Overview

Verify session + select triage targets
  -> For each target: read description -> investigate -> determine finding
    -> Update task with findings (comment + priority/complexity adjustment)
      -> Close duplicates with cross-references
        -> Report triage summary

Phase 0: Select Targets

0a. Verify Session

Call my_info() to confirm active session.

0b. Load Triage Candidates

Parse $ARGUMENTS for filters:

bugs — list_tasks(task_type: "bug", status: "open")
open — list_tasks(status: "open")
critical — list_tasks(priority: "critical", status: "open")
TASK-N — investigate a specific task
(empty) — list_tasks(task_type: "bug", status: "open") (default: open bugs)

0c. Count and Warn

If more than 12 candidates, warn the user and propose chunking per batch-safety rules. Write intermediate results to memory/scratch/seam-triage-chunk-N.md between chunks.

0d. Display Candidates

## Triage Targets (N)

| # | Ticket | Type | Title | Priority | Filed |
|---|--------|------|-------|----------|-------|

Phase 1: Investigate Each Target

For each task, in priority order:

1a. Read the Task

Call get_task(id: <uuid>) to get the full description and any existing comments.

1b. Investigate

Based on the task type and description:

For bugs:

Identify the affected code area from the description
Read the relevant files
Look for the described symptom in the code
Determine if the bug is: confirmed (code is wrong), cannot-reproduce (code looks correct), or needs-info (not enough detail to investigate)
If confirmed, identify the root cause and estimate fix scope

For feature requests/stories:

Identify what the feature requires
Check what already exists
Estimate scope: small (< 50 lines), medium (50-200), large (200+)
Identify dependencies on other work

For duplicates:

Search for related tasks: list_tasks(search: "<key terms>")
If a duplicate exists, note the original ticket ID

1c. Update the Task

Post findings as a comment:

call add_comment(task_id: <uuid>, content: "## Triage Findings\n\n**Status**: confirmed | cannot-reproduce | needs-info | duplicate\n**Root cause**: <if confirmed>\n**Affected files**: <file paths>\n**Fix scope**: small | medium | large\n**Notes**: <additional context>")

If the investigation suggests a different priority or complexity, update:

call update_task(id: <uuid>, priority: "<new priority>", complexity: "<new complexity>")

1d. Handle Duplicates

If a task is a duplicate:

call add_comment(task_id: <uuid>, content: "Duplicate of TASK-N. Same root cause: <description>.")
call close_task(id: <uuid>)

1e. Handle Needs-Info

If the task lacks enough detail to investigate:

call ask_question(question: "TASK-N (<title>) doesn't have enough detail to investigate. Can you provide: <specific missing info>?", context: "{\"task_id\": \"<ticket-id>\"}")

Phase 2: Triage Summary

After investigating all candidates, produce a summary:

## Triage Summary

### Investigated: N tasks

| Ticket | Verdict | Priority Change | Fix Scope |
|--------|---------|-----------------|-----------|
| TASK-N | confirmed | medium -> high | small |
| TASK-N | duplicate of TASK-M | — | — |
| TASK-N | needs-info | — | — |

### Quick Wins (confirmed + small scope)
- TASK-N: <title> — <1-line root cause>

### Needs Attention (confirmed + large scope)
- TASK-N: <title> — <1-line root cause>

### Closed as Duplicates: N
### Awaiting Info: N

Guidelines

Read before judging. Always read the actual code before marking a bug as confirmed or cannot-reproduce. Don't guess from the description.
Root cause over symptom. A triage comment should explain WHY the bug happens, not just confirm it exists.
File paths are mandatory. Every confirmed finding must reference the affected file(s).
Duplicates save time. Actively look for duplicates — multiple bugs with the same root cause are common after dogfooding sessions.
Priority adjustments are proposals. Update the task, but note in the comment why you changed priority. The human may disagree.
Batch-safety at 12. If triaging more than 12 items, write intermediate results between chunks.