Get Unpublished Changes

Name: Get Unpublished Changes
Author: code-yeongyu

code-yeongyu/oh-my-opencode

115 installs
67.2k repo stars
Updated August 4, 2026
code-yeongyu/oh-my-opencode

Compare HEAD against the latest published npm versions and list all unpublished changes grouped by release layer with per-layer semver recommendations.

About

A skill that diffs HEAD against the latest published npm versions and reports every unpublished change classified into release layers. A developer uses it to draft a changelog and decide per-layer version bumps before publishing.

Reads actual commit diffs rather than copying commit messages
Produces a layered impact matrix with per-layer semver bump recommendations

Get Unpublished Changes by the numbers

115 all-time installs (skills.sh)
Ranked #105 of 248 Release Management skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/code-yeongyu/oh-my-opencode --skill get-unpublished-changes

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/code-yeongyu/oh-my-opencode/get-unpublished-changes.svg)](https://skillselion.com/skills/code-yeongyu/oh-my-opencode/get-unpublished-changes)

Installs	115
repo stars	★ 67.2k
Last updated	August 4, 2026
Repository	code-yeongyu/oh-my-opencode ↗

What it does

Compare HEAD against the latest published npm versions and list all unpublished changes grouped by release layer with per-layer semver recommendations.

Files

SKILL.mdMarkdownGitHub ↗

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?

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