Okay, so I have to share this workflow I just cemented because the efficiency gain is honestly a little ridiculous. 😅 We all know the pain: you jump into a new codebase or even just a new feature area in your own repo, and you're asking the assistant about patterns, or to draft something, but you spend half your prompt just pasting in relevant file paths and explaining recent changes.
I was manually copying PR descriptions and diff highlights like a chump. Not anymore.
My new setup automatically pulls the last 5 merged Pull Requests (title, description, and the list of changed files) and injects them as context at the start of every coding session with my assistant. The difference in contextual awareness is night and day.
Here’s the recipe breakdown:
* **The Core Idea:** Before starting a deep work session, I run a local script that fetches PR context from GitHub. This gives the AI a perfect "what have we been doing lately" briefing.
* **My Toolstack:** I use the GitHub CLI (`gh`) because it's simple and I'm already authenticated. The script is just a shell script that I run in my terminal, and it outputs a beautifully formatted text block.
* **The Workflow:**
1. Navigate to my project repo in terminal.
2. Run my command: `./pr-context.sh` (or I have it aliased to `ctx`).
3. It spits out the last 5 PRs with a clear separator.
4. I copy that entire block and paste it right into my assistant's custom instructions/context window for the session.
The script essence (conceptual, since we don't use code blocks here) is using `gh pr list --state merged --limit 5` to get the numbers, then looping to get each PR's details with `gh pr view --json title,body,files`. I format it cleanly with headers.
**The value is so concrete:**
- No more "we recently added a notification service" preamble. The assistant *sees* that PR #42 was "Add Firebase Cloud Messaging layer" and knows the new files.
- Asking for a new function following "existing patterns" actually works now, because it has the last 5 patterns right there.
- Onboarding to a new area is faster. I just did this for a colleague's project, and I was productive in minutes instead of hours.
It's like giving your assistant a short-term memory of the team's momentum. The prompts are sharper, the outputs are more aligned, and I'm not constantly fighting to provide background.
Has anyone else built similar context-harvesting automations? I'm thinking of expanding this to grab recent Jira tickets or Figma comment threads next. The potential for stitching together *project* context, not just code context, feels huge for avoiding siloed thinking.
happy evaluating
Nice hack! I've been doing something similar but feeding the context via a small CLI tool that taps the GitHub API directly. The "last 5 PRs" limit is interesting - found that's the sweet spot before you hit token limits?
How are you handling the output formatting? I pipe mine straight into my prompt template, but sometimes the markdown from PR descriptions gets messy.
Automate everything.
Yeah, the token limit thing is real. I'm still experimenting, but I found that after five PRs, the context starts to get a bit noisy and the main point gets lost.
> sometimes the markdown from PR descriptions gets messy
Totally. I use a simple regex filter to strip out any markdown images or complex tables before injecting. It's not perfect, but it keeps things clean enough. Do you think stripping too much context hurts the results?
Still learning.
You've hit on the core tension of context injection: signal vs. noise. Stripping markdown like images and complex tables is almost always beneficial, as those elements rarely contain semantic value for code generation. The risk isn't there.
The real danger is stripping semantic content that *looks* like noise. I've seen regexes that accidentally remove inline code blocks or error messages wrapped in backticks because they were too aggressive. That directly hurts results.
A more nuanced approach is to define a whitelist of markdown elements to keep, like headers, lists, and code blocks, while stripping everything else. This preserves structure and critical info. Have you considered parsing the markdown to an AST and then reconstituting only the nodes you want? It's more work, but it's precise.
Oh yeah, the token limit is definitely the hard constraint. Five PRs feels right because it usually captures the sprint's active context without blowing past the 10-15k token budget I reserve for this. I've started filtering out PRs that are just dependency bumps or version updates - they add almost no signal.
> How are you handling the output formatting?
I template the output into a condensed format before piping it in. Something like this:
```
PR: {title}
Files: {changed_files}
Summary: {description_first_paragraph}
```
It loses some nuance, but it keeps the token count predictable. The raw markdown from GitHub, especially with checklists and PR templates, was a total token hog.
editor is my home