Pr Writer Vp

PR Writer

Use this skill for external open-source PR work. The workflow has six phases:

1. Step1 Fork & Clone
2. Step2 Find PR Chances
3. Step3 Validate PR Value
4. Step4 Implement & Create Formal PR
5. Step5 Address Reviewer Feedback
6. Step6 Refine PR Comment Section

Non-Negotiables

• Always start multi-agent work when this skill runs. Launch at least two agents before phase-specific work; use more for Step2, Step3, Step4, Step5, and Step6 when the repository is large, the task is ambiguous, reviewer feedback touches behavior-sensitive code, or a PR comment section needs stronger evidence.
• Treat submission as dry-run by default outside Step4 and Step5. Do not commit, push, create, mark ready, or update a PR unless the user explicitly asks for that action. When the user invokes Step4 by asking to create or submit a PR, treat that as permission to commit, push, and create a formal ready-for-review PR by default, unless the user explicitly asks for a draft PR.
• Do not modify references/ files as part of ordinary PR workflow.
• Default clone path is D:\ZXY\Github\ on this Windows machine unless the user gives another path.
• Prefer small, reviewable bug fixes. The default target is a production-code fix of 0-20 changed lines.
• Do not include unrelated refactors, generated churn, broad formatting, or CHANGELOG.md unless the project explicitly requires it.
• Keep evidence honest. Distinguish runtime reproduction, UI reproduction, package reproduction, focused unit reproduction, inferred risk, and unavailable validation.
• For every commit created while using this skill, explicitly include the relevant Codex/GitHub bot as a Co-authored-by trailer when a valid bot noreply identity can be verified. Prefer the active reviewer bot identity when responding to bot review feedback, for example Co-authored-by: chatgpt-codex-connector[bot] . Do not guess bot IDs or emails; verify them with GitHub user metadata such as gh api users/ before committing.
• When a commit implements a substantive human reviewer's requested change, best-effort include that reviewer as an additional Co-authored-by trailer using a valid GitHub noreply or otherwise verified public email. Never guess private emails; skip the human trailer if the identity cannot be verified or if the repository's norms discourage human co-authorship.
• Read references/pr-examples.md before drafting or revising PR prose. Treat it as the few-shot style guide for concise, evidence-driven bug-fix PRs.

Multi-Agent Baseline

At the start of every skill run:

1. Launch a coordinator/main pass in the current thread.
2. Launch at least two independent agents with separate scopes.
3. Ask agents for concrete findings with file paths, evidence, risks, and next actions.
4. Merge findings yourself. Do not paste raw agent output unless the user asks.
5. If subagents are unavailable in the runtime, state that the skill requires them and continue only after explaining the limitation to the user.

Mechanical gate:

• Before taking phase-specific actions in Step1, Step2, Step3, Step4, Step5, or Step6, at least two independent agents must have been successfully started for that phase or for the overall skill run.
• Before completing Step2, Step3, Step4, Step5, or Step6, collect outputs from at least two agents and reconcile them in the main thread.
• If two agents cannot be started or cannot return useful output, pause the phase, tell the user the exact blocker, and ask whether to continue with a degraded single-agent pass.
• Do not describe ordinary sequential self-review as "multi-agent" work.

Recommended agent roles:

• Repo rules agent: contribution guide, PR template, issue requirements, CLA, tests, AI disclosure, submission norms.
• Bug-hunt agents: independent source review by area, language, package, or feature surface.
• Evidence agent: reproduction path, failing payload, focused test, command output, before/after proof.
• Diff/body agent: actual diff review, PR-body claim audit, validation gap check.
• Reviewer-feedback agent: all review threads, requested changes, maintainer intent, comment-to-diff traceability, and reply wording.
• CI agent: repository CI workflow discovery, local full-CI command selection, remote check monitoring, and failure triage.
• Comment-section agent: expands a user-specified section of the first PR comment with concrete problem framing, narrow changes, reproducible evidence, and call-chain impact while preserving the surrounding PR body.

Mandatory Patch-Generation Review Lenses

Whenever agents are asked to generate, review, or integrate PR patch code, their prompts and final findings must explicitly consider these five lenses. The main agent must reconcile the answers before accepting a patch as reviewable:

• Correctness: Is the code logic right? Does the patch actually fix the bug, and can it introduce a new bug?
• Ownership boundary: Is the change placed in the correct module/file/package? Does it cross a boundary that should be owned by another layer?
• Completeness: Did the review cover the whole decision surface, not just the changed diff lines? Include callers, callees, sibling modules, fallback paths, and adjacent feature variants.
• Best-fix judgment: Is this the best fix, not merely a workable fix? Prefer the smallest durable fix that removes the real failure mode, follows established local patterns, and avoids whack-a-mole patches.
• Risk awareness: Does the patch touch compatibility-sensitive behavior such as configuration, authentication, routing, rollback, persistence, parsing, platform paths, or provider behavior? If yes, include a concrete risk assessment and targeted validation plan.

Patch-producing agents must report their conclusion for each lens using the labels Correctness, Ownership, Completeness, Best fix, and Risk. If a lens is not applicable, they must say why. A patch is not ready for commit, PR body drafting, or submission until the main agent has checked these five lenses against the actual diff.

Mandatory PR Evidence Review Lenses

When drafting a PR, updating a PR body, or addressing reviewer-requested changes, agents must also consider these evidence lenses. These lenses answer whether the PR proves the change, not just whether the patch looks plausible:

• Behavior proof: Is there a screenshot, screen recording, log, terminal output, before/after trace, or live/API result showing that the change actually works? Use the smallest proof that demonstrates the user-visible or runtime behavior.
• Media proof bonus: If the change is visual, UI, interactive, terminal/TUI, browser, desktop, or workflow-facing, prefer video or screen recording evidence when feasible. Treat media proof as extra reviewer confidence, not a substitute for tests.
• Test/CI proof: Are relevant tests added or updated? Is CI green, or are any failing/skipped checks explained? If the change cannot be covered by tests, explain why and provide the closest focused validation.
• Dependency contract proof: If the patch changes or relies on an external dependency, provider, SDK, API, protocol, CLI, or documented behavior, read the upstream documentation, source, schema, changelog, or captured response and cite the exact contract being relied on.
• Sibling surface proof: If one path/channel/surface was changed, check sibling paths and explain whether they are affected. Examples: changed route A, check B/C routes; changed CLI path, check TUI/ACP/desktop equivalents; changed one provider, check similar providers.

Evidence agents and diff/body agents must report these labels as Behavior proof, Media proof, Test/CI proof, Dependency contract, and Sibling surfaces. If a lens is not applicable, they must say why. The main agent must include the relevant evidence in the PR body or reviewer reply, and must not claim evidence that was not actually gathered.

Step1 Fork & Clone

Use this phase when the user gives a project name, GitHub URL, or asks to prepare a local PR workspace.

1. Resolve the upstream repository.

• Prefer the user-provided URL or official GitHub repository search.
• Record upstream URL and fork URL in the response.

1. Start multi-agent setup review.

• Assign one agent to inspect repository contribution/setup files.
• Assign one agent to inspect package manager, build, test, and project-specific agent instructions.

1. Fork and clone.

• Fork to the user's GitHub account when no suitable fork exists.
• Clone the fork into D:\ZXY\Github\ on this machine unless another path is requested.
• Add upstream pointing to the original repository.

1. Synchronize main.

• Fetch upstream main.
• Fast-forward fork main to upstream when possible.
• Do not force-push main unless the user explicitly approves and the reason is clear.

1. Create a work branch.

• Use local branch fix if available and pushable.
• If fix conflicts with existing refs, use fix/ or codex/.
• Keep main unchanged except for synchronization.

1. Bootstrap only what is needed.

• Read README, CONTRIBUTING, AGENTS, package manager files, and project-specific instructions.
• Install dependencies only when needed for targeted validation.
• If install/build fails, capture exact commands and errors.

Local Environment Bootstrap On This Machine

After cloning into D:\ZXY\Github\, inspect project files before installing dependencies. Configure only the minimum environment needed for reproduction and targeted validation.

Check these files first when present: README*, CONTRIBUTING*, AGENTS.md, pyproject.toml, setup.py, setup.cfg, requirements*.txt, environment.yml, conda-lock.yml, .python-version, package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb, Dockerfile, docker-compose.yml, compose.yaml, .devcontainer/, and CI workflow files.

Python projects:

• Use this machine's Miniforge first: D:\ZXY\Dev\Miniforge3\condabin\mamba.bat; fall back to D:\ZXY\Dev\Miniforge3\condabin\conda.bat.
• Create one isolated conda environment per repository, named prw--py.
• Infer the Python version from project files or CI config. Default to Python 3.12 only when the project does not specify a version.
• Prefer mamba env create -n -f environment.yml when an environment file exists.
• Otherwise create a minimal environment with mamba create -y -n python=, then install dependencies with the project's declared tooling.
• Prefer conda run -n ... or mamba run -n ... for non-interactive commands instead of relying on shell activation.
• Keep the environment isolated to the PR candidate; do not reuse a shared base environment.

Node.js projects:

• Use this machine's Node.js installation at D:\ZXY\Dev\nodejs.
• Node executable: D:\ZXY\Dev\nodejs\node.exe (currently observed as Node.js v24.15.0).
• npm executable: D:\ZXY\Dev\nodejs\npm.cmd (currently observed as npm 11.12.1).
• When a repository's CI requires a different major version (for example Node 22.x), report the mismatch before treating local build results as CI-equivalent evidence.
• Select the package manager from packageManager or lockfiles:
• pnpm-lock.yaml -> pnpm install
• yarn.lock -> yarn install
• package-lock.json -> npm ci
• no lockfile -> npm install
• If the selected package manager is missing, use Corepack when appropriate or report the missing tool and exact next command needed.
• Run only focused validation scripts needed for the PR candidate, such as targeted tests, lint, typecheck, or the narrow package build.

Docker and WSL projects:

• Use Docker only when the project requires service dependencies or its README, compose files, Dockerfile, or devcontainer requires it.
• This machine uses WSL2 with Ubuntu-22.04. Windows path D:\ZXY\Github maps to /mnt/d/ZXY/Github in WSL.
• If Docker CLI exists but the daemon is unavailable, report that Docker Desktop is not running and start Docker Desktop before running compose commands when feasible.
• Prefer Docker Desktop with the WSL2 backend. Do not install a second Docker Engine inside WSL unless the project explicitly requires it.
• Use WSL for Linux-only shell scripts, Makefile/bash-heavy workflows, Docker workflows, or projects that depend on Linux path semantics. Otherwise stay in the Windows project directory.
• Capture exact compose commands, service names, ports, and startup errors when Docker validation is required.

1. Finish with repository state.

• Report local path, active branch, upstream remote, fork remote, whether main is synchronized, and bootstrap blockers.
• Treat Step1 as complete only when the user can continue from a clean, explainable repository state.

Step2 Find PR Chances

Use this phase when the user asks to find PR opportunities, inspect a project for small fixes, or launch bug hunting.

1. Start multi-agent bug hunting. This phase must use multiple agents.

• Give agents different source areas or bug templates so they do not duplicate work.
• Default prompt direction: "Find likely real bugs with fixes under 20 changed production-code lines, especially compatibility regressions, API contract mismatches, parser edge cases, tool/function calling schema issues, serialization/deserialization bugs, path/URL handling, validation bypasses, and small runtime failures with reproducible impact."
• Require each agent to return candidates with file path, call chain, suspected failure mode, user impact, fix sketch, evidence plan, and risk.
• Do not edit code in Step2 unless the user explicitly asks to implement a chosen candidate immediately.

1. Search for fixable bugs, not cleanup.

• Prefer deterministic runtime errors, broken branches, bad exception handling, null/undefined access, incorrect state transitions, and realistic failing code paths.
• Prefer compatibility bugs: Windows/Linux path differences, Python/Node/browser version drift, encoding differences, dependency API changes, case sensitivity, newline/path separator behavior, and fallback handling.
• Prefer API contract bugs: returned fields, parameter names, default values, status codes, optional/required semantics, and type expectations that differ from documented or caller behavior.
• Prefer parser and serialization bugs: empty input, escaping, nested structures, partial parsing, malformed structured data, JSON/YAML/TOML/env/config conversion, date/time conversion, numeric conversion, and round-trip loss.
• Prefer tool/function-calling bugs: JSON schema mismatches, required/optional field mistakes, tool result parsing failures, streaming/tool-call ordering bugs, and provider-specific quirks.
• Prefer path, URL, validation, diagnostics, and security-adjacent bugs when the evidence is concrete.

1. Filter candidates aggressively.

• Return a set of concrete, fixable bug candidates, not a single vague lead.
• Default to candidates whose production-code fix is likely 0-20 changed lines.
• Treat production-code fixes over 20 lines as exceptions requiring explicit justification.
• Tests, reproduction scripts, and PR body evidence can exceed 20 lines when they improve maintainer confidence.
• Reject speculative style changes, broad refactors, large migrations, typing-only improvements, naming fixes, theoretical robustness, and issues requiring unavailable credentials or production services.
• Prefer candidates reproducible with a focused script, unit test, console snippet, small payload, or narrow command.
• Do not promote a candidate into the shortlist unless it has either a plausible executable reproduction entry point, a minimal payload/snippet, an existing failing path, or a clearly stated smallest-evidence plan.

1. Present a shortlist before editing.

• Include rank, candidate type, file path, bug summary, why it matters, likely production-code fix size, evidence plan, validation approach, and risk.

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: VectorPeak
• Source: VectorPeak/vectorpeak-agent-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.