PR #482: Add rate limiting to /api/orders
New middleware caps requests per API key. Needs review of edge cases around burst traffic and Redis key expiry.
Track every pull request from open to merged
The Code Review Board gives engineering teams a clear, four-column view of pull request status: what's waiting on a reviewer, what needs changes, what's approved, and what's already merged. Instead of scanning a crowded PR list on your git host, your team (and any connected coding agent) can see at a glance where every review stands. Built for use with the MCP server, this board lets agents create tasks the moment a PR opens and move them through review automatically, while human reviewers use the kanban board, keyboard shortcuts, or command palette to triage quickly. It's a lightweight companion to your existing git workflow, not a replacement for the diff itself.
Template preview
Pull requests that are open and waiting for a first pass from a reviewer.
PR #482: Add rate limiting to /api/orders
New middleware caps requests per API key. Needs review of edge cases around burst traffic and Redis key expiry.
PR #489: Migrate auth service to async handlers
Converts blocking calls to async/await. Reviewer should check for missed error handling in the token refresh path.
PR #491: Fix flaky checkout integration test
Adds explicit waits and retries. Confirm the fix addresses root cause instead of masking timing issue.
Tasks where a reviewer left feedback and the author needs to push updates before re-review.
PR #470: Refactor pricing calculator
Reviewer flagged missing unit tests for discount stacking logic. Waiting on author to add coverage.
PR #475: Update onboarding email templates
Copy approved but reviewer requested extraction of hardcoded strings into the i18n config file.
Pull requests that passed review and are cleared to merge once CI is green.
PR #465: Add dark mode toggle to settings page
Two approvals received. Waiting on final CI run before merge.
PR #468: Bump dependency versions for security patch
Approved by security lead. Merge after confirming no breaking changes in staging.
Pull requests merged into the base branch, kept briefly for reference before cleanup.
PR #452: Add pagination to admin user list
Merged to main. Deployed to staging for verification.
PR #459: Remove deprecated v1 webhook endpoint
Merged and confirmed no active integrations were broken.
Step 1
A PR is opened and a task is created in Needs Review with the PR link and a short summary of the change.
Step 2
A reviewer examines the diff; if changes are needed the task moves to Changes Requested with notes, otherwise it advances toward Approved.
Step 3
The author addresses feedback and requests re-review, moving the task back to Needs Review or directly to Approved once resolved.
Step 4
Once approvals are collected and CI passes, the task moves to Approved and merge is cleared.
Step 5
After merging, the task moves to Merged and is deleted or archived during the weekly cleanup to stay under the task limit.
AI agent usage
This board gives coding agents and human reviewers a shared source of truth for pull request status. An agent connected via the MCP server can create a task the moment a PR opens, move it across columns as review feedback comes in, and flag merge readiness without anyone touching the git host UI. Because column names are fixed and descriptive, an agent only needs to read the board once (get_board) to know exactly where a task belongs at each stage of the review lifecycle.
## Code Review Board (MCP)
Columns: `Needs Review` -> `Changes Requested` -> `Approved` -> `Merged`.
- When a new pull request is opened, call `create_task` with the PR title and link, placing it in `Needs Review`.
- When a reviewer requests changes, call `move_task` to `Changes Requested` and append reviewer comments via `update_task`.
- When all required approvals are collected, call `move_task` to `Approved`.
- After the PR is merged into the base branch, call `move_task` to `Merged` and leave the task for the weekly cleanup pass.
- Use `get_task` before moving a task to confirm current column and avoid skipping states.
- Respect the plan limit: free plan allows 1 project and 25 tasks total, so archive or delete merged tasks (`delete_task`) once they age out.Learn more about the board-centric workflow in Kanban for AI Agents or open the MCP guide.
The free plan supports 1 project and up to 25 tasks total, so you can track roughly 25 open or recently merged pull requests before needing to archive Merged tasks or upgrade to pro.
Yes, you can track multiple repos on a single project board by prefixing task titles with the repo name, as long as total tasks stay within your plan's limit.
Yes. Any agent connected to the MCP server can call create_task, move_task, and update_task to reflect PR status changes without a human manually dragging cards.
You'll need to delete or archive completed tasks (typically from Merged) using delete_task, or upgrade to pro for $12/mo or $96/yr to remove the task cap.
No, it's a lightweight status tracker. Keep the actual diff and comments in your git host; use this kanban board, via the macOS app, command palette, or MCP server, to track review stage at a glance.
Ready to create this board?
Sign in and use the template to create a project with columns and sample tasks.