Yak ↔ external tracker sync

This skill performs a single-yak, bidirectional, plan-then-apply sync between a yak and its external issue (Jira, Linear, GitHub Issues, etc.). It is intentionally manual. Automating bidirectional sync across arbitrary trackers is a fool's errand — the goal here is to make it easy to keep one yak in sync when you want to, not to run a daemon.

Hard rules

• Never touch the external tracker without confirming with the user first. Every upstream write (field update, comment post, attachment upload, issue creation) is preceded by an explicit user-approved resolution in the sidecar.
• When in doubt, do not sync. A field, comment, or label whose mapping isn't clearly 1:1 should be left alone rather than guessed. False sync is worse than no sync — data loss is hard to reverse, missed drift is easy.
• Never silently drop a local note or a remote comment. If in doubt whether two items are the same, keep both — conservative duplication beats data loss.
• Never annotate upstream content with yak-specific markers. The user may be working in a shared tracker where yaks are a private tool. Comments ferried yak→external post as plain content, no [yaks:…] prefix. Only the local yak body may carry provenance annotations.
• Never create an upstream issue automatically. If a yak has no source:, ask the user whether to create one and where (project + issue type for Jira, team for Linear, repo for GitHub, etc.) before doing anything.
• You must have the necessary MCP tools available. If the yak's source points at a tracker whose MCP is not connected, stop and tell the user.

The plan / apply / discard model

A sync is split into two phases separated by a durable artifact, the sidecar at .yaks/.sync-pending/<yak-id>.yaml:

• Plan phase — fetch upstream, compute the per-field diff, write a sidecar capturing every proposed change as a YAML structure with explicit resolution fields. No mutations. The user can inspect the sidecar (yak sync show <id>), hand-edit it (it's just YAML), or discard it (yak sync clear <id>).
• Apply phase — re-fetch upstream, verify the snapshot stored in the sidecar still matches, then process each item according to its resolution. On full success the sidecar is cleared; on partial failure it stays so the user can re-resolve.