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

65

Quality

79%

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

92%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.

An exceptionally well-structured autonomous-review procedure: concrete executable commands at every phase, explicitly sequenced validation checkpoints with feedback loops, and exemplary use of a one-level-deep reference bundle indexed by a category README. The only deductible is a modest amount of rhetorical justification and rule restatement that could be tightened.

DimensionReasoningScore

Conciseness

The body is dense and policy-driven rather than explanatory — it does not teach concepts Claude already knows, and nearly every sentence carries a directive or disambiguation. Minor instances of over-explanation could be trimmed (e.g. justificatory flourishes like "a wrong approve ships the defect with a green checkmark" and near-duplicate statements of the assumptions/one-terminal-call rules in the Behavior Rules section), keeping it below the lean-every-token-earns-its-place anchor.

4 / 5

Actionability

Fully executable commands throughout: exact `gh pr view --json` field lists, a copy-paste-ready GraphQL query with pagination instructions, `env -u GH_TOKEN -u GITHUB_TOKEN pnpm --filter <pkg> test`, `git rev-parse -q --verify MERGE_HEAD`, `gh pr review --body-file`, and artifact paths like `.artifacts/factory-review/pr-<number>.md`. Concrete commands cover the common cases of every phase.

5 / 5

Workflow Clarity

Six clearly sequenced phases with explicit validation checkpoints and feedback loops: pending-bot polling (60s/10min) with a proceed-with-disclosure rule, head-SHA check before publishing with re-review-on-movement, transition-rejection retry with the reason addressed first, a six-item approval-gates checklist, and a mandatory adversarial check before every approve. This matches the top anchor including checklists for complex processes.

5 / 5

Progressive Disclosure

The body keeps the workflow and navigation inline while the bulk of domain detail (15 category pages, indexed by a README table with a "when relevant" column, plus `references/archaeology.md` for command recipes) lives one level deep in the bundle — both referenced paths exist and are explicitly loaded at the right phase ("Load the category guidance before opening the diff"). Structure and navigation are exemplary: category guidance is appropriately split out with per-page relevance triggers rather than inlined.

5 / 5

Total

19

/

20

Passed

Description

66%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.

A concrete, action-oriented description that names its domain and workflow steps clearly. Its main gap is the missing explicit "Use when..." trigger clause, which caps completeness at 3; it also omits common synonyms like "PR" and "approve".

Suggestions

Add an explicit trigger clause, e.g. "Use when a Factory work item in the review phase needs its pull request reviewed and a verdict published".

Include natural synonyms users would say — "PR", "code review", "approve/request changes" — to improve trigger term coverage.

Name the judgment dimensions (correctness, tests, scope, pattern-consistency) already listed in the body to round out capability coverage.

DimensionReasoningScore

Specificity

Lists several concrete actions — "Review a pull request", "history and context first", "a verdict published on the PR", "mark the review complete" — matching the 'several specific actions' anchor. Not a 5 because coverage is high-level: sub-actions like judging correctness/tests/scope or the handoff/transition mechanics are omitted.

4 / 5

Completeness

The "what" is clear (review the PR, build history/context, publish the verdict, mark complete), but there is no "Use when..." clause or equivalent explicit trigger guidance — the when is only weakly implied by the Factory framing. Per the guidelines, a missing trigger clause caps completeness at 3, and the score-4 anchor requires both what and an explicit (if imperfect) when.

3 / 5

Trigger Term Quality

Natural phrases users would say are present — "Review a pull request", "Factory work item", "verdict" — giving good keyword coverage. A few natural terms are missing (no "PR" abbreviation, "code review", "approve"), keeping it below the comprehensive-with-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

"For a Factory work item" carves a clear niche that generic PR-review skills don't occupy, but "Review a pull request ... verdict" overlaps semantically with generic PR/code-review skills. Mostly distinct with minor overlap risk against closely related skills — the score-5 anchor's minimal-conflict profile isn't quite met.

4 / 5

Total

15

/

20

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 1 deeper-than-1-level

Warning

Total

15

/

16

Passed

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.