agentsclimarketplace

Pull request workflow

Skill yuri-semenenko/ai-engineering-workspace/codex/skills/pull-request-workflow

One engineering workflow across Claude Code, Codex, Copilot, and Gemini CLI. A portable persona canon, process skills, and safety guardrails, kept in sync by design.

Install
npx -y skills add yuri-semenenko/ai-engineering-workspace --skill pull-request-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when reviewing a PR, drafting PR feedback, classifying code-review comments, preparing a pull-request description, or creating copy-pasteable GitHub PR markdown.

SKILL.md

3.4 KB, 712 tokens by cl100k_base, as published. Nobody here has run it

Pull Request Workflow

Support two related jobs: reviewing PRs and drafting PR descriptions. Use English for GitHub markdown unless the user explicitly asks otherwise.

PR Review

Lead with findings. Classify every meaningful comment:

  • Critical — correctness, security, reliability, data loss, auth bypass, broken happy path, severe regression.
  • Important — maintainability, scalability, readability, missing tests for non-trivial logic, misleading boundaries.
  • Optional — style or preference only when ignoring it has a real cost. Drop pure nitpicks.

Rules:

  • Verify PR scope with gh pr view, PR URL/number, or git diff <base>...HEAD.
  • Read the tests and PR description first to recover intended behavior, then read the implementation against that intent.
  • Read enough surrounding code to validate each finding.
  • Cite path:line for every issue.
  • Order by severity, not by file.
  • Classification is severity, not certainty: when unsure a finding is real, phrase it as a question, not an assertion, and do not inflate a Critical you cannot fully trace.
  • Delegate the reading, keep the ruling. Run the same sequence every review, not only on large diffs: a cheaper-tier subagent orients on the changed surface, subagents gather by angle (correctness, tests, security when the surface is sensitive, performance) returning compact findings with path:line, and classification plus the verdict stay on the main model. A subagent finding is evidence, not a ruling.
  • End with verdict: approve, request changes, or needs discussion.

Format:

## Summary
<scope and verdict>

## Critical
- `path/to/file.ts:42` — <issue> — <impact> — <suggested fix>

## Important
_None._

## Optional
_None._

## Verdict
<approve | request changes | needs discussion> — <one sentence>

Review Loop

For non-trivial PRs or when the user asks for a deeper pass, run the review as a loop:

  1. Establish scope from the PR, issue, branch name, template, and diff.
  2. Inspect from independent angles: correctness/regression risk, tests/validation, maintainability, and security/performance only when the diff touches those surfaces.
  3. Merge findings into one ordered review. Do not duplicate comments across angles.
  4. Split feedback into fixes worth doing now, optional improvements, and items to defer or ignore with a short reason.
  5. If the user asks for autofix, apply only fixes worth doing now, then rerun targeted verification and inspect the final diff.

On a re-review after fixes, delegate the gather — the prior review comments plus the new work since them — to a cheaper-tier subagent, and keep the addressed / not-addressed judgment and the verdict on the main model.

Do not blindly apply every review suggestion. If a finding depends on an unapproved product, scope, or architecture decision, pause and ask for that decision instead of coding around it.

PR Description

When drafting the PR body:

  • Mirror the repo's PR template if present.
  • Inspect git diff --stat HEAD and the actual diff.
  • Derive ticket keys from branch names when obvious.
  • Include concrete, runnable test steps.
  • For UI work, include a placeholder for screenshot or recording evidence.

Output the body as one raw markdown fenced block so it can be pasted into GitHub.

What ships with it: 1 file

166 B alongside SKILL.md

agents/

Gives 0 of the 12 instructions most pr commit review skills give in 712 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07

  • Use conventional commits formatin 127 of 888, across 115 files
  • Keep subject line under 72 charactersin 62 of 888, across 48 files
  • Delete branches after mergein 51 of 888, across 38 files
  • Use imperative mood in subject linein 51 of 888, across 42 files
  • Use imperative mood in commit messagesin 44 of 888
  • Verify directory is ignored before creating worktreein 43 of 888, across 12 files
  • Generate a conventional commit messagein 43 of 888
  • Add unignored worktree directories to gitignorein 42 of 888, across 10 files
  • Make atomic commitsin 39 of 888, across 27 files
  • Run tests before committingin 36 of 888, across 25 files
  • Verify clean test baselinein 35 of 888, across 9 files
  • Split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

  • Drop pure nitpick comments
  • Verify PR scope before reviewing
  • Read surrounding code to validate each finding
  • Cite path:line for every issue
  • Keep classification and verdict on the main model
  • Output the PR body as one raw markdown block

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 327,132. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.