github / github/github-mcp-server

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

Aberta
#2,647 1 comentário 0 reações 1 responsável Reivindicada por @SamMorrowDrums Ver no GitHub
Linguagem predominante
Go
Estrelas
33k
Forks
5k
Merge médio
2d 1h
PRs com merge (30d)
52

Descrição

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

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.