---
name: Get Unpublished Changes
slug: get-unpublished-changes
category: DevOps
description: Get Unpublished Changes compares the current git HEAD with the latest published npm versions and lists all unpublished changes grouped by release layer. Use it when you need to see what has changed since the last release to prepare changelogs or release notes.
github: "https://github.com/code-yeongyu/oh-my-openagent/tree/dev/.agents/skills/get-unpublished-changes"
language: TypeScript
stars: 67782
forks: 5541
install: "npx degit https://github.com/code-yeongyu/oh-my-openagent/tree/dev/.agents/skills/get-unpublished-changes ~/.claude/skills/get-unpublished-changes"
installs_to: ~/.claude/skills/get-unpublished-changes
source_path: .agents/skills/get-unpublished-changes/SKILL.md
collection_size: 21
category_size: 798
collection_url: "https://dirskills.com/collections/code-yeongyu/oh-my-openagent"
added: 2026-08-13T07:36:29.359Z
last_synced: 2026-08-13T07:36:29.359Z
canonical_url: "https://dirskills.com/skills/get-unpublished-changes"
---

# Get Unpublished Changes

Get Unpublished Changes compares the current git HEAD with the latest published npm versions and lists all unpublished changes grouped by release layer. Use it when you need to see what has changed since the last release to prepare changelogs or release notes.

**Install:**

```bash
npx degit https://github.com/code-yeongyu/oh-my-openagent/tree/dev/.agents/skills/get-unpublished-changes ~/.claude/skills/get-unpublished-changes
```

## README

IMMEDIATELY output the analysis. NO questions. NO preamble.

## CRITICAL: DO NOT just copy commit messages!

For each commit, you MUST:
1. Read the actual diff to understand WHAT CHANGED
2. Describe the REAL change in plain language
3. Explain WHY it matters (if not obvious)

## Release Layers

Analyze every change against these exact layers:

| Layer | Includes | Version question |
|---|---|---|
| `omo pure components` | `packages/*-core`, MCP packages, `packages/shared-skills`, reusable scripts | Do shared components need a patch/minor/major release note even if adapters only consume them internally? |
| `omo opencode` | Root `oh-my-opencode` / `oh-my-openagent`, `src/`, `.opencode/`, `.agents/`, CLI, config, hooks, tools, docs | What semver bump should the OpenCode/OpenAgent npm packages use? |
| `omo codex` | `packages/omo-codex`, `lazycodex-ai`, Codex plugin metadata/hooks, bundled MCP runtimes, `code-yeongyu/lazycodex` marketplace payload | Does LazyCodex need the same bump, a Codex-only note, or a marketplace release? |

Exclude commits and paths matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` from user-facing notes and version recommendations. Record them only in a separate internal-adapter exclusion ledger.

## Steps:
1. Detect latest published versions for `oh-my-opencode`, `oh-my-openagent`, and `lazycodex-ai`.
2. Run `git diff v{published-version}..HEAD` to see actual changes.
3. Classify every file into one or more release layers before grouping by feat/fix/refactor/docs.
4. Describe the REAL changes and why each layer cares.
5. Note breaking changes by affected layer.
6. Recommend a layer-specific version bump and one overall workflow bump.

## Output Format:
- feat: "Added X that does Y" (not just "add X feature")
- fix: "Fixed bug where X happened, now Y" (not just "fix X bug")
- refactor: "Changed X from A to B, now supports C" (not just "rename X")

Include:
- `Layered Impact Matrix`: rows for `omo pure components`, `omo opencode`, `omo codex`
- `Layer-specific Version Recommendation`: patch/minor/major per layer plus one overall release bump