Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

get-unpublished-changes

Estrelas63.369

Forks5.164

Atualizado4 de junho de 2026 às 02:13

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

code-yeongyu

code-yeongyu/oh-my-openagent

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

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

IMMEDIATELY output the analysis. NO questions. NO preamble.

CRITICAL: DO NOT just copy commit messages!

For each commit, you MUST:

Read the actual diff to understand WHAT CHANGED
Describe the REAL change in plain language
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:

Detect latest published versions for oh-my-opencode, oh-my-openagent, and lazycodex-ai.
Run git diff v{published-version}..HEAD to see actual changes.
Classify every file into one or more release layers before grouping by feat/fix/refactor/docs.
Describe the REAL changes and why each layer cares.
Note breaking changes by affected layer.
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

Mais deste repositório

mesmo repositório

teammode

code-yeongyu/oh-my-openagent

Codex-only team orchestration: run a named team of cooperating Codex threads with durable, script-managed state. MUST USE when the user asks Codex to create, run, coordinate, inspect, archive, or delete a team of threads/sessions, or to work on something as a team in parallel. The main session is always the leader; members are defined by a concrete part, ownership area, or perspective - never a vague job role; a bundled cross-platform script writes the .omo/teams state plus an auto-generated member field manual. Use a team when the work is not perfectly isolated but parallelizing helps, or when a task still needs exploration under a clear goal; use plain subagents when scope is perfectly isolated or the goal is ambiguous. Triggers: team mode, teammode, make a team, run as a team, team of agents, coordinate threads, parallel Codex threads, archive the team, delete the team.

2026-06-2363.4k

codex-qa

code-yeongyu/oh-my-openagent

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.

2026-06-2363.4k

opencode-qa

code-yeongyu/oh-my-openagent

QA opencode itself, per case: verify the CLI/terminal (opencode run, db, serve, export), prove a specific plugin hook/action/event fired via the SSE event stream, smoke-test the TUI under tmux, and investigate sessions in opencode's SQLite DB by id, title/name, or message text. Ships tested helper scripts (each with a --self-test) plus per-domain references. Use whenever someone wants to QA, smoke-test, verify, or debug opencode's CLI, HTTP server, plugin hooks/events, or TUI, or to find/inspect opencode sessions in the database. Triggers: opencode qa, qa opencode, test opencode, verify opencode hook, opencode session db, find opencode session by id/name/text, opencode tui test, opencode server health, opencode event stream.

2026-06-2363.4k

ulw-loop

code-yeongyu/oh-my-openagent

Goal-like loop that uses ultrawork mode to decompose work into systematic, evidence-bound steps.

2026-06-2363.4k

start-work

code-yeongyu/oh-my-openagent

Execute a Prometheus work plan in Codex with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan.

2026-06-2363.4k

visual-qa

code-yeongyu/oh-my-openagent

Rigorous visual QA for any UI you built or changed, across BOTH web/page UIs and TUI/terminal UIs. MUST USE after building or changing any UI to verify it visually before declaring it done. Captures objective reference evidence with a bundled diff script (image-diff for screenshots, tui-check for terminal captures), then runs two parallel read-only oracle passes (design-system and functional integrity; visual fidelity and CJK precision) and synthesizes one good/bad verdict. Triggers: visual QA, visual regression, screenshot diff, pixel diff, image comparison, UI looks wrong, design system check, is this really a design system or just an image, alpha channel breakage, responsive check, CJK text, Korean/Japanese/Chinese text clipping or semantic line breaks, baseline drop, glyph drop, TUI alignment, terminal UI, tmux capture, box-drawing border misalignment, wide-character column drift. Use it even when the user does not say visual QA but asks whether a page, component, or terminal layout looks right.

2026-06-2363.4k

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

IMMEDIATELY output the analysis. NO questions. NO preamble.

CRITICAL: DO NOT just copy commit messages!

For each commit, you MUST:

Read the actual diff to understand WHAT CHANGED
Describe the REAL change in plain language
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:

Detect latest published versions for oh-my-opencode, oh-my-openagent, and lazycodex-ai.
Run git diff v{published-version}..HEAD to see actual changes.
Classify every file into one or more release layers before grouping by feat/fix/refactor/docs.
Describe the REAL changes and why each layer cares.
Note breaking changes by affected layer.
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