/Catalogue/Prompt/code-yeongyu/code-yeongyu-oh-my-openagent-get-unpublished-changes

Origin: github

get-unpublished-changes

Compare HEAD with the latest published npm versions and list all unpublished changes by release layer. Triggers: unpublished changes, changelog, what changed, whats new.

by code-yeongyu · updated 14h ago · imported from GitHub

Installs0+0/7d
Security score73/100
Retention 14d0%
GitHub stars69.4K

Skill logic

Execution graph
User message
Prompt rewrites behaviour
Response

SKILL.md

View on GitHub ↗

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:

LayerIncludesVersion question
omo pure componentspackages/*-core, MCP packages, packages/shared-skills, reusable scriptsDo shared components need a patch/minor/major release note even if adapters only consume them internally?
omo opencodeRoot oh-my-opencode / oh-my-openagent, src/, .opencode/, .agents/, CLI, config, hooks, tools, docsWhat semver bump should the OpenCode/OpenAgent npm packages use?
omo codexpackages/omo-codex, lazycodex-ai, Codex plugin metadata/hooks, bundled MCP runtimes, code-yeongyu/lazycodex marketplace payloadDoes 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

Discussion

No comments yet — start the thread.

Sign in to join the discussion.

/More from code-yeongyu/oh-my-openagent

code-yeongyu· 14h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 14h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 14h agoSandbox
pre-publish-review

Prompts · TypeScript · v0.1.0

Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 14h agoSandbox
codex-qa

Prompts · TypeScript · v0.1.0

QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.

#ai#ai-agents#anthropic

0 69.4K