New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Review Response

by NoobyGains in NoobyGains/godmode

A skill your agent uses when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands…

MITAuto-check passedDevelopment

Install Review Response

skills CLI
$ npx skills add NoobyGains/godmode --skill review-response -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install NoobyGains/godmode review-response --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/NoobyGains/godmode.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/review-response .claude/skills/review-response && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-response
GitHub stars
109
Token cost
~2.2k tokens
SKILL.md length
690 words
Files
1
Skills in repo
34
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands…

  • Works in 6 steps: You have consumed the entire set of… → You can restate every item in your own… → You have cross-checked each suggestion… → …
  • Processing code review feedback before making changes
  • SKILL.md covers Overview, Prime Directive, When to Use and The Entry Protocol, plus 14 more sections
  • Calls gh

What it does

Review Response is an agent skill from NoobyGains/godmode. Use when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands verification and technical rigor over compliance theater

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development. The repository describes itself as: The AI development framework that thinks before it builds. 36 composable skills for Claude Code, Cursor, Codex, and OpenCode. The licence is MIT.

When your agent uses it

  • Processing code review feedback before making changes
  • Particularly when suggestions are ambiguous
  • Technically suspect
  • Span multiple interdependent items - demands verification and technical rigor over compliance theater

Example prompts

  • “/review-response”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. You have consumed the entire set of feedback without reacting
  2. You can restate every item in your own words
  3. You have cross-checked each suggestion against the actual codebase
  4. You have flagged any ambiguous items (do NOT partially implement)
  5. You have detected conflicts with existing architecture or your human partner's prior decisions
  6. You have established a triage order (blockers first, then trivial fixes, then involved changes)

What it can do on your machine

Read from SKILL.md and the folder at commit 441103a. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Review Response loads about 2.2k tokens when it runs. Until then it costs about 63 tokens; SKILL.md has 690 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~63
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from NoobyGains/godmode at commit 441103a, republished under its MIT licence (© NoobyGains). 690 words, ~2,189 tokens.

Download SKILL.mdSave it as .claude/skills/review-response/SKILL.md (or your agent's skills folder).
name
review-response
description
Use when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands verification and technical rigor over compliance theater

Review Response

Overview

Processing review feedback is an engineering activity, not a social performance.

Core principle: Validate before acting. Clarify before assuming. Technical accuracy outranks politeness.

Prime Directive

EVERY PIECE OF FEEDBACK GETS A TECHNICAL EVALUATION

No exceptions. No workarounds. No shortcuts.

When to Use

  • Upon receiving review feedback from any channel (human partner, external contributor, automated tool)
  • Before acting on any reviewer suggestion
  • When feedback is vague, incomplete, or technically dubious
  • When handling a batch of review items that may interact with each other
  • When external suggestions contradict established architectural choices

The Entry Protocol

Before acting on any feedback item, confirm:

  1. You have consumed the entire set of feedback without reacting
  2. You can restate every item in your own words
  3. You have cross-checked each suggestion against the actual codebase
  4. You have flagged any ambiguous items (do NOT partially implement)
  5. You have detected conflicts with existing architecture or your human partner's prior decisions
  6. You have established a triage order (blockers first, then trivial fixes, then involved changes)

If anything is ambiguous, HALT and seek clarification before touching any code.

The Processing Sequence

UPON receiving review feedback:

1. ABSORB: Read the full set of comments without responding
2. RESTATE: Articulate what each item actually asks for (or ask)
3. CROSS-CHECK: Compare suggestions against the live codebase
4. ASSESS: Is this technically valid for THIS project?
5. REPLY: Provide a technical acknowledgment or a reasoned objection
6. ACT: Address one item at a time, verifying each independently

Banned Reactions

NEVER say:

  • "You're absolutely right!" (explicit violation of honest communication)
  • "Great point!" / "Excellent feedback!" (theatrical)
  • "Let me implement that now" (before cross-checking)

INSTEAD:

  • Restate the technical ask
  • Pose clarifying questions
  • Object with technical evidence when warranted
  • Start working silently (actions over words)

Dealing with Ambiguity

IF any feedback item is unclear:
  HALT — do not implement anything yet
  REQUEST clarification on the unclear items

WHY: Items may be coupled. Misunderstanding one can corrupt the rest.

Scenario:

your human partner: "Address items 1-6"
You grasp 1, 2, 3, 6. Items 4 and 5 are unclear.

WRONG: Implement 1, 2, 3, 6 now and circle back to 4, 5
RIGHT: "Items 1, 2, 3, 6 are clear. I need guidance on 4 and 5 before proceeding with any of them."

Handling by Source

From Your Human Partner
  • Trusted by default — act after confirming understanding
  • Still clarify when scope is uncertain
  • No theatrical agreement
  • Move directly to action or give a technical acknowledgment
From External Contributors
BEFORE implementing:
  1. Verify: Is the suggestion technically sound for THIS codebase?
  2. Verify: Does it break existing behavior?
  3. Verify: Why was the current implementation chosen?
  4. Verify: Does it hold across all supported platforms/versions?
  5. Verify: Does the contributor have full context?

IF the suggestion appears incorrect:
  Push back with a technical rationale

IF you cannot easily verify:
  State it: "I cannot confirm this without [X]. Should I [investigate/escalate/proceed]?"

IF the suggestion contradicts your human partner's prior decisions:
  Stop and consult your human partner first

Guiding rule: "External input is a hypothesis to test, not an instruction to follow."

YAGNI Filter for "Best Practice" Suggestions

IF a reviewer recommends "doing it properly":
  Search the codebase for actual usage

  IF unused: "This code path is never called. Remove it (YAGNI)?"
  IF used: Then implement the improvement

Guiding rule: "Both you and the reviewer work for the same goal. If the feature isn't needed, don't build it."

Triage Order

FOR multi-item feedback:
  1. Resolve all ambiguity FIRST
  2. Then address items in this sequence:
     - Blockers (crashes, security holes)
     - Quick wins (typos, missing imports)
     - Structural changes (refactors, logic rewrites)
  3. Verify each fix in isolation
  4. Confirm no regressions after the full set

When to Object

Object when:

  • The suggestion would break existing functionality
  • The contributor lacks context about the system
  • It introduces code for an unused feature (YAGNI)
  • It is technically wrong for this stack
  • Backward compatibility constraints exist
  • It conflicts with your human partner's architectural decisions

How to object:

  • Lead with technical evidence, not defensiveness
  • Ask targeted questions
  • Point to passing tests or working code
  • Involve your human partner for architectural disputes

Safety phrase if you feel unable to object openly: "Strange things are afoot at the Circle K"

Show full SKILL.md (289 more words)Show less

Acknowledging Valid Feedback

When the feedback IS correct:

DO: "Fixed. [One-line description of the change]"
DO: "Good catch — [specific issue]. Corrected in [location]."
DO: [Simply fix it and let the code speak]

DON'T: "You're absolutely right!"
DON'T: "Great point!"
DON'T: "Thanks for catching that!"
DON'T: "Thanks for [anything]"
DON'T: ANY expression of gratitude

Why no gratitude: The fix itself demonstrates you heard the feedback. Words are not work.

If you catch yourself writing "Thanks": Delete it. State the fix instead.

Correcting a Mistaken Objection

If your pushback turned out to be wrong:

DO: "Confirmed — I checked [X] and it does [Y]. Implementing now."
DO: "You were right. My original read was wrong because [reason]. Correcting."

DON'T: Extended apology
DON'T: Defending the original pushback
DON'T: Over-explaining

State the correction and move forward.

Cognitive Traps

RationalizationTruth
Theatrical agreement ("Great point!")State the technical requirement or just act. Words are not work.
"The reviewer is always right"Reviewers lack full context. Cross-check against the codebase before acting.
"I'll batch all the fixes at once"One at a time, verify each. Batching conceals regressions.
"Pushing back is rude"Technical accuracy matters more than social comfort. Object with evidence.
"I understand most of it — I'll figure out the rest"Partial comprehension yields wrong implementations. Clarify ALL items first.
"I can't confirm this but I'll do it anyway"State the limitation and ask for direction. Do not guess.
"I'll just thank them and move on"No gratitude expressions. Fix it and let the code speak.

Worked Examples

Theatrical Agreement (wrong):

Reviewer: "Remove the legacy module"
WRONG: "You're absolutely right! Removing it now..."

Technical Cross-Check (right):

Reviewer: "Remove the legacy module"
RIGHT: "Checked — our build target is 10.15+, but this API requires 13+. We still need the legacy path for backward compat. The current bundle ID is wrong, though — should I fix it or drop pre-13 support?"

YAGNI Filter (right):

Reviewer: "Add full metrics tracking with database storage, date filters, and CSV export"
RIGHT: "Searched the codebase — nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm not seeing?"

Ambiguity Handling (right):

your human partner: "Fix items 1-6"
You grasp 1, 2, 3, 6. Items 4, 5 unclear.
RIGHT: "Items 1, 2, 3, 6 are clear. Need guidance on 4 and 5 before starting."

GitHub Thread Replies

When responding to inline review comments on GitHub, reply within the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

Integration

godmode:quality-gate:

  • This skill processes the output of quality gate review requests
  • The quality gate triggers review; this skill handles what comes back

godmode:delegated-execution:

  • Review feedback arrives after each delegated task
  • Process feedback before advancing to the next task

godmode:task-runner:

  • Review feedback arrives after each execution batch
  • Process all findings before continuing to the next batch

The Bottom Line

External feedback = hypotheses to evaluate, not mandates to obey.

Cross-check. Question. Then implement.

No theatrical agreement. Technical rigor always.

© NoobyGains, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/review-response of NoobyGains/godmode.

Open the folder on GitHubat commit 441103a

Compare with similar skills

Review Response next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Review Response compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Review Response this skillNoobyGains/godmode109—~2.2kAutomated safety check: PassMIT
Vercel Composition Patternssupabase/supabase111k58 repos~726Automated safety check: PassMIT
Finishing a Development Branchobra/superpowers297k5 repos~1.9kAutomated safety check: PassMIT
Typescript Advanced Typesrolling-scopes/rsschool-app10k25 repos~4.2kAutomated safety check: PassMPL-2.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k4 repos~1.1kAutomated safety check: PassMIT

Similar skills

  • Vercel Composition Patterns

    supabase/supabase

    Official

    React composition patterns that scale. An agent skill from supabase/supabase.

    111k GitHub starsUsed in 58 repos~726 tokens
    DevelopmentAuto-check passed

  • Finishing a Development Branch

    obra/superpowers

    Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    297k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed

  • Typescript Advanced Types

    rolling-scopes/rsschool-app

    Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications.

    10k GitHub starsUsed in 25 repos~4.2k tokens
    DevelopmentAuto-check passed

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 4 repos~1.1k tokens
    DevelopmentAuto-check passed

  • Greploop

    onyx-dot-app/onyx

    Iteratively improves a PR (GitHub), MR (GitLab), or shelved changelist (Perforce) until Greptile gives it a 5/5 confidence score with zero unresolved comments.

    32k GitHub starsUsed in 4 repos~3.3k tokens
    DevelopmentAuto-check passed

More from NoobyGains/godmode

All 34 skills in this repo

  • Activation

    NoobyGains/godmode

    A skill your agent uses when starting any conversation - establishes how to locate and invoke skills, mandating Skill tool usage before ANY response including clarifying questions

    109 GitHub stars~2.4k tokensUpdated 7 mo ago
    Auto-check passed

  • Agent Messaging

    NoobyGains/godmode

    A skill your agent uses when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents.

    109 GitHub stars~3k tokensUpdated 7 mo ago
    Auto-check passed

  • Codebase Research

    NoobyGains/godmode

    A skill your agent uses when building ANY feature within an existing project - search the current codebase for existing patterns, conventions, similar implementations, and established approaches…

    109 GitHub stars~3.2k tokensUpdated 7 mo ago
    Auto-check: notes

  • Completion Gate

    NoobyGains/godmode

    A skill your agent uses when about to declare work done, fixed, or passing, before committing or opening PRs - demands executing verification commands and reading their output before making any…

    109 GitHub stars~1.6k tokensUpdated 7 mo ago
    Auto-check passed

  • Comprehension Check

    NoobyGains/godmode

    A skill your agent uses when implementing any substantial feature, multi-file modification, or architectural change - produces a plain-language walkthrough of every alteration so the developer can…

    109 GitHub stars~1.5k tokensUpdated 7 mo ago
    Auto-check passed

  • Delegated Execution

    NoobyGains/godmode

    A skill your agent uses when executing implementation plans with independent tasks in the current session

    109 GitHub stars~2.4k tokensUpdated 7 mo ago
    Auto-check passed

Categories

Questions about Review Response

What does Review Response do?

A skill your agent uses when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands…. Review Response is an agent skill from NoobyGains/godmode.

When should I use Review Response?

Review Response fits situations like: processing code review feedback before making changes; particularly when suggestions are ambiguous; technically suspect; span multiple interdependent items - demands verification and technical rigor over compliance theater.

How do I install Review Response in Claude Code?

Run `npx skills add NoobyGains/godmode --skill review-response -a claude-code`. Or copy the skill folder (skills/review-response in NoobyGains/godmode) into .claude/skills/review-response in your project. Claude Code loads it when a task matches its description.

How do I install Review Response in Codex?

Run `npx skills add NoobyGains/godmode --skill review-response -a codex`. Or copy the skill folder (skills/review-response in NoobyGains/godmode) into .agents/skills/review-response in your project. Codex loads it when a task matches its description.

Can I use Review Response in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add NoobyGains/godmode --skill review-response -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-response, .gemini/skills/review-response, .github/skills/review-response and .opencode/skills/review-response in your project.

What does Review Response need to run?

Going by SKILL.md and its folder, Review Response needs the command-line tools its instructions call (gh).

Does Review Response access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Review Response safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Review Response use?

Review Response is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Review Response use?

About 2.2k tokens (SKILL.md is roughly 8.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Review Response?

Skills that share tags, products or a category with Review Response: Vercel Composition Patterns (supabase/supabase, 111k stars), Finishing a Development Branch (obra/superpowers, 297k stars), Typescript Advanced Types (rolling-scopes/rsschool-app, 10k stars) and PR Babysitter (openinterpreter/openinterpreter, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Review Response?

NoobyGains (a GitHub user) maintains it in NoobyGains/godmode, which has 109 GitHub stars. The repository holds 34 skills in this directory. The repository was last updated on March 9, 2026.

Source: NoobyGains/godmode on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.