[shiplog/plan] Add work-triage protocol — filter recommendations by agent identity constraints

[devallibus]

Context

When an agent is asked to "hunt for issues to work on," shiplog has no protocol for producing an actionable recommendation list. The current decision tree covers brainstorming, branching, committing, PRing, and retrieval — but not triage. This leads to the agent recommending work it cannot actually perform.

Observed failure: An opus-4.6 agent listed 4 open PRs as "needing review" without checking Authored-by: signatures. All 4 were Authored-by: claude/opus-4.6 (claude-code) — the agent's own identity. The cross-model review protocol (closure-and-review.md §3) explicitly forbids same-model review, but the triage path never invoked that check.

Design Summary

• Shiplog needs a triage protocol that an agent follows when asked "what should I work on?" or "find issues"
• The protocol must check PR authorship signatures against the agent's own identity before recommending review
• Open issues without PRs are always actionable (new work); open PRs are only actionable if cross-model review is possible
• The output should be a prioritized, filtered list where every item is something the current agent can actually do

Approach

Add a triage section to the shiplog decision tree — a lightweight protocol (not a full new phase) that:

1. Scans open issues — groups by: has-PR vs no-PR, labeled vs unlabeled, blocked vs unblocked
2. Scans open PRs — reads Authored-by: / Updated-by: signatures, compares against current agent identity
3. Filters — removes PRs the agent cannot review (same model+version), flags PRs needing cross-model review as "blocked on external reviewer"
4. Prioritizes — applies a simple heuristic: unblocked issues without PRs > PRs reviewable by current agent > blocked items (listed for awareness only)
5. Presents — actionable items first, blocked items separately with reason

This could live as a new entry in the decision tree or as a reference document similar to closure-and-review.md.

Alternatives Considered

• New full phase (Phase 8): Overkill — triage is a read-only scan, not a workflow with artifacts. It doesn't produce commits or PRs.
• Extend Phase 6 (Knowledge Retrieval): Tempting since it's already the "search" phase, but Phase 6 is about looking up past decisions, not prioritizing future work. Mixing the two muddles both.
• Put it only in closure-and-review.md: The authorship check is already there (§3), but the broader triage protocol (scanning issues, prioritizing, presenting) doesn't belong in a closure-focused document.

Tasks

• T1: Design the triage protocol [tier-1]

  • What: Draft the triage protocol as a new reference document (references/triage-protocol.md) or as a new section in SKILL.md. Define the exact steps: scan issues, scan PRs, read signatures, filter, prioritize, present.
  • Files: skills/shiplog/references/triage-protocol.md (create) or skills/shiplog/SKILL.md (modify)
  • Decision budget: Full — decide whether this is a reference doc, a SKILL.md section, or a decision tree extension. Decide the priority heuristic.
  • Accept when: The protocol, when followed, would have prevented the observed failure (agent recommending self-review)
  • Why tier-1: Requires deciding where this lives in shiplog's architecture and what the right abstraction level is

• T2: Add decision tree entry [tier-3]

  • What: Add a new entry to the SKILL.md decision tree that routes "hunt for work" / "find issues" / "what should I work on" requests to the triage protocol
  • Files: skills/shiplog/SKILL.md (modify — decision tree section only)
  • Allowed to change: The decision tree block in SKILL.md
  • Must not change: Existing phase definitions, phase templates, other references
  • Verification: The decision tree has a new entry that points to the triage protocol
  • Return artifact: Diff of the decision tree section
  • Decision budget: none — the routing target is defined by T1
  • Accept when: "What should I work on?" matches a decision tree entry

• T3: Validate against observed failure [tier-2]

  • What: Walk through the triage protocol with the real data from the observed failure (4 PRs authored by opus-4.6, 4 issues without PRs) and verify the protocol produces correct output
  • Files: None modified — this is a validation exercise
  • Accept when: The protocol correctly filters out all 4 PRs as non-reviewable and presents the 4 unworked issues as actionable

Open Questions

• Should the triage protocol also consider issue labels (e.g., shiplog/blocker) for priority sorting?
• Should it check PR review comments for existing cross-model reviews that might make a PR merge-ready?
• Should it integrate with ork:memory to recall which issues the user was recently working on?

---

Authored-by: claude/opus-4.6 (claude-code)
Captain's log entry created by shiplog