When I give an agent an issue, I want it to follow the context before writing code.
The issue might link to a Slack conversation. That conversation might contain a video showing the bug. The discussion might explain why an earlier fix was rejected. Reading only the issue description leaves out information that could change the whole approach.
I've been building tools and skills to make that process repeatable, then extending it through implementation and PR review.
Watch the 10-minute workflow walkthrough.
Follow the context
In The Complete Guide to pstack Pt. 2, Lauren, who posts as @poteto, describes two failure modes she observes: agents don't fully understand poorly specified intent, and they lack context to do the work correctly.
One technique she describes is asking the agent to read a Slack thread and restate the underlying issue in plain English. That gives her a chance to catch a misunderstanding before the agent starts coding.
In my workflow, gathering context means following the relevant references:
- Read the issue and its comments.
- Inspect attachments, including images, videos, and documents.
- Read linked conversations and related PRs.
- Check the relevant code against what people reported.
Connecting an MCP can provide access to these sources. What happens next depends on the connector, the agent, and the tools available. I want explicit steps for reading the material, including a clear report when something couldn't be accessed.
For example, my video-reading skill uses frame inspection and audio transcription. It can become part of a larger issue-reading workflow. The parent skill follows the attachment; the smaller skills handle the media. I explain that composition in The real power of skills is composition, using the same video-reading example.
Deep context means following the evidence that matters. It doesn't mean loading every conversation in the company into the context window. I want the agent to bring back the problem, the supporting evidence, and the unanswered questions.
Check what belongs in the product
Understanding a request doesn't tell the agent whether we should build it.
Before implementation, I want it to know three things:
- What do we build?
- Why does it exist?
- What don't we own?
You can document this in a README, AGENTS.md, or a dedicated PRODUCT.md. The instructions need to tell the agent where to find it and when to read it.
Some context belongs closer to the code. In Comments only matter when the code doesn’t, I tested comments that explain rules the code itself doesn’t express. In that small benchmark, placing the rule near the edit mattered.
For example, a request might be real but belong in an upstream library. Or it might describe a useful feature that falls outside the current scope. I want that distinction made before the agent starts adding code.
Give the agent a goal and a way to check its work
Once the request is understood and in scope, I give the agent a clear outcome and have it work in small steps:
Make a small change → Run the relevant checks → Compare with the goal
For a bug, that might mean reproducing the failure, making a fix, and showing that the same reproduction now passes. For a UI change, it might include running the app and checking the actual interaction.
The tools matter here too. Asking an agent to verify a change is only useful if it can run the checks that would expose a mistake. A confident explanation isn't enough.
I keep the goal and progress in a file so the work can continue across sessions. The next step should come from what's still missing, rather than a fresh guess about the task.
Follow the PR after opening it
- Address valid review comments
- Pass CI checks
- Resolve conflicts
Opening a PR creates more work: reviews arrive, checks fail, and other changes can introduce conflicts.
I give each PR an owner to follow those changes. It investigates review findings before acting, fixes failures related to the branch, and checks the updated commit again. An unrelated runner failure needs a different response from a failing test caused by the change.
OpenAI's babysit-pr skill is another concrete example. It checks reviews, CI, and mergeability, distinguishes branch problems from infrastructure failures, and keeps watching for new feedback. It also defines when user help is needed.
When several PRs are open, I delegate each PR to a subagent and use the main session to coordinate. A background monitor handles waiting for updates; the PR owner handles the work those updates reveal. For stacked PRs, the coordinator also has to account for dependencies between changes.
Auto-merge can finish the process once the repository's required checks and reviews pass. When something is blocked or needs a decision, I want the agent to say exactly what's missing.
Start with one missing capability
You don't need my whole setup to use this approach.
Pick one place where you're repeatedly stepping in. Maybe the agent skips video attachments. Maybe it starts coding before understanding the product. Maybe it opens a PR and leaves you to follow CI.
Give it the tools and instructions for that step, then try it on a real task. Check what it read, what it changed, and how it verified the result before adding more automation.