package
Rebuild the SkyWalking distribution and OAP Docker image after source changes. Use before running e2e tests so the image reflects your code changes. Avoids the "image looks updated but runtime has stale jars" trap.
72
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
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.
This is a strong, well-crafted skill description. It clearly specifies the concrete action (rebuilding SkyWalking distribution and Docker image), provides an explicit 'when' trigger (before e2e tests after source changes), and adds practical context about the problem it solves (stale jars). The domain-specific terminology makes it highly distinctive and unlikely to conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists specific concrete actions: 'Rebuild the SkyWalking distribution and OAP Docker image after source changes.' It also mentions a specific use case context (e2e tests) and a specific problem it avoids (stale jars in runtime). | 3 / 3 |
Completeness | Clearly answers both 'what' (rebuild the SkyWalking distribution and OAP Docker image) and 'when' ('Use before running e2e tests so the image reflects your code changes'). The 'Use before...' clause serves as an explicit trigger. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords a user would say: 'SkyWalking', 'distribution', 'OAP Docker image', 'source changes', 'e2e tests', 'rebuild', 'stale jars'. These are terms a developer working in this domain would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific to SkyWalking OAP Docker image rebuilds for e2e testing. The combination of 'SkyWalking', 'OAP Docker image', and 'e2e tests' creates a very clear niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 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 strong, highly actionable skill that addresses a genuinely tricky build system gotcha — the silent stale-jar problem. Its greatest strengths are the decision table, concrete verification steps, and clear workflow sequencing. Minor weaknesses include some verbosity in explanatory sections and the monolithic structure that could benefit from splitting detailed reference material into separate files.
Suggestions
Tighten the 'flatten:flatten' and 'Why this matters' sections — the Makefile rule quote and detailed explanation of ${revision} resolution could be condensed since the actionable takeaway is simply 'always include flatten:flatten before package'.
Consider extracting the common pitfalls and verification procedure into a separate reference file to improve progressive disclosure and reduce the main skill's length.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient and covers genuinely non-obvious build system behavior, but some sections are slightly verbose — e.g., the `flatten:flatten` explanation could be tightened, and the 'Why this matters' Makefile internals section, while useful, is longer than necessary. The pitfalls section has some redundancy with earlier content. | 2 / 3 |
Actionability | Provides fully executable, copy-paste-ready commands for each scenario, a clear decision table mapping commands to their effects, and a concrete verification procedure (docker cp + jar extraction + grep). Every recommendation is specific and directly usable. | 3 / 3 |
Workflow Clarity | The skill clearly sequences the two-step dependency (rebuild tarball → rebuild image), provides explicit verification steps after the build, includes error recovery guidance (re-run with correct chain, delete dist/), and the decision table acts as a checkpoint for choosing the right path. The 'golden rule' summary reinforces the workflow. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sections, but it's a fairly long single file (~120 lines of substantive content) with no references to external files. The common pitfalls and flatten:flatten sections could potentially be split out. However, given no bundle files exist, the inline approach is reasonable though not ideal. | 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 | |
- Repository
- apache/skywalking
- Commit
bf0fe4b
- 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.