Content
61%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 well-structured, actionable policy skill with concrete commands, routing rules, and exact output formats, and its anti-patterns section is unusually good at encoding failure modes. Its weaknesses are redundancy in the convention/enablement prose, an implicit rather than sequenced validation checkpoint for batch page-writes, and undefined notability criteria in the entity branch.
Suggestions
Fold the duplicate convention-vs-guarantee paragraph into the single contract bullet and cut the Anti-Patterns entries that restate the enablement rules verbatim, keeping only the failure modes not already covered.
Promote the readback verification into an explicit sequenced step (e.g., Phase 4: read back each written page and fix mismatches before logging), giving the batch-write loop a real validate-and-retry checkpoint.
Define notability criteria for the 'If NO page' branch (e.g., repeated mentions, a brain page elsewhere, or the user asking to track them) so the entity gate is executable rather than judgment-only.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly dense, useful policy content, but the convention-vs-guarantee point is stated twice (the contract bullet 'Never blocking the response is the intent, not a runtime contract' plus the following full paragraph), and the enablement rules are restated nearly verbatim in Anti-Patterns, which is padding that could be tightened. | 3 / 5 |
Actionability | Concrete executable guidance throughout: 'gbrain search "name"', 'gbrain timeline-add <slug> <date> "<summary>"', routing paths like 'originals/{slug}', the exact back-link format '- **YYYY-MM-DD** | Referenced in [page title](path) — brief context', and copy-ready signal-log lines. Minor gaps: 'check notability' has no criteria and page content structure is unspecified. | 4 / 5 |
Workflow Clarity | The three phases are clearly sequenced with explicit decision branches (no page / THIN / RICH), but validation is thin for a batch-write skill: the one checkpoint ('verify captured content with an actual readback') is buried in Output Format rather than sequenced as a step, and there is no fix-and-retry loop if the readback mismatches. | 3 / 5 |
Progressive Disclosure | Well-organized single-file skill with clearly labeled sections and one clearly signaled, one-level reference (skills/conventions/quality.md); no nested references and no bundle sprawl. At ~163 lines, the enablement and per-user storage policy prose is inline content that could plausibly live in a reference file, which keeps it from a 5. | 4 / 5 |
Total | 14 / 20 Passed |