Content
88%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 excellent operational playbook: fully executable commands for every datasource, a tightly sequenced diagnose-and-verify workflow with real validation gates, and no filler. The main weaknesses are mild redundancy between the repair playbook and the diagnostic-codes table, and a monolithic single-file structure that could offload the codes table to a reference file.
Suggestions
Consolidate the duplicated diagnostic explanations: 'jikji-unavailable', 'embedder-unavailable', and 'datasource-auth-error' are described in both the 'Missing or wrong setup' section and the diagnostic codes table — keep one canonical entry and cross-reference it.
Move the diagnostic-codes table (and optionally the per-CLI repair detail) into a one-level-deep reference file (e.g. references/diagnostic-codes.md), keeping SKILL.md as the triage-and-workflow overview with well-signaled links.
The 'docs/minsync-setup.md' pointer is not part of the skill bundle — either add it as a bundled reference or reword to point at where the user can actually find it (e.g. the AutoRAG install directory).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Efficient and dense — nearly every sentence is an AutoRAG-specific operational fact Claude could not know, with commands, paths, and diagnostic codes rather than concept explanations. Not 5: a few rules are wordy, and 'jikji-unavailable', 'embedder-unavailable', and 'datasource-auth-error' are each explained twice (once in the repair playbook, again in the diagnostic codes table), which could be consolidated. | 4 / 5 |
Actionability | Fully executable throughout: a per-datasource table of exact native-check and re-sync commands, copy-paste refresh/rebuild/retry commands, concrete MCP invocations with arguments ('autorag.search {"query":...,"topK":3}', 'autorag.evidence {"sessionId":...}'), and a worked SQL cross-check example. Specific examples cover the common failure cases. | 5 / 5 |
Workflow Clarity | A clear triage → probe → prove-searchability → repair → report sequence with explicit validation checkpoints: repairs must be re-verified by re-running the failing check, 'Re-run autorag status --json afterwards to confirm inFlight: false', never kill a running sync, and a completion condition gates the run on real query hits. The destructive operations (kills, lock deletion, index reset) all carry confirm-first validation, so the destructive/batch cap does not apply. | 5 / 5 |
Progressive Disclosure | Well-sectioned single file with no nested references and clear navigation (triage, per-datasource table, repair playbook, codes table, report). Not 5: the ~280-line body keeps the full diagnostic-codes table and repair playbook inline where well-signaled one-level references could carry them, and the lone external pointer 'docs/minsync-setup.md' is not part of the bundle. Not 3: structure is good and inline placement is defensible for a repair run that needs the codes at hand. | 4 / 5 |
Total | 18 / 20 Passed |