github / github/github-mcp-server

Skill catalog: missing find-prs and find-issues skills

Ouverte
#2,647 1 commentaire 0 réactions 1 personne assignée Réclamée par @SamMorrowDrums Voir sur GitHub
Langage dominant
Go
Étoiles
33k
Forks
5k
Merge moyen
2 j 1 h
PR mergées (30 j)
52

Description

## Context

The github-mcp-server skill catalog exposes `search_pull_requests` and `search_issues` as raw tools, and bundles them inside higher-level skills like `trace-history` and `prepare-release`. There is no dedicated **`find-prs`** or **`find-issues`** skill — i.e. a small, focused skill whose contract is *just* "find PRs/issues matching these criteria, return a list".

## Why this matters

Observed during an external evaluation harness (progressive-disclosure-evals) running model arms against the github-mcp-server skill catalog: when a task is "find recent PRs by author X" or "find issues mentioning Y", the model that browses the skill catalog reliably picks **`search_issues` with `type:pr` qualifiers** rather than `search_pull_requests`. Both go to the same `/search/issues` REST endpoint and are functionally equivalent, but the catalog lacks a discoverable "find-prs" entry point, so the model lands on the more generic `search_issues` path.

This is fine for correctness (it works) but it has two downstream effects:
1. Evaluation rubrics that mention `search_pull_requests` as the expected tool now have to encode that-or-`search_issues` equivalence themselves (we just shipped this as a schema change on our side).
2. Users / agents browsing the skill catalog see no obvious skill for the common "find PRs by author" workflow and have to either reach for `trace-history` (which does more) or improvise with `search_issues`.

## Ask

Consider adding two small skills:

- `find-prs` — find pull requests matching author / repo / label / state / date / keyword criteria. Wraps `search_pull_requests` (or `search_issues type:pr`, doesn't matter which the implementation picks).
- `find-issues` — same shape for issues. Wraps `search_issues type:issue`.

These would be the obvious search-and-list entry points and would resolve the catalog-gap symptom described above.

## Out of scope

I'm not asking you to change `search_issues` / `search_pull_requests` themselves, or to deprecate anything. This is purely about a discoverability gap in the higher-level skill layer.

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.