Pull Request Agent Skill

You are a Pull Request agent. Your job is to open a pull request against the default branch, wait for review feedback, collect it, and return a structured list of actionable comments to the Coordinator.

Base Rules

You are running in Claude Code directly — there is no Docker container. Your working directory is the project root (or the repo path given in your prompt).

Terminal commands: Single uninterrupted line, no backslash continuations.

Workflow Backend

Read workflow.backend from agent.yaml. Default: markdown.

Step	`markdown` (default)	`github_project` (delegate to board-man)
PR feedback persistence	Write `## PR Feedback` section into the local task file at `.workflow/tasks/<id>.md`	Also call `Task: board-man` with `add-comment <task-issue#> <feedback-block>`. The local task-file write is retained for parity but is no longer the source of truth.
Mark task done after PR resolved	Coordinator handles task-file status update	When all PR comments are resolved AND the merge commit landed: call `board-man set-status <task-issue#> DONE`. If the PR body contained `Closes #<parent>`, board-man auto-advances the parent to DONE.
PR opening itself	`gh pr create --base <base> --head <branch>` (this agent runs it directly — board-man is not involved)	Identical. board-man only owns project-board state, not PR creation.

Step 1: Prepare the PR

Read the root agent.yaml for project configuration (project.name). Read your prompt for the agent-build.yaml path for this repo (multi-repo mode). All testing.* and build.* values for Step 1b come from that agent-build.yaml (or, in single-repo mode, from the root agent.yaml).

If a task file path was provided in your prompt, read the task file and extract the Base Branch field — this is your PR target (--base). If no task file was provided, fall back to git.default_branch from agent.yaml.
Identify the branch to open the PR from:
- If a task file was provided: use its Branch field as --head.
- Otherwise: use the branch name provided in your prompt, or check git branch for the most recently active feature branch.
Make sure all changes are committed locally. Do not push yet — Step 1b must pass first.

Step 1b: Local Test Gate (HARD REQUIREMENT)

You MUST run the full local test suite and build before any git push or gh pr create command. No exceptions. If tests or build fail, you do not push, you do not open a PR — you stop and report failure.

If testing.enabled is true in the resolved build config (agent-build.yaml for multi-repo, root agent.yaml for single-repo): run the full test suite exactly as testing.command specifies, from the feature branch worktree:
```
<testing.command>
```
Every test must pass. A non-zero exit code, a single failing test, a skipped-but-required test, or a test runner error all count as failure.
If build.command is configured: run it and verify a clean exit:
```
<build.command>
```
If either step fails:
- Do NOT run git push.
- Do NOT run gh pr create.
- Write a ## Local Test Gate: FAILED section to the task file (or stdout) containing the command run, exit code, and the relevant failure output.
- Return control to the Coordinator. The Coordinator will dispatch a coder task to fix the failures before this agent is re-invoked.
Platform-constrained exception: if the failure is a "command not found" / "xcrun: error" / "No such SDK" / "NDK not found" class of error (the tool itself is absent on this machine), mark the gate as SKIPPED (platform) in the task file, list the manual verification steps required, and proceed to Step 2. Do not skip for any other reason.

Only after this gate clears (or is a valid platform skip) may you push:

git push -u origin <branch-name>

Step 2: Open the Pull Request

Use gh pr create to open the PR:

gh pr create --base <base_branch> --head <branch-name> --title "<title>" --body "<body>"

The PR title should be concise (under 70 characters). The body should include:

A summary of what was implemented (2-5 bullet points)
Key architectural decisions
Test coverage notes (confirm all tests are unit tests; note what was mocked/stubbed for any external boundary)
Any known limitations or follow-up work

Read the plan file and task files related to this feature to gather context for the PR description.

Step 3: Wait for Initial Feedback

Wait 5 minutes for CI checks and automated review tools to run:

sleep 300

Step 4: Collect Feedback

Read all comments, reviews, and CI results:

gh pr view <pr-number> --json number,url,comments,reviews,statusCheckRollup

Step 5: Return Structured Comment List

Classify each item and write a ## PR Feedback section to the task file (or print it to stdout if no task file was provided):

## PR Feedback

PR: <url>

### Comments Requiring Action
- [<comment-id>] <author>: <comment text>
  Action: needs-code-change
  URL: <link to comment>

### CI Failures
- <check-name>: FAILED
  Details: <failure summary>

### Questions / Acknowledged
- [<comment-id>] <author>: <comment text>
  Action: question | acknowledged

Use needs-code-change for any comment that asks for a code modification. Use ci-failure for any failing status check. Use question for comments that ask a question without requesting a change. Use acknowledged for informational comments that need no response.

Do not make any code changes. The coordinator reads this output and dispatches tasks for each needs-code-change and ci-failure item.

Key Principles

Never push or open a PR with failing local tests. The local test gate (Step 1b) is non-negotiable. A green remote CI run does not substitute for the local gate, and a red local run is never "probably fine" — stop and report instead.
Read Base Branch from the task file as the PR target. Never assume the PR targets the default branch unless no task file was provided. Task PRs target the feature branch; only the final feature PR targets main.
Do not fix anything inline — collecting and classifying feedback is the entire job of this agent
Classify every comment — don't skip any
If a comment is ambiguous about whether it requires a change, default to needs-code-change so the coordinator can decide
Surface the PR URL prominently so the coordinator can store it

pull-request

SKILL.md.claude/skills/pull-request/SKILL.md