pull-requests_skill

This skill helps you manage pull requests in this repo by enforcing guidelines, attribution footers, and lifecycle checks.

TypeScript

897

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill coder/mux --skill pull-requests

SKILL.md4.7 KB

Overview

This skill provides concise, actionable guidelines for creating and managing Pull Requests in a TypeScript desktop app repo focused on isolated, parallel agentic development. It codifies branch naming, PR body structure, CI handling, and review workflows to keep contributions consistent and reviewable. It also enforces an attribution footer for generated work and defines rules for rebasing and merging.

How this skill works

The skill inspects PR metadata and developer actions and describes the expected branching, commit, and review behaviors. It explains the required attribution footer, status meanings (mergeable, mergeStateStatus), and scripts to wait for CI or resolve automated review comments. It also prescribes how to post multi-line gh comments and how to handle Codex review threads.

When to use it

Before opening any PR to ensure branch and base are correct and the attribution footer is present
When a PR needs rebasing, conflict resolution, or to be kept up to date with main
When Codex or automated reviewers leave review threads that must be addressed before merging
When deciding PR title prefixes and when writing a structured PR body
Before waiting on CI to prefer local validation and reduce wasted time

Best practices

Always include the specified attribution footer and verify $MUX_MODEL_STRING, $MUX_THINKING_LEVEL, and $MUX_COSTS_USD are set when applicable
Rebase work onto origin/main before opening a new PR; force-push only for small fixes to preserve history where required
Follow the PR body structure: Summary, Background, Implementation, Validation, Risks — omit sections that don’t apply
Use scripts for CI and Codex workflows (wait_pr_checks.sh, check_codex_comments.sh, resolve_pr_comment.sh) instead of manual polling
Never enable auto-merge or merge into main yourself; the user must explicitly merge PRs

Example use cases

Opening a feature PR: name the branch clearly, add the attribution footer, use prefix feat: in the title, and fill the structured body
Updating an existing PR with minor fixes: force-push a small commit and keep the PR open for continuous review
Resolving Codex review threads: run check_codex_comments.sh, push fixes, resolve threads via resolve_pr_comment.sh, and request re-review
Handling a stale PR: rebase onto origin/main, resolve conflicts, then push with --force-with-lease and confirm CI status

FAQ

Include the 🤖 emoji in the PR title and add the required attribution footer in the PR body with model, thinking level, and cost if available.

How do I handle a PR that is behind main?

Fetch and rebase: git fetch origin && git rebase origin/main && git push --force-with-lease; then verify CI and status fields before requesting merge.

How should I post multi-line gh comments for Codex review?

Use --body-file - with a heredoc to preserve newlines, e.g., gh pr comment <pr_number> --body-file - <<'EOF' … EOF.