GitHub Copilot CLI as a PR-triage co-pilot: how I keep up with 40+ upstream orgs

Drafted for the GitHub Copilot Challenge (opens May 21). Will add the official devchallenge tag once the challenge announcement is live.

For the last 18 months I have been running a small one-person open-source program: meaningful PRs across Anthropic, OpenAI, Google, Microsoft, NVIDIA, AWS repos, plus 20-something smaller projects in the MCP and LLM tooling space. The math gets bad fast. You cannot keep 40 repos warm in your head; the cost of context-switching is what kills throughput, not the typing.

GitHub Copilot CLI is the one tool that has actually moved that number for me. Not for writing code: I write most of the code by hand. For navigating code I have never seen before in repos I have just cloned. Below is the workflow that survived two iterations and the prompts I keep coming back to.

The triage loop

When a triage candidate comes in (an issue I tagged earlier, a thread I bookmarked, a TODO I left in a fork), I run roughly this sequence:

# 1. Fast skim: what is this repo, where is the meat?
gh copilot suggest "explain the architecture of this repo from the top-level dirs"

# 2. Locate the file the issue is about, without grepping for an hour
gh copilot suggest "where is the streaming response handler in this repo?"

# 3. Once the file is in front of me, ask copilot to make sense of the
# function I am staring at, not in general but specifically
gh copilot explain "this function" -- src/streaming/handler.py:412-510

# 4. Stage a small, surgical patch and have copilot sanity-check it
gh copilot suggest "review this diff for correctness and side effects"

Three prompts and a diff review is what 80% of my PRs look like in practice. The remaining 20% are the ones where Copilot is wrong (or I am) and I have to slow down. Those are the PRs that ship the most value.

What Copilot CLI is genuinely good at

Mapping a repo I have never read. I ask "what does this repo do" and get a 6-line summary that is correct often enough to be load-bearing. Saves the 20 minutes of skimming I used to do.

Pointing at the right file by description. "Where is the rate limiter implemented?" gets me a path in seconds. The path is right 9 times out of 10. The one time it is wrong, the wrong path is at least adjacent, and that adjacency is itself a clue.

Translating between languages I do not have in working memory. I ship to Python, TypeScript, and Rust regularly. I can write all three fluently but I context-switch slowly. gh copilot suggest "what is the TypeScript equivalent of this Rust pattern" lets me carry an idea between languages without re-reading the syntax for ? operator semantics for the seventh time.

Generating the boring 80% of a CI workflow. GitHub Actions YAML is one of the worst per-keystroke languages I know. Copilot CLI gives me a YAML that is right enough to commit and tweak. The first version is rarely the final version, but it is closer than mine would have been from a blank file.

What it is not good at

Anything that needs to reason about cross-file state. Copilot CLI sees one snippet at a time. If your refactor touches three files and the question is "what breaks downstream," ask a human or a tool with broader context.

Telling you which of two patches is better. I asked Copilot to evaluate two patches I had written against the same issue. It picked the worse one, because the worse one looked tidier in the diff. Aesthetic correctness, not behavioral correctness. Copilot is great for shape, bad for taste.

Replacing your understanding of the codebase. This is the trap. The first month I used Copilot CLI for triage, I shipped a PR that touched a part of the codebase I had not actually read. The review caught it. I have not made that mistake since, and I will not get away with it again. Use Copilot to find the code; do not use Copilot to avoid reading the code.

Concrete win: a 47-second triage

The fastest triage I have had was an open issue on a popular Python MCP SDK. Repo new to me. Issue: a streaming handler dropped final tokens occasionally.

gh repo clone foo/bar && cd bar
gh copilot suggest "where is the streaming response chunked"
# -> src/forem/streaming.py
gh copilot explain "the early-return condition in chunk_iter()" -- src/forem/streaming.py:204-244
# -> "Returns when chunk size is 0, but the producer also emits empty
#     keepalive chunks; the early return ends the stream prematurely."
# Fix:
sed -i 's/if not chunk:/if chunk is None:/' src/forem/streaming.py
gh copilot suggest "write a regression test for keepalive empty-chunk handling"
# -> generates a test that I keep and edit
git checkout -b fix/keepalive-chunks
git commit -am "Don't end stream on empty keepalive chunks"
gh pr create

The PR took 47 seconds to draft. The review took two days. The fix was right.

This is the workflow that the CLI unlocks. Not "write my code for me." It is "tell me where to look so I can spend my brain on the thing only I can do."

Three habits that took me three months to learn

1. Always confirm the path before reading. gh copilot suggest "where is X" is fast and confident, but it can be wrong. Type the path it suggests into your editor and check the file actually contains what you expect. Two-second sanity check.

2. Quote real code into the prompt. "Explain this function" is mediocre. "Explain the early-return at line 204" is targeted. The narrower the prompt, the more useful the answer. Copy-paste the line of code into the prompt; do not summarize it.

3. Treat the first answer as a hypothesis. Copilot will hand you something confident-sounding. The right move is to verify, not to trust. The fastest verifier is the test that should fail before your fix and pass after.

What I still want

A "show me the three places this function is called" command. I know I can gh copilot suggest for it, but a first-class command for cross-file context is the gap between "useful triage tool" and "real refactor partner." If GitHub ships that, I will retire grep -R for half my workflow.

If you are doing OSS contributions across many repos and have not tried gh copilot suggest for repo-mapping, install it once and run it once. It is one apt-install away on Ubuntu, one brew-install on Mac.

gh extension install github/gh-copilot
gh copilot suggest "what is this repo about"

If it sticks, the rest of this post is the playbook.

Happy triaging.