receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced workflow with strong validation checkpoints and clean single-file organization. The main weakness is redundancy, with the same guidance repeated across the checklist, tone guidelines, mistakes table, and red flags.

Suggestions

Consolidate the repeated guidance: the YAGNI check appears in both Step 3 and Response Tone Guidelines — state it once and reference it, or remove the duplicate.

Merge 'Red Flags' (Never/Always) and the 'Common Mistakes' table with the Quick Reference Checklist to avoid re-stating the same prohibitions three times.

Trim the Response Tone Guidelines to only the unique material (push-back phrasing, external-reviewer rules, Circle K signal) since the rest duplicates the checklist.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient and avoids explaining basics Claude already knows, but guidance is repeated across the Quick Reference Checklist, Response Tone Guidelines (Forbidden/Required), Common Mistakes table, and Red Flags (e.g., the YAGNI check appears twice); not a 3 because of this redundancy, not a 1 because there is no padding with fundamental concepts.	2 / 3
Actionability	Provides fully executable commands ('gh pr view [PR-NUMBER] --comments', 'grep -r "endpointName" .', 'npm run format', 'git push') plus copy-paste TodoWrite and ✅/❌ examples; not below 3 because guidance is concrete and ready to run.	3 / 3
Workflow Clarity	Clear numbered sequence (Steps 0-6) with explicit validation checkpoints ('If ANY item is unclear, STOP', 'test each fix individually', run tests/lint/format before pushing) and feedback loops; the batch-operation cap does not apply because verification is present, so not a 2.	3 / 3
Progressive Disclosure	Single-file skill with well-organized sections and one clearly signaled one-level-deep external reference (finishing-a-development-branch SKILL.md); no nested references and no monolithic wall, so not a 2.	3 / 3
	Total	11 / 12 Passed

Description

90%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit 'Use when' trigger and natural keywords, clearly answering both what stance the skill enforces and when to invoke it. It is slightly weaker on specificity because it emphasizes attitude over a concrete enumerated action list.

Suggestions

Add a brief concrete action sequence to the description (e.g. 'fetch PR comments, verify each against the codebase, implement in order, re-test, push') to lift specificity toward 3.

Keep the trigger phrasing but consider adding a couple more user-natural variants like 'code review comments' or 'reviewer feedback' for broader coverage.

Dimension	Reasoning	Score
Specificity	Names the domain and some actions ('receiving code review feedback', 'implementing suggestions', 'verification') but describes a stance rather than listing multiple concrete actions like fetch, verify, implement, push; not a 3 because it is not comprehensive on specific actions, not a 1 because it names the domain and several activities.	2 / 3
Completeness	It explicitly answers both 'when' ('Use when receiving code review feedback... before implementing suggestions, especially if feedback seems unclear or technically questionable') and 'what' ('requires technical rigor and verification, not performative agreement or blind implementation'); not a 2 because it has an explicit 'Use when' clause covering both facets.	3 / 3
Trigger Term Quality	'Use when receiving code review feedback' and 'feedback seems unclear or technically questionable' are natural terms a user would say, giving good coverage of common phrasings; not below 3 because the trigger language is natural and explicit.	3 / 3
Distinctiveness Conflict Risk	'receiving code review feedback' is a clear niche with distinct triggers unlikely to conflict with other skills; not a 2 because it targets a specific reception-of-feedback scenario rather than a broad overlap.	3 / 3
	Total	11 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: microsoft/FluidFramework
Path: .agency/plugins/nori/skills/receiving-code-review/SKILL.md
Commit: f9f2007

Reviewed: about 7 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.