github / github/github-mcp-server

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

Abierto
#2,647 1 comentario 0 reacciones 1 asignado Reclamado por @SamMorrowDrums Ver en GitHub
Lenguaje dominante
Go
Estrellas
33k
Forks
5k
Merge medio
2 d 1 h
PR fusionados (30 d)
52

Descripción

## 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.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.