CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Paranoid architect review of code changes for bugs, security, missing tests, and undocumented assumptions. Works on local git diffs OR a GitHub pull request (e.g. `owner/repo N`). For PRs, can post findings as line-level review comments.

66

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/code-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

77%

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 code-review skill with executable repl examples and explicit validation at every risky step. Its main weaknesses are mild verbosity in the bug-category checklists and a monolithic single-file structure with no progressive disclosure to offload the lengthy lens/posting detail.

Suggestions

Tighten the six-lens checklists to focus on review-specific framing rather than re-listing well-known bug classes (TOCTOU, SQL injection) Claude already recognizes.

Consider moving the GitHub posting recipe (Step 5) and/or the full lens checklist into a reference file linked from the body, reducing SKILL.md length and giving real progressive disclosure.

DimensionReasoningScore

Conciseness

Most of the body is substantive and earns its tokens (the async/FINAL gotcha, the missing base64 module, the raw-media-type workaround), but the six-lens checklists re-enumerate bug categories like TOCTOU and SQL injection that Claude already knows, so it is mostly efficient with room to tighten rather than fully lean.

2 / 3

Actionability

Provides fully executable, copy-paste-ready 'repl' blocks with exact API URLs, Accept headers, request bodies, and status-code checks, plus a concrete severity scale — matching the level 3 'fully executable, specific examples' anchor and not the pseudocode level 2.

3 / 3

Workflow Clarity

A clear five-step sequence (Load → Read every file → Deep review → Present → Post) with explicit validation checkpoints (status != 200 returns fast, post status not in 200/201 returns an error) and error-recovery feedback, matching the level 3 anchor with validation rather than the checkpoint-missing level 2.

3 / 3

Progressive Disclosure

The skill is a single file with no bundle files or external references and is well-sectioned internally, but at well over 50 lines it is monolithic and the six-lens detail and posting examples are inline rather than split out, so it sits at the 'good structure but could be better organized' level 2 rather than the file-split level 3.

2 / 3

Total

10

/

12

Passed

Description

82%

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 specific, well-targeted description that names concrete capabilities and natural trigger terms and is clearly distinct from other skills. Its one gap is the absence of an explicit 'Use when...' clause, which leaves the 'when to use it' half of completeness only implied.

Suggestions

Append an explicit 'Use when...' clause, e.g. 'Use when the user asks to review a diff, staged/unstaged changes, a commit, or a GitHub pull request for bugs and security issues.'

Consider listing the most common natural trigger phrases (e.g. 'review my changes', 'look at this PR') to reinforce the when-to-use signal alongside the existing what-it-does wording.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'review of code changes for bugs, security, missing tests, and undocumented assumptions', 'Works on local git diffs OR a GitHub pull request', and 'post findings as line-level review comments' — matching the anchor for multiple specific concrete actions rather than the single-action level 2.

3 / 3

Completeness

The 'what' is explicit, but there is no 'Use when...' clause or equivalent explicit trigger guidance for when to invoke it, which the judging guidelines cap at 2; it does not reach the explicit 'what AND when' level 3 anchor.

2 / 3

Trigger Term Quality

Uses natural terms a user would say — 'code changes', 'git diffs', 'GitHub pull request', and the 'owner/repo N' shape — giving good coverage of common phrasings rather than just one keyword (level 2).

3 / 3

Distinctiveness Conflict Risk

'Paranoid architect review of code changes' carves a clear code-review niche with distinct triggers (diffs, PRs) unlikely to collide with unrelated skills, matching the level 3 anchor rather than the overlap-prone level 2.

3 / 3

Total

11

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
nearai/ironclaw
Reviewed

Table of Contents

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.