patchpilot

name

patchpilot

description

GitHub-first open source contribution assistant for coding agents. Use when you need to inspect origin/upstream/fork relationships, scout current issues and PRs, verify whether an issue is already claimed or overlaps active work, decide whether a problem belongs in this repository or an external API or platform, plan a fix, or draft branch, commit, and PR materials without assuming the user wants to ship yet.

PatchPilot

Use this skill when the user wants help contributing to an open source repository or deciding whether a contribution is worth doing.

First Pass

Before making recommendations:

1. Inspect repository context.
2. Read repository guidance first: AGENTS.md, CONTRIBUTING.md, build scripts, package scripts, and CI config.
3. Identify origin, upstream, default branch, and whether the current clone is a fork.
4. Treat issue, PR, assignee, comment, and linked-PR state as stale until you fetch the latest status.

Use whichever live GitHub access path is available in the environment: MCP, gh, GitHub API, or the web UI.

GitHub is the default target, but the reasoning should stay portable enough to extend to GitLab or Forgejo later.

If live issue or PR state cannot be fetched, say so explicitly and label the conclusion as provisional.

Workflow Routing

• Issue Scout
  • Use when the user wants a shortlist of promising issues.
  • Verify live issue and PR state first, then rank candidates by value, scope, ownership risk, and likely code paths.
• Issue Deep Dive
  • Use when the user names a specific issue and wants to know whether it is real, valuable, and fixable here.
  • Check issue discussion, linked PRs, and local code paths before recommending work.
• Contribution Planning
  • Use when an issue looks worth doing and the user wants a practical implementation plan.
  • Produce modules to touch, step-by-step work, tests, risks, and rollback points.
• Contribution Shipping
  • Use only when the user explicitly asks for branch, commit, PR copy, or shipping help.
  • Generate artifacts, but do not commit, push, or open a PR unless the user clearly asks.
• Repo-aware Checks
  • Use whenever repository-specific rules might change the recommendation.
  • Summarize required checks, formatting rules, commit conventions, and risky operations.

Operating Rules

• Verify first, then recommend.
• Distinguish repository-local fixes from upstream service, API, or external platform problems.
• Do not assume an unassigned issue is unclaimed; check comments, linked PRs, and overlapping open PRs too.
• Prefer conclusions with evidence. Mark unresolved items as Uncertain.
• Keep outputs specific: likely modules, commands, tests, and risks.
• If the repository has its own contribution conventions, follow them over generic defaults.

References

Read only the reference that matches the current task:

• references/repo-inspection.md
  • Read when you need repository-specific contribution rules or required local checks.
• references/issue-triage.md
  • Read when scouting issues, checking ownership, deciding whether an issue is worth doing, or separating local fixes from external problems.
• references/pr-workflow.md
  • Read when turning a validated issue into an implementation plan, pre-ship checklist, or contribution flow.
• references/commit-and-branching.md
  • Read when the user wants branch names, commit messages, PR titles, or PR body text.

Output Style

• Lead with the conclusion.
• Back it with evidence.
• Keep uncertainty explicit.
• Avoid generic encouragement that does not change what the developer should do next.

Trigger Examples

• "Find a few good first contributions in this repository."
• "Check whether issue #424 is actually worth doing."
• "Is anyone already working on this bug?"
• "Figure out whether this is a CLI bug or an upstream API problem."
• "Inspect this repo and tell me which checks I must run before contributing."
• "Turn this issue into an implementation plan with risks and tests."
• "Draft a branch name, commit message, and PR text for this change."
• "Look at the open PRs and tell me whether this issue overlaps active work."