CtrlK
BlogDocsLog inGet started
Tessl Logo

agent-v3-security-architect

Agent skill for v3-security-architect - invoke with $agent-v3-security-architect

62

1.36x
Quality

45%

Does it follow best practices?

Impact

93%

1.36x

Average score across 3 eval scenarios

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/agent-v3-security-architect/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

61%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 competent security-remediation brief: concrete code patterns, per-CVE fix plans with files and timelines, and defined validation criteria. Its weaknesses are structural rather than substantive — implicit workflow sequencing without feedback loops, some decorative padding, corrupted path/dependency tokens, and a malformed double frontmatter block (lines 6–44) that leaks scaffolding metadata and hook scripts into the content.

Suggestions

Turn the Phase 1 plan into an ordered, numbered workflow with explicit checkpoints — e.g. "1. Update deps in package.json 2. Validate: npm audit shows 0 high/critical 3. Only when clean, move to CVE-2" — which would lift workflow_clarity from 3 to 4-5.

Repair the corrupted path/dependency tokens ("api$auth-service.ts" → "api/auth-service.ts", "2>$dev$null" → "2>/dev/null", "@anthropic-ai$claude-code@^2.0.31") and replace vague file scopes like "All file operation modules" with named files or a discovery command.

Trim the mission prose and ASCII threat-model box, move the Secure Patterns Catalog into a one-level-deep reference file, and relocate the leaked second YAML block (version/date metadata and hook scripts) out of the markdown body.

DimensionReasoningScore

Conciseness

The body is mostly dense checklists and executable code, but carries trimmable padding: the "Critical Security Mission" prose paragraph, an ASCII-art threat-model box that conveys nothing the four bullet items under it don't, emoji-laden headers, and time-sensitive version/date data ("3.0.0-alpha", "updated 2026-01-04") that sits outside any deprecated/old-patterns section. It avoids explaining concepts Claude already knows, so it stays at 3 rather than 2.

3 / 5

Actionability

The three TypeScript patterns (Zod TaskInputSchema, securePath() with prefix validation, execFile with shell:false) are concrete and executable, and each CVE entry pairs an action with files and a timeline. Minor gaps keep it from 5: path tokens are corrupted as written ("api$auth-service.ts:580-588", "@anthropic-ai$claude-code@^2.0.31", "2>$dev$null"), and "Files: All file operation modules" is too vague to act on directly.

4 / 5

Workflow Clarity

Sequence exists only implicitly via "Timeline: Phase 1 Week 1/2" labels and deliverable checklists, and the Validation Criteria section names end-states ("npm audit shows 0 high$critical vulnerabilities") without wiring them into ordered steps or a validate→fix→retry loop. For batch security-remediation work this matches anchor 3 — steps present, checkpoints missing or implicit.

3 / 5

Progressive Disclosure

A single-file skill (~135 body lines) with clear, navigable section headers and no dangling or nested references — the .md files named under Deliverables are outputs to produce, not pointers to follow. Not 5 because the Secure Patterns Catalog and per-CVE detail are bulky enough that a well-signaled split into one-level-deep reference files (e.g. SECURE-PATTERNS reference) would serve better than inlining everything.

4 / 5

Total

14

/

20

Passed

Description

28%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 auto-generated wrapper text that communicates only how to invoke the skill, not what it does or when to use it. It fails both core jobs of a description: concrete capability statements and natural-language trigger conditions.

Suggestions

Replace the wrapper text with the substantive capability list already written in the body: e.g. "Designs security architecture, builds threat models, and plans CVE remediation (weak hashing, command injection, path traversal, vulnerable dependencies)." — this alone would lift specificity from 2 to 4.

Add an explicit "Use when..." clause with natural user phrasing, e.g. "Use when the user mentions security vulnerabilities, CVEs, threat modeling, hardening authentication, or auditing dependencies."

Drop the "$agent-v3-security-architect" invocation token — users never say it, so it contributes only jargon and no trigger value.

DimensionReasoningScore

Specificity

"Agent skill for v3-security-architect - invoke with $agent-v3-security-architect" names the domain but lists zero concrete actions — threat modeling, CVE remediation, and secure-pattern work described in the body are entirely absent from the description. It fits anchor 2 (domain named, actions minimal/generic), not 3, because no concrete capability is stated at all.

2 / 5

Completeness

The "what" is a vague restatement of the skill's own name ("Agent skill for v3-security-architect") and there is no "when" — the invoke clause is an invocation instruction, not a use-condition, so the missing-"Use when" cap applies hard. Not 1, since a domain-level what is present.

2 / 5

Trigger Term Quality

"invoke with $agent-v3-security-architect" is invocation scaffolding jargon rather than language a user would naturally say when needing security help; natural terms like "vulnerability", "CVE", "threat model", or "security audit" never appear. It edges above anchor 1 only because the role name itself gestures at the security domain.

2 / 5

Distinctiveness Conflict Risk

The niche ("v3-security-architect") is specific, but the boilerplate "Agent skill for X - invoke with $X" template would trigger identically across a whole family of sibling agent-wrapper skills. Somewhat specific yet real overlap risk with similar skills — anchor 3.

3 / 5

Total

9

/

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
ruvnet/ruflo
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.