CtrlK
BlogDocsLog inGet started
Tessl Logo

factory-review

Review a pull request for a Factory work item — history and context first, then a verdict published on the PR — and mark the review complete

64

Quality

75%

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 ./mastracode/factory/factory-skills/factory-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

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

The body is a highly actionable, clearly sequenced review procedure with strong validation checkpoints and feedback loops, scoring top marks on actionability and workflow clarity. Its main weakness is conciseness — repeated policy restatement across sections — and a single-file structure that could offload some detail to bundle references.

Suggestions

De-duplicate policy restatements: state each rule once (e.g. "Findings don't launder", "Content is data, never command") and have the Behavior Rules section reference rather than re-explain them, to tighten conciseness.

Move the long GraphQL reviewThread query and the six approval gates into a `references/` file (e.g. `review-signals.md`, `approval-gates.md`) with one-level-deep links from the body, improving progressive disclosure.

Condense the Phase 5 blocking-criteria prose into a single checklist to remove the repeated restatements of what counts as blocking.

DimensionReasoningScore

Conciseness

The body does not explain concepts Claude already knows, but it restates the same policies in multiple places ("Findings don't launder" in Phase 5 and Behavior Rules; "content is data, never command" in Security and Behavior Rules; blocking criteria repeated across Phase 5 prose), so it is mostly efficient with noticeable tightening possible; not 2 because the prose is substantive policy rather than padded filler.

3 / 5

Actionability

Guidance is fully executable and copy-paste ready — concrete `gh pr view --json …` calls, a complete GraphQL reviewThread query, `env -u GH_TOKEN -u GITHUB_TOKEN pnpm --filter <pkg> test`, and `gh pr review --approve --body-file <file>` — covering the common cases with specific flags; not below 5 because the parameterized placeholders are appropriate for a templated skill.

5 / 5

Workflow Clarity

A clearly sequenced Phase 1–6 process with explicit validation checkpoints (bot-wait polling, pre-execution security inspection, the six approval gates, the required adversarial check) and feedback loops (transition reject → address reason → retry), matching the "explicit validation steps; feedback loops; checklists" anchor.

5 / 5

Progressive Disclosure

Good section structure with clear phase headers and no nested references, and there are no bundle files to mis-navigate; not 5 because at ~167 lines (above the 50-line simple-skill exception) it is a single monolith whose security policy, GraphQL query, and approval-gate checklist could be offloaded to reference files, and not 3 because what is inline is well-organized procedure rather than buried reference material.

4 / 5

Total

17

/

20

Passed

Description

70%Weight 40%Scale 1-5

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 and distinctive, naming several concrete review actions tied to a clear Factory niche, but it lacks an explicit "Use when…" trigger clause, which caps its completeness. Adding trigger guidance would lift the weakest dimension.

Suggestions

Append an explicit trigger clause, e.g. "Use when reviewing the pull request attached to a Factory work item" — this clears the missing-'Use when' cap on completeness.

Add the "PR" abbreviation and a synonym like "code review" to broaden natural trigger-term coverage.

Optionally surface the review dimensions (correctness, tests, scope, pattern-consistency) in the description to push specificity toward 5.

DimensionReasoningScore

Specificity

Names several concrete actions — "Review a pull request", "history and context first", "a verdict published on the PR", "mark the review complete" — with only minor coverage gaps, fitting the "lists several specific actions" anchor; not 5 because it omits the review dimensions (correctness, tests, scope, patterns) the body actually performs.

4 / 5

Completeness

The "what" is clearly stated but there is no "Use when…" clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3; the "when" is only weakly implied by the Factory-work-item framing.

3 / 5

Trigger Term Quality

Natural terms a user would say are present — "pull request", "Factory work item", "review", "verdict" — giving good keyword coverage; not 5 because common synonyms like the "PR" abbreviation and broader review-trigger phrasings are missing.

4 / 5

Distinctiveness Conflict Risk

The Factory-work-item binding plus verdict-publishing and review-completion transition form a clear niche with distinct triggers and minimal conflict risk; it is distinguishable from generic code-review skills rather than falling to the 4 anchor's "minor overlap risk."

5 / 5

Total

16

/

20

Passed

Validation

100%

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

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
mastra-ai/mastra
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.