greptimedb-fuzz-ci-failure-investigation

Investigate a failed GreptimeDB fuzz CI target link by downloading GitHub Actions job logs plus fuzz artifacts such as kind logs, monitor dumps, and CSV dumps, then correlate the failure with local GreptimeDB source code. Use when the user provides a failed fuzz CI target/job URL or asks to diagnose GreptimeDB fuzz CI failures.

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

85%Weight 40%Scale 1-5

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

An excellent, highly actionable investigation runbook with strong sequencing and validation checkpoints. Its main weaknesses are a monolithic structure that inlines reference-worthy material (artifact catalog, methodology, response template) into a long SKILL.md and prose sections that could be tightened.

Suggestions

Move the detailed diagnosis methodology (section 5) and the final response template (section 10) into references/ files (e.g., references/diagnosis-method.md, references/response-format.md), keeping one-line pointers in SKILL.md to shorten the always-loaded context.

Move the per-directory artifact contents catalog (section 4) into a reference file, keeping only the top-level artifact layout (manifest.json, summary.md, targets/<target>/) inline.

Tighten the prose in sections 5.1-5.6 into compact bullet guidance to reduce token cost without losing the competing-hypotheses and falsifiability requirements.

Dimension	Reasoning	Score
Conciseness	The body is dense with executable commands and non-obvious procedural specifics, but at ~465 lines it includes trimmable prose, notably the six-subsection diagnosis methodology in section 5. It is efficient with minor over-explanation, matching the 4 anchor rather than the 5 anchor's lean-everywhere bar.	4 / 5
Actionability	Copy-paste ready `gh api`/`gh run`/`jq`/`git worktree` commands with exact field lists, jq filters, and concrete fallbacks (artifact-by-id download, REST log endpoints, worktree at run SHA) cover the common cases end to end, matching the 5 anchor.	5 / 5
Workflow Clarity	A clear 10-step sequence with explicit validation checkpoints and feedback loops: exit-on-error for empty HEAD_SHA or missing artifacts, manifest-before-bulk-logs ordering, SHA-verified source inspection, a common-mistakes list, and a falsifiability requirement. This matches the 5 anchor including error-recovery guidance.	5 / 5
Progressive Disclosure	The body is well-sectioned but monolithic at ~465 lines with no bundle files: the artifact-contents catalog (section 4), layered diagnosis methodology (section 5), and final response template (section 10) are inlined where a 4-5 structure would split them into clearly signaled, one-level-deep reference files.	3 / 5
	Total	17 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states concrete capabilities with named artifact types and an explicit, concrete 'Use when' trigger clause in third person. The only gap is minor synonym coverage (e.g., "fuzz test", flake/hang phrasing) in the trigger vocabulary.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete actions with named specifics — "downloading GitHub Actions job logs plus fuzz artifacts such as kind logs, monitor dumps, and CSV dumps, then correlate the failure with local GreptimeDB source code" — comprehensively covering the skill's core capabilities. It fits the 5 anchor rather than 4 because coverage is complete rather than minor-gapped.	5 / 5
Completeness	Both what ("Investigate a failed GreptimeDB fuzz CI target link by downloading... then correlate the failure with local GreptimeDB source code") and when ("Use when the user provides a failed fuzz CI target/job URL or asks to diagnose GreptimeDB fuzz CI failures") are explicit with concrete trigger phrases, exactly matching the 5 anchor.	5 / 5
Trigger Term Quality	Good natural keyword coverage — "failed fuzz CI target/job URL", "diagnose GreptimeDB fuzz CI failures", "GitHub Actions job logs" — with target/job synonym pairing. It falls short of the 5 anchor because the literal phrase "fuzz test" (the actual CI job name) and flake/hang/timeout vocabulary users would naturally use are absent.	4 / 5
Distinctiveness Conflict Risk	The "GreptimeDB fuzz CI" niche is highly specific with distinct triggers (fuzz CI target/job URL, kind logs, monitor dumps), creating minimal conflict risk with any other skill.	5 / 5
	Total	19 / 20 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: GreptimeTeam/greptimedb
Path: .agents/skills/greptimedb-fuzz-ci-failure-investigation/SKILL.md
Commit: 3a4c24a

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