Git Unpublished Changes Audit
Compare HEAD with the latest published releases (npm, PyPI, Crates.io, or Git release tags)
and produce an auditable inventory of all unpublished changes structured by architectural layer.
IMMEDIATELY output the analysis. NO unnecessary conversational preamble.
CRITICAL: DO NOT just copy commit messages!
For each commit or diff range, you MUST:
- Read the actual code diff to understand WHAT CHANGED.
- Describe the REAL change in plain, precise technical language.
- Explain WHY it matters to consumers, operators, or upstream systems.
Universal Monorepo / Package Layers
Analyze every change against the repository's architectural layers:
| Layer |
Typical Contents |
Versioning Questions |
| Core / Shared Components |
packages/*-core, libraries, schemas, shared utils |
Do shared libraries require a patch/minor/major bump? Are downstream consumers broken? |
| Application / CLI / Agent |
src/, root apps, CLI commands, agent configs, skills |
What user-facing features or bug fixes are introduced? What semver bump applies? |
| Adapters / Extensions |
Platform plugins, MCP runtimes, integrations |
Do platform adapters need independent versioning or coordinated release? |
Note: Exclude private internal test fixtures, temporary scratch directories, or local-only files from consumer-facing release notes.
Steps to Execute:
- Detect latest published versions/tags:
- For npm: query
npm view <pkg> version
- For Python: check PyPI or
pyproject.toml
- For Rust: check
Cargo.toml
- Universal Git fallback:
git describe --tags --abbrev=0
- Inspect raw changes:
- Run
git diff <published-tag-or-version>..HEAD to inspect all unreleased diffs.
- Run
git log <published-tag-or-version>..HEAD --oneline for commit history.
- Classify changed files:
- Group files into Core, Application, or Adapter layers.
- Categorize each change:
feat, fix, refactor, perf, docs, security.
- Evaluate breaking changes:
- Identify schema changes, signature alterations, or removed flags.
- Recommend SemVer bump:
- Determine whether changes require
PATCH (backwards-compatible fixes), MINOR (new backwards-compatible features), or MAJOR (breaking changes).
Output Format
Change Summaries
feat: "Added [capability] that [action]" (explain impact, not just commit title)fix: "Fixed [issue] where [behavior] occurred, now [resolution]"refactor: "Refactored [component] to [benefit]"
Layered Impact Matrix
| Layer |
Changed Files |
Breaking? |
Recommended Bump |
| Core / Shared |
... |
Yes / No |
patch / minor / major |
| Application / CLI |
... |
Yes / No |
patch / minor / major |
| Adapters / Integrations |
... |
Yes / No |
patch / minor / major |
Overall Release Recommendation
- Current Published:
vX.Y.Z
- Recommended Next:
vX.Y.Z (with explicit technical justification)
1---2name: git-unpublished-changes-audit3description: Audits unpublished commits and tags against release registries across monorepos.4---56# Git Unpublished Changes Audit78Compare HEAD with the latest published releases (npm, PyPI, Crates.io, or Git release tags)9and produce an auditable inventory of all unpublished changes structured by architectural layer.1011IMMEDIATELY output the analysis. NO unnecessary conversational preamble.1213## CRITICAL: DO NOT just copy commit messages!1415For each commit or diff range, you MUST:161. Read the actual code diff to understand WHAT CHANGED.172. Describe the REAL change in plain, precise technical language.183. Explain WHY it matters to consumers, operators, or upstream systems.1920## Universal Monorepo / Package Layers2122Analyze every change against the repository's architectural layers:2324| Layer | Typical Contents | Versioning Questions |25|---|---|---|26| **Core / Shared Components** | `packages/*-core`, libraries, schemas, shared utils | Do shared libraries require a patch/minor/major bump? Are downstream consumers broken? |27| **Application / CLI / Agent** | `src/`, root apps, CLI commands, agent configs, skills | What user-facing features or bug fixes are introduced? What semver bump applies? |28| **Adapters / Extensions** | Platform plugins, MCP runtimes, integrations | Do platform adapters need independent versioning or coordinated release? |2930*Note: Exclude private internal test fixtures, temporary scratch directories, or local-only files from consumer-facing release notes.*3132## Steps to Execute:33341. **Detect latest published versions/tags**:35 - For npm: query `npm view <pkg> version`36 - For Python: check PyPI or `pyproject.toml`37 - For Rust: check `Cargo.toml`38 - Universal Git fallback: `git describe --tags --abbrev=0`392. **Inspect raw changes**:40 - Run `git diff <published-tag-or-version>..HEAD` to inspect all unreleased diffs.41 - Run `git log <published-tag-or-version>..HEAD --oneline` for commit history.423. **Classify changed files**:43 - Group files into Core, Application, or Adapter layers.44 - Categorize each change: `feat`, `fix`, `refactor`, `perf`, `docs`, `security`.454. **Evaluate breaking changes**:46 - Identify schema changes, signature alterations, or removed flags.475. **Recommend SemVer bump**:48 - Determine whether changes require `PATCH` (backwards-compatible fixes), `MINOR` (new backwards-compatible features), or `MAJOR` (breaking changes).4950## Output Format5152### Change Summaries53- `feat`: "Added [capability] that [action]" (explain impact, not just commit title)54- `fix`: "Fixed [issue] where [behavior] occurred, now [resolution]"55- `refactor`: "Refactored [component] to [benefit]"5657### Layered Impact Matrix58| Layer | Changed Files | Breaking? | Recommended Bump |59|---|---|---|---|60| Core / Shared | ... | Yes / No | patch / minor / major |61| Application / CLI | ... | Yes / No | patch / minor / major |62| Adapters / Integrations | ... | Yes / No | patch / minor / major |6364### Overall Release Recommendation65- **Current Published**: `vX.Y.Z`66- **Recommended Next**: `vX.Y.Z` (with explicit technical justification)
robertoatila