docs(skills): github-webhook-events playbook (prose layer for SAM-5)

[spashii]

What this changes

• Sam acquires a new skill src/skills/github-webhook-events/ (catalog skill.md + 6 per-event sub-pages) that defines what each GitHub webhook event means and what Sam should do in response — grounded in Google's eng-practices (review handling) + async-team best practices
• Sam learns to name the action when acking webhook events: "PR #588 CI failed — looking now", not "got webhook" — the UX rules live in the catalog's "Ack message UX" section
• Sam gains a coaching posture: when patterns across multiple webhook-triggered sessions conflict with healthy collaboration (review latency, recurring CI failures, PRs without Linear tickets), Sam surfaces them gently to the team — once, with an offer to help
• PR descriptions now include the Slack-thread permalink in the body (was: only in the linked Linear ticket). The daemon's cross-system chain PR body → Linear → Slack thread resolves from either source — closes the gap where PRs without Linear tickets had no traceable thread

What Sam noticed that led to this

SAM-5 (PR feedback-loop webhooks) was specced as one big Tier 3 ticket. After scoping with the operator on 2026-05-26, the work split cleanly into two layers:

• Prose layer (this PR) — per-event playbook so Sam knows what to do when each webhook fires
• Runtime layer (next PR) — the daemon's /github/webhook aiohttp route with HMAC validation, contributor check, delivery-ID dedupe, event → WebhookEventTrigger translation

This is the prose. The runtime piece is next.

Operator-confirmed direction in this PR:

• Each event gets its own sub-page (folder structure, not one giant prompt template)
• Best practices are Exa-researched (Google eng-practices was the top reference; included citations in each sub-page)
• Sam coaches the team gently when patterns warrant — once, with an offer to help, never as a critique
• Slack metadata in both PR body AND Linear ticket (since not every PR has a Linear ticket)
• Ack messages name the action concretely — operator-stated UX rule: "got webhook doesn't make sense. Name the action like PR558 CI failed."

Tier

1 (skills + capability prose). No runtime changes.

Confidence

High. The skill files are grounded in Google's eng-practices (handling-comments + reviewer/standard + reviewer/comments) plus a survey via Exa of async-collaboration best practices for 2026. Coaching rules are conservative ("once, with an offer to help") to avoid Sam becoming nagging. The dual-metadata rule is the load-bearing piece — without it, the cross-system chain breaks on Linear-less PRs (housekeeping fixes, docs-only PRs).

The receiver code (runtime layer for SAM-5) lands as a separate PR — sam/github-webhook-receiver — when this prose is reviewed.

[linear]

SAM-5