phase: Skill for Claude Code

Bug Triage System — Operator Reference

Quick Commands

Working directory — run everything from the repo root (/Users/matt/dev/forge.rs), NOT from this skill directory. The triage script lives at ./scripts/sync-bug-reports.ts and every path it reads/writes (triage/…, client/public/card-data.json) is resolved relative to the current working directory. Running from .claude/skills/bug-triage/ fails with Module not found "scripts/sync-bug-reports.ts".

# Full pipeline (fetch new Discord messages → extract → triage → render)
bun scripts/sync-bug-reports.ts fetch
bun scripts/sync-bug-reports.ts extract
bun scripts/sync-bug-reports.ts triage     # also emits triage/triage-delta.jsonl
bun scripts/sync-bug-reports.ts render

# Full-drain queue — REQUIRED unless the user explicitly asks for latest-delta-only.
# `pending` is the durable unpublished backlog; it is not a diagnostic optional extra.
bun scripts/sync-bug-reports.ts pending --limit=500

# Review the delta as the authoritative latest-fetch slice. Never infer
# latest work from the full triage-items.jsonl; this review is in addition to
# the default `pending` backlog drain.
bun scripts/sync-bug-reports.ts delta      # re-emit delta without re-classifying

# CRITICAL — the script does NOT dedup against GitHub and does NOT pre-judge
# duplicates (only `create_issue` / `skip` / `needs_human_review` exist). YOU are
# the arbiter: for each non-skip delta item, decide whether it is a new bug, a
# duplicate of an existing issue, or already-known, then act on it. `publish`
# only files the threads you pass via `--thread`; every other non-skip delta item
# (`needs_human_review`, or a `create_issue` thread you did not publish) must
# still be resolved inline — see *Delta Completion Invariant* below.

# Publish: for each --thread, CREATE a new GH issue from the triage item,
# include machine-readable Discord thread/message ids in the issue body, AND
# react 👀 + post a tracking link inside the originating Discord thread.
# IMPORTANT: `publish` ALWAYS creates a NEW issue (resolveIssue(..., "created"))
# — it has NO reconcile / write-back-only mode, despite older doc claims. The
# ONLY dedup gate is `published_threads` in triage/sync-state.json: a thread
# already recorded there is skipped entirely (no issue, no write-back). So use
# `publish` ONLY for threads that have NO GH issue yet. If an issue already
# exists (incl. one you filed by hand), do NOT run `publish` — it would create
# a duplicate. Use the manual write-back procedure below instead.
bun scripts/sync-bug-reports.ts publish --thread=<id>[,<id>...] --dry-run   # preview without side effects
bun scripts/sync-bug-reports.ts publish --thread=<id>[,<id>...]             # create GH issue + Discord write-back
# If a previous publish created the GH issue but Discord write-back failed,
# rerun the same publish command. It repairs the missing reaction/reply from
# published_threads instead of creating a duplicate issue.

# Check a specific card's parser status
jq '.["card name"]' client/public/card-data.json
jq '.["card name"] | {abilities: [.abilities[]? | select(.effect.type == "Unimplemented")], triggers: [.triggers[]? | select(.mode == "Unknown")]}' client/public/card-data.json

# Regenerate card data (after parser changes)
./scripts/gen-card-data.sh

# Single card debug
cargo run --bin oracle-gen -- data --filter "card name"

# Active cluster trackers (open thematic workstreams) — see Cluster Tracking with Sub-Issues below
gh issue list --repo phase-rs/phase --label "collector" --state open

# View a tracker and its sub-issues
gh issue view <N> --repo phase-rs/phase --json subIssues,title,body

# Browse closed trackers (retrospective archive)
gh issue list --repo phase-rs/phase --label "collector" --state closed --limit 50 --json number,title,closedAt