# Skill evaluation
Use this method to determine what a skill demonstrably does under realistic conditions. It supports evaluation design, authorized execution, and careful interpretation; a few examples do not establish universal reliability.
Define the question
State the intended and prohibited behavior, fixed baseline, inputs, expected artifacts, and decisions the evaluation will inform. Design normal, missing-or-conflicting, and boundary cases. Include trigger cases and near misses when the question is whether a skill activates appropriately.
Write observable assertions separately from qualitative criteria. Preserve the same prompt, relevant input files, environment assumptions, ordering, and grader rubric for a comparison. Do not call a case untouched when it influenced the design, selection, or revision being measured.
Run or prepare the evaluation
Read `references/host-operations.md` and `references/evaluation-record.md` before using a host runner, viewer, evaluator, or reviewer. When execution is unavailable or unauthorized, produce an authored-not-executed plan; include cases, assertions, baseline, commands or operations, expected artifacts, and grading criteria without inventing outcomes.
For an authorized comparison, keep all outputs, failures, invalid trials, retries, timings, and grading rationale. Use a fresh reviewer for independent judgment, and blind labels when comparing alternatives would otherwise bias the review. A failed run, order-sensitive result, or missing artifact is evidence, not something to discard silently.
Interpret and report
Report scope, sample, baseline, execution record, passed and failed checks, qualitative observations, limitations, and the next revision or decision. Keep authored cases, executed results, human approval, and publication state as separate facts. Do not infer acceptance from silence, or independent review from a reviewer who designed or tuned the evaluated method.
Use `skill-refinement` to make a bounded revision from a supported finding. Use `skill-authoring` only when the evaluation shows the package contract, trigger, or workflow itself needs redesign.