label-sync
Skill76 starsChanged 9 days agoMITView on GitHub
Deterministically reconcile size/area/type labels on issues and PRs against a declared taxonomy — add-only, never overriding a human's label. Band A, no LLM. The mechanical labeling floor beneath the judgment-gated pr_labeling.
In this repository13 other files it gives its agents.
- action-watchdogSkill
- coding-principlesSkill
- contributor-trustSkill
- issue-autocloseSkill
- issue-captureSkill
- issue-close-proposalSkill
- issue-triageSkill
- pr-deep-reviewSkill
- project-system-setupSkill
- pr-triageSkill
- release-announceSkill
- release-pipelineSkill
- triage-scoreboardSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
Select what to process (incremental): Only issues/PRs new or changed since the last-seen marker — not the whole back catalog.
- Very specific: line 65
Every applied label is in the declared labels: allowlist.
- Distinctive: line 66
Add-only held: no label was removed, reassigned, or applied over a human's label.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
label-sync
When to load: applying the mechanical, reversible labels (size/area/type) that don't need
judgment. Runs the label-sync step referenced by issue-triage and the
Level-3 rung of the adoption ladder. Band A —
deterministic, add-only, no LLM. Steward role. Designed as a
scheduled job (label-sync, agent: false).
Precondition: a declared taxonomy exists. This skill reconciles labels toward the
labels:block inconfig.yaml; it never invents label names. If no taxonomy is declared, there is nothing to sync — stop.
Config: read the taxonomy and
add_onlyflag fromconfig.yaml(labels:) and the repos fromrepositories:. The allowlist — the only labels this skill may apply — is exactly the label values named underlabels.{size,area,type}.map/buckets. Thescheduled_jobsentry that runs this skill is namedlabel-sync. It isagent: false: a plain deterministic script with no model in the loop. Judgment labels (priority, needs-discussion, wontfix) are not this skill — they stay Band B underautonomy.pr_labeling.
Steps
- Read
config.yaml. Loadrepositories:, thelabels:taxonomy (the allowlist), andadd_only. Iflabels:is empty → silent no-op. - Select what to process (incremental). Only issues/PRs new or changed since the last-seen marker — not the whole back catalog. The one-time backfill is a manual initial run; the recurring job is cheap. Mark the marker forward only after a clean pass.
- Compute the desired labels deterministically per item — from structured signals only:
- size (PRs only): diff-line count → the matching
labels.size.bucketsrung (S/M/L/XL). - area: PRs from changed-path globs (
labels.area.map); issues from a structured issue-template field (a declared form dropdown), never from parsing the free-text body. - type: PRs from the title conventional-commit prefix (
feat/fix/docs/…); issues from a structured template "kind" field, falling back to a title prefix only if the project uses one. - No deterministic signal → apply nothing. A missing label beats a guessed one.
- size (PRs only): diff-line count → the matching
- Reconcile add-only. For each desired label: apply it only if absent. Never remove a label, never reassign, never override a human-applied label. A label already present (by anyone) is left untouched. Same input → same result (idempotent); a second run changes nothing.
- Ledger the applied labels. Append each label actually applied — item, label, source signal, timestamp — to the append-only action ledger that the watchdog re-verifies. The ledger is the list of what to check, never the proof it was right.
- Silent-on-no-op; loud on error. Nothing applied → no output. A non-zero exit or timeout alarms (it never fails silently); silent-on-no-op is for success with nothing to do, never for errors.
Pitfalls
- Overriding a human. The one invariant that makes this safe to run unattended: add-only, and a human's label always wins. Check presence before applying; never "correct" a label a person set.
- Guessing from free text. Labels come only from structured signals (diff, paths, template
fields, title prefix). An issue/PR body is untrusted, attacker-controllable, and unreliable —
never parse it to decide a label. (This is also why the job is
agent: false: no model, no injection surface.) - Labeling outside the allowlist. The only labels this skill may apply are those declared in
labels:. A label not in the taxonomy is out of scope — surface it for a human to add to the taxonomy, don't apply it. - Full-rescan every tick. Reconcile only what changed since the marker; re-scanning the whole tracker each run is slow and pointless once the backfill is done.
- Judgment labels. Priority, needs-discussion, wontfix, and the like are Band-B decisions under
autonomy.pr_labeling— not this deterministic floor. Don't let scope creep pull them in.
Verification
- Every applied label is in the declared
labels:allowlist. - Add-only held: no label was removed, reassigned, or applied over a human's label.
- Re-running immediately is a no-op (idempotent) — the second pass applies nothing.
- On no new/changed items, the job is silent; on error, it alarms.
action-watchdoghas a corresponding check for autonomous labels.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

