component-identification-sizing

Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

65%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable with executable code and concrete rules, but it is over-long, restates known concepts, lacks explicit validation checkpoints in its analysis workflow, and keeps all content in one monolithic file. Tightening and splitting reference material would lift the weaker dimensions.

Suggestions

Move language-specific statement-counting rules, the fitness-function code, and the output-format templates into reference files (e.g. references/counting-rules.md, scripts/fitness-functions.js) and link to them one level deep, reducing SKILL.md to a concise overview.

Trim restatements of known concepts (the standard-deviation formula, the definition of 'statements', basic component explanation) and collapse the redundant Quick Start examples that repeat the Phase 1-3 process.

Add explicit validation checkpoints to the analysis workflow, e.g. 'Confirm all leaf nodes are detected before sizing' and 'Verify summed component statements equal the total before computing percentages.'

Dimension	Reasoning	Score
Conciseness	At ~430 lines it restates concepts Claude already knows (the mean/standard-deviation formula, definitions of 'statements', what a component is) and pads with redundant Quick Start examples and multiple output mockups, so it is mostly efficient but could be tightened rather than the lean anchor at 3.	2 / 3
Actionability	It provides fully executable JavaScript fitness-function code, explicit threshold rules, real directory/package examples, and language-specific counting rules that are copy-paste ready, matching the executable-code anchor at 3 rather than the pseudocode anchor at 2.	3 / 3
Workflow Clarity	Phases 1-3 are sequenced with a checklist, but validation checkpoints are implicit (e.g., no 'verify leaf-node detection before sizing' or 're-check totals after counting' steps), fitting the anchor for sequence present but checkpoints missing rather than the explicit-validation anchor at 3.	2 / 3
Progressive Disclosure	There are no bundle files and the entire skill is a single ~430-line SKILL.md, so content that should be separate — language-specific counting rules, fitness functions, output templates — is inline; the simple-skill carve-out does not apply given the length, leaving it at the 'structure present but content inline' anchor rather than 3.	2 / 3
	Total	9 / 12 Passed

Description

100%

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 exemplary: concrete third-person capabilities, natural trigger phrases, explicit use/boundaries, and a clear niche that avoids conflicts. No improvements needed.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete actions in third person — 'Maps architectural components', 'measures their size', 'identify what should be extracted first' — matching the anchor for several specific concrete actions rather than the partial domain-only anchor at 2.	3 / 3
Completeness	It answers both 'what' (map components, measure size, identify extraction candidates) and 'when' with an explicit 'Use when' clause plus a 'Do NOT use for' boundary, satisfying the explicit-trigger anchor rather than the implied-when anchor at 2.	3 / 3
Trigger Term Quality	It provides natural phrasings a user would actually say — 'how big is each module?', 'what components do I have?', 'which service is too large?', 'size my monolith' — giving good coverage rather than the sparse keyword set of anchor 2.	3 / 3
Distinctiveness Conflict Risk	The architectural-sizing-for-decomposition niche is distinct, and the explicit 'Do NOT use for runtime performance sizing or infrastructure capacity planning' boundary makes conflict with adjacent skills unlikely, matching the clear-niche anchor.	3 / 3
	Total	12 / 12 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: tech-leads-club/agent-skills
Commit: 9026164

Reviewed: 4 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.