task-sync

Sync the board with PR reality

Trackers often can't auto-advance a work item when its PR merges, so cards rot in the wrong state. This skill detects that drift from facts, not guesses — every fact comes from a Baron primitive — and offers a batch fix. It works on any provider Baron binds (Azure DevOps, GitHub), because it reads normalized roles and PR state, not vendor columns.

The drift rule (fixed — you apply it, you don't judge it)

For each in-flight item, correlate it to its branch's PR via the core-derived branchName:

• A — merged-but-stuck (the common one): role is in_progress AND its branch has a merged PR → should be in_review. Auto-fixable.

• C — closed with a stale role label (label-keyed providers): the item's role reads done (the provider closed it — a PR merging with Closes #N) but labels still carries another role's label, so boards and label filters keep showing it as in-flight. Auto-fixable: run the task-reconcile recipe. It commands no role — it clears the label the provider's own state contradicts. Prefer it over a transition here: transitioning would work on GitHub and be wrong on a provider where a close does not mean done. Since task-land reconciles after every merge, this class should now only appear for items landed before that, or where the provider had not closed the item yet when the run finished.

• B — in-review-without-a-PR (rare): role is in_review AND its branch has no PR at all → flag for the human; do NOT auto-change (something is off — wrong branch, force-push, manual move).

Steps

1. Detect — one call, no correlating by hand. baron_recipe_run { name: "task-sync-report", inputs: { scope } } — scope: "all" sweeps everyone, empty sweeps the caller's own items. The engine runs the sweep and its context comes back with two lists of item keys:
   • mergedButOpen — class A, auto-fixable
   • reviewWithoutPr — class B, report only
2. Class C is yours to spot. The report cannot express it: recipe conditions compare values, they do not search a list of labels. Read it off baron_issue_read { op: "query", role: "done" } and look for a stale role label. Reading is always allowed; fixing goes through a recipe like everything else.
3. Report + confirm. A compact table (key · current role · finding · fix). Nothing drifted → say so and stop. Batch-confirm the class-A set with AskUserQuestion. Class B is never auto-fixed.
4. Apply — one recipe call per item, so one failure cannot abort the rest:
   • class A → baron_recipe_run { name: "task-move", inputs: { issueId, role: "in_review" } }
   • class C → baron_recipe_run { name: "task-reconcile", inputs: { issueId } }