Release Oc

---
name: release-oc
description: OpenChrome release workflow — issue verification, triage, review, fix own PRs, merge, and optionally publish
---

# OpenChrome Release Workflow

$ARGUMENTS

---

## STEP 0: Issue Audit (CRITICAL — do this BEFORE reviewing PRs)

If the release involves specific issues (e.g., `#440`), audit each issue FIRST:

### 0a. Extract Requirements

```bash
gh issue view <N> --json title,body,labels,state

For each issue, create a Requirements Matrix:

| Req ID | Description | Files That Should Change | Verification Method |
|--------|-------------|-------------------------|---------------------|
| P0-1   | normalizeQuery in all tools | fill-form, interact, find, click-element, wait-and-click | grep for normalizeQuery import |
| P0-2   | In-page duplicate comment | element-discovery.ts | Read file, check comment |
| ...    | ... | ... | ... |

0b. Map PRs to Requirements

git log --oneline --all --grep="<issue-number>"
gh pr list --search "<issue-number>" --state all --json number,title,state,mergedAt,headRefName

Create a Coverage Matrix:

| Req ID | Covered By | PR Status | Verified in Code |
|--------|-----------|-----------|-----------------|
| P0-1   | PR #442   | merged    | [ ] not yet checked |
| P2-1   | PR #???   | NOT FOUND | [ ] MISSING |

Gate: If any requirement has NO PR and NO code change, flag it as a RELEASE BLOCKER. Do NOT proceed to merge until all requirements are accounted for.

0c. Verify Each Requirement in Code

For each requirement, actually check the codebase — not just the PR diff:

# Example: "normalizeQuery applied in all tools that accept text queries"
grep -r "normalizeQuery" src/tools/ --include="*.ts" -l
# Compare against the list of tools that SHOULD have it

Mark each requirement as:

• PASS — implemented and verified in current code
• PARTIAL — implemented in some but not all required locations
• MISSING — not implemented at all
• UNTESTED — implemented but no tests exist

Gate: Any PARTIAL or MISSING requirement is a RELEASE BLOCKER. UNTESTED requirements should have tests added before release.

---

STEP 1: Status Check

Run all of these and report results:

git status
git stash list
git branch -a
gh pr list --state open --json number,title,headRefName,baseRefName,additions,deletions,author,files
npm run build
npm run lint
npm test

Gate: If build, lint, or tests fail, fix errors first. Do NOT proceed with any failures.

STEP 2: Classify Open PRs

For each open PR, determine ownership:

Type	How to Identify	Action
MY PR	author.login matches repo owner	Review -> Fix P0/P1 -> Merge
OTHER's PR	Different author	Review -> Post comment -> Do NOT merge

List all PRs in a table:

| PR # | Title | Author | Type | Linked Issue | Files Changed |
|------|-------|--------|------|-------------|---------------|

STEP 3: Triage Local Changes

Check for uncommitted local work:

git status
git stash list
git diff --stat

For each local change, classify:

Change Type	Action
Source code (.ts) changes	Create PR by category (feat/fix/refactor/chore). All PR titles, descriptions, and commit messages MUST be in English.
.claude/ agents/commands	Validate YAML frontmatter, bundle into chore PR
Temp/experiment files	Delete if not needed
Stashed changes	Pop, resolve conflicts, commit or drop

Gate: All local changes committed or discarded. git status shows clean working tree.

STEP 4: Review Each PR

For EACH open PR (both mine and others'), in order:

4a. Run /pr-review-oc <N>

This produces a P0/P1/P2 issue list and verdict (single-agent inline review).

4b. Run /code-review-oc on PR changed files (deep specialist review)

Extract the PR's changed files and run a deep code review with 3 parallel specialist agents:

gh pr diff <N> --name-only

Then invoke: /code-review-oc <space-separated file list>

This spawns 3 specialist agents in parallel:

• oc-code-reviewer — CDP/Puppeteer domain expertise, 6-area review
• oc-silent-failure-hunter — empty catches, swallowed errors, resource leaks
• oc-platform-reviewer — Windows/Linux/macOS compatibility (paths, signals, process mgmt)

Merge the findings from both 4a and 4b. Use the higher-confidence finding when duplicates exist.

4c. Issue-Requirement Verification (NEW — prevents incomplete merges)

For each PR that references an issue:

1. Scope Check: Does the PR implement ALL parts of the issue it claims to address, or only a subset?

   • If subset: Is this clearly scoped in the PR title/description? Are there other PRs for remaining parts?
   • If "centralize X across all tools" but only 3 of 7 tools are changed: P0 BLOCKER

2. Test Coverage Check: Does the PR include tests for new functionality?

   • New function/module with 0 tests: P1 — must add tests before merge
   • New behavior branch with 0 coverage: P1
   • Refactored code with existing tests still passing: OK (no new tests required)

3. Completeness Grep: Verify the change was applied everywhere it should be:

   # Example: if PR adds normalizeQuery to tools, verify ALL tools have it
   # List tools that accept text queries:
   grep -rn "query.*as string\|query.*string" src/tools/ --include="*.ts" -l
   # List tools that import normalizeQuery:
   grep -rn "normalizeQuery" src/tools/ --include="*.ts" -l
   # The two lists should match (minus tools that don't need normalization)
   

4. Cross-Reference with STEP 0: Update the Coverage Matrix. If this PR marks a requirement as PASS, verify it in code.

4d. Check Greptile review (if available)

Greptile AI automatically reviews PRs via GitHub App. Fetch its review:

gh api repos/{owner}/{repo}/pulls/<N>/reviews \
  --jq '[.[] | select(