CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

create-architecture

Author the architecture blueprint before code is written. Validates decisions against the pinned engine, flags knowledge gaps.

Quality

72%

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 ./.claude/skills/create-architecture/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

85%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 well-structured orchestration overview: it sequences nine phases through clearly signaled, verified, one-level-deep reference files, defines explicit approval checkpoints and crash-recovery state, and stays lean by assuming competence and delegating detail. Its only weaknesses are mild — repeated per-phase boilerplate and a convoluted docs.density paragraph — with executable specifics largely delegated to the reference bundle.

DimensionReasoningScore

Conciseness

The body assumes Claude's competence — it never explains what an architecture document is — and stays lean by delegating all phase steps to reference files. Minor over-explanation could be trimmed: the per-phase boilerplate "Read it again if the conversation was compacted or resumed during this phase" is repeated nine times, and the docs.density paragraph is convoluted. This sits at anchor 4 (efficient, minor trimmable instances) rather than 5, and well above 3 (no padded or unnecessary concept explanations).

4 / 5

Actionability

Guidance is concrete and executable for an instruction-orchestration skill: exact paths ("docs/architecture/architecture.md", "production/session-state/active.md"), a runnable hook command with explicit config keys ("resolve_config --keys review_mode,automation,workflow,docs.density"), and a specified structured-ask pattern ("Use the structured tool with labeled options [A]/[B]/[C]"). It is not anchor 5 because the per-phase executable detail lives entirely in the reference files, leaving minor gaps in the body itself.

4 / 5

Workflow Clarity

Phases 0–8 are explicitly sequenced, each pointing to exactly one reference file, with explicit validation checkpoints: "Draft before approval — show the content inline before asking to write it", "One write, after every section is approved", session-state recording "so a crash loses no decision", and a defined Phase 7b revision loop for re-drafted sections. This matches anchor 5's clear sequence with explicit validation steps and error-recovery loops; this is document authoring, not a destructive or batch operation, so no cap applies.

5 / 5

Progressive Disclosure

The body is a pure overview: 9 numbered phases each with a clearly signaled, one-level-deep reference ("Read `references/0-load-context.md` now and follow it"), and all nine referenced files exist with substantial content (verified). Grep confirms no reference file links onward to another reference, so navigation is flat and easy. This matches anchor 5 (clear overview, well-signaled one-level-deep references, appropriately split content).

5 / 5

Total

18

/

20

Passed

Description

50%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 grammatical, third-person, and concise, with a clear 'what' and a domain-specific hook ("pinned engine"). However, it lacks any explicit 'Use when...' trigger clause, its actions are abstract rather than concrete, and it neither covers the skill's actual scope (layers, data flow, API boundaries, ADR audit) nor distinguishes it from the adjacent /architecture-decision and /architecture-review skills.

Suggestions

Add an explicit trigger clause, e.g., "Use when starting a project before implementation begins, when the user asks for an architecture blueprint, system design, or technical design doc."

Enumerate the concrete deliverables/sections (system layers, module ownership, data flow, API boundaries, ADR audit) instead of abstract verbs like "author" and "validates", so users can tell what the skill actually produces.

Differentiate from sibling skills in the description itself (e.g., "Creates the whole-system blueprint; use /architecture-decision for individual ADRs") to reduce trigger overlap.

DimensionReasoningScore

Specificity

The description lists three actions ("Author the architecture blueprint", "Validates decisions against the pinned engine", "flags knowledge gaps"), but these are abstract verbs rather than concrete operations, and it omits the major capabilities the body documents (layer mapping, data flow, API boundaries, ADR audit) — a coverage gap larger than 'minor'. It names the domain plus a couple of actions but is not comprehensive, matching anchor 3 rather than 4.

3 / 5

Completeness

The 'what' is clear ("Author the architecture blueprint"), but there is no 'Use when...' clause or equivalent explicit trigger guidance; "before code is written" states a lifecycle stage, only weakly implying when to invoke the skill. Per the judging guidelines, a missing 'Use when' clause caps completeness at 3.

3 / 5

Trigger Term Quality

"architecture blueprint" and "pinned engine" are relevant domain terms a user might say, but the description misses common natural variations and synonyms (e.g., "system design", "tech spec", "design doc", "technical architecture"). Some relevant keywords with missing synonyms matches anchor 3, not 4 (good coverage with only a few gaps).

3 / 5

Distinctiveness Conflict Risk

"Validates decisions against the pinned engine" carves out a niche, but the description does not distinguish this skill from its siblings — the body itself references "/architecture-decision" and "/architecture-review", which cover adjacent architecture territory and would compete for the same triggers. Somewhat specific with real overlap risk matches anchor 3; it is not anchor 4 because the overlap is with closely related, same-family skills rather than a minor edge case.

3 / 5

Total

12

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

Donchitos/Claude-Code-Game-Studios

Path

.claude/skills/create-architecture/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.