CtrlK
BlogDocsLog inGet started
Tessl Logo

find-postgres-bug

Find latent bugs in a local PostgreSQL source tree (REL_xx_STABLE branch or HEAD) the way a core hacker does: build a heavily-poisoned debug instance (cassert + cache-discard + -O0/-ggdb3 + core dumps), fuzz it (sqlsmith) until the backend crashes, triage the core into a minimal reproducer (MRE), git-bisect the introducing commit, and render a community-style pgsql-bugs markdown report. The instance never auto-shuts-down. Use when the user says "find a bug in postgres", "fuzz postgres", "hunt for a crash", "test a recent commit", "write a repro", "bisect this crash", "把 PG 跑起来找 bug", "fuzz 一下 postgres", "看看这个 commit 会不会出问题", etc. Triggers whenever the user points at a PG source dir and wants to hunt bugs.

77

Quality

96%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

92%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.

A well-engineered operational skill: the workflow is an unambiguous, validated pipeline with executable scripts at every step, and detail is correctly split into one-level-deep bundle files that all exist. The only cost is repetition — the already-fixed/never-revert rule and the 'poison the build' framing are each restated three or four times across the Overview, steps, and decision tree.

Suggestions

State the never-revert-a-fix / already-fixed rule once (e.g. in the three hard rules) and link to references/already_fixed.md from the other mentions, instead of restating it in full in Step 0, Step 6, and the decision tree.

Drop the duplicated '90% lever' framing: it appears in the Overview prose, the Quick Start comment, and the Step 1 heading — one mention plus the reference link is enough.

Consider collapsing the Quick Start command block or the per-step commands in the Workflow section, since they duplicate each other; keeping one canonical command sequence would trim ~30 lines without losing actionability.

DimensionReasoningScore

Conciseness

The body is high-signal throughout — no explaining what Postgres or git bisect is, commands dominate over prose — but there is noticeable repetition that could be tightened: the never-revert-a-fix / already-fixed rule is stated in full in Overview rule 3, Step 0, Step 6, and again in the decision tree, and the '90% lever' framing appears in the Overview, the Quick Start comment, and the Step 1 heading. Not 5: these repeated passages are tokens that don't add new information for a reader who read the first statement. Not 3: the repetition is deliberate safety-rule emphasis, and apart from it every section is lean and earns its place.

4 / 5

Actionability

Every step gives copy-paste-ready, fully executable commands with concrete arguments (e.g. "./scripts/fuzz_sqlsmith.sh 3600 postgres", "./scripts/bisect_run.sh repro/mybug.sql REL_17_STABLE HEAD"), the Quick Start is a runnable end-to-end script, and the env-override example ("PG_PORT=55433 PG_POISON_CACHE=1 ./scripts/build_and_start_pg.sh") covers customization. Not 4: no gaps — even failure-mode outputs are specified ("SERVER IS DOWN = good", "Cache poison: guc (or macro), not none").

5 / 5

Workflow Clarity

Eight explicitly sequenced steps, each ending in a bolded "Success:" validation criterion, with feedback loops for error recovery ("Until this holds, do not theorise about root cause", "If it says none, poisoning was disabled", dirty-tree stop-and-ask gate) and an ASCII decision tree covering both crash and clean-fuzz branches. Not 4: validation checkpoints are explicit and unavoidable at every stage, including for the risky git operations.

5 / 5

Progressive Disclosure

SKILL.md is a genuine overview: the workflow stays inline while details are pushed one level deep into 9 references, 12 scripts, and 1 asset — all verified to exist — with an annotated reference index that says "Load only what you need; each file is self-contained." Not 4: navigation is easy, references are clearly signaled at the exact step where they're needed, and nothing that belongs in a bundle file is inlined.

5 / 5

Total

19

/

20

Passed

Description

100%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.

An exemplary description: it names the target (local PG source tree, REL_xx_STABLE or HEAD), enumerates the complete pipeline as concrete actions in third person, and gives an explicit 'Use when' clause with quoted natural-language triggers in two languages. It is dense but not padded — every clause carries information.

DimensionReasoningScore

Specificity

Lists multiple concrete, comprehensive actions: "build a heavily-poisoned debug instance (cassert + cache-discard + -O0/-ggdb3 + core dumps), fuzz it (sqlsmith) until the backend crashes, triage the core into a minimal reproducer (MRE), git-bisect the introducing commit, and render a community-style pgsql-bugs markdown report." Every pipeline stage is a specific executable capability, not vague language. Not 4: coverage is comprehensive with no minor gaps in the action list.

5 / 5

Completeness

Explicitly answers both questions: 'what' is the full crash-first pipeline sentence, and 'when' is the concrete "Use when the user says..." clause with quoted trigger phrases plus "Triggers whenever the user points at a PG source dir and wants to hunt bugs." Not 4: the 'when' is maximally explicit — enumerated quoted phrases rather than a general 'use when working with' hint.

5 / 5

Trigger Term Quality

Trigger phrases are the natural words a user would say: "find a bug in postgres", "fuzz postgres", "hunt for a crash", "test a recent commit", "write a repro", "bisect this crash", plus bilingual variants ("把 PG 跑起来找 bug", "fuzz 一下 postgres", "看看这个 commit 会不会出问题") that cover synonyms real users of this skill would use. Not 4: even non-English phrasings and casual variants are included, leaving essentially no common variation missing.

5 / 5

Distinctiveness Conflict Risk

Clear niche — latent-bug hunting in a local PostgreSQL source tree with a build/fuzz/triage/bisect pipeline — with triggers ("fuzz postgres", "bisect this crash") that no general PG-admin or query-tuning skill would claim. Not 4: the domain is narrow and the trigger vocabulary is distinct, so overlap risk with related skills is minimal.

5 / 5

Total

20

/

20

Passed

Validation

100%

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
digoal/blog
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.