CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-demo-automation-isolation

Review changes for whether the intentionally vulnerable public demo, Tessl factory automation, and OSS remediation loop stay isolated to guypod/goof-factory without broadening access, deployment, or execution from untrusted input. Use as one lens in a code review run.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

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

A tight, well-structured instruction-only review lens: concise, free of padding, with concrete reporting thresholds and explicit do-not-report carve-outs. The main improvement would be a worked example of a guarded vs. unguarded trigger and a numbered method checklist to make the review pass fully mechanical.

DimensionReasoningScore

Conciseness

The ~28-line body is lean with zero padding: every section (Scope, Method, Threshold, Reporting) carries operational signal and nothing explains concepts Claude already knows. Each sentence states a constraint or a check, so every token earns its place.

5 / 5

Actionability

Concrete, checkable criteria are given throughout — 'automation can run from arbitrary external comment text', 'a trigger lacks exact repository or actor constraints', 'scan failures are reported as clean' — plus an explicit method listing what to trace. It is not a 5 because no example of a violating or correctly-guarded workflow is shown, leaving the reviewer to construct the boundary patterns from prose alone.

4 / 5

Workflow Clarity

The sequence is coherent — trace the trigger (Method), apply the decision rule (Threshold), then report with required elements (Reporting) — and the Threshold section acts as an explicit go/no-go checkpoint with a do-not-report list. It falls short of 5 because the Method packs its six ordered questions into one dense sentence instead of an explicit numbered checklist, making the pass-through order implicit.

4 / 5

Progressive Disclosure

The skill is under 50 lines with no need for external references, and it is organized into four well-labeled sections that are easy to navigate. No bundle files exist and none are needed, satisfying the simple-skill exception.

5 / 5

Total

18

/

20

Passed

Description

67%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 specific, mostly complete description that clearly delimits a niche review lens around repository isolation of a vulnerable demo and its automation loop. Its main weaknesses are thin natural trigger coverage and a generic 'when' clause that doesn't name the change types (workflows, CI, deployment) this lens targets.

Suggestions

Add natural trigger phrases and synonyms users would actually say, e.g. 'Use when reviewing pull requests or changes that touch GitHub workflows, CI/CD, factory automation, scanner configuration, or deployment of the Goof demo.'

Make the 'when' clause concrete by naming the artifacts in scope (workflow YAML, environment/secret config, deployment paths) rather than only 'a code review run'.

Briefly enumerate the boundary checks (repository, external input, access, demo exposure) so the description communicates full capability coverage instead of one summary clause.

DimensionReasoningScore

Specificity

The description names concrete review targets and actions — 'stay isolated to guypod/goof-factory without broadening access, deployment, or execution from untrusted input' — checking specific boundaries rather than vague domains. It falls short of a 5 because it does not enumerate the distinct review checks (repository boundary, external input, access, demo exposure) that the body actually covers.

4 / 5

Completeness

Both parts are present: the 'what' is clear (review changes for isolation of the demo, factory automation, and remediation loop) and the 'when' is explicit ('Use as one lens in a code review run'). It is not a 5 because the 'when' is generic — it never states which kinds of changes (workflows, automation, deployment paths) should prompt use of this lens.

4 / 5

Trigger Term Quality

It includes some natural phrases ('Review changes', 'code review run') but misses common variations users would say such as 'pull request', 'PR', 'security review', or 'workflow/CI changes'. Repo-specific jargon like 'Tessl factory automation' and 'OSS remediation loop' is not language a user naturally types when requesting the skill.

3 / 5

Distinctiveness Conflict Risk

The tight binding to 'guypod/goof-factory' and its named components gives a clear, distinct niche with minimal confusion risk. Minor overlap remains with generic code-review and security-review skills because the trigger ('one lens in a code review run') fires during any review run, keeping it below a 5.

4 / 5

Total

15

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

guypod/goof-factory

Path

review-lenses/review-demo-automation-isolation/SKILL.md

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.