Skip to content
Back to skills

R Util Chg Dedup

ASecurity

Deduplicate changelog entries for the current version. Scans CHANGELOG

  • 20 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 7, 2026
developmentgorefactoringgit

Security analysis

A100/100

Scanned November 7, 2026

npx -y skills add rfxn/rdf --skill r-util-chg-dedup --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of R Util Chg Dedup?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for R Util Chg Dedup
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/rfxn-r-util-chg-dedup/badge)](https://www.skillsdirectory.com/skills/rfxn-r-util-chg-dedup)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: r-util-chg-dedup
description: >
  Deduplicate changelog entries for the current version. Scans CHANGELOG
---

Deduplicate changelog entries for the current version. Scans CHANGELOG
and CHANGELOG.RELEASE for duplicates, overlapping entries, tracking
artifacts, fluff, and section proliferation. Report mode by default —
only modify files when explicitly told to fix.

## Arguments
- `$ARGUMENTS` — optional: `--full` for cross-reference against git log

## Setup

Read `.rdf/governance/index.md` to identify:
- Changelog format and section structure (from governance/conventions.md)
- Changelog file locations
- Version naming convention

## Scoping

Scope to the current branch version ONLY:
1. Get branch name: `git branch --show-current`
2. Find version header line number in CHANGELOG
3. Find NEXT version header (or EOF)
4. Read only that range with offset/limit
5. Read CHANGELOG.RELEASE (typically small — full read is fine)

## Detection Rules

### 1. Tracking artifact removal (MANDATORY)
Strip session artifacts from all entries:
- Finding references: `(F-NNN)`, `(C-NNN)`, `(R-NNN)`
- Phase markers: `Phase N`, `[R-NNN]`
- Pattern: `\([A-Z]-[0-9]+\)` or `\[[A-Z]-[0-9]+\]`

Strip silently — note total count in summary.

### 2. Fluff entries (DROP or MERGE)
**Drop entirely**: copyright header updates, changelog housekeeping,
gitignore changes, comment-only changes, whitespace fixes, formatting.

**Merge into one line**: multiple README updates, multiple man page
corrections, multiple test infrastructure changes.

### 3. Duplicates
- Exact duplicates: identical lines ignoring whitespace
- Near-duplicates: same file + same function = likely duplicate
- Tag mismatches: same change with different tags
- Contradictions: "added X" and "removed X"

### 4. Overlapping entry collapse
Aggressively merge entries describing different facets of the same change:
- Feature + config + docs -> one `[New]` entry
- Sequential fixes for same bug -> keep only the final fix
- Refactor + cleanup of same function -> one `[Change]` entry
- Multiple test additions for same feature -> one entry with count

### 5. Internal-only entries (DROP or FOLD)
**Drop**: internal variable changes, code comments, dead code removal,
test rewrites, internal refactoring names.
**Fold into parent**: entries that describe a sub-step of a larger change.

The sysadmin test: would a user upgrading this software understand and
care about this entry?

### 6. Verbose entries
Flag entries longer than ~100 characters that repeat file paths, restate
the tag meaning, or include implementation details.

### 7. Section proliferation (MANDATORY)
Maximum 3-5 sections. Flag topical micro-sections and propose
consolidation into standard sections (New Features, Bug Fixes, Changes).

### 8. First-release consolidation
For first release of a major version: fold iterative development entries
into single feature entries. `[Change]` tags refining a `[New]` feature
should merge into the parent.

### 9. Cross-reference (OPT-IN — --full only)
When enabled: identify orphaned entries (no matching commit) and missing
entries (commit with no changelog entry). Skip by default.

## Target Entry Counts

| Release size | Target | Max |
|---|---|---|
| Small (< 50 commits) | 10-20 | 30 |
| Medium (50-150 commits) | 20-40 | 60 |
| Large (150-300+ commits) | 35-70 | 90 |

## Process

1. Scope to current branch version
2. Check section structure (rule 7)
3. Strip tracking artifacts (rule 1)
4. Parse every entry
5. Identify internal-only entries (rule 5)
6. Identify fluff (rule 2)
7. Group remaining entries by topic
8. Apply duplicate/overlap/verbose rules (3, 4, 6)
9. If first release: apply consolidation (rule 8)
10. If `--full`: cross-reference against git log (rule 9)
11. Check entry count against target table
12. Compare CHANGELOG vs CHANGELOG.RELEASE for drift

## Output

    ## CHANGELOG Dedup: v<version>

    Entries scanned: <N>
    Tracking artifacts stripped: <N>
    Section structure: <ok / N sections — proposed restructure>
    Entry count: <N> (target: <T> for <size> release)

    ### Section proliferation (if applicable)
    ### Internal-only entries (<N>)
    ### Fluff entries (<N>)
    ### Duplicates (<N>)
    ### Merge candidates (<N> groups)
    ### Verbose entries (<N>)
    ### Tag mismatches (<N>)
    ### Orphaned entries (<N>) — --full only
    ### Missing entries (<N>) — --full only

If no issues: "CHANGELOG v<version> is clean — <N> entries, no issues."

## Rules
- Only examine the current branch version block — ignore history
- Do NOT modify files unless user explicitly says to fix/apply
- Strip tracking artifacts silently — they are never user-facing
- Proposed merges must preserve all meaningful factual content
- Changelogs should be readable by someone with no knowledge of the
  development process

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.