update-dedupe

# Update Dedupe Use this skill to improve `.agents/skills/dedupe-issue-local/SKILL.md` from real closed-as-duplicate signals. The core skill at `.agents/skills/dedupe-issue/SKILL.md` is the cross-repo contract and is read-only from this loop. This loop is focused exclusively on closed-as-duplicate signals. Other maintainer signals (re-labels, re-opens, follow-up comments) are handled by the separate `update-triage` loop. ## Write surface This self-improvement loop may only write to: - `.agents/skills/dedupe-issue-local/` (and `SKILL.md` inside it) It must NOT touch: - `.agents/skills/dedupe-issue/SKILL.md` (the core contract) - `.agents/skills/triage-issue-local/SKILL.md` (owned by `update-triage`) - any other core skill The self-improvement runner enforces this via a `git diff` check against allowed prefixes before pushing. A violation aborts the run. ## Inputs - Optional repository override if you are not running from the target checkout. - Optional time window override when you need something other than the default seven-day lookback. ## Workflow 1. Verify GitHub CLI auth: ```bash gh auth status ``` 2. Aggregate closed-as-duplicate signals for recently closed issues with the bundled script: ```bash python3 .agents/skills/update-dedupe/scripts/aggregate_dedupe_feedback.py ``` By default this targets the current repo and looks back 7 days. It collects only issues GitHub itself recorded as closed with the *duplicate* close reason (`state_reason == "duplicate"`) and looks up the canonical issue each was closed against via the issue timeline's `marked_as_duplicate` event. Ad-hoc maintainer comments that merely mention another issue are intentionally ignored to avoid false positives. The script writes structured JSON to a temporary file and prints the path. 3. Read the generated JSON and look for repeated clusters: - two or more different reporters filed similar issues that maintainers closed as duplicates of the same canonical thread - an explicit maintainer statement that a class of issue should always be treated as a duplicate of a canonical thread 4. Propose the smallest edit that explains the cluster. Add or update a bullet under the "Known-duplicate clusters" section of `.agents/skills/dedupe-issue-local/SKILL.md` summarizing the canonical thread and the distinguishing signals maintainers use to identify duplicates. 5. Keep the core dedupe contract stable — never edit `dedupe-issue/SKILL.md`, never weaken the 2-candidate minimum, never change the similarity thresholds or the output shape. ## Evidence Rules - Only encode a cluster when at least two independent closed-as-duplicate events point at the same canonical issue, or a maintainer explicitly asks for one. - Skip the PR when there is no repeated signal. - Do not weaken precision-over-recall for dedupe. ## Final Checks - Re-read the updated `dedupe-issue-local` companion skill and confirm any new clusters are explicit. - Keep the companion concise; prefer canonical links and short distinguishing notes over long prose. - Commit any changes on a local branch named `oz-agent/update-dedupe`. Do NOT push the branch; the Python entrypoint will run a write-surface guard and push only when the guard passes. - If the updates warrant a PR, it will be opened from the pushed branch. Tag `@captainsafia` as a reviewer on that PR. - Validate any temporary JSON with `jq` before relying on it.