Content
68%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a dense, high-signal reference for querying a Slackdump SQLite database, with genuinely non-obvious semantics (thread flags, ID/TS, DATA JSON, latest-version dedup) and ready-to-run SQL. Its weaknesses are the reference-style organization without an explicit ordered workflow or result-validation steps, and a mislabeled pragmas section that explains CLI basics Claude already knows.
Suggestions
Fix the "Useful pragmas" section: `.tables` and `.schema` are sqlite3 dot-commands, not pragmas; either drop them or replace with actual useful pragmas (e.g., `PRAGMA table_info(MESSAGE);`) and skip basics Claude already knows.
Add a brief validation step to the query workflow, e.g. check which chunk types and sessions exist (`SELECT ID, TYPE_ID, SESSION_ID FROM CHUNK`) before applying the latest-version pattern.
Give a concrete command for locating the database (e.g., `find . -name 'slackdump*.sqlite'`) instead of the vague instruction to "look for" it.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Nearly every section delivers non-obvious, Slackdump-specific knowledge (ID vs TS conversion, PARENT_ID/IS_PARENT semantics, DATA-column JSON access, latest-version deduplication) with no padding. Not a 5 because the "Useful pragmas" section mislabels basic sqlite3 dot-commands (`.tables`, `.schema`) that Claude already knows and adds little. | 4 / 5 |
Actionability | Two complete, executable CTE queries with explicit `[CHANNEL_ID]`/`[PARENT_MESSAGE_ID]` placeholders, a runnable JSON_EXTRACT example, and a concrete table/type map make this mostly copy-paste ready. It misses a 5 due to gaps like the vague "Look for slackdump.sqlite in the current directory" (no actual command) and no example for the SEARCH_* tables. | 4 / 5 |
Workflow Clarity | The sections imply a sensible order (locate database → enforce read-only → inspect schema → apply the latest-version query pattern) and the read-only guard is a real safety checkpoint, but the material is presented as a reference rather than a sequenced workflow with validation steps (e.g., verifying which chunk types/sessions exist before querying). This fits 'steps listed but validation gaps; checkpoints missing or implicit' better than 4's 'most checkpoints present'. | 3 / 5 |
Progressive Disclosure | The single-file body is well organized with clear, scannable section headers and no nested or buried references, matching 'good structure; most content is appropriately placed'. It is not a 5 because the lookup-table material (key tables, chunk-type map) is inlined reference content that could live in a separate references file given the body exceeds the ~50-line simple-skill threshold. | 4 / 5 |
Total | 15 / 20 Passed |