Pre Publish Review

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

task(  category="ultrabrain",  model="gpt-5.6-sol",  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 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>{GROUP_NAME}</group_name><verdict>PASS or FAIL</verdict><risk>SAFE / CAUTION / RISKY</risk><summary>2-3 sentence assessment of this change group</summary><has_breaking_changes>YES or NO</has_breaking_changes><breaking_change_details>If YES, describe what breaks and for whom</breaking_change_details><findings>  For each finding:  - [CRITICAL/MAJOR/MINOR] Category: Description  - File: path (line range)  - Evidence: specific code reference  - Suggestion: how to fix</findings><blocking_issues>Issues that MUST be fixed before publish. Empty if PASS.</blocking_issues>""")

task(  category="unspecified-high",  model="gpt-5.6-sol",  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 — run the manual QA phase, launch the gate reviewer, and collect its verdict. Do NOT skip the QA phase or the reviewer.""")

task(  subagent_type="oracle",  model="gpt-5.6-sol",  run_in_background=true,  load_skills=[],  description="Oracle: overall release synthesis and version bump recommendation",  prompt="""<review_type>RELEASE SYNTHESIS — OVERALL ASSESSMENT</review_type>
<project>oh-my-opencode (npm package)</project><published_version>{PUBLISHED}</published_version><local_version>{LOCAL}</local_version>
<all_commits>{ALL COMMITS since published version — hash, message, author, date}</all_commits>
<diff_stat>{DIFF_STAT — files changed, insertions, deletions}</diff_stat>
<changed_files>{CHANGED_FILES — full list of modified file paths}</changed_files>
<full_diff>{FULL_DIFF — the complete git diff between published version and HEAD}</full_diff>
<file_contents>{Read and include full content of KEY changed files — focus on public API surfaces, config schemas, agent definitions, hook registrations, tool registrations}</file_contents>
You are the final gate before an npm publish. 10 ultrabrain agents are reviewing individual changes and the review-work gate reviewer is doing the 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 for each release layer and the overall workflow 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:<verdict>SAFE / CAUTION / RISKY / BLOCK</verdict><recommended_version_bump>PATCH / MINOR / MAJOR</recommended_version_bump><layer_specific_version_bump>omo pure components: PATCH/MINOR/MAJOR; omo opencode: PATCH/MINOR/MAJOR; omo codex: PATCH/MINOR/MAJOR</layer_specific_version_bump><version_bump_justification>Why this bump level</version_bump_justification><release_coherence>Assessment of whether changes belong in one release</release_coherence><breaking_changes>  Exhaustive list, or "None" if none.  For each:  - What changed  - Who is affected  - Migration steps</breaking_changes><changelog_draft>  Ready-to-use changelog entry</changelog_draft><deployment_risk>  Overall risk assessment with specific concerns</deployment_risk><monitoring_recommendations>  What to watch after publish</monitoring_recommendations><blocking_issues>Issues that MUST be fixed before publish. Empty if SAFE.</blocking_issues>""")