pre-publish-review

# Pre-Publish Review — 16-Agent Release Gate

Three-agent-layer review before publishing to npm. Every layer covers a different angle, and every result is mapped onto the release layers below.

| Layer | Agents | Type | What They Check |
|-------|--------|------|-----------------|
| Per-Change Deep Dive | up to 10 | ultrabrain | Each logical change group individually — correctness, edge cases, pattern adherence |
| Holistic Review | 5 | review-work | Goal compliance, QA execution, code quality, security, context mining across full changeset |
| Release Synthesis | 1 | oracle | Overall release readiness, version bump, breaking changes, deployment risk |

## Release Layer Taxonomy

Every phase classifies evidence and risk across:

| Release Layer | Scope | Required version decision |
|---|---|---|
| `omo pure components` | Core packages, MCP packages, shared skills, reusable scripts, platform binary inputs | Patch/minor/major impact for shared logic consumed by adapters. |
| `omo opencode` | Root `oh-my-opencode` / `oh-my-openagent`, `src/`, OpenCode plugin hooks/tools/CLI/config/docs, `.opencode/`, `.agents/` | Semver bump for the OpenCode/OpenAgent npm release. |
| `omo codex` | `packages/omo-codex`, `lazycodex-ai`, Codex plugin metadata/hooks, bundled MCP runtimes, `code-yeongyu/lazycodex` marketplace payload | Codex adapter bump, LazyCodex npm publish risk, and marketplace/GitHub release need. |

---

## Phase 0: Detect Unpublished Changes

Run `/get-unpublished-changes` FIRST. This is the single source of truth for what changed and must include `omo pure components`, `omo opencode`, and `omo codex` layer-specific version recommendations.

```
skill(name="get-unpublished-changes")
```

This command automatically:
- Detects published npm version vs local version
- Lists all commits since last release
- Reads actual diffs (not just commit messages) to describe REAL changes
- Groups changes by type (feat/fix/refactor/docs) with scope
- Identifies breaking changes
- Recommends a layer-specific version bump plus one overall workflow bump

**Save the full output** — it feeds directly into Phase 1 grouping and all agent prompts.

Then capture raw data needed by agent prompts:

```bash
# Extract versions (already in /get-unpublished-changes output)
PUBLISHED=$(npm view oh-my-opencode version 2>/dev/null || echo "not published")
LOCAL=$(node -p "require('./package.json').version" 2>/dev/null || echo "unknown")

# Raw data for agents (diffs, file lists)
COMMITS=$(git log "v${PUBLISHED}"..HEAD --oneline 2>/dev/null || echo "no commits")
COMMIT_COUNT=$(echo "$COMMITS" | wc -l | tr -d ' ')
DIFF_STAT=$(git diff "v${PUBLISHED}"..HEAD --stat 2>/dev/null || echo "no diff")
CHANGED_FILES=$(git diff --name-only "v${PUBLISHED}"..HEAD 2>/dev/null || echo "none")
FILE_COUNT=$(echo "$CHANGED_FILES" | wc -l | tr -d ' ')
```

If `PUBLISHED` is "not published", this is a first release — use the full git history instead.
---

## Phase 1: Parse Changes into Groups

Use the `/get-unpublished-changes` output as the starting point — it already groups by scope and type.

**Grouping strategy:**
1. Start from the `/get-unpublished-changes` analysis which already categorizes by feat/fix/refactor/docs with scope
2. Further split by **module/area** — changes touching the same module or feature area belong together
3. Target **up to 10 groups**. If fewer than 10 commits, each commit is its own group. If more than 10 logical areas, merge the smallest groups.
4. For each group, extract:
   - **Group name**: Short descriptive label (e.g., "agent-model-resolution", "hook-system-refactor")
   - **Release layer(s)**: `omo pure components`, `omo opencode`, `omo codex`
   - **Commits**: List of commit hashes and messages
   - **Files**: Changed files in this group
   - **Diff**: The relevant portion of the full diff (`git diff v${PUBLISHED}..HEAD -- {group files}`)

---

## Phase 2: Spawn All Agents

Launch ALL agents in a single turn. Every agent uses `run_in_background=true`. No sequential launches.

### Layer 1: Ultrabrain Per-Change Analysis (up to 10)

For each change group, spawn one ultrabrain agent. Each gets only its portion of the diff — not the full changeset.

```
task(
  category="ultrabrain",
  run_in_background=true,
  load_skills=[],
  description="Deep analysis: {GROUP_NAME}",
  prompt="""
<review_type>PER-CHANGE DEEP ANALYSIS</review_type>
<change_group>{GROUP_NAME}</change_group>

<project>oh-my-opencode (npm package)</project>
<published_version>{PUBLISHED}</published_version>
<target_version>{LOCAL}</target_version>

<commits>
{GROUP_COMMITS — hash and message for each commit in this group}
</commits>

<changed_files>
{GROUP_FILES — files changed in this group}
</changed_files>

<diff>
{GROUP_DIFF — only the diff for this group's files}
</diff>

<file_contents>
{Read and include full content of each changed file in this group}
</file_contents>

You are reviewing a specific subset of changes heading into an npm release. Focus exclusively on THIS change group. Other groups are reviewed by parallel agents.

ANALYSIS CHECKLIST:

1. **Intent Clarity**: What is this change trying to do? Is the intent clear from the code and commit messages? If you have to guess, that's a finding.

2. **Correctness**: Trace through the logic for 3+ scenarios. Does the code actually do what it claims? Off-by-one errors, null handling, async edge cases, resource cleanup.

3. **Breaking Changes**: Does this change alter any public API, config format, CLI behavior, or hook contract? If yes, is it backward compatible? Would existing users be surprised?

4. **Pattern Adherence**: Does the new code follow the established patterns visible in the existing file contents? New patterns where old ones exist = finding.

5. **Edge Cases**: What inputs or conditions would break this? Empty arrays, undefined values, concurrent calls, very large inputs, missing config fields.

6. **Error Handling**: Are errors properly caught and propagated? No empty