Pull Request

Create high-quality pull requests with pre-submission validation, maintainer-friendly formatting, and automated quality checks.

Security Scan

This is an instruction-only skill that provides repository- and PR-focused guidance; its requirements and instructions are coherent with the stated goal and it does not request unusual privileges or install anything.

Purpose & Capability

The name/description ('Pull Request' guidance) matches the included files (checklist, red-flags, repo-context, templates). There are no unrelated required env vars, binaries, or config paths; all guidance is appropriate for creating maintainable PRs.

Instruction Scope

SKILL.md and the companion files instruct the agent to read repository metadata (CONTRIBUTING.md, CI files, style configs) and to avoid secrets and sensitive paths. The instructions do not direct the agent to collect or transmit data outside the normal PR workflow, nor do they instruct accessing unrelated system files. They explicitly tell the contributor not to include secrets and to disclose AI involvement.

Install Mechanism

No install spec and no code files — instruction-only skill. Nothing will be written to disk or downloaded during install, so there is no installer-related risk.

Credentials

The skill does not request any environment variables, credentials, or config paths. Guidance about repository context is proportionate to the skill's purpose and the files explicitly say not to read secrets (e.g., .env).

Persistence & Privilege

The skill is not marked always:true and does not request persistent system presence or modify other skills. It is user-invocable and may be invoked autonomously by the agent (platform default), which is expected for a guidance skill.

Assessment

This skill is a collection of best-practice instructions and templates for authoring PRs and is internally consistent. Before installing or enabling it: 1) Confirm your agent won't be given automatic write/push permissions to repositories you care about (the skill doesn't request credentials, but an agent could be granted repo access separately). 2) Never use the skill to collect or share private secrets or .env contents—its docs explicitly forbid that. 3) If you plan to let the agent act autonomously, decide whether you want any automatic pushes/PR openings enabled and review prompts/logs before sending them to third parties. Otherwise, this skill appears safe and aligned with its stated purpose.

When to Use

Before creating or suggesting a pull request to ANY repository. Acts as a quality filter to prevent wasting maintainer time and embarrassing the contributor.

Quick Reference

Domain	File
Pre-submission checklist	checklist.md
Red flags to avoid	red-flags.md
Repository context gathering	repo-context.md
PR description templates	templates.md

Critical Rules

• Read CONTRIBUTING.md first — Adapt to project's workflow, not a fixed pattern
• Issue policy depends on scope — Small fixes may PR directly; features need discussion first
• Disclose AI involvement — Mark AI-assisted PRs in title/description
• Run checks if possible — If you can't run tests, say so explicitly
• Match existing style — Check for .editorconfig, prettier, eslint configs
• Small and focused — One logical change per PR
• No secrets ever — Use <PLACEHOLDER> syntax

Issue Policy (Contextual)

NOT all projects require issues first. Check CONTRIBUTING.md, then:

Change Type	Default Action
Typo, small bug fix	PR directly (unless CONTRIBUTING.md says otherwise)
New feature	Open Discussion/Issue first, wait for approval
Architecture change	RFC or Discussion required
When in doubt	Ask in issue before coding

AI-Assisted PRs

If this PR was created with AI assistance:

1. Mark it — Add [AI-assisted] to PR title or note in description
2. Testing level — State: untested / lightly tested / fully tested
3. Include context — Prompts or session logs if available and helpful
4. Confirm understanding — "I have reviewed this code and understand what it does"
5. Human accountable — Link to the human directing the contribution

Rate Limiting (Avoid Spam)

• MAX 1 open PR per repo at a time
• Wait 24h between PRs to same repo
• If 2 PRs rejected consecutively → STOP and escalate to human
• Check repo's PR velocity first (don't flood low-activity projects)

Abandonment Prevention

• MUST respond to review feedback within 48h
• If unable to address feedback, close with: "I cannot continue; @human please take over or close"
• Never leave PRs to rot

Scope Boundaries — STOP and Discuss First If:

• Change touches >5 files OR >200 lines
• Change modifies public API
• Change involves security, auth, or crypto
• Change is in governance, licensing, or CoC
• Maintainer requested discussion in issue
• You're unsure if this aligns with project philosophy

Human Escalation Required

Escalate to human when:

• Reviewer asks clarifying questions about design intent
• CI fails in non-obvious way
• Any pushback beyond "fix this typo"
• Reviewer seems confused or frustrated
• You can't run the test suite locally