CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

common-architecture-audit

Audit structural debt, logic leakage, and monolithic components across Web, Mobile, and Backend codebases. Use when reviewing architecture, assessing tech debt, detecting logic in wrong layers, or identifying God classes.

64

Quality

80%

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 ./.agents/skills/common/common-architecture-audit/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 genuinely lean, actionable audit skill: numbered workflow, per-ecosystem grep commands, quantified thresholds, and a scoring rubric. The main defects are a dangling 'Priority: P1' heading, a missing decision threshold for the backend leakage grep, and a bundle organization gap where detection.md is orphaned from SKILL.md while its content is partially re-inlined in the body.

Suggestions

Link references/detection.md from the body (e.g., in section 2, 'See [framework detection](references/detection.md) for the manifest-to-source-directory mapping ($SRC) for each ecosystem') instead of hardcoding per-ecosystem paths like lib/widgets and src/controllers, which both duplicates and fragments the reference's systematic table.

Remove or contextualize the orphaned '## **Priority: P1 (HIGH)**' heading, and give the backend leakage grep an explicit decision threshold like the Web rule (e.g., 'count > 0 per controller = High Debt') so all three ecosystems have actionable rules.

Tighten awkward phrasing that impedes execution: replace 'Resources > 1,000 lines require granulation' with plain language (e.g., 'split resource files over 1,000 lines'), and rewrite the double-negative Anti-Patterns entries as direct imperatives.

DimensionReasoningScore

Conciseness

The body is lean: it never explains concepts Claude already knows (no 'what is SRP' padding), and each section is a compact rule set with thresholds and one-line grep commands. Not a 5 due to minor noise that could be trimmed: the orphaned '## **Priority: P1 (HIGH)**' heading carries no actionable content, and awkward phrasing ('Resources > 1,000 lines require granulation', 'No applying generic patterns over project-specific rules') forces re-reading.

4 / 5

Actionability

Mostly executable guidance: concrete grep pipelines per ecosystem (e.g. 'grep -rE "useEffect|useState|useMemo" components --include="*.tsx" | wc -l') plus decision rules ('components/ hook count > 20x hooks/ folder, architecture monolithic', '> 1,500 lines indicates "God Class"'). Not a 5 because the Web and Mobile rules have thresholds while the Backend grep yields a count with no action threshold ('Controllers must only handle request parsing' is a principle, not a decision rule), and step 1's duplication detection is described rather than given as a runnable command in the body.

4 / 5

Workflow Clarity

A clear numbered sequence (1 duplication → 2 logic leakage → 3 monoliths → 4 resources) terminates in a quantified 'Scoring Impact' rubric (-15 per layer violation, -10 per monolith), which serves as the output checkpoint. Not a 5 because there are no explicit validation or verification steps for the audit findings (e.g., confirm flagged files against remediation patterns before reporting), though the read-only nature of the audit keeps this at minor-gap level rather than triggering the destructive/batch cap.

4 / 5

Progressive Disclosure

Structure exists and the two cited references (references/implementation.md, linked three times with section-specific context; references/PATTERNS.md) are clearly signaled and one level deep. However, the bundle's references/detection.md — a systematic manifest-to-directory-structure table — is never referenced from SKILL.md, while the body hardcodes per-ecosystem paths (lib/widgets, src/controllers, components/) that this file systematically maps. That is inline content that should live behind a clearly signaled reference, matching 'some structure; references present but not clearly signaled; content that should be separate is inline' more closely than the anchor-4 'minor organization gaps'.

3 / 5

Total

15

/

20

Passed

Description

83%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 strong description in third-person voice with an explicit 'Use when' clause, concrete capability nouns, and distinctive niche terminology ('God classes', 'logic in wrong layers'). Its only weaknesses are that capability coverage is slightly narrower than the body's actual scope and a few natural trigger synonyms (code review, refactor, monolith) live in metadata triggers rather than in the description text.

DimensionReasoningScore

Specificity

Names the domain ('Web, Mobile, and Backend codebases') and three concrete audit targets ('structural debt, logic leakage, and monolithic components'), which matches the 'several specific actions; minor gaps in coverage' anchor. Not a 5 because the three targets are audit categories rather than a comprehensive list of distinct concrete actions (no mention of e.g. duplication detection or resource/performance auditing, which the body actually covers).

4 / 5

Completeness

Explicitly answers both questions: the 'what' is 'Audit structural debt, logic leakage, and monolithic components across Web, Mobile, and Backend codebases' and the 'when' is a concrete 'Use when' clause listing four trigger scenarios. This matches the top anchor's pattern ('what' + 'Use when...' with concrete trigger phrases), and it is well above the anchor 4 where the 'when' is present but only vaguely specified.

5 / 5

Trigger Term Quality

The 'Use when' clause includes natural phrases users would say: 'reviewing architecture, assessing tech debt, detecting logic in wrong layers, or identifying God classes'. Not a 5 because common variations users would plausibly say — 'code review', 'refactor', 'monolith', 'layer separation' — appear only in the metadata triggers, not in the description itself.

4 / 5

Distinctiveness Conflict Risk

Distinctive niche vocabulary ('logic in wrong layers', 'God classes', 'structural debt') clearly separates it from generic skills, matching 'mostly distinct; minor overlap risk'. Not a 5 because 'reviewing architecture' and 'tech debt' overlap with general code-review/refactoring skills, and the broad three-ecosystem scope widens the collision surface slightly.

4 / 5

Total

17

/

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

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

Total

14

/

16

Passed

Repository

HoangNguyen0403/agent-skills-standard

Path

.agents/skills/common/common-architecture-audit/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.