code-import

Read an existing repository's structure into the project cwd as a normalised snapshot the agent can analyse without re-walking the tree on every turn.

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/_official/atoms/code-import/SKILL.md

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 body is a tight, well-structured spec: precise inputs, an exact output schema, explicit convergence/validation criteria, and concrete anti-pattern rules with no filler. Its main limitation is that it describes what the daemon implementation does rather than giving the reader executable steps, and it cites external spec sections the reader cannot navigate to.

Suggestions

Either add one or two executable commands/steps (e.g. how to invoke `od project import` and confirm the snapshot) or explicitly state that the atom runs automatically so the reader knows no action is required.

Replace or link the "Spec §10 / §21.3.2" provenance reference with a resolvable path, since the cited spec document is not in the skill bundle.

Drop the sentence restating the re-walking motivation (already in the description) to save tokens and tighten the opening further.

Dimension	Reasoning	Score
Conciseness	The body is lean: no explanation of concepts Claude already knows, and each section (Inputs, Output, Convergence, Anti-patterns, Status) earns its tokens. Minor trimmable padding exists ("The point is to stop re-walking the tree on every turn" repeats the frontmatter description, and the Spec §10/§21.3.2 provenance line is internal bookkeeping), keeping it below the 'every token earns its place' anchor at 5.	4 / 5
Actionability	Guidance is concrete: an exact output tree with per-file JSON shapes, named inputs with sources, exclusion rules (node_modules/.git/.next/dist/build), framework-evidence requirements (declared dep + next.config./vite.config.), and a 60s default budget. It stops short of fully executable, copy-paste-ready instruction because the actual work is delegated to the daemon implementation rather than given as commands/steps the reader executes.	4 / 5
Workflow Clarity	There is an explicit validation checkpoint and error-recovery path: "completes when code/index.json exists and contains at least one entry. Empty repos abort with a clear error event so the user re-imports", plus the skipped-paths record for exclusions. However the sequence of steps is implicit rather than enumerated, and there is no intermediate validate-and-retry loop for the walk itself, so it does not reach the anchor at 5.	4 / 5
Progressive Disclosure	For a short single-purpose skill with no bundle files, the sectioned structure (Inputs / Output / Convergence / Anti-patterns / Status) is well organized and all content is appropriately inline; the implementation pointer (apps/daemon/src/plugins/atoms/code-import.ts) is clearly signalled. It falls just short of 5 because the body is marginally over the minimal length and the Spec §10 / §21.3.2 references point to external documentation that is not included or linked as a readable reference.	4 / 5
	Total	16 / 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 communicates a clear, concrete purpose in a single efficient sentence, but it omits any explicit trigger guidance (no 'Use when...' clause) and leans on internal vocabulary rather than natural user phrasing. Adding a trigger clause and a couple of plain-language keywords would materially raise completeness and trigger-term quality.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to import, snapshot, or analyse an existing repository or codebase before a migration/rewrite task."

Include natural synonyms users would actually say ("import a repo", "scan this codebase", "analyse the project") alongside the technical terms.

Briefly enumerate the outputs (index of files/imports, detected components, routes) so the 'what' covers more of the skill's capabilities.

Dimension	Reasoning	Score
Specificity	The description names the domain (repository structure) and one-to-two concrete actions ("Read an existing repository's structure into the project cwd as a normalised snapshot"), but coverage is not comprehensive — detection of components/routes/framework or the written index files are never mentioned. It sits above the 'names domain only' anchor (2) because the snapshot-without-re-walking action is concrete, and below 4 because there are clear gaps in the actions listed.	3 / 5
Completeness	The 'what' is clearly stated (read repo structure into a normalised on-disk snapshot), but there is no 'Use when...' clause or equivalent trigger guidance, capping completeness at 3 per the judging guidelines. Not 2 because the 'what' is concrete rather than vague; not 4 because the 'when' is entirely missing rather than weakly implied.	3 / 5
Trigger Term Quality	Relevant keywords exist ("repository's structure", "snapshot", "normalised", "re-walking the tree") but they are largely internal/technical phrasing rather than natural user utterances like "import a repo", "analyse this codebase", or file extensions. This matches the 'some relevant keywords but missing common variations or synonyms' anchor; not 4 because natural trigger phrases a user would actually say are largely absent.	3 / 5
Distinctiveness Conflict Risk	The snapshot/normalised-import niche is fairly distinct ("normalised snapshot", "without re-walking the tree") and unlikely to trigger for unrelated skills, with only minor overlap risk against generic code-analysis skills. Not 5 because 'read a repository's structure' is broad enough that code-analysis or repo-review skills could plausibly compete for the same trigger.	4 / 5
	Total	13 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: nexu-io/open-design
Path: plugins/_official/atoms/code-import/SKILL.md
Commit: 1b47e60

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.