Name: skill-upper
Author: alibaba

Create, run, diagnose, and iteratively improve Agent Skill evaluations (evals) with the skill-up CLI / 使用 skill-up CLI 创建、运行、诊断并持续改进 Agent Skill 评测. Use when the user asks to evaluate, test, regress, verify, fix, improve, iterate, or evolve a Skill; add or strengthen eval cases; write eval.yaml/case

use skill up cli Help the user evaluate and evolve Agent Skills through the skill up CLI. Manual: <https://alibaba.github.io/skill up/ Language Policy Default to English when responding to the user. If the user writes in Chinese (or any other language), switch to that language and stay consistent with the user's input throughout the session. Detection rules (highest priority first): 1. The user explicitly specifies a language in the current message (e.g. "answer in English" or "reply in Chinese") → follow the user's instruction. 2. The natural language used in the user's current message → match it. 3. None of the above → use English (default). Regardless of the response language, technical identifiers in this SKILL — CLI commands, eval.yaml / case.yaml field names, report field names, etc. — MUST stay in their original English form. Do not translate them. Language Rules for Generated Artifacts Use the user's current language for replies, newly authored explanatory prose, and YAML comments. Preserve the language and semantics of test inputs, expected output literals, identifiers, commands, paths, and existing regression cases. Do not translate a deterministic assertion merely because the conversation language changed. When testing localized behavior, keep the original business text even in an English conversation. Treat assets/ .tmpl as structural references: adapt placeholder prose and comments to the requested language. Review only files created or changed for this task; never rewrite unrelated cases to enforce a language preference. Use short field leading comments for generated YAML. Explain actual configured fields: schema version , environment.type , engine.name , cases.files , and report.formats in eval.yaml; id , title , input.prompt , and judge.type in case YAML. For nested fields, place the comment inside the parent mapping immediately before the child field, rather than only before the parent. For example, comment both prompt and type at their own indentation: Comment expect and a top level judge when present; do not add an optional field just to satisfy a comment check. Keep field names and enum values unchanged. skill up import does not preserve template comments. What is skill up skill up is an evaluation CLI for Agent Skill authors. It installs the Skill into a real Agent Engine (Claude Code, Codex, qodercli, etc.), spins up an execution environment for each case, runs the prompt, then grades the result via declared rules / LLM judges / custom scripts, and finally produces a report. Typical layout: When to trigger Use this skill in any of the following situations: The user asks to "run / evaluate / verify / test this skill". The user asks to "fix / improve / iterate / evolve this skill" from eval failures. The user wants to "add evals, test cases, or regression cases to a skill". The user asks to record explicitly attributed Skill usage, evidence, or feedback. The user wants to review captured Skill observations or turn approved feedback into a regression case. The user wants to edit eval.yaml / case.yaml , or asks you to choose an appropriate judge type. The user mentions skill up run/validate/list cases/report/import/init . The user wants to migrate from Anthropic evals.json to skill up. The current working directory contains evals/eval.yaml or evals/evals.json and the user wants to run it. Choose the requested workflow Diagnose or plan: read the target Skill and supplied evidence, identify concrete problems, and propose changes or cases. Do not install tools, create eval files, change configuration, or run evaluations unless requested. Create or edit cases: use Steps 1–4 to create or update the suite and validate its configuration. Stop before credentials and execution unless the user also requests a run. Report the actual config/case paths and validation status in the final reply. Evaluate: follow Steps 0–7 for the requested suite; report failures without automatically editing the Skill. Improve: follow the evaluation workflow and Step 8 within the requested scope. Preserve valid existing cases and assertions. Evaluation workflow Observation capture mode (optional) Use this mode when the user asks to record the current Skill interaction or feedback and observation tools are available. It requires either a current Codex release with the codex skill up plugin and lifecycle hook support, or DSH with the skill up plugin's observer explicitly enabled. Do not retrofit observation capture onto the pinned Codex 0.80.0 evaluation adapter. If the user asks how to install either host plugin, or the required observation tools are missing and the user asks to enable them, read references/install.md under "Install an observation host plugin (optional)". Do not install or enable a plugin unless the user asks. Claude Code, qodercli, Qwen Code, and other Agent Engines are not supported for this observation workflow. This restriction does not apply to normal skill up evaluation runs, which remain multi engine. 1. Attribute the interaction only when the user explicitly references a Skill (for example, $my skill ) or the responsible Skill is otherwise known with certainty. 2. In Codex, if explicit attribution is absent but certain, call mark skill invocation once with the Skill name and optional version. DSH derives exact attribution from its durable /skill injection or successful skill tool result; do not add inferred attribution. 3. In Codex, use attach skill evidence only for references that help reproduce or evaluate the behavior. Prefer paths and short summaries over copied file contents. 4. In Codex, use record skill feedback during the observed turn. In DSH, the observer stores the next user turn in the same session as an unclassified follow up candidate. For explicit feedback, use record observation feedback with the completed observation's ID. Never invent sentiment or comments. Both adapters redact common credential shapes before local persistence, but still avoid sending secrets to marker tools. If the request is capture only, stop after recording it; do not edit, evaluate, commit, or publish a Skill unless the user also asks for that work. Observation input mode (optional) When the request starts from a captured Skill observation, read references/observations.md first. Use the available observation tools to inspect and preview the observation, require explicit approval for the exact candidate, write it only after approval, and then continue at Step 4. If the request does not start from an observation, use the normal flow below. Step 0: Make sure skill up is installed Before doing anything, verify skill up is available: If a version is printed, continue. If you see command not found , on macOS / Linux : Platform: skill up currently supports macOS / Linux only; Windows is not supported. After installing, run skill up version again. If the command is still missing, add ~/.local/bin to PATH . More details, including optional Codex and DSH observation host plugins: references/install.md . Step 0.5 (optional): User config and telemetry For OTLP defaults, runtime kwargs (e.g. OpenSandbox base url ), etc.: Precedence (low → high): embedded empty defaults < user config < project .skill up.yaml < config . SKILL UP CONFIG can point at the user config file (env var name is historical). See the upstream README "User config". Step 1: Locate the target Skill 1. Identify the root directory of the target Skill (the directory containing SKILL.md ). Search in this priority: user path → nearest SKILL.md upward from CWD → recently viewed files. 2. Read the target SKILL.md for scope, triggers, and dependencies. Preserve localized behavior and expected literals when designing cases. 3. Check evals/ : evals/eval.yaml exists → Step 4 (optionally Step 3). Only evals/evals.json → references/migrate anthropic.md ( skill up run auto or skill up import ). Nothing → Step 2. Step 2: Scaffold the evals (only when none exist) Copy assets/eval.yaml.tmpl to <skill root /evals/eval.yaml . Copy assets/case.yaml.tmpl to <skill root /evals/cases/<case id .yaml . Start with the smallest complete scaffold requested by the user. Unless they request broader coverage, create one representative case; add more only for distinct requirements. For a script judge, implement the required output contract in a short script and reuse it across cases with the same contract. Do not build a general report parser or an extensive script test matrix as part of scaffolding. For a JSON only contract, use json.loads and explicit field checks; support prose or Markdown wrappers only when the contract allows them. Adapt language per "Language Rules for Generated Artifacts". Replace the templates' generic English placeholders with case specific prose in the requested output language. Preserve short field leading comments in generated YAML; translate them when the output language differs from English, while keeping field names and enum values in English. Selection guidelines: environment.type : use none for pure text Skills; use opensandbox when you need a remote sandbox (set OPENSANDBOX API KEY , put non secrets in environment.kwargs ). engine.name + engine.model : default claude code ; model is optional. For qodercli , often omit model . judge.type : rule based (preferred), script , agent judge (expensive) — see references/judge types.md . Case ID = filename without .yaml ; prompts should exercise real Skill value. For interactive cases, preserve fixed input.turns[].content where the user message is known. Use input.turns[].respond only for a reply that must react to the agent, or input.prompt plus case level user simulator.scenario when the simulator should choose all later replies and when to stop. Set an independent eval level user simulator model and a bounded max turns ; see both YAML references. Do not reuse engine.model or judge.model as an implicit simulator model. See references/eval yaml.md and references/case yaml.md . Step 3: Fill the gaps (when evals already exist) skill up list cases <path Review eval.yaml and representative cases; avoid agent judge abuse. Add or edit YAML under cases/ as needed. For byte for byte preservation checks, compare sha256sum <file (or shasum a 256 <file ) before and after editing, within the user's allowed command profile. If adding simulated user turns, check that the selected engine supports session resumption, configure the separate simulator connection, and retain deterministic fixed turns and judge assertions wherever possible. Step 4: Validate the configuration Expect: ✓ eval.yaml is valid (loaded N case(s)) . For a case authoring request, finish here with the config and case paths plus validation status. Do not start a background evaluation as part of scaffolding. Before replying, reopen the generated YAML and check comments immediately before nested input.prompt , judge.type , and report.formats where configured. A comment before input , judge , or report does not document its child field. Check every generated case separately: read its actual judge: block and ensure the explanatory comment sits between judge: and type: , indented like type: . If the comment is above judge: , move it inside the mapping and validate again. Do not infer comment coverage from a successful YAML validation or from what you intended to write. For an expect block, put its explanatory comment immediately above expect: ; a comment inside it above must contain does not document the parent gate. For a new scoring script, check one passing and one failing sample when feasible, then report the check