Content
80%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.
An exemplary lean instruction-only skill body: well-organized, concrete folder and template conventions with no padding and correct delegation to the platform skill. Its main gap is that the flagship auto-stub and contradiction-flagging behaviors are described as rules rather than as a sequenced workflow with checkpoints, leaving a few operational details to inference.
Suggestions
Add a short numbered auto-stub sequence (e.g., 1. Search existing entries for the mentioned name; 2. Pick the folder by entity type; 3. Create the stub with that folder's frontmatter fields; 4. Add backlinks to the mentioning entry) so the flagship behavior is a workflow rather than a rule.
Specify what a stub body and backlink look like with one small example, and state where a flagged contradiction should be recorded (conversation only vs. a dedicated entry or field).
Clarify how to check whether a name is already captured (e.g., a graph/keyword search step or an index file) so stub creation has an explicit validation checkpoint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~24-line body is lean and every section earns its place: folder conventions with their frontmatter fields, four behavioral rules, and one concrete template call. It assumes Claude's competence — no explanations of what wikis, templates, or graphs are — and even the flavor lines ("The 'where' of the story") compress real guidance. This matches the 5 anchor ("every token earns its place") rather than 4, where noticeable over-explanation would remain. | 5 / 5 |
Actionability | Mostly concrete guidance: an exact API call (`write({ document: { path, template: "<name>" } })`), named shipped templates per folder, per-folder frontmatter fields, and an explicit prohibition on TTRPG stat-block fields. It falls short of fully executable because key operations are underspecified: what a stub's body/backlinks should look like, how to search for whether a name is "not yet captured", and what "surface the conflict" concretely means (file vs. conversation). This is the 4 anchor ("mostly executable; minor gaps"), not 3, since no pseudocode or vague-only direction appears. | 4 / 5 |
Workflow Clarity | The core behaviors are individually unambiguous, but the auto-stub workflow is only implicit (mention → pick folder → stub with backlinks) rather than sequenced, and no checkpoints exist (e.g., how to verify a name is truly uncaptured before stubbing, or where a flagged contradiction gets recorded). This matches the 3 anchor ("sequence present but checkpoints missing or implicit"). It does not reach 4's "clear sequence with most checkpoints"; the destructive/batch cap does not apply since stubbing and flagging are additive, non-destructive operations. | 3 / 5 |
Progressive Disclosure | Per the simple-skill guideline (under 50 lines, no external references needed), well-organized sections alone warrant a 5: the body is a clean overview with Folders, Agent behaviors, and Templates sections, no inlined content that belongs in separate files, and it correctly delegates platform mechanics to the `open-knowledge` skill instead of duplicating them. No bundle files (references/, scripts/, assets/) exist, and none are needed at this size. | 5 / 5 |
Total | 17 / 20 Passed |