CtrlK
BlogDocsLog inGet started
Tessl Logo

octopus-architecture

Review system architecture, simplify boundaries, or compare interface designs from repository evidence

60

Quality

70%

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

Fix and improve this skill with Tessl

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

Quality

Content

75%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 content is an efficient, well-structured instruction skill that gives concrete procedural guidance with grounding gates and a clear deliverable contract. It scores consistently at 4 across all dimensions, held back from 5 by minor over-explanation, the lack of a worked example, and external references that cannot be verified against a local bundle.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence, giving procedural directives rather than explaining what architecture or LSP is; not a 5 because the host-adapter blockquote and the 'Transport diversity does not prove model family diversity' aside could be trimmed or moved to a referenced file.

4 / 5

Actionability

It gives concrete, specific instructions for an instruction-only skill: pin the source revision, inspect five named evidence sources, produce Draft A/B with defined properties, and return six named deliverables plus a keep/simplify/investigate decision; below 5 because no worked example or minimal template ties the steps together.

4 / 5

Workflow Clarity

A clear sequence runs from method selection through producing drafts to the Completion deliverables, with grounding gates ('simplify requires exact source evidence and a concrete caller example', report incomplete reviewer coverage); below 5 because there is no explicit validate-then-retry feedback loop, though the task is non-destructive so no 3-cap applies.

4 / 5

Progressive Disclosure

The body is a well-sectioned overview (Method, Completion, LSP Integration) pointing one level deep to plugin blocks like engineering-method-selection.md and architecture-simplification.md; below 5 because those references are external plugin paths with no local bundle files present to verify, and THIRD_PARTY_NOTICES.md is named but not bundled.

4 / 5

Total

16

/

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.

The description is concise and names three concrete architectural actions grounded in repository evidence, giving it good specificity and distinctiveness. Its main weakness is the absence of any explicit 'Use when...' trigger guidance, which caps completeness at 3.

Suggestions

Add an explicit 'when' clause, e.g. 'Use when reviewing a system's module boundaries, proposing an interface simplification, or comparing two interface designs from code evidence.'

Broaden trigger coverage with natural synonyms users say ('API design', 'refactor boundaries', 'module coupling', 'caller surface') to lift trigger-term quality toward 5.

Tighten the distinctiveness by naming the artifact type (e.g. 'module/interface boundaries') so it cannot be confused with general code review.

DimensionReasoningScore

Specificity

The phrase 'Review system architecture, simplify boundaries, or compare interface designs from repository evidence' names the domain plus three concrete actions (review, simplify, compare) grounded in 'repository evidence'; not a full 5 because the actions stay at a fairly broad architectural altitude without naming concrete artifacts.

4 / 5

Completeness

It clearly answers 'what' (review/simplify/compare architecture) but offers no 'Use when...' clause or equivalent explicit trigger guidance, so per the rubric guideline completeness is capped at 3; it is not 2 because the 'what' is concrete rather than vague.

3 / 5

Trigger Term Quality

It surfaces natural developer phrasings like 'system architecture', 'simplify boundaries', 'interface designs', and 'repository evidence' that a user would plausibly say; below 5 because synonyms and broader trigger variants (e.g. 'refactor boundary', 'API design', 'module coupling') are absent.

4 / 5

Distinctiveness Conflict Risk

'Architecture review' is a fairly distinct niche with its own trigger surface and low conflict risk; below 5 because it could still overlap with general code-review or refactoring skills on broad phrasings.

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
nyldn/claude-octopus
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.