Comprehensive documentation synchronization - scan local git changes and propagate updates to ALL design docs, task lists, specs, diagrams, and planning artifacts. Use when finishing a feature, after merging, or when design docs are out of date.
Install with Tessl CLI
npx tessl i github:0xrabbidfly/eric-cartman --skill doc-sync-all80
Quality
72%
Does it follow best practices?
Impact
93%
1.03xAverage score across 3 eval scenarios
Optimize this skill with Tessl
npx tessl skill review --optimize ./.github/skills/doc-sync-all/SKILL.mdDiscovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description effectively communicates when to use the skill with clear trigger scenarios, but the core capability description is somewhat vague about what 'synchronization' and 'propagate updates' actually means in practice. The trigger terms are decent but could include more natural user phrasings.
Suggestions
Specify concrete actions beyond 'propagate updates' - e.g., 'updates version numbers, reflects API changes, marks completed tasks, updates architecture diagrams'
Add more natural trigger terms users might say: 'update docs', 'sync documentation', 'docs are stale', 'refresh specs'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (documentation synchronization) and lists document types (design docs, task lists, specs, diagrams, planning artifacts), but the core action 'scan and propagate updates' is somewhat vague - doesn't specify how updates are propagated or what 'synchronization' entails concretely. | 2 / 3 |
Completeness | Clearly answers both what (scan git changes and propagate updates to documentation artifacts) AND when (finishing a feature, after merging, when design docs are out of date) with explicit trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes some natural terms like 'design docs', 'task lists', 'specs', 'out of date', 'finishing a feature', 'after merging', but misses common variations users might say like 'update documentation', 'sync docs', 'refresh docs', 'stale documentation'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on git-based documentation synchronization is fairly specific, but 'documentation' and 'design docs' could overlap with general documentation writing skills or individual doc editing skills. The git change scanning aspect helps distinguish it somewhat. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, highly actionable skill for documentation synchronization with clear workflows and validation checkpoints. Its main weakness is verbosity—the skill could be 30-40% shorter while retaining all essential guidance. The monolithic structure works but would benefit from progressive disclosure for the detailed sync rules and file patterns.
Suggestions
Extract the detailed sync rules (Phase 3) and file detection patterns (Phase 5) into separate reference files, keeping only summaries in the main SKILL.md
Remove or condense the 'Sample Invocation Phrases' section—Claude doesn't need examples of how users might invoke the skill
Tighten the Core Principle and When to Use sections; the bullet points are somewhat redundant with the skill description
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but verbose in places. Tables and structured sections are efficient, but some explanatory text (e.g., 'Documentation should reflect reality, not aspirations') and the extensive phase descriptions could be tightened. The glob patterns and sample invocation phrases add bulk without proportional value. | 2 / 3 |
Actionability | Provides concrete, executable bash commands for git analysis, specific file paths to check, clear validation patterns with examples, and detailed tables mapping change types to documentation updates. The step-by-step execution process is copy-paste ready. | 3 / 3 |
Workflow Clarity | Excellent multi-phase workflow with clear sequencing (Discover → Inventory → Sync Rules → Execute → Report). Includes explicit validation in Step 5 (re-read files, check cross-references), a verification checklist, and feedback loops for error detection. The manifest generation before applying changes is a good checkpoint. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections and tables, but it's monolithic—all content is inline rather than split into referenced files. For a skill this comprehensive (~300 lines), the sync rules and file detection patterns could be externalized. References to other skills at the end are good but the main content could benefit from better splitting. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
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.