CtrlK
BlogDocsLog inGet started
Tessl Logo

1k-architecture

OneKey monorepo architecture, project structure, package relationships, and import hierarchy rules.

52

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./.skillshare/skills/1k-architecture/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 solid, well-organized architecture reference whose strongest material — the package map, naming conventions, and import hierarchy rules — is specific and immediately usable. Its weaknesses are redundancy (the violations list and repeated suffix rules), a generic process-framework back half that restates practices Claude already follows, and the absence of any executable verification for the rules it labels 'STRICTLY ENFORCED'.

Suggestions

Delete the 'COMMON VIOLATIONS TO AVOID' section — it is the exact inverse of the hierarchy stated immediately above — and merge the duplicated platform-suffix lines (lines 27 and 34).

Trim or split off the 'Deep Analysis & Architecture Consistency Framework': keep only OneKey-specific checks (hierarchy, platform suffixes, package placement) and drop generic advice like 'Find Similar Examples' and 'Match existing code style' that Claude already does by default.

Make the import hierarchy verifiable: name the actual command or check (e.g. an ESLint import rule, madge, or a repo script) and add a feedback loop to the pre-commit checklist ('if the check fails, move the code to the package that may import it and re-run').

DimensionReasoningScore

Conciseness

The first half (platform structure, core packages, import hierarchy) is lean, specific, and every token earns its place, but there is noticeable padding: the 'COMMON VIOLATIONS TO AVOID' list restates the exact inverse of the hierarchy rules directly above it, platform file suffixes are stated twice (lines 27 and 34), and the 'Deep Analysis & Architecture Consistency Framework' explains generic practice Claude already knows ('Find Similar Examples: Search codebase for similar implementations', 'Match existing code style'). This fits anchor 3 — mostly efficient with unnecessary explanation that could be tightened — rather than 2 because the core architectural content is dense and un padded.

3 / 5

Actionability

Concrete and specific throughout: exact package paths ('packages/core/src/chains/'), exact workspace names in the hierarchy, concrete file-suffix conventions ('.native.ts', '.web.ts'), and one executable command ('yarn why <package>'). Per the rubric's instruction-skill note, absence of code is not penalized since the guidance is actionable; the gap keeping it from 5 is that key checks have no executable mechanism — e.g. 'Check if the import creates a circular dependency' names the step but gives no command or tool to actually perform it, and the analysis protocol steps are abstract directives ('Evaluate runtime performance effects').

4 / 5

Workflow Clarity

The 'Pre-Modification Analysis Protocol' provides a clear numbered sequence (scope impact, pattern consistency, architecture integrity, performance) and the 'Architecture Validation Checklist' gives an explicit pre-commit checkpoint. However, checkpoints are largely implicit for the highest-stakes rule — the 'STRICTLY ENFORCED' import hierarchy has no verification mechanism (no lint command, script, or check to run), and there is no feedback loop describing what to do when a check fails. This matches anchor 3 (steps listed but validation gaps) rather than 4, whose example pairs each step with an executable verification command; it is above anchor 2 because the sequences are well-defined, not rough.

3 / 5

Progressive Disclosure

The body (~120 lines) is well-sectioned with clear headers, bold labels, and consistent formatting, and no bundle files exist so there are no broken or nested references to penalize. It fits anchor 4 (good structure, most content appropriately placed, minor organization gaps): the overview, conventions, and hierarchy are appropriately inline for a single-file architecture skill, though the generic 'Deep Analysis & Architecture Consistency Framework' (about half the body) is a candidate for a separate reference file. Not 5 because the one-level-deep reference pattern of anchor 5 is absent and the framework section dilutes the overview's focus.

4 / 5

Total

14

/

20

Passed

Description

53%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 domain-specific, clearly identifying this as OneKey monorepo documentation, but it reads as a topic list rather than a capability statement and entirely lacks a 'Use when...' trigger clause. Adding explicit trigger conditions and natural-language synonyms would substantially improve completeness and trigger-term quality.

Suggestions

Add an explicit trigger clause, e.g. 'Use when navigating the OneKey codebase, adding cross-package imports, deciding where new code belongs, or resolving circular dependency errors.'

Reframe as third-person actions with natural synonyms: 'Documents the OneKey monorepo layout (apps/, packages/), explains where code lives, and enforces package import hierarchy rules.'

Include common user phrasings like 'monorepo structure', 'package layout', 'circular dependency' to widen trigger-term coverage.

DimensionReasoningScore

Specificity

The description names the domain ('OneKey monorepo') and specific topics ('architecture, project structure, package relationships, and import hierarchy rules'), but uses noun phrases rather than concrete actions — there is no verb describing what the skill actually does with these things. It sits between anchor 2 (domain named, actions minimal) and anchor 4 (several specific actions listed): the topics are specific, but nothing is framed as a capability or action.

3 / 5

Completeness

The 'what' is clear (documents the OneKey monorepo's architecture, structure, package relationships, and import rules), but there is no 'Use when...' clause or equivalent trigger guidance — per the judging guidelines, a missing 'Use when' clause caps completeness at 3. It is not below 3 because the 'what' half is specific and unambiguous.

3 / 5

Trigger Term Quality

'architecture', 'project structure', 'package relationships', and 'import hierarchy' are relevant keywords a developer might say, but common natural variations are missing — e.g. 'monorepo layout', 'where does X live', 'package structure', 'circular dependencies', 'codebase organization'. This matches anchor 3: some relevant keywords but missing common variations or synonyms.

3 / 5

Distinctiveness Conflict Risk

Scoping to the 'OneKey monorepo' gives it a clear niche with minimal conflict risk against skills for other codebases. It falls short of anchor 5 because the generic terms 'architecture' and 'project structure' (without any explicit trigger phrasing) could pull in general architecture-organization queries, leaving minor overlap risk with closely related skills.

4 / 5

Total

13

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

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

Warning

Total

15

/

16

Passed

Repository
OneKeyHQ/app-monorepo
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.