From a00bb8b6a714278abd47ab8e1607e7f442ac3b6d Mon Sep 17 00:00:00 2001 From: YeonGyu-Kim Date: Fri, 13 Mar 2026 14:59:46 +0900 Subject: [PATCH] feat(skill): integrate /get-unpublished-changes and /review-work into pre-publish-review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Phase 0 now runs /get-unpublished-changes as single source of truth instead of manual bash commands. Phase 1 uses its output for grouping. Layer 2 explicitly references /review-work skill flow. 🤖 Generated with assistance of [OhMyOpenCode](https://github.com/code-yeongyu/oh-my-opencode) --- .opencode/skills/pre-publish-review/SKILL.md | 407 +++++++++++++++++++ 1 file changed, 407 insertions(+) create mode 100644 .opencode/skills/pre-publish-review/SKILL.md diff --git a/.opencode/skills/pre-publish-review/SKILL.md b/.opencode/skills/pre-publish-review/SKILL.md new file mode 100644 index 000000000..25a84e76f --- /dev/null +++ b/.opencode/skills/pre-publish-review/SKILL.md @@ -0,0 +1,407 @@ +--- +name: pre-publish-review +description: "Nuclear-grade 16-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 (5 agents) for holistic review, and 1 oracle for overall release synthesis. Use before EVERY npm publish. 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'." +--- + +# Pre-Publish Review — 16-Agent Release Gate + +Three-layer review before publishing to npm. Every layer covers a different angle — together they catch what no single reviewer could. + +| 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 | + +--- + +## Phase 0: Detect Unpublished Changes + +Run `/get-unpublished-changes` FIRST. This is the single source of truth for what changed. + +``` +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 version bump (patch/minor/major) + +**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") + - **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=""" +PER-CHANGE DEEP ANALYSIS +{GROUP_NAME} + +oh-my-opencode (npm package) +{PUBLISHED} +{LOCAL} + + +{GROUP_COMMITS — hash and message for each commit in this group} + + + +{GROUP_FILES — files changed in this group} + + + +{GROUP_DIFF — only the diff for this group's files} + + + +{Read and include full content of each changed file in this group} + + +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 catch blocks? No swallowed promises? + +7. **Type Safety**: Any `as any`, `@ts-ignore`, `@ts-expect-error`? Loose typing where strict is possible? + +8. **Test Coverage**: Are the behavioral changes covered by tests? Are the tests meaningful or just coverage padding? + +9. **Side Effects**: Could this change break something in a different module? Check imports and exports — who depends on what changed? + +10. **Release Risk**: On a scale of SAFE / CAUTION / RISKY — how confident are you this change won't cause issues in production? + +OUTPUT FORMAT: +{GROUP_NAME} +PASS or FAIL +SAFE / CAUTION / RISKY +2-3 sentence assessment of this change group +YES or NO +If YES, describe what breaks and for whom + + For each finding: + - [CRITICAL/MAJOR/MINOR] Category: Description + - File: path (line range) + - Evidence: specific code reference + - Suggestion: how to fix + +Issues that MUST be fixed before publish. Empty if PASS. +""") +``` + +### Layer 2: Holistic Review via /review-work (5 agents) + +Spawn a sub-agent that loads the `/review-work` skill. The review-work skill internally launches 5 parallel agents: Oracle (goal verification), unspecified-high (QA execution), Oracle (code quality), Oracle (security), unspecified-high (context mining). All 5 must pass for the review to pass. + +``` +task( + category="unspecified-high", + run_in_background=true, + load_skills=["review-work"], + description="Run /review-work on all unpublished changes", + prompt=""" +Run /review-work on the unpublished changes between v{PUBLISHED} and HEAD. + +GOAL: Review all changes heading into npm publish of oh-my-opencode. These changes span {COMMIT_COUNT} commits across {FILE_COUNT} files. + +CONSTRAINTS: +- This is a plugin published to npm — public API stability matters +- TypeScript strict mode, Bun runtime +- No `as any`, `@ts-ignore`, `@ts-expect-error` +- Factory pattern (createXXX) for tools, hooks, agents +- kebab-case files, barrel exports, no catch-all files + +BACKGROUND: Pre-publish review of oh-my-opencode, an OpenCode plugin with 1268 TypeScript files, 160k LOC. Changes since v{PUBLISHED} are about to be published. + +The diff base is: git diff v{PUBLISHED}..HEAD + +Follow the /review-work skill flow exactly — launch all 5 review agents and collect results. Do NOT skip any of the 5 agents. +""") +``` + +### Layer 3: Oracle Release Synthesis (1 agent) + +The oracle gets the full picture — all commits, full diff stat, and changed file list. It provides the final release readiness assessment. + +``` +task( + subagent_type="oracle", + run_in_background=true, + load_skills=[], + description="Oracle: overall release synthesis and version bump recommendation", + prompt=""" +RELEASE SYNTHESIS — OVERALL ASSESSMENT + +oh-my-opencode (npm package) +{PUBLISHED} +{LOCAL} + + +{ALL COMMITS since published version — hash, message, author, date} + + + +{DIFF_STAT — files changed, insertions, deletions} + + + +{CHANGED_FILES — full list of modified file paths} + + + +{FULL_DIFF — the complete git diff between published version and HEAD} + + + +{Read and include full content of KEY changed files — focus on public API surfaces, config schemas, agent definitions, hook registrations, tool registrations} + + +You are the final gate before an npm publish. 10 ultrabrain agents are reviewing individual changes and 5 review-work agents are doing holistic review. Your job is the bird's-eye view that those focused reviews might miss. + +SYNTHESIS CHECKLIST: + +1. **Release Coherence**: Do these changes tell a coherent story? Or is this a grab-bag of unrelated changes that should be split into multiple releases? + +2. **Version Bump**: Based on semver: + - PATCH: Bug fixes only, no behavior changes + - MINOR: New features, backward-compatible changes + - MAJOR: Breaking changes to public API, config format, or behavior + Recommend the correct bump with specific justification. + +3. **Breaking Changes Audit**: Exhaustively list every change that could break existing users. Check: + - Config schema changes (new required fields, removed fields, renamed fields) + - Agent behavior changes (different prompts, different model routing) + - Hook contract changes (new parameters, removed hooks, renamed hooks) + - Tool interface changes (new required params, different return types) + - CLI changes (new commands, changed flags, different output) + - Skill format changes (SKILL.md schema changes) + +4. **Migration Requirements**: If there are breaking changes, what migration steps do users need? Is there auto-migration in place? + +5. **Dependency Changes**: New dependencies added? Dependencies removed? Version bumps? Any supply chain risk? + +6. **Changelog Draft**: Write a draft changelog entry grouped by: + - feat: New features + - fix: Bug fixes + - refactor: Internal changes (no user impact) + - breaking: Breaking changes with migration instructions + - docs: Documentation changes + +7. **Deployment Risk Assessment**: + - SAFE: Routine changes, well-tested, low risk + - CAUTION: Significant changes but manageable risk + - RISKY: Large surface area changes, insufficient testing, or breaking changes without migration + - BLOCK: Critical issues found, do NOT publish + +8. **Post-Publish Monitoring**: What should be monitored after publish? Error rates, specific features, user feedback channels. + +OUTPUT FORMAT: +SAFE / CAUTION / RISKY / BLOCK +PATCH / MINOR / MAJOR +Why this bump level +Assessment of whether changes belong in one release + + Exhaustive list, or "None" if none. + For each: + - What changed + - Who is affected + - Migration steps + + + Ready-to-use changelog entry + + + Overall risk assessment with specific concerns + + + What to watch after publish + +Issues that MUST be fixed before publish. Empty if SAFE. +""") +``` + +--- + +## Phase 3: Collect Results + +As agents complete (system notifications), collect via `background_output(task_id="...")`. + +Track completion in a table: + +| # | Agent | Type | Status | Verdict | +|---|-------|------|--------|---------| +| 1-10 | Ultrabrain: {group_name} | ultrabrain | pending | — | +| 11 | Review-Work Coordinator | unspecified-high | pending | — | +| 12 | Release Synthesis Oracle | oracle | pending | — | + +Do NOT deliver the final report until ALL agents have completed. + +--- + +## Phase 4: Final Verdict + + + +**BLOCK** if: +- Oracle verdict is BLOCK +- Any ultrabrain found CRITICAL blocking issues +- Review-work failed on any MAIN agent + +**RISKY** if: +- Oracle verdict is RISKY +- Multiple ultrabrains returned CAUTION or FAIL +- Review-work passed but with significant findings + +**CAUTION** if: +- Oracle verdict is CAUTION +- A few ultrabrains flagged minor issues +- Review-work passed cleanly + +**SAFE** if: +- Oracle verdict is SAFE +- All ultrabrains passed +- Review-work passed + + + +Compile the final report: + +```markdown +# Pre-Publish Review — oh-my-opencode + +## Release: v{PUBLISHED} -> v{LOCAL} +**Commits:** {COMMIT_COUNT} | **Files Changed:** {FILE_COUNT} | **Agents:** {AGENT_COUNT} + +--- + +## Overall Verdict: SAFE / CAUTION / RISKY / BLOCK + +## Recommended Version Bump: PATCH / MINOR / MAJOR +{Justification from Oracle} + +--- + +## Per-Change Analysis (Ultrabrains) + +| # | Change Group | Verdict | Risk | Breaking? | Blocking Issues | +|---|-------------|---------|------|-----------|-----------------| +| 1 | {name} | PASS/FAIL | SAFE/CAUTION/RISKY | YES/NO | {count or "none"} | +| ... | ... | ... | ... | ... | ... | + +### Blocking Issues from Per-Change Analysis +{Aggregated from all ultrabrains — deduplicated} + +--- + +## Holistic Review (Review-Work) + +| # | Review Area | Verdict | Confidence | +|---|------------|---------|------------| +| 1 | Goal & Constraint Verification | PASS/FAIL | HIGH/MED/LOW | +| 2 | QA Execution | PASS/FAIL | HIGH/MED/LOW | +| 3 | Code Quality | PASS/FAIL | HIGH/MED/LOW | +| 4 | Security | PASS/FAIL | Severity | +| 5 | Context Mining | PASS/FAIL | HIGH/MED/LOW | + +### Blocking Issues from Holistic Review +{Aggregated from review-work} + +--- + +## Release Synthesis (Oracle) + +### Breaking Changes +{From Oracle — exhaustive list or "None"} + +### Changelog Draft +{From Oracle — ready to use} + +### Deployment Risk +{From Oracle — specific concerns} + +### Post-Publish Monitoring +{From Oracle — what to watch} + +--- + +## All Blocking Issues (Prioritized) +{Deduplicated, merged from all three layers, ordered by severity} + +## Recommendations +{If BLOCK/RISKY: exactly what to fix, in priority order} +{If CAUTION: suggestions worth considering before publish} +{If SAFE: non-blocking improvements for future} +``` + +--- + +## Anti-Patterns + +| Violation | Severity | +|-----------|----------| +| Publishing without waiting for all agents | **CRITICAL** | +| Spawning ultrabrains sequentially instead of in parallel | CRITICAL | +| Using `run_in_background=false` for any agent | CRITICAL | +| Skipping the Oracle synthesis | HIGH | +| Not reading file contents for Oracle (it cannot read files) | HIGH | +| Grouping all changes into 1-2 ultrabrains instead of distributing | HIGH | +| Delivering verdict before all agents complete | HIGH | +| Not including diff in ultrabrain prompts | MAJOR |