スキル一覧に戻る
axiomantic

receiving-code-review

by axiomantic

Multi-platform AI assistant skills and workflows. Serious engineering. Also fun.

2🍴 0📅 2026年1月24日
GitHubで見るManusで実行

SKILL.md


name: receiving-code-review description: "Use when you have received code review feedback and need to process it. [DEPRECATED] Routes to code-review --feedback" deprecated: true replacement: code-review --feedback

Receiving Code Review (Deprecated)

Invariant Principles

  1. Route to Replacement - Always route to code-review --feedback
  2. Pass Context Through - Forward all provided context to replacement skill
  3. No Independent Execution - This skill does not execute feedback processing logic itself

Automatic Routing

When this skill is loaded, immediately invoke:

/code-review --feedback

With any provided context passed through.


Handoff from Requesting Skill

When processing external feedback after internal review:

Context Loading

  1. Check for existing review-manifest.json
  2. Load internal findings for comparison
  3. Cross-reference external findings against internal

Finding Reconciliation

ScenarioAction
External finding matches internalMark as confirmed, higher confidence
External finding not in internalVerify carefully (we may have missed it)
Internal finding not raised externallyStill valid, consider addressing
External finding contradicts internalInvestigate thoroughly, escalate if unclear

Shared Context

Access via review-manifest.json:

  • reviewed_sha - What commit was reviewed
  • files - What files were in scope
  • complexity - Size estimate

/code-review --feedback

With any provided context passed through.

Migration Guide

Old UsageNew Equivalent
receiving-code-reviewcode-review --feedback
"Address review comments"Same (auto-routes)
"Fix PR feedback"code-review --feedback --pr <num>

Thread Reply Protocol

Reply Location

  • ALWAYS reply in the existing thread, never as top-level comment
  • Use gh pr comment --reply-to <comment-id> or MCP reply tools
  • If thread ID unavailable, quote the original comment

Response Formats

FIXED - Issue addressed with code change:

Fixed in [commit SHA].

[Optional: brief explanation of fix approach]

ACKNOWLEDGED - Will address, not yet fixed:

Acknowledged. Will address in [scope: this PR / follow-up / future iteration].

[Optional: brief plan or reason for deferral]

QUESTION - Need clarification:

Question: [specific question]

Context: [what you understand so far]
[Optional: what you tried or considered]

DISAGREE - Technical disagreement with evidence:

I see a different tradeoff here.

**Current approach:** [what code does]
**Suggested change:** [what was requested]
**My concern:** [specific technical issue with evidence]

[Optional: alternative proposal]

Happy to discuss further or defer to your judgment on [specific aspect].

Forbidden Responses

  • "Done" (no context, no SHA)
  • "Fixed" (no SHA, can't verify)
  • "Will do" (no commitment scope)
  • "Thanks!" (performative, adds no information)
  • "You're right" (without explaining what you learned)

Feedback Source Trust Levels

Source TypeTrust LevelVerification Required
Internal code-reviewer agentHighSpot-check (verify 1-2 findings)
Partner/collaborator (human)HighSpot-check + consider context
External reviewer (human)SkepticalFull verification of each finding
External AI toolLowFull verification + partner escalation for ambiguous cases
CI/Linter (automated)ObjectiveTrust if tool is validated; check config if unexpected

Trust Level Actions

High Trust:

  • Verify 1-2 representative findings
  • Proceed with implementation if spot-check passes
  • Escalate only if spot-check fails

Skeptical:

  • Verify EVERY finding against codebase
  • Cross-reference with internal review if exists
  • Question assumptions, request evidence for vague feedback

Low Trust:

  • Treat as suggestions, not requirements
  • Full verification mandatory
  • Escalate to partner before implementing substantial changes

Objective:

  • Tool output is factual (lint errors, type errors)
  • Verify tool configuration is correct
  • Address systematically, don't argue with tools

MCP Tool Failures

When MCP tools fail during feedback verification, follow this fallback chain:

Failure Logging

Log every failure with:

  • Tool name and operation attempted
  • Error message or timeout
  • Context (what verification was being performed)

Fallback Chain

  1. Primary: MCP tools (pr_fetch, pr_diff, etc.)
  2. Fallback 1: Direct file reading with Read tool
  3. Fallback 2: Git commands via Bash (git show, git diff)
  4. Fallback 3: Request manual paste from user

Hard Stop Rule

If ALL fallbacks fail for a verification:

  • Report: "Cannot verify: [finding summary]"
  • Do NOT implement unverifiable suggestions
  • Mark finding as UNVERIFIED in response
  • Escalate to user for manual verification decision

Never Implement Unverified

Why Deprecated?

The code-review skill consolidates all review functionality:

  • --self: Pre-PR self-review
  • --feedback: Process received feedback (this functionality)
  • --give: Review someone else's code
  • --audit: Comprehensive multi-pass review

See code-review/SKILL.md for full documentation.

スコア

総合スコア

60/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です