dotfiles

Close out GitHub pull request review feedback on the current branch: fetch unresolved review threads with gh, assess each in code, decide validity, create an implementation plan, implement fixes, run quality gates, push, and resolve addressed threads with commit-hash references. Use when addressing PR comments, fixing review feedback, resolving review threads, or closing out PR review. For reply-only, use when user asks to respond without code changes. Not for reviewing others' PRs (use gh-review-specific-pr) or opening/splitting PRs (use open-pr / slice-pr).

Review a specific GitHub pull request: verify findings in the diff and surrounding code, post inline review comments or thread replies with gh, and keep reviews pending unless the user asks to submit. Use when reviewing a PR, posting review comments, pending review comments, or validating findings before posting on a PR.

Prepare git commit history and open a GitHub pull request in the browser. Use when the user wants Codex to commit the current session's work, derive a ticket like ABC-123 from the branch name, craft a conventional commit and PR title in the form scope: [TICKET-NR] summary, push the branch, and open `gh pr create --web` with a helpful prefilled description.

Rebuild a large, messy git branch into small reviewable PRs by mapping the current diff into final intent-based commits and recreating branches from the default branch. Use when a user wants to split one branch into multiple PRs, drop preparatory or unrelated changes, replace development chronology with cleaner history, or run a sequential branch-to-PR-to-merge workflow.

Use when summarizing raw one-on-one markdown notes, especially when they include speaker direction, blockquotes, Q/A markers, shorthand, or fragmented note-taking syntax.

Analyze, verify, and refine architecture documentation against the implemented system. Use when Codex needs to align architecture docs, ADRs, technical design notes, diagrams, or system overviews with actual runtime behavior, enforced interfaces, real data flow, and current constraints; remove outdated or aspirational architecture; and make boundaries, invariants, and failure modes explicit before decisions or changes.

Use when refining rough notes, draft Slack messages, bullet points, or internal announcements into an internal Slack message for engineering, product, technology, or cross-functional stakeholders in a tech organization.

Use when converting project notes, meeting outcomes, Jira updates, status reports, or bullet points into a concise project status update that is comparable across projects.

Ruby workflow for bug fixes, refactors, incidents, and targeted code review. Use when work needs disciplined Ruby investigation, small safe changes, repo-native validation, TDD-oriented fixes, and clear routing to test review or finish-review when the request is narrower or later-stage.

Rewrite, tighten, and verify existing public-facing documentation against the current codebase and supporting files in high-churn, low-trust environments. Use primarily to improve existing docs, reduce documentation bloat, refresh README or contributor docs, or fix inaccurate, stale, unclear, or obsolete documentation. Inspect the repository first, prefer verified public-facing clarity, and avoid inventing behavior that is not present in code or supporting artifacts.

Investigate, scope, and implement a Jira ticket in this repository from a ticket URL or key such as ABC-123. Use when work starts from Jira, must use Atlassian MCP to gather issue details, may need Datadog MCP for linked observability evidence, must verify the current codebase before changing code, and should branch from a fresh default branch before autonomous implementation.

Rails overlay for API/controller/service/policy/serializer/worker changes. Use with $ruby-dev for Rails architecture, tenancy, authz, and API contracts.

Security and compliance-focused code review workflow for changes that may impact confidentiality, integrity, availability, privacy, auditability, or regulatory controls. Use for threat-driven review, control-gap assessment, and remediation guidance.

Review Ruby code, branches, or PRs for performance risks and optimization opportunities. Use when the user asks for a performance review, wants explicit big-O analysis, requests fewer iterations or fewer allocations, asks whether Set/Hash/Array are the right data structures, wants better Enumerable usage, or wants architectural rearrangements for hot paths in Ruby code.

Production-readiness review for a git branch at the end of delivery. Use when user asks for production quality, readiness, finishing, or a senior/principal review; includes mandatory diff vs default branch and risk/compliance posture.

Review changed test files and spec diffs for over-mocking, hidden regressions, contract gaps, assertion weakness, fixture dishonesty, flaky test seams, and brittle architecture. Use when Codex is asked to review specs, tests, or test-related changes in Ruby, JavaScript, or similar codebases, especially when the user suspects mocks are covering bugs, wants stronger regression detection, or wants architectural advice to make tests more precise.