github-multi-repo
Multi-repository coordination, synchronization, and architecture management with AI swarm orchestration
Install with Tessl CLI
npx tessl i github:ruvnet/agentic-flow --skill github-multi-repo36
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
17%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 too abstract and jargon-heavy, failing to provide concrete actions or explicit usage triggers. While it identifies a domain (multi-repository work), the buzzword 'AI swarm orchestration' adds confusion rather than clarity. The lack of a 'Use when...' clause makes it difficult for Claude to know when to select this skill.
Suggestions
Add a 'Use when...' clause with natural trigger terms like 'sync multiple repos', 'cross-repository changes', 'coordinate branches across projects'
Replace abstract terms with concrete actions: instead of 'coordination and synchronization', specify 'propagate changes across repos, manage shared dependencies, coordinate releases'
Clarify or remove 'AI swarm orchestration' - either explain what this means in practical terms or remove the buzzword entirely
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (multi-repository) and mentions some actions (coordination, synchronization, architecture management), but these are fairly abstract. 'AI swarm orchestration' is vague and doesn't describe concrete actions like 'merge branches' or 'sync dependencies'. | 2 / 3 |
Completeness | Only addresses 'what' at a high level with no 'Use when...' clause or explicit trigger guidance. Users cannot determine when this skill should be selected over others. | 1 / 3 |
Trigger Term Quality | Uses technical jargon ('AI swarm orchestration', 'architecture management') that users are unlikely to naturally say. Missing common terms users would use like 'monorepo', 'sync repos', 'cross-repo changes', or 'multiple repositories'. | 1 / 3 |
Distinctiveness Conflict Risk | 'Multi-repository' provides some specificity, but 'coordination', 'synchronization', and 'architecture management' are broad terms that could overlap with general git skills, CI/CD skills, or project management skills. | 2 / 3 |
Total | 6 / 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 suffers from severe verbosity, attempting to document an entire multi-repository coordination system in a single massive file. While it provides numerous examples, they mix real and pseudo-code without clear distinction, and the lack of validation checkpoints in destructive operations is concerning. The content would benefit greatly from being split into focused sub-documents with a concise overview.
Suggestions
Reduce content by 70%+ by extracting detailed examples into separate reference files (e.g., PATTERNS.md, EXAMPLES.md, CONFIG.md) and keeping only a concise overview with links
Clarify which code examples are executable vs. pseudocode patterns, and ensure executable examples are complete and copy-paste ready
Add explicit validation checkpoints to multi-repo operations (e.g., 'Verify all tests pass before proceeding to PR creation') with rollback procedures for failures
Remove obvious best practices that Claude already knows (e.g., 'use semantic versioning', 'document dependencies') and focus only on project-specific conventions
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 700+ lines with extensive repetition. Contains unnecessary explanations, redundant examples showing the same patterns multiple times, and sections like 'Best Practices' that state obvious principles Claude already knows (e.g., 'Clear repository roles and boundaries', 'Documented dependencies'). | 1 / 3 |
Actionability | Provides many code examples and CLI commands, but they mix pseudocode patterns (e.g., `Task()`, `Read()`, `LS()`) with real bash commands without clarifying which are executable. The JavaScript examples use undefined functions and unclear APIs that aren't copy-paste ready. | 2 / 3 |
Workflow Clarity | Multi-step processes are shown but lack explicit validation checkpoints. For example, the 'Synchronized Operations' section executes changes across repositories without clear rollback procedures or validation gates before creating PRs. Destructive batch operations lack feedback loops. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files for detailed content. All configuration examples, patterns, and use cases are inline rather than appropriately split. The document tries to cover everything in one massive file instead of linking to specialized references. | 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 (875 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 | |
- 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.