Takes review notes you've already worked out — the issues, not the raw diff — and turns them into 5 polished GitHub PR comments ready to post. Each one stays direct without being harsh, names the specific issue, explains its impact, and suggests a fix, capped at 80 words so reviewers actually read it. Useful when you already know what's wrong and just want the wording tightened before publishing.
A fixed, project-specific checklist for reviewing changes in a React/TypeScript plus FastAPI/Python codebase, not a generic "review this code" prompt.
- Frontend: React Flow node patterns, Zustand store selectors, design tokens
- Backend: Pydantic model layering, FastAPI auth dependencies, response models
- Also covers security, performance, test coverage, docs, and commit hygiene
- Reach for it before merging, to keep reviews consistent across the team
A reusable context block to paste at the start of any AI coding session, covering your stack, key files, conventions, and known constraints so replies stop being generic.
- Fill in project name, stack, main/config files, and naming/testing conventions once
- Lists known constraints like performance limits and technical debt to work around
- Save it as a markdown file and refresh it weekly as the project changes
- Re-paste key facts mid-session on long threads to keep the AI anchored
Turns a pasted directory tree into a guided tour of an unfamiliar codebase, aimed at whoever is starting fresh or inheriting legacy code.
- Identifies the architecture pattern, entry points, and the 5 most important files
- Traces data flow, external dependencies, and maintenance red flags
- Points to exactly which files to open first for a stated task
- A follow-up step explains any single pasted file in depth: role, dependents, gotchas
Built for the PR that looks trivial in the diff but quietly changes an assumption something downstream relies on.
- Flags changed assumptions, edge cases, and null/empty handling
- Checks off-by-one logic, state transitions, and API contract drift
- For each issue: what changed, what it could break, and the smallest test that would have caught it
Reviews a pasted diff the way a security-focused application engineer would, prioritizing auth and authorization checks, input validation, secret handling, injection risks, unsafe defaults, and data exposure over general code quality. Every finding is labeled a confirmed vulnerability, a plausible risk, or something needing manual verification, and it won't speculate beyond what the code shows. Reach for it on changes touching permissions, secrets, or user input.
Fill in the feature you want built, the language, and up to three specific requirements, and get an implementation request structured enough that nothing important gets skipped. It explicitly asks for error handling, edge cases, performance, and framework best practices to be considered up front, and instructs the output to keep existing comments intact and explain its own logic inline.
Reviews a PR the way a strict test reviewer would when the code looks fine but the test coverage feels shaky. It calls out missing negative and boundary tests, gaps in integration coverage, flaky test risks, and spots where implementation changed but the matching tests didn't. Returns the critical missing tests first, then useful additional ones, described as sample test cases in plain English.
Summarizes a pasted diff in exactly three bullets for a reviewer who has never seen this codebase: what changed, why it changed, and what could go wrong.
It's built to name real classes, functions, and file paths rather than describe changes abstractly, and it doubles as a scope check — if the diff can't be summarized in three concrete bullets, the PR is probably too big.