github / github/github-mcp-server

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

Đang mở
#2,647 1 bình luận 0 reaction 1 người được giao Được @SamMorrowDrums nhận Xem trên GitHub
Ngôn ngữ chính
Go
Star
33k
Fork
5k
Merge trung bình
2 ngày 1 giờ
Pull request đã merge (30 ngày)
52

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.