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.
A compact, well-structured skill that gives highly specific operational rules for choosing VASP preparation tools, regimes, defaults, and output layout. Its main weakness is the absence of validation/verification in the workflow — batch directory preparation produces no checkpoint confirming the prepared inputs match intent — plus minor redundancy and missing concrete examples of tool invocation and INCAR override structure.
Suggestions
Add an explicit validation step to the workflow after preparation, e.g. 'inspect the prepared INCAR/KPOINTS to confirm the regime defaults and user_incar_settings overrides actually applied before dispatch', with a fix-and-recheck loop for mismatches — this addresses the workflow_clarity cap for batch directory preparation.
Add one short example of a tool invocation and a user_incar_settings override (including the element-map form for MAGMOM/LDAUU/LDAUJ and a null removal) so the override guidance is copy-paste concrete.
Consolidate the duplicated k_product and relax_cell guidance from 'Respect built-in defaults' (step 3) and 'Method-critical defaults' into one place to remove redundancy and tighten the body.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is a lean bullet-list with no concept explanations (no 'what is VASP' padding) and every section carries operational content. Minor tightening is possible: the k_product=35 default is stated twice ('Project house default for k_product is 35' and 'use k*a ~= 35 Å'), and the rule 'do not set relax_cell=true unless the task explicitly requires a variable-cell study and the system is not in slab mode' is convoluted and partially restates the slab rule in step 2. | 4 / 5 |
Actionability | Concrete, executable guidance throughout: named tools (vasp_relax_prepare / vasp_sp_prepare), concrete parameter values (NSW=0, IBRION=-1, ISIF=3/2, k_product 35/50), output paths ('output_root/<stem>/'), and override semantics (element maps, null removal). Gaps keep it below 5: no example tool invocation and no concrete example of a user_incar_settings override or an element-map MAGMOM/LDAUU structure. | 4 / 5 |
Workflow Clarity | The five numbered steps give a clear, well-sequenced process (pick tool → regime → defaults → overrides → layout), but there is no validation checkpoint on the outputs. Preparation with directory input is a batch operation ('Directory input preserves relative layout and appends <stem>/ per structure'), and the only verification is the Output Contract's reporting of counts and non-default toggles — no step to confirm the generated INCAR/KPOINTS reflect the intended regime or that overrides actually applied. Per the batch-operation cap, workflow clarity cannot exceed 3 without an explicit validation step; it is not a 2 because the sequence itself is explicit and each step's rules are specific. | 3 / 5 |
Progressive Disclosure | A single well-organized SKILL.md with clear sections (Overview, Quick Start, Suggested tools, Workflow, Method-critical defaults, Output Contract, References) and no nested or dead references; the 'References' section correctly defers edge cases to the tool schema/source rather than inlining them. Kept below 5 because the body is just over 50 lines and the 'Method-critical defaults' section partially duplicates step 3 of the Workflow (both cover k_product, relax_cell, and D3/DFT+U/dipole toggles), which could be consolidated. | 4 / 5 |
Total | 15 / 20 Passed |