القائمة
Use when PR review comments need to be analyzed for validity, evaluated for interest, and implemented with test-first approach where the change alters behavior
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create or update a GitHub PR for the current branch. It handles branch creation from main, rebases the full branch chain up to main, pushes with --force-with-lease, and generates a PR with a smart title and description focused on business rules and architecture changes. It can also screenshot the affected UI if the change touches frontend code.
Implement features and bugfixes using strict outside-in TDD. Each cycle traces back to requirements and design docs when available. It includes a deliberate refactoring phase and generates integration tests when a vertical slice is complete. It wires up BDD step definitions when feature files exist. It can receive a Linear issue as input, rebuilds docs (requirements, design, plan) from the issue into the repo before coding, and graduates them into permanent knowledge after the implementation is complete.
Create an implementation plan for an initiative. It references specific requirements and design decisions from docs/requirements/ and docs/design/, produces a plan in docs/plans/, and generates test cases traced back to requirements. It bridges "what to build" and "building it."
Record a "before/after" walkthrough video pair for a PR using Playwright. Trigger when the user asks to record a PR video, demo a fix, capture a UI walkthrough, or produce reviewer-facing media for a frontend or workflow change. Produces narrated mp4 (preferred for browser drag-drop into a PR description) and gif (committable to the repo so no browser is needed). Follows the team visual standard.
Split requirements, design specs, and plans into self-contained Linear issues targeting ~200-300 LOC each. It reads from the project's docs/requirements/, docs/design/, and docs/plans/, creates issues with the full spec embedded in the body, tags them with "agent issue", and creates an epic parent issue when more than two issues are generated. It deletes the repo docs files after the issues are created.
Review a PR or diff for architectural quality - SOLID principles, codebase consistency, dependency direction, error handling, data flow, test architecture, performance, and security. It reads the code review output for context, checks alignment with design docs, and produces actionable findings for the coding agent to fix.
| name | implement-review |
| description | Use when PR review comments need to be analyzed for validity, evaluated for interest, and implemented with test-first approach where the change alters behavior |
| user_invocable | true |
| allowed-tools | Bash(*), Read, Grep, Glob, Agent, AskUserQuestion, Edit, Write |
| argument-hint | [PR number, branch name, or pasted review comments] |
This skill takes PR review feedback, evaluates each comment for technical validity, and implements the accepted changes with tests where possible. It does not blindly comply - it pushes back when a suggestion is wrong, and it includes nice-to-haves when they genuinely improve the code.
Argument: $ARGUMENTS
$ARGUMENTS can be one of:
When no argument is provided (or it is "current"), detect the current branch's PR:
gh pr view --json number,title,body,baseRefName,headRefName,url
If no PR exists for the current branch, tell the user and stop.
For PR-based input:
gh pr view $PR --json number,title,body,baseRefName,headRefName,urlgh api repos/{owner}/{repo}/pulls/{number}/commentsgh api repos/{owner}/{repo}/pulls/{number}/reviewsgh pr diff $PRCollect all comments into a single list. For each comment, note the file, line, the reviewer's suggestion, and the comment ID (needed for replying later).
Before evaluating any comment:
git log --oneline -10 <file> for each affected file.docs/codebase-learnings.json if it exists, filtered by relevant tags (use jq to filter by tags matching the changed file areas).For each review comment, answer two questions:
If you cannot easily verify whether a suggestion is correct, say so. Do not guess.
For "nice to have" items, lean toward implementing. If the suggestion improves readability, robustness, or maintainability, it is worth doing.
Before implementing anything, present the full evaluation:
MUST FIX:
1. [file:line] <what to change and why you agree>
NICE TO HAVE (will implement):
2. [file:line] <what to change and why it is worth doing>
NICE TO HAVE (will skip):
3. [file:line] <what was suggested and why it is not worth doing>
DISAGREE:
4. [file:line] <what was suggested, why you disagree, and what you checked>
Wait for the user to approve, adjust, or override before proceeding.
Work through the accepted changes one at a time. For each change:
RED - Write a test that captures the expected behavior after the change. Run it. Confirm it fails for the right reason (the behavior is not implemented yet), not because of a typo or import error.
GREEN - Implement the minimal change to make the test pass. Do not fix other things.
REFACTOR - Clean up if needed. Run tests again to confirm everything is still green.
Add a traceability comment on the test:
# Review: <brief description of what the reviewer flagged>
def test_<descriptive_name>():
...
Implement directly. These are mechanical changes that do not alter behavior.
Run the related tests to confirm nothing broke. Do not batch multiple changes before running tests.
For each comment, draft a reply based on the commenter and the outcome:
No performative language. No "Great catch!", "You're right!", or "Thanks for flagging!". Be direct but respectful, especially with humans.
Present the replies to the user for review before posting them.
Summarize:
Wait for the user to review before committing.
After the commit lands, Steps 7 and 8 are MANDATORY — do not consider the skill complete until both are done. If the user pivots to a new task (another skill, a deploy, a code review), complete the pivot in whatever way the user wants, then return here and finish Step 7 and Step 8 before reporting done. Do not ask permission to finish them; the user already approved the implementation in Step 3, and posting replies + resolving threads is the baseline expected behavior for any review-implementation flow.
After all changes are committed, rebase the branch onto the PR's base branch (usually main) to keep the history clean:
git fetch origin <base>git rebase origin/<base>git push --force-with-leaseThis ensures the PR stays up to date and avoids merge commits. Use --force-with-lease (never --force) to avoid overwriting changes someone else may have pushed.
After the user approves, post the replies and resolve comment threads on GitHub.
For each comment, decide whether to reply based on the resolution rules from Step 5:
Post replies using:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies -X POST -f body="<reply>"
After replying, resolve all threads that are done (implemented, or bot-disagree). First, fetch the thread IDs:
gh api graphql -f query='
{
repository(owner: "{owner}", name: "{repo}") {
pullRequest(number: {pr_number}) {
reviewThreads(first: 50) {
nodes {
id
isResolved
comments(first: 1) {
nodes { databaseId }
}
}
}
}
}
}'
Match each thread to its comment ID, then resolve it:
gh api graphql -f query='
mutation {
resolveReviewThread(input: {threadId: "<thread_id>"}) {
thread { isResolved }
}
}'
When to resolve:
| Commenter | Outcome | Reply? | Resolve? |
|---|---|---|---|
| Bot | Implemented | Yes | Yes |
| Bot | Disagree (nonsensical) | No | Yes |
| Bot | Skip (valid point) | Yes | Yes |
| Human | Implemented | Yes | Yes |
| Human | Disagree or skip | Yes | No (leave open for discussion) |
Note: GitHub auto-resolves threads when the commented lines change in a new push. If threads are already resolved after the force-push, skip the resolve step for those and just post the reply.
| Excuse | Reality |
|---|---|
| "Reviewer is senior, so they must be right" | Seniority does not override codebase reality. Verify. |
| "Too small to test" | If it changes behavior, test it. It takes 30 seconds. |
| "I will test after implementing all changes" | Test each change individually. Batching hides regressions. |
| "The reviewer probably knows more context" | Maybe. Or maybe they missed something. Check. |
| "Disagreeing is confrontational" | Technical pushback with evidence is professional. Blind compliance is not. |
| "Nice to have means skip" | Nice to have means evaluate. If it improves the code, do it. |
| "I will just implement everything to be safe" | Implementing wrong suggestions introduces bugs. Evaluate first. |
| "Let me batch the replies" | Reply per comment, one at a time. Each deserves its own reasoning. |
The skill is complete only when every item below is true. Run through this list explicitly at the end. If the user redirects you to another task mid-flow (another skill, a deploy, a code review), do the redirect, then come back and finish this list before declaring the overall task done.
# Review: <reason> traceability comment, and the tests pass.--force-with-lease.gh api repos/{owner}/{repo}/pulls/{pr}/comments and diff against the comment IDs you evaluated in Step 3.resolveReviewThread mutation, except human-disagree/skip threads (left open for human discussion). Verify with the reviewThreads GraphQL query and check isResolved is true for each target thread.If you are unsure whether you completed a step, re-run the verification query. Do not assume. "I think I replied to all of them" is the failure mode this checklist exists to prevent.