Use when responding to code review feedback on your changes. Guides you through processing comments, making fixes, and re-requesting review. Triggers: "address review", "fix review comments", "respond to feedback", "review feedback".
From superomninpx claudepluginhub wilder1222/superomni --plugin superomniThis skill is limited to using the following tools:
SKILL.md.tmplSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
mkdir -p ~/.omni-skills/sessions
_PROACTIVE=$(~/.claude/skills/superomni/bin/config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
_TEL_START=$(date +%s)
echo "Branch: $_BRANCH | PROACTIVE: $_PROACTIVE"
If PROACTIVE is false: do NOT proactively suggest skills. Only run skills the
user explicitly invokes. If you would have auto-invoked, say:
"I think [skill-name] might help here β want me to run it?" and wait.
Report status using one of these at the end of every skill session:
Pipeline stage order: THINK β PLAN β REVIEW β BUILD β VERIFY β SHIP β REFLECT
REVIEW is the only human gate. All other stages auto-advance on DONE.
| Status | At REVIEW stage | At all other stages |
|---|---|---|
| DONE | STOP β present review summary, wait for user input (Y / N / revision notes) | Auto-advance β print [STAGE] DONE β advancing to [NEXT-STAGE] and immediately invoke next skill |
| DONE_WITH_CONCERNS | STOP β present concerns, wait for user decision | STOP β present concerns, wait for user decision |
| BLOCKED / NEEDS_CONTEXT | STOP β present blocker, wait for user | STOP β present blocker, wait for user |
When auto-advancing:
docs/superomni/[STAGE] DONE β advancing to [NEXT-STAGE] ([skill-name])When the user sends a follow-up message after a completed session, before doing anything else:
ls docs/superomni/specs/spec-*.md docs/superomni/plans/plan-*.md docs/superomni/ .superomni/ 2>/dev/null | head -20
git log --oneline -3 2>/dev/null
To find the latest spec or plan:
_LATEST_SPEC=$(ls docs/superomni/specs/spec-*.md 2>/dev/null | sort | tail -1)
_LATEST_PLAN=$(ls docs/superomni/plans/plan-*.md 2>/dev/null | sort | tail -1)
workflow skill for stage β skill mapping) and announce:
"Continuing in superomni mode β picking up at [stage] using [skill-name]."using-skills/SKILL.md.When asking the user a question, match the confirmation requirement to the complexity of the response:
| Question type | Confirmation rule |
|---|---|
| Single-choice β user picks one option (A/B/C, 1/2/3, Yes/No) | The user's selection IS the confirmation. Do NOT ask "Are you sure?" or require a second submission. |
| Free-text input β user types a value and presses Enter | The submitted text IS the confirmation. No secondary prompt needed. |
| Multi-choice β user selects multiple items from a list | After the user lists their selections, ask once: "Confirm these selections? (Y to proceed)" before acting. |
| Complex / open-ended discussion β back-and-forth clarification | Collect all input, then present a summary and ask: "Ready to proceed with the above? (Y/N)" before acting. |
Rule: never add a redundant confirmation layer on top of a single-choice or text-input answer.
Custom Input Option Rule: Whenever you present a predefined list of choices (A/B/C, numbered options, etc.), always append a final "Other" option that lets the user describe their own idea:
[last letter/number + 1]) Other β describe your own idea: ___________
When the user selects "Other" and provides their custom text, treat that text as the chosen option and proceed exactly as you would for any other selection. If the custom text is ambiguous, ask one clarifying question before proceeding.
Load context progressively β only what is needed for the current phase:
| Phase | Load these | Defer these |
|---|---|---|
| Planning | Latest docs/superomni/specs/spec-*.md, constraints, prior decisions | Full codebase, test files |
| Implementation | Latest docs/superomni/plans/plan-*.md, relevant source files | Unrelated modules, docs |
| Review/Debug | diff, failing test output, minimal repro | Full history, specs |
If context pressure is high: summarize prior phases into 3-5 bullet points, then discard raw content.
All skill artifacts are written to docs/superomni/ (relative to project root).
See the Document Output Convention in CLAUDE.md for the full directory map.
Agent failures are harness signals β not reasons to retry the same approach:
harness-engineering skill to update the harness before retrying.It is always OK to stop and say "this is too hard for me." Escalation is expected, not penalized.
After completing any skill session, run a 3-question self-check before writing the final status:
If any answer is NO, address it before reporting DONE. If it cannot be addressed, report DONE_WITH_CONCERNS and name the gap.
For a full performance evaluation spanning the entire sprint, use the self-improvement skill.
_TEL_END=$(date +%s)
_TEL_DUR=$(( _TEL_END - _TEL_START ))
~/.claude/skills/superomni/bin/analytics-log "SKILL_NAME" "$_TEL_DUR" "OUTCOME" 2>/dev/null || true
Nothing is sent to external servers. Data is stored only in ~/.omni-skills/analytics/.
Goal: Process code review feedback systematically, fix what needs fixing, discuss what needs discussing, and re-request review with a clean diff.
NEVER DISMISS FEEDBACK WITHOUT UNDERSTANDING IT FIRST.
Before marking any comment as "won't fix" or "disagree," you must:
Read every comment. Classify each one:
| Priority | Meaning | Action |
|---|---|---|
| P0 β Must fix | Correctness bug, security issue, test gap, spec violation | Fix immediately, no discussion needed |
| P1 β Should fix | Code quality, naming, readability, DRY violation | Fix unless you have a strong reason not to |
| P2 β Optional | Style preference, minor suggestion, alternative approach | Consider, but OK to skip with brief explanation |
# Review the PR comments (if using GitHub)
gh pr view --comments 2>/dev/null | head -60
# See the current diff to understand what was reviewed
git diff main...HEAD --stat
Produce a triage list:
REVIEW TRIAGE
βββββββββββββββββββββββββββββββββ
P0 (must fix):
[ ] [file:line] β [summary of issue]
P1 (should fix):
[ ] [file:line] β [summary of issue]
P2 (optional):
[ ] [file:line] β [summary of suggestion]
Taste discussions:
[ ] [file:line] β [topic to discuss]
βββββββββββββββββββββββββββββββββ
Work through fixes in priority order: all P0s first, then P1s.
For each fix:
# After each fix, run tests
npm test 2>&1 | tail -10
# or
pytest -v 2>&1 | tail -10
# Verify no regressions
git diff HEAD --stat
For comments you disagree with:
Agreeing:
Good catch, fixed in [commit SHA].
Partially agreeing:
I see the concern about [X]. I've addressed [part] but kept [other part] because [reason]. Let me know if you'd prefer a different approach.
Respectfully disagreeing:
I considered [their approach] but went with [your approach] because [specific reason]. The tradeoff is [what you lose vs. gain]. Happy to change if you feel strongly.
Asking for clarification:
I want to make sure I understand β are you suggesting [interpretation A] or [interpretation B]?
After all fixes are applied:
# Verify everything passes
npm test 2>&1 | tail -10
# Review your own diff before re-requesting
git diff main...HEAD --stat
git diff main...HEAD | head -100
# Check for leftover debug code
git diff main...HEAD | grep -E "console\.log|debugger|TODO|FIXME|print\(" | head -10
# Commit and push
git add -A
git commit -m "Address review feedback
- [summary of P0 fixes]
- [summary of P1 fixes]
- [summary of taste decisions made]"
git push
Leave a summary comment on the PR:
Review feedback addressed:
- β [P0 fix 1]
- β [P0 fix 2]
- β [P1 fix 1]
- π¬ [Taste discussion β see inline reply]
- β [P2 skipped β reason]
Ready for re-review.
After 2+ rounds of review on the same comment:
REVIEW RESPONSE
ββββββββββββββββββββββββββββββββββββββββ
PR/Branch: [name]
Comments total: [N]
P0 fixed: [N]
P1 fixed: [N]
P2 addressed: [N]
Taste discussed: [N]
Skipped (with reason): [N]
Tests passing: [yes/no]
Re-review requested: [yes/no]
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
ββββββββββββββββββββββββββββββββββββββββ