github / github/github-mcp-server

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

未關閉
#2,647 1 則留言 0 個 reaction 已指派 1 人 已被 @SamMorrowDrums 認領 在 GitHub 檢視
主要語言
Go
星號
33k
分支
5k
平均合併
2 天 1 小時
30 天內合併 PR
52

描述

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

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。