$ ~/registry/skill/microsoft-agency-plugins-nori-skills-receiving-code-review

SKILL

receiving-code-review

Name: receiving-code-review
Author: microsoft

Evaluate code review feedback rigorously before deciding whether to implement it.

Stars

★ 4,934

Source

GitHub

Updated

2026-07-14

// securityCaution

Prompt only, no code
Open source

Summary

This skill appears to be an open-source prompt/document artifact with no required secrets and no declared remote endpoints, so the overall risk is low. However, it explicitly instructs use of gh/git/npm/grep and repository data, so if an agent actually follows it, it would involve local code execution and repository data access that should be constrained by the runtime environment.

CredentialsLow risk

The material declares no required secrets or environment variables, and it does not ask for tokens, API keys, or pasted credentials, so credential exposure risk is low.

Network egressCaution

No remote endpoint is explicitly declared, but the README instructs `gh pr view` to fetch PR comments and `git push` to send updates, which normally connect to the code hosting platform and may transmit code/metadata. This is standard for developer workflows, with no clear sign of exfiltration to unrelated or unknown endpoints.

Code executionCaution

The README explicitly suggests running local commands and developer tools such as `gh`, `grep`, `npm test`, `npm run lint`, `npm run format`, and `git push`, so following it would entail local command execution. This is normal for the stated use case, but it should be confined to a controlled repository and environment.

Data accessCaution

The material calls for reading PR comments, checking branch/diff state, searching repository contents, and modifying code before committing, indicating access to the local codebase and related development data. There is no evident request for system-wide data unrelated to code review or other excessive permissions.

Supply chainLow risk

The system marks it as prompt-only and open-source, with a GitHub source pointing to a Microsoft-associated repository, which provides good auditability. Community adoption, license clarity, and maintenance status are limited/unclear, but the current material shows no obvious red flags such as closed-source exfiltration, disguised installers, or clear prompt-injection patterns.

Recommendations

Use it only in a controlled development environment and limit which repositories/branches it can access.
If an agent may actually execute README commands, gate or review high-impact actions such as `git push`, `gh pr view`, and `npm` commands first.
Verify the local `gh` identity and target remote repository before use to avoid reading from or pushing to the wrong repository.
Pair usage with repository permission controls and audit logs for PR-comment access and code changes.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "receiving-code-review" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/FluidFramework/main/.agency/plugins/nori/skills/receiving-code-review/SKILL.md
2. Save it as ~/.claude/skills/receiving-code-review/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Assess whether review feedback is valid

Prompt

Help me analyze whether this code review comment is technically valid, and whether I should accept, partially accept, or reject it. Here is the code: {{code}}. Here is the review feedback: {{review feedback}}. Please check for misunderstandings, outdated assumptions, style-vs-correctness confusion, or conflicts with project constraints.

Expected

A technical assessment of the feedback, supporting reasoning, risks, and a recommended response and action.

Draft a well-reasoned reply

Prompt

I received a code review comment that may be inaccurate. Based on the following context, help me draft a professional, concise, non-confrontational reply: code snippet: {{code}}; review comment: {{review feedback}}; my current assessment: {{my assessment}}; project constraints: {{project constraints}}. If my assessment may be wrong, point that out too.

Expected

A professional reply draft plus any technical questions or evidence that should be verified.

Verify before changing code

Prompt

Do not change the code just because of the review comment. First design a verification plan for this suggestion: the review comment is {{review feedback}}, and the relevant code is {{code}}. List the facts to check, runnable tests, edge cases, and only then propose changes if the feedback is validated.

Expected

A verification checklist, test plan, and conditional implementation advice based on the findings.

// docs

Code Review Reception

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Fetch feedback → Verify → Implement → Re-test → Push updates.

Announce at start: "I'm using the Nori Receiving Code Review skill to handle this feedback."

The Process

Step 0: Create Todo List

For multi-item feedback, use TodoWrite:

- [ ] Fetch and read all PR comments
- [ ] Clarify unclear items (if any)
- [ ] Fix item 1: [description]
- [ ] Fix item 2: [description]
...
- [ ] Run tests/lint/format
- [ ] Push updates

Why: Prevents skipping items and provides visibility to user.

Step 1: Fetch PR Comments

Determine PR number from context:

User mentions PR number: Use that
Current branch: Run gh pr view --json number -q .number

Fetch all comments:

# View all comments (review + general)
gh pr view [PR-NUMBER] --comments

Read completely before reacting.

Step 2: Understand and Clarify

Apply these checks to each item:

Can I restate this requirement in my own words?
Is this technically sound for THIS codebase?
Does this break existing functionality?
Is there a reason for the current implementation?

CRITICAL: If ANY item is unclear, STOP. Ask for clarification on ALL unclear items before implementing ANYTHING.

Example:

User: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.

✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
❌ Implement 1,2,3,6 now, ask about 4,5 later

Step 3: Implement Changes

Follow implementation order:

Blocking issues (breaks, security)
Simple fixes (typos, imports)
Complex fixes (refactoring, logic)

For each fix:

Implement one at a time
Test individually
Commit individually (frequent commits)

YAGNI check: If reviewer suggests "implementing properly", grep for actual usage:

grep -r "endpointName" .

If unused: "This endpoint isn't called. Remove it (YAGNI)?"

Step 4: Run Tests, Lint, and Format

Reference finishing-a-development-branch skill (Steps 1-2):

See .claude/skills/finishing-a-development-branch/SKILL.md

Run tests: npm test (or project equivalent)
- If tests fail, fix before proceeding
Run type checks: npm run lint:*-types (if available)
- If type errors, fix before proceeding
Run formatter: npm run format
Run linter: npm run lint
Verify changes: git diff --stat

Step 5: Push Updates

Push changes to PR:

git push

Step 6: Summary and Next Action

Report what changed:

"Code review feedback addressed:

Fixed [item 1]: [brief description]
Fixed [item 2]: [brief description] ...

Changes pushed to PR. Options:

Done - PR is ready for re-review
More feedback - Additional changes needed
Show changes - Review diffs before marking done

Which would you like?"

Quick Reference Checklist

Create TodoWrite for all feedback items
Fetch PR comments (gh pr view --comments)
Clarify ALL unclear items before implementing ANY
Implement in order: blocking → simple → complex
Test each fix individually
Run tests, type checks, formatting, linting (finishing-a-development-branch)
Push updates
Summarize changes and ask for next action

Response Tone Guidelines

Forbidden:

"You're absolutely right!" / "Great point!" / "Thanks for..." (performative agreement)
Implementing before verifying against codebase
Proceeding with unclear feedback

Required:

Verify suggestions against codebase reality before implementing
Push back with technical reasoning if suggestion breaks things or violates YAGNI
Ask for clarification on ALL unclear items before implementing ANY items
State fixes factually: "Fixed. [what changed]" or just show the code

…

View full docs ↗

Clarify ambiguous changes into testable acceptance criteria and implementation requirements.

affaan-mGet→

$ loading_