Dynamic multi-repo and monorepo awareness for Claude Code. Analyze workspace topology, track API contracts, and maintain cross-repo context.
42
30%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/workspace/SKILL.mdQuality
Discovery
32%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 identifies a clear domain (multi-repo and monorepo workspaces) and lists some relevant capabilities, but the actions described are abstract rather than concrete. The most significant weakness is the complete absence of a 'Use when...' clause, making it unclear when Claude should select this skill. The trigger terms lean technical and miss common natural language variations.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user is working across multiple repositories, asks about dependencies between repos, or needs to understand how changes in one repo affect another.'
Replace abstract phrases like 'analyze workspace topology' and 'maintain cross-repo context' with concrete actions such as 'map inter-repo dependencies', 'detect breaking API changes across services', or 'identify shared libraries and their consumers'.
Include natural language trigger terms users might say, such as 'multiple repositories', 'microservices', 'dependency graph', 'breaking changes', or 'shared packages'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (multi-repo/monorepo workspaces) and some actions ('analyze workspace topology', 'track API contracts', 'maintain cross-repo context'), but these are somewhat abstract rather than concrete, actionable operations like 'detect breaking changes' or 'map dependency graphs'. | 2 / 3 |
Completeness | Describes what it does (analyze topology, track contracts, maintain context) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also somewhat vague, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'multi-repo', 'monorepo', 'API contracts', and 'cross-repo', which are useful but somewhat technical. Missing common natural language variations users might say like 'multiple repositories', 'workspace', 'dependencies between repos', or 'microservices'. | 2 / 3 |
Distinctiveness Conflict Risk | The multi-repo/monorepo focus provides some distinctiveness, but terms like 'workspace awareness' and 'cross-repo context' are broad enough to potentially overlap with general project navigation or dependency management skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is comprehensive in scope but severely undermined by its verbosity — it's a reference manual masquerading as a skill file. The extensive inline artifact format examples (5 full document templates) consume the majority of the content and should be split into separate reference files. While the detection commands and CI integration are concrete and useful, the core analysis workflow lacks executable completeness and proper validation checkpoints.
Suggestions
Move all artifact format examples (TOPOLOGY.md, CONTRACTS.md, DEPENDENCY_GRAPH.md, KEY_FILES.md, CROSS_REPO_INDEX.md templates) into a separate ARTIFACT_FORMATS.md reference file, keeping only a brief summary table in the main skill
Move the CI/CD integration section (GitHub Actions, pre-commit hooks) into a separate WORKSPACE_CI.md file referenced from the main skill
Add explicit validation/verification steps to the analysis protocol phases — e.g., after Phase 3 contract extraction, validate that extracted contracts match actual endpoints before generating artifacts
Remove explanatory content Claude already knows (what monorepos are, how symlinks work, what API contracts are) and reduce the problem statement section to 2-3 lines
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~600+ lines. Contains extensive ASCII diagrams, lengthy example outputs for every artifact format (TOPOLOGY.md, CONTRACTS.md, DEPENDENCY_GRAPH.md, KEY_FILES.md, CROSS_REPO_INDEX.md), and explains concepts Claude already understands like what monorepos are, how symlinks work, and what API contracts are. The token budget section ironically wastes tokens explaining token budgets. Most of this content should be in referenced files, not inline. | 1 / 3 |
Actionability | Contains concrete bash commands for detection and a real GitHub Actions workflow, but the core analysis protocol is more of a conceptual framework than executable guidance. The 'phases' describe what to do at a high level with checklists and grep commands, but lack complete executable scripts. The commands section defers to external files ('See commands/analyze-workspace.md') without providing the actual implementation. | 2 / 3 |
Workflow Clarity | The four-phase analysis protocol provides a clear sequence, and the freshness tiers define when actions trigger. However, validation checkpoints are weak — the cross-repo change detection shows a UI mockup rather than actual validation steps, and the contract sync workflow lacks explicit error recovery loops. The pre-push validation gate is described but not fully specified. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with all artifact format examples fully inline. The TOPOLOGY.md, CONTRACTS.md, DEPENDENCY_GRAPH.md, KEY_FILES.md, and CROSS_REPO_INDEX.md format examples alone consume hundreds of lines that should be in separate reference files. While it does reference external command files, the main document itself fails to practice the progressive disclosure it preaches. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (972 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
d4ddb03
Table of Contents
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.