agentsclimarketplace

Pull requests

Skill latent-variable/agentscope/skills/pull-requests

One user-scope brain every agent CLI reads: Claude Code, Codex, Antigravity/Gemini, Pi. Clone to ~/.agents, let your agent onboard you.

Install
npx -y skills add latent-variable/agentscope --skill pull-requests

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

How to write pull requests and commits, terse style, structure, and attribution. Load when opening a PR, writing a commit, or summarizing a branch.

SKILL.md

1.8 KB, as published. Nobody here has run it

Pull Requests & Commits

House style for PR descriptions and commit messages. Artifacts, so write them normally (terse, not ELI5, ELI5 is only for talking to the user).

Commit messages

  • Subject ≤ ~50 chars, imperative mood. Conventional Commits prefix when the repo already uses it (feat:, fix:, chore:…).
  • Body only when the "why" isn't obvious from the diff. Explain intent/tradeoff, not the line-by-line.
  • Attribution line for non-trivial commits:
    Assisted-by: <Agent> <model-id>
    
    e.g. Assisted-by: Claude claude-opus-4-8. Omit for trivial commits (typo, version bump, whitespace).

PR descriptions

  • Action before context. Lead with what changed. Why-it-matters second.
  • Terse and punchy. Say it once. Cut hedging preamble.
  • Structure: 1 to 2 sentence summary → bullets of concrete changes → testing/verification → caveats/follow-ups if any.
  • No duplicate summaries. One source of truth per fact.
  • Don't restate the diff line-by-line; surface what a reviewer can't see (intent, risk, what was verified).
  • End the body with the attribution line (same as commits) for non-trivial PRs.

Review behavior

  • Project may ship its own review tooling/skill, check the repo's AGENTS.md first.
  • When reviewing, one line per finding: location, problem, fix. Cut noise, keep the actionable signal.

Before pushing

  • Confirm tests pass; if they don't, say so plainly with the output. Never report green when it's red.
  • Branch off the default branch first if currently on it. Push/open PR only when the user asks (or per the review-cycle skill if adopted).

Keep looking

Skills are one crate of 328,083. 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.