Verify gates one last time and merge an assistant PR (new-assistant or vendor-evolution). Use when the issue is at phase:merge-ready.
Scaffold (new-assistant) or refactor (vendor-evolution), document, test, and open a draft PR. Use when the issue is at phase:approved or phase:implementing and the contributor is starting or resuming work.
Open the right `type:new-assistant` / `type:vendor-evolution` GitHub issue from a free-form intent. Use when the user says they want to support / fix / evolve a vendor and has not yet filed an issue.
Review an open assistant PR against the dual-track checklist (dated documentation first, then code), with per-issue-type addenda for new vendors vs evolution. Use when the issue is at phase:review.
Routes to the correct sub-skill of the assistant family based on the issue's type:* and phase:* labels. Use when the user mentions a vendor onboarding or evolution and is unsure which skill to run.
Tally tester sign-off comments on a phase:testing issue, audit any attached connector logs for sanitization gaps, and draft follow-ups for incomplete confirmations. Use whenever a tester comments.
Help the maintainer triage a phase:proposed assistant issue (new-assistant or vendor-evolution) — duplicate check, scope sanity, kind:* label application, decision draft. Use when reviewing an incoming proposal.
Re-verify a vendor's API behavior against its docs/vendors/<vendor>.md snapshot, bump dates, append a Change log entry, and either open a doc-only PR (no drift impact) or file a type:vendor-evolution issue (drift forces connector changes). Use when API drift is suspected.