Hali Triage Skill

Purpose

Transform a noisy issue list or audit findings into a clean, prioritized, actionable queue. Deduplicate aggressively. Recommend which issues to close, merge, defer, relabel, or implement — and in what order. Does not write code.

When to use

• After /audit produces findings that need sequencing
• When the GitHub issue list has grown noisy and needs a cull pass
• At the start of a new workstream to establish priority order
• When multiple issues overlap and you suspect duplicates

When NOT to use

• You need to inspect the codebase first → /audit
• You are ready to implement a specific issue → /execute
• You are reviewing a PR → /validate
• A single issue is already clearly scoped and approved → go directly to /execute

Required pre-read

CLAUDE.md
docs/arch/HALI_PHASE_BLOCKERS.md
docs/arch/HALI_PHASE_SCAFFOLD.md

docs/arch/label-taxonomy.md

If label-taxonomy.md does not exist on disk at the time of the triage run, fall back to the label conventions observed in the repo: feature:, fix:, chore:, docs:, phase:1, phase:2, phase:3, blocked:, wont-fix.

Inputs expected

Example: /triage source=issue-list scope=phase:1

Procedure

Step 1 — Gather raw input

If source includes issue-list:

bash
1gh issue list --repo irvinesunday/Hali --state open --limit 100 \
2  --json number,title,labels,createdAt,updatedAt,body

For each issue, also fetch the current state (verify open/closed):

bash
1gh issue view <NUMBER> --repo irvinesunday/Hali --json state,title,labels

Never assume an issue is open without checking.

If source includes audit-report: read the supplied audit findings before proceeding.

Step 2 — Classify each issue

Apply exactly one classification per issue:

Step 3 — Apply phase and out-of-scope filters

Cross-reference each IMPLEMENT candidate against CLAUDE.md Phase 1 out-of-scope list:

• Comments / replies / threads → CLOSE as out-of-scope
• Likes / reactions → CLOSE as out-of-scope
• Messaging / chat → CLOSE as out-of-scope
• Media uploads → CLOSE as out-of-scope
• Admin portal (before Phase 2 gating) → DEFER
• Microservices → CLOSE as doctrine violation

Flag any issue requesting a locked architectural decision change (H3 → geohash, PostgreSQL → other, etc.) as NEEDS-HUMAN-DECISION.

Step 4 — Deduplicate

For issues with overlapping scope:

1. Identify the canonical issue (oldest with most complete description, or explicitly linked to a spec)
2. Mark duplicates as MERGE-DUPLICATE referencing the canonical number
3. Propose closing the duplicates with a comment pointing to the canonical

Do not preserve issue noise just because it exists.

Step 5 — Sequence the IMPLEMENT queue

Order IMPLEMENT issues by:

1. Phase gate (Phase 1 before Phase 2 before Phase 3)
2. Dependency order (blocking issues before dependent issues)
3. Risk surface (auth/schema changes before feature additions)
4. Value/stability ratio (low-risk high-value first)

Flag any cross-issue dependencies explicitly:

• "Issue #N must land before #M because [reason]"

Step 6 — Detect phase gate violations

Check CLAUDE.md — Phase 2 full UI delivery must not begin until Phase 1 mobile app is in pilot state. Any Phase 2 UI issue in IMPLEMENT status must be flagged with:

PHASE_GATE: Verify Phase 1 mobile pilot state before scheduling.

Step 7 — Draft actions

For each CLOSE recommendation: draft a brief, factual close reason. For each MERGE-DUPLICATE: identify the canonical issue number and draft a close comment. For each RELABEL: specify current labels → proposed labels.

Do not execute any of these actions without explicit approval unless the /triage invocation explicitly includes --apply.

Output requirements

=== HALI TRIAGE REPORT ===

Source: [input type]
Scope: [declared scope]
Issues reviewed: [count]
Date: [ISO 8601]

Classification summary:
- IMPLEMENT:         [count]
- DEFER:             [count]
- CLOSE:             [count]
- MERGE-DUPLICATE:   [count]
- RELABEL:           [count]
- BLOCKED:           [count]
- NEEDS-HUMAN-DECISION: [count]

Triage table:
| # | Title | Current labels | Classification | Reason | Action |
|---|---|---|---|---|---|
| [n] | [title] | [labels] | [classification] | [1-line reason] | [proposed action] |

Proposed IMPLEMENT sequence:
1. #[n] — [title] — [why first]
2. #[n] — [title] — [dependency note]
...

Phase gate flags:
[any PHASE_GATE warnings]

Cross-issue dependencies:
[explicit dependency graph if any]

Doctrine violations detected:
[any CLOSE recommendations due to out-of-scope or stack violations]

NEEDS-HUMAN-DECISION items:
[list with precise question for owner]

Recommended next step:
- Approve sequence and proceed to /execute #[first issue]
- OR review NEEDS-HUMAN-DECISION items first

STOP. Waiting for instruction.

Handoff guidance

• After triage report is reviewed and a sequence is approved → hand first issue to /execute
• NEEDS-HUMAN-DECISION items → stop until owner responds
• CLOSE / MERGE-DUPLICATE actions → execute only after explicit approval

Guardrails / hard rules

• No code changes. Triage does not touch implementation files.
• No silent issue closes. All CLOSE and MERGE-DUPLICATE actions require explicit approval before execution (unless --apply flag is set by the invoker).
• No invented priorities. Sequence recommendations must be based on phase gates, dependencies, or explicit doctrine — not arbitrary judgment.
• Deduplicate aggressively. Duplicate issues waste sprint capacity. Merge them.
• Never preserve out-of-scope noise. Issues requesting features on the Phase 1 out-of-scope list should be closed, not deferred indefinitely.
• Respect NEEDS-HUMAN-DECISION. Do not resolve architectural decisions autonomously.
• Stop at ~80% context window pressure. Output STOPPED_CONTEXT_LIMIT.

Example invocations

/triage
/triage source=issue-list scope=phase:1
/triage source=audit-report
/triage source=both scope=backend
/triage source=issue-list scope=all --apply