---
name: prcdx
description: Create a GitHub Pull Request in Codex with Claude and Codex review requests and standard GitHub polling
disable-model-invocation: true
---

# prcdx

You are given the following context:
$ARGUMENTS

## Task: Create a GitHub Pull Request in Codex

Based on the provided context, create a pull request following these steps:

1. First, check the current git status and uncommitted changes.
2. If there are uncommitted changes, ask if they should be committed first.
3. Ensure the current branch is not `main` or `master`.
4. Push the current branch to remote if needed.
5. Create the pull request using `gh pr create` with:
   - A clear, descriptive title
   - A comprehensive description including:
     - Summary of changes
     - Testing performed
     - Any breaking changes or notes
6. Return the PR URL when complete.

## IMPORTANT: Final Summary

**ALWAYS** end your response with a clear summary that includes:

- What was done (branch created, commits made, PR opened, review requested, etc.)
- **The PR URL** (for example: `PR #123: https://github.com/owner/repo/pull/123`)
- Whether Claude review was requested
- Whether Codex review was requested
- Whether the PR is ready for review

Format the PR link prominently so it's easy to find.

If no arguments are provided, create a PR with an auto-generated title and description based on the current branch and commit history.

Use `--draft` if the work is clearly in progress.

## Review Flow

After the PR is created, follow this review workflow unless the user explicitly says not to:

1. Post a comment requesting Claude review:
   ```bash
   gh pr comment <PR_NUMBER> --body "@claude please review this PR"
   ```
2. Post a second comment requesting Codex review:
   ```bash
   gh pr comment <PR_NUMBER> --body "@codex please review this PR"
   ```
3. Poll GitHub using standard CLI or API commands, not Claude Code slash commands.
4. Check issue comments, PR reviews, and inline review comments every 2 minutes for a bounded period.
5. Codex review usually takes longer than Claude review. Do not stop polling just because Claude replied first.
6. Continue polling until you see a real Codex comment or review, not just an "in progress" placeholder, or until a reasonable bounded wait expires.
7. Show the returned review feedback to the user and ask what they want to do next. If Claude replied but Codex has not yet replied, say that Codex review is still pending and keep polling until the bounded wait is reached.

## Suggested Polling Approach

Use normal GitHub commands such as:

```bash
gh pr view <PR_NUMBER> --json comments,reviews,url
```

or:

```bash
gh api repos/<owner>/<repo>/issues/<PR_NUMBER>/comments
gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/reviews
```

When polling:

- Record a baseline timestamp immediately before or after posting the `@claude` and `@codex` comments
- Only treat newer comments or reviews as candidate review results
- Ignore empty bodies and obvious "review in progress" placeholders
- Codex review usually takes longer, so keep checking until you see Codex feedback or the bounded wait expires
- Stop after a reasonable bounded wait if no review arrives, and tell the user that Claude review and Codex review were requested but have not yet returned

## IMPORTANT: Review Inspection Hygiene

Do **not** assume a top-level review with generic text means there are no findings.

- Always inspect **inline review comments / file-level review threads** in addition to issue comments and top-level reviews.
- Actionable feedback can exist only in inline comments even when the main review body looks boilerplate.
- Inline comments may be attached to an older reviewed commit on the same branch and still be relevant.
- Before dismissing a review as empty, check all three surfaces:
  - issue comments
  - PR reviews
  - pull request review comments / inline comments

Suggested extra command:

```bash
gh api repos/<owner>/<repo>/pulls/<PR_NUMBER>/comments
```

## Handling Review Feedback

- **Real critical bugs** (regressions, data loss, crashes, security issues): fix them immediately without asking.
- **Everything else** (style, theoretical issues, nice-to-haves, non-critical improvements): present to the user with your assessment and ask before fixing.

## Merge Requests

If the user explicitly says `merge`, do not wait for CI to finish.

- Merge the PR immediately using a regular merge commit.
- Do not block on pending checks unless the user explicitly asks to wait.
- If you see ongoing GitHub Actions build jobs for that PR or branch, submit a cancel request after merging instead of leaving them running.
- Do not wait for GitHub to confirm the cancellation. One cancel request is enough unless the user explicitly asks you to verify.
- Right after the merge, switch the local repository back to `main`.

## Post-Merge: Update What's New

After the PR is merged, update the running What's New file in the Obsidian vault:
- **File**: `Projects/VivaDicta/what's new/whats-new-running.md` in the vault at `/Users/antonnovoselov/Documents/Vault/`
- **Skip** if the PR is a one-liner simple fix, bug fix, refactor, or minor cleanup that users wouldn't notice.
- **Add** a concise, user-facing bullet point when the PR introduces a new feature or notable improvement. Write it from the user's perspective (what they can now do), not technical details. This file feeds into App Store Connect "What's New" release notes.