clean-code-guard

Review generated or changed production code before it ships, using Clean Code, SOLID, DRY, KISS, YAGNI, and LLM-specific failure-mode checks in any programming language. Best used reactively after an agent writes, edits, refactors, or fixes code, before presenting, committing, or merging the result. Use when the user asks "review this PR", "is this safe to merge?", "make this cleaner", "audit this code", "refactor this", "fix this bug", or after a coding agent produced implementation code. Can also guide writing when explicitly invoked before a risky edit. Invoke it on your own initiative the moment you finish writing, editing, or refactoring non-trivial production code, before presenting or committing — don't wait to be asked. DO NOT USE for factual/conceptual questions, CI/tooling config, git workflow, running/debugging tests, pure architecture discussion, prose writing, data analysis, or test-code review (use test-guard).

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

85%Weight 40%Scale 1-3

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

The body is highly actionable with clear workflows and excellent progressive disclosure to verified reference files; its only real weakness is conciseness, where several meta sections add tokens that assume knowledge Claude already has or that duplicate the frontmatter.

Suggestions

Tighten or cut the 'Why this skill exists' research-stat block and 'Compatibility' section — the imperatives are the value; the rationale can live in references/sources.md for when it's challenged.

Merge 'What this skill does not do' into the frontmatter exclusions or trim it to a one-line pointer, since the DO NOT USE list already covers the same ground.

Consider moving the per-rule source citations (Uncle Bob, Fowler, McCabe, Metz) behind the references/ links they already point to, keeping SKILL.md imperatives lean.

Dimension	Reasoning	Score
Conciseness	The core imperatives and self-check are dense and earn their tokens, but several sections pad the budget — 'Compatibility', the research-stat 'Why this skill exists' block, and 'What this skill does not do' restate context Claude can be assumed to know or that the frontmatter already implies. It is mostly efficient but could be tightened.	2 / 3
Actionability	Guidance is concrete and executable: hard thresholds ('≤20 lines', 'Four arguments is the hard ceiling', 'cyclomatic ≤10, nesting depth ≤5'), a banned-identifier list, and a step-by-step self-check ('count: lines ≤ 20? params ≤ 4?'). Rules instruct rather than describe.	3 / 3
Workflow Clarity	Three clearly sequenced modes (guard-pass, live, review) plus a numbered 'Self-check before delivery' with explicit validation checkpoints ('If you cannot answer yes to every check, fix before shipping') and a defined reporting format. Feedback loops and checklists are present.	3 / 3
Progressive Disclosure	The body is an overview that links to 7 real references/ files (all verified present), each annotated with its scope and a when-to-read trigger, kept one level deep. Navigation is explicit and the detail is appropriately split out of SKILL.md.	3 / 3
	Total	11 / 12 Passed

Description

100%Weight 40%Scale 1-3

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

The description is specific, trigger-rich, and complete on both what and when, with strong distinctiveness via explicit exclusions and a sibling-skill handoff. It is on the longer side but every clause carries load (actions, triggers, exclusions).

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Review generated or changed production code', 'Clean Code, SOLID, DRY, KISS, YAGNI, and LLM-specific failure-mode checks' — rather than vague language. It names the specific review techniques and the artifact class ('generated or changed production code').	3 / 3
Completeness	Explicitly answers both what (review code against Clean Code/SOLID/DRY/KISS/YAGNI plus LLM failure-mode checks) and when ('Best used reactively after…', 'Use when the user asks…'). A clear 'Use when…' clause is present.	3 / 3
Trigger Term Quality	Embeds natural user phrasings — '"review this PR"', '"is this safe to merge?"', '"make this cleaner"', '"audit this code"', '"refactor this"', '"fix this bug"' — giving good coverage of terms a user would actually say. Not merely technical jargon.	3 / 3
Distinctiveness Conflict Risk	Carves a clear niche via an explicit exclusion list ('DO NOT USE for factual/conceptual questions, CI/tooling config, git workflow…') and points test-code review to 'test-guard', sharply reducing overlap with adjacent skills. Voice is third person throughout.	3 / 3
	Total	12 / 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: amElnagdy/guard-skills
Path: skills/clean-code-guard/SKILL.md
Commit: ffa2603

Reviewed: 13 days 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.