[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EEQWV7ZB22TYTDA0TYTBAZ":3,"skill-same:01M7EEQWV7ZB22TYTDA0TYTBAZ":125},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7EEQWV7ZB22TYTDA0TYTBAZ","multi-skill-creator",null,"Create new skills, modify and improve existing skills, and measure skill performance with reproducible evals. Use when users want to build a skill from scratch, edit or optimize an existing skill, run evals to verify a skill actually works, benchmark a skill's value with variance analysis, or optimize a skill description for better triggering accuracy. Defaults to writing every skill in both Chinese (zh-CN) and English (en-US) unless the user asks for a specific language. Reach for it even when the user never says the word \"skill\" — if the conversation is about packaging a repeatable procedure, script, or reference material into a reusable capability, this skill applies.","luestr\u002Fskills","luestr","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F152216177?v=4","01M7EEH85TQXC26ZZTNFPWV5E9","可莉","01M7EEH86EYXTVTCERP22VMFXX",94,"MIT","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: multi-skill-creator\ndescription: Create new skills, modify and improve existing skills, and measure skill performance with reproducible evals. Use when users want to build a skill from scratch, edit or optimize an existing skill, run evals to verify a skill actually works, benchmark a skill's value with variance analysis, or optimize a skill description for better triggering accuracy. Defaults to writing every skill in both Chinese (zh-CN) and English (en-US) unless the user asks for a specific language. Reach for it even when the user never says the word \"skill\" — if the conversation is about packaging a repeatable procedure, script, or reference material into a reusable capability, this skill applies.\nmetadata:\n  language: en-US\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nOne premise up front: **this skill is not tied to any single vendor, IDE, or CLI.** Anything that can run Python and invoke an agent CLI non-interactively can use it — Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Finch, or an agent you wrote yourself. The scripts pick an agent through one adapter layer, `scripts\u002Fagent_cli.py`, so switching tools never requires rewriting the skill. Users whose main tool is Claude will find notes for those environments below, but those are \"special cases for one tool\", not the main path.\n\nAt a high level, creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft (bilingual by default: Chinese first, then sync English once verified; only one language when the user asked for one)\n- Create a few test prompts and run an agent-with-access-to-the-skill on them\n- Help the user evaluate the results, both qualitatively and quantitatively\n  - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, use them as-is or modify what needs changing). Then explain them to the user — or, if they already existed, explain the ones that already exist\n  - Use `eval-viewer\u002Fgenerate_review.py` to show the user the results, and let them look at the quantitative metrics too\n- Rewrite the skill based on the user's evaluation of the results (and fix any glaring flaws the quantitative benchmarks make obvious)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process, then jump in and help them move forward. If they say \"I want to make a skill for X\", you can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and iterate. If they already have a draft, go straight to the eval\u002Fiterate loop.\n\nAlways stay flexible: if the user says \"I don't need a pile of evals, just think it through with me\", do that instead.\n\nOnce the skill is basically done (order stays flexible), you can also run the description improver — a separate script whose only job is improving triggering accuracy.\n\n## Language: Bilingual by Default, User Overrides\n\n**Produce bilingual skills by default**: `zh-CN\u002F\u003Cskill-name>\u002F` and `en-US\u002F\u003Cskill-name>\u002F`, each independently usable, structured as described in the Bilingual Versions section. Don't stop to ask \"Chinese or English?\" before starting — unless the user has stated a language preference, go straight to bilingual.\n\nSwitch to a single language only when:\n\n- The user names a language (\"Chinese only\", \"English is fine\", \"do Chinese now, English later\"). Do what they said; don't helpfully add a second version they didn't ask for.\n- The user says explicitly that this is internal, throwaway, or not worth maintaining twice.\n\nFor a single-language skill, pick the language the same way: the user's choice wins, otherwise follow the language of the conversation — and mention in one line at delivery that only the \u003Clanguage> version exists and the other can be added on request.\n\nEither way, **finish the implementation before translating**. Simplified Chinese is the primary development language: implement, verify, and revise in the Chinese version, then produce the English version from it. Never introduce functionality or behavioral changes independently in the English version.\n\n## Capture Intent\n\nStart by understanding what the user actually wants. The conversation may already contain a workflow they want to capture (e.g. \"turn this into a skill\"). In that case, extract answers from the conversation first — the tools used, the sequence of steps, the corrections the user made, the input\u002Foutput formats you observed. Fill the remaining gaps with questions, and get confirmation before moving on.\n\n1. What should this skill enable the agent to do?\n2. When should it trigger? (what phrases, what contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't. Suggest the appropriate default for the skill type, but let the user decide.\n\n## Interview and Research\n\nProactively ask about edge cases, input\u002Foutput formats, example files, success criteria, and dependencies. Get this ironed out before writing test prompts.\n\nCheck which MCP tools are available. If they help with research (searching docs, finding similar skills, looking up best practices), research in parallel — via subagents if you have them, inline otherwise. Come prepared with context to reduce the burden on the user.\n\n## Write the SKILL.md\n\nFrom the interview, fill in these parts:\n\n- **name**: the identifier, kebab-case, 64 characters max\n- **description**: when to trigger, what it does. This is the entire triggering mechanism — include both what the skill does AND specific contexts for when to use it. All \"when to use\" information goes here, not in the body. Note that agents have a general tendency to *undertrigger* — to skip a skill that would have helped. To counter that, descriptions can be a little **pushy**. Instead of \"How to build a simple dashboard to display company data\", write \"How to build a simple dashboard to display company data. Use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **metadata.language**: the language tag for this copy (see the Bilingual section)\n- **compatibility**: required tools and dependencies (optional, rarely needed)\n- **the body, and everything else**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name\u002F\n├── SKILL.md (required)\n│   ├── YAML frontmatter (name, description required)\n│   └── Markdown instructions\n└── Bundled Resources (optional)\n    ├── scripts\u002F    - executable code for deterministic\u002Frepetitive tasks\n    ├── references\u002F - docs loaded into context as needed\n    └── assets\u002F     - files used in output (templates, icons, fonts)\n```\n\nSkills are bilingual by default, so the real deliverable wraps one of these in a language directory — `zh-CN\u002Fskill-name\u002F` and `en-US\u002Fskill-name\u002F`, each containing the full structure above. See \"Bilingual Versions → 1. Language Structure\".\n\n#### Progressive Disclosure\n\nSkills load in three levels:\n1. **Metadata** (name + description) — always in context (~100 words)\n2. **SKILL.md body** — in context whenever the skill triggers (\u003C500 lines ideal)\n3. **Bundled resources** — as needed (unlimited; scripts can execute without loading)\n\nThese counts are rules of thumb; go longer if the content genuinely needs it.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines. As you approach that limit, add another layer of hierarchy and clear pointers telling the agent where to go next\n- Reference files clearly from SKILL.md, with guidance on when to read them\n- For reference files over 300 lines, include a table of contents\n\n**Domain organization**: when a skill covers multiple domains or frameworks, split by variant:\n\n```\ncloud-deploy\u002F\n├── SKILL.md (workflow + selection logic)\n└── references\u002F\n    ├── aws.md\n    ├── gcp.md\n    └── azure.md\n```\n\nThe agent reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nSkills must not contain malware, exploit code, or anything that could compromise system security. Once a skill is adopted, its contents should not surprise the user in intent. Don't go along with requests to build misleading skills, or skills designed for unauthorized access or data exfiltration — and don't pretend not to notice a problem just to keep the user happy. \"Roleplay as an XYZ\" is fine.\n\n#### Writing Patterns\n\nPrefer the imperative form in instructions.\n\n**Defining output formats** — like this:\n\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** — examples are valuable. You can format them like this (if \"Input\"\u002F\"Output\" labels don't fit the domain, rename them):\n\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n#### Writing Style\n\nExplain **why** something matters rather than piling on heavy-handed MUSTs. Today's models are smart, with good theory of mind: give them a good harness and they'll go beyond rote instructions. So write a draft, then read it again with fresh eyes and improve it.\n\nKeep the skill **general** rather than over-fitted to the handful of examples in front of you.\n\n### Test Cases\n\nAfter writing the draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user (don't feel bound to my exact wording): \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals\u002Fevals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next section, while the runs are in flight.\n\n```json\n{\n  \"skill_name\": \"example-skill\",\n  \"evals\": [\n    {\n      \"id\": 1,\n      \"prompt\": \"User's task prompt\",\n      \"expected_output\": \"Description of expected result\",\n      \"files\": []\n    }\n  ]\n}\n```\n\nSee `references\u002Fschemas.md` for the full schema, including the `assertions` field you'll add later.\n\n## Running and Evaluating Test Cases\n\nThis section is one continuous sequence — don't stop partway through.\n\nPut results in `\u003Cskill-name>-workspace\u002F`, a sibling of the skill directory. The layout is a contract, because the aggregator scans for exactly this shape — miss a level and it finds nothing:\n\n```text\n\u003Cskill-name>-workspace\u002F\n└── iteration-1\u002F\n    ├── csv-column-tidy\u002F            ← test case, descriptive name\n    │   ├── eval_metadata.json\n    │   ├── with_skill\u002F\n    │   │   ├── run-1\u002F\n    │   │   │   ├── outputs\u002F        ← produced files\n    │   │   │   ├── grading.json\n    │   │   │   └── timing.json\n    │   │   └── run-2\u002F              ← only when repeating a config\n    │   └── without_skill\u002F\n    │       └── run-1\u002F\n    │           ├── outputs\u002F\n    │           └── grading.json\n    └── pdf-table-extract\u002F\n        └── …\n```\n\nThe rules:\n- Test-case directories may — and should — be descriptively named rather than `eval-0`\n- **Every configuration needs that `run-\u003CN>\u002F` level**, and `grading.json` belongs inside the run directory\n- One run means `run-1`; repeat runs mean `run-1`, `run-2`, which the aggregator turns into mean ± stddev\n- Don't create all of it upfront — build as you go\n\n`python -m scripts.aggregate_benchmark` scans for `\u003Ccase>\u002F\u003Cconfig>\u002Frun-\u003CN>\u002Fgrading.json`. If the shape is wrong it exits with an error instead of writing an all-zero benchmark.\n\n### Step 1: Spawn every run in the same turn\n\nEach test case gets two runs — one with the skill, one as a baseline. The important part: don't run the with-skill cases first and come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \u003Cpath-to-skill>\n- Task: \u003Ceval prompt>\n- Input files: \u003Cthe eval's files, or \"none\">\n- Save outputs to: \u003Cworkspace>\u002Fiteration-\u003CN>\u002F\u003Ccase-name>\u002Fwith_skill\u002Frun-1\u002Foutputs\u002F\n- Outputs to save: \u003Cwhat the user actually cares about — e.g. \"the .docx file\", \"the final CSV\">\n```\n\n**Baseline run** (same prompt; what the baseline is depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, saved to `without_skill\u002Frun-1\u002Foutputs\u002F`\n- **Improving an existing skill**: the old version. Snapshot it before editing (`cp -r \u003Cskill-path> \u003Cworkspace>\u002Fskill-snapshot\u002F`, or `Copy-Item -Recurse` on Windows), then point the baseline run at the snapshot, saved to `old_skill\u002Frun-1\u002Foutputs\u002F`\n\nBilingual skills: `\u003Cpath-to-skill>` points at a **specific language directory** (e.g. `zh-CN\u002F\u003Cskill-name>`), one language per evaluation run, with test prompts written in that language. Each language gets its own full with-skill\u002Fbaseline comparison — don't mix them, and don't use the Chinese results to draw conclusions about the English version.\n\nWrite an `eval_metadata.json` for each test case (assertions can stay empty for now). Name each eval for what it tests — not just \"eval-0\". Use that name for the directory too. If this iteration uses new or modified prompts, create these files for every new eval directory; don't assume they carry over from the previous iteration.\n\n```json\n{\n  \"eval_id\": 0,\n  \"eval_name\": \"descriptive-name-here\",\n  \"prompt\": \"The user's task prompt\",\n  \"assertions\": []\n}\n```\n\n**On \"spawning\" a run**: it depends on your harness. With parallel subagents, give each run its own (for example Finch's `multi_agent_run`, or a task\u002Fsubagent tool in other CLIs). Without them, run the cases in series, or just work through the skill's instructions yourself in the main conversation. Either way, two things stay true: the with-skill and baseline runs must be a fair comparison, and each run's outputs must land in its own `outputs\u002F` directory.\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait. Use the time to draft quantitative assertions for each test case and explain them to the user. If `evals\u002Fevals.json` already has assertions, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — someone glancing at the benchmark report should immediately understand what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively; don't force assertions onto things that need human judgment.\n\nUpdate `eval_metadata.json` and `evals\u002Fevals.json` once the assertions are drafted. Also explain what the user will see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nEvery finished run should give you a token count and a duration. Whatever your harness exposes — a task completion notification, a log line, your own timing — write it to `timing.json` in that run's directory straight away:\n\n```json\n{\n  \"total_tokens\": 84852,\n  \"duration_ms\": 23332,\n  \"total_duration_seconds\": 23.3\n}\n```\n\nThis is easy to skip and impossible to recover later. **If you don't have exact numbers, don't invent them**: keep the fields you do have (even if it's only your own wall-clock time) and omit the rest. A missing column in the benchmark beats a fabricated one.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — have a grader agent (or yourself, in the main conversation) read `agents\u002Fgrader.md` and evaluate each assertion against the outputs; save results to `grading.json` in each run directory. The `grading.json` expectations array must use the field names `text`, `passed`, and `evidence` (not `name`\u002F`met`\u002F`details` or any other variant) — the viewer depends on those exact names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it: faster, more reliable, and reusable across iterations.\n\n2. **Aggregate into a benchmark** — run the aggregator from the skill directory:\n   ```bash\n   python -m scripts.aggregate_benchmark \u003Cworkspace>\u002Fiteration-N --skill-name \u003Cname>\n   ```\n   This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens per configuration, including mean ± stddev and the delta. If you write benchmark.json by hand, follow `references\u002Fschemas.md` exactly. Put each with-skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregates hide. See the \"Analyzing Benchmark Results\" section of `agents\u002Fanalyzer.md` for what to look for: assertions that pass no matter what (non-discriminating), high-variance evals (possibly flaky), and time\u002Ftoken tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n   ```bash\n   python \u003Cskill-creator-path>\u002Feval-viewer\u002Fgenerate_review.py \\\n     \u003Cworkspace>\u002Fiteration-N \\\n     --skill-name \"my-skill\" \\\n     --benchmark \u003Cworkspace>\u002Fiteration-N\u002Fbenchmark.json\n   ```\n   For iteration 2 and later, also pass `--previous-workspace \u003Cworkspace>\u002Fiteration-\u003CN-1>`.\n\n   **Environments with no display or browser** (remote servers, containers, sandboxes): use `--static \u003Coutput_path>` to write a standalone HTML file and hand the user the path to open. When the user clicks \"Submit All Reviews\", `feedback.json` downloads as a file; copy it back into the workspace directory so the next iteration picks it up.\n\n   Use `generate_review.py` to build the viewer — don't write your own HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. Come back here when you're done.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): last iteration's output, collapsed\n- **Formal Grades** (if grading ran): assertion pass\u002Ffail, collapsed\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage per configuration, with per-eval breakdowns and analyst observations.\n\nNavigate with the prev\u002Fnext buttons or arrow keys. When done, \"Submit All Reviews\" saves everything to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user says they're done, read `feedback.json`:\n\n```json\n{\n  \"reviews\": [\n    {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n    {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n    {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n  ],\n  \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus improvements on the cases where they raised something specific.\n\nShut down the viewer server when you're done with it (not applicable if you used `--static`).\n\n## Improving the Skill\n\nThis is the heart of the loop. The test cases ran, the user reviewed the results, and now you make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture: we're building skills meant to be used a million times (maybe literally, who knows), while iterating on only a handful of examples. That's fine for speed — the user knows these examples inside out and can judge new outputs quickly. But if the skill only works for those examples, it's useless. Rather than fiddly over-fitted tweaks, or oppressively constrictive MUSTs, try branching out: different metaphors, a different way of working. Experiments are cheap and you might land on something great.\n\n2. **Keep it lean.** Remove what isn't pulling its weight. Read the **transcripts**, not just the final outputs. If the skill is making the model waste time on unproductive work, delete the parts causing it and see what happens.\n\n3. **Explain the why.** Try hard to explain the **reason** behind everything you ask for. If you catch yourself writing ALWAYS or NEVER in all caps, or reaching for rigid structures, that's a yellow flag — reframe and explain the reasoning instead.\n\n4. **Look for repeated work across test cases.** Read the run transcripts and notice whether every run independently wrote a similar helper script or took the same multi-step approach. If all 3 cases produced a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts\u002F`, and tell the skill to use it. That saves every future invocation from reinventing the wheel.\n\nThis matters — the goal is real economic value at scale — and thinking time is not the bottleneck. Slow down and mull it over. Draft a revision, then look at it again with fresh eyes and improve it. Really try to get inside the user's head and understand what they want and need.\n\n### The iteration loop\n\nAfter improving:\n\n1. Apply the improvements to the skill\n2. Rerun all test cases into a new `iteration-\u003CN+1>\u002F` directory, including baseline runs. When creating a new skill, the baseline is always `without_skill` (no skill) and stays the same across iterations. When improving an existing skill, use judgment on what makes the better baseline: the version the user arrived with, or the previous iteration\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and say they're done\n5. Read the new feedback, improve again, repeat\n\nBilingual skills: iterate in the Chinese version until it's stable, then sync the finalized text to English and **run a separate verification pass on the English version** — translation drifts, so don't let English inherit the Chinese conclusions. Usually one English pass is enough.\n\nStop when:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n## Advanced: Blind Comparison\n\nWhen you want a more rigorous comparison between two versions of a skill (e.g. the user asks \"is the new version actually better?\"), there's a blind comparison system. See `agents\u002Fcomparator.md` and `agents\u002Fanalyzer.md` for details. The idea: hand two outputs to an independent agent without telling it which is which, let it judge quality, then analyze why the winner won.\n\nOptional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n## Description Optimization\n\nThe `description` field in the SKILL.md frontmatter is the primary mechanism determining whether an agent loads a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n  {\"query\": \"the user prompt\", \"should_trigger\": true},\n  {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic — something a user of this agent would actually type. Not abstract requests: concrete and specific, with detail. File paths, the user's own job and situation, column names and values, company names, URLs, a bit of backstory. Some can be all lowercase, include abbreviations, typos, or casual speech. Mix the lengths, and focus on edge cases rather than clean-cut ones (the user gets a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nThe **should-trigger** queries (8-10) need coverage: different phrasings of the same intent, some formal and some casual; cases where the user never names the skill or file type but clearly needs it; some uncommon use cases; and cases where this skill competes with another but should win.\n\nThe **should-not-trigger** queries (8-10) are most valuable as near-misses — queries that share keywords or concepts with the skill but actually need something else. Think adjacent domains, ambiguous phrasing where naive keyword matching would fire but shouldn't, and cases that touch the skill's territory where another tool is the better answer.\n\nThe key thing to avoid: should-not-trigger queries that are obviously irrelevant. \"Write a fibonacci function\" as a negative for a PDF skill is too easy — it tests nothing. Negatives have to be genuinely tricky.\n\n### Step 2: Review with the user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read `assets\u002Feval_review.html`\n2. Replace the placeholders:\n   - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no surrounding quotes — it's a JS variable assignment)\n   - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n   - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file and open it:\n   - macOS: `open \u002Ftmp\u002Feval_review_\u003Cskill-name>.html`\n   - Windows: `Start-Process \u003Cpath>`\n   - Linux: `xdg-open \u003Cpath>`\n4. The user can edit queries, toggle should-trigger, add or remove entries, then click \"Export Eval Set\"\n5. The file downloads to the Downloads folder — if there are several (e.g. `eval_set (1).json`), take the newest\n\nThis step matters: bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take a while — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run it:\n\n```bash\npython -m scripts.run_loop \\\n  --eval-set \u003Cpath-to-trigger-eval.json> \\\n  --skill-path \u003Cpath-to-skill> \\\n  --agent auto \\\n  --max-iterations 5 \\\n  --verbose\n```\n\n`--agent auto` picks the first supported CLI found on PATH. To use something else, or pass a model:\n\n```bash\n# a specific preset\npython -m scripts.run_loop ... --agent codex\n\n# any custom CLI: tell it how to receive the prompt\npython -m scripts.run_loop ... --agent-cmd \"my-agent --print {prompt}\"\n\n# that CLI reads the prompt from stdin\npython -m scripts.run_loop ... --agent-cmd \"my-agent --print\" --agent-transport stdin\n\n# model (only when the CLI supports one)\npython -m scripts.run_loop ... --model \u003Cmodel-id>\n```\n\n`{prompt}` is a placeholder. If your template has none, the prompt is appended as the final argument. The `SKILL_CREATOR_AGENT_CMD` environment variable works in place of `--agent-cmd`.\n\nThis handles the full loop automatically: it splits the eval set 60% train \u002F 40% held-out test, evaluates the current description (running each query 3 times for a reliable trigger rate), then asks the agent to propose improvements based on what failed. Each new description is re-evaluated on both splits, iterating up to 5 times. When it finishes it opens an HTML report showing the results per iteration and returns JSON whose `best_description` is selected by test score rather than train score, to avoid overfitting.\n\nWhile it runs, tail the output periodically and tell the user which iteration it's on and how the scores look.\n\n### How skill triggering works\n\nUnderstanding triggering helps you design better eval queries. Skills appear in the agent's skill list as name + description, and the agent decides purely from that description whether to consult the skill. Crucially, agents only consult skills for tasks they can't easily handle on their own. A simple one-step request like \"read this PDF\" may not trigger a skill even with a perfect description, because the agent can just do it. Complex, multi-step, or specialized requests reliably trigger skills when the description matches.\n\nSo eval queries need enough substance that the agent would actually benefit from the skill. \"Read file X\" is a poor test case — it won't trigger regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user the before\u002Fafter and report the scores.\n\nFor a bilingual skill, **run this once per language**: the two descriptions are worded differently and trigger differently, so a Chinese `best_description` cannot be translated into the English result. Write the eval queries in the target users' language too — Chinese queries for the zh-CN copy, English for the en-US copy. Running Chinese queries against an English description measures the wrong thing.\n\n## Package and Present\n\nTo hand the user a distributable skill package (only if your environment can give files back to the user; otherwise skip this):\n\n```bash\npython -m scripts.package_skill \u003Cpath\u002Fto\u002Fskill-folder>\n```\n\nAfter packaging, point the user at the resulting `.skill` file so they can install it.\n\nA bilingual skill means **one package per language directory**, keeping the identical output filename apart by directory (e.g. `dist\u002Fzh-CN\u002F\u003Cskill-name>.skill` and `dist\u002Fen-US\u002F\u003Cskill-name>.skill`) so one doesn't overwrite the other. Say clearly which package is which language. If the user asked for a single language, package only that one.\n\n## Adapting to Your Environment\n\nThe core workflow (draft → test → review → improve → repeat) is the same everywhere; only the mechanics change. Work out which environment you're in, then adjust. Three questions settle it: can you run subagents in parallel? Is there a display? Is an agent CLI available?\n\n### Parallel subagents available\n\nThe best case. Test cases really do run in parallel, baseline comparisons are meaningful, and quantitative benchmarking is worth doing.\n\n- Spawn two subagents per test case (with skill \u002F baseline) in the same turn\n- Have each subagent write its own `metrics.json` (tool call counts, output characters, errors encountered) for use during grading\n- If you hit severe timeout problems, running cases in series is acceptable\n\n### No subagents (single-threaded, e.g. a web chat or a single-process CLI)\n\n- Can't parallelize, so go one at a time. For each test case, read the skill's `SKILL.md` and then follow it to complete the prompt. Less rigorous than independent subagents (you wrote the skill and you're carrying all the context), but a useful sanity check — and the human review step compensates\n- **Skip baseline runs** — without independent execution, baseline comparison means nothing\n- **Skip quantitative benchmarking** — same reason. Put the effort into qualitative feedback instead\n\n### No browser or display\n\n- Generate the viewer with `--static \u003Coutput_path>` to write a standalone HTML file, and give the user the path to open themselves\n- If you can't show HTML at all, present results directly in the conversation: for each test case, the prompt and the output. If the output is a file (.docx, .xlsx), save it to the filesystem and tell the user where, so they can download and inspect it. Ask inline: \"How does this look? Anything you'd change?\"\n\n### No agent CLI available\n\nThe quantitative triggering features (turn the description into a template any CLI can consume) need a non-interactive agent CLI. Without one:\n\n- Skip the description-optimization section entirely\n- Test cases can still run, but only by hand in the main conversation, with scores judged by a human\n- Writing the skill, designing evals, and packaging are all unaffected\n\n### If Claude Code \u002F Claude.ai \u002F Cowork is your main tool\n\nThe upstream original was written for these environments. What's different here:\n\n- **Claude Code**: the full workflow works. `--agent claude` is one of the default presets and `auto` usually selects it. Packaged `.skill` files can be shared directly\n- **Claude.ai**: no subagents, and no non-interactive `claude` CLI, so follow the two reduced modes above. `package_skill.py` still works with nothing but Python and a filesystem\n- **Cowork**: has subagents, so the main workflow runs; no display, so use `--static` for the viewer. Note that agents in these environments tend to skip generating the viewer after tests finish, so one more time: **in every environment, generate the viewer with `generate_review.py` before evaluating or revising the skill yourself.** Use the provided script; don't write boutique HTML. The whole point is getting examples in front of the human as fast as possible\n\n### Updating an existing skill\n\nThe user may be asking you to update an existing skill rather than create a new one. If so:\n\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field and use them unchanged. If the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`)\n- **Copy to a writable location before editing.** The installed path may be read-only. Copy to a temp directory, edit there, and package from the copy\n- **When packaging manually, stage in a temp directory first**, then copy to the output location — direct writes may fail on permissions\n\n## Reference Files\n\nThe `agents\u002F` directory holds instructions for specialized subagents. Read them when you need to spawn the relevant one:\n\n- `agents\u002Fgrader.md` — how to evaluate assertions against outputs\n- `agents\u002Fcomparator.md` — how to do a blind A\u002FB comparison between two outputs\n- `agents\u002Fanalyzer.md` — how to analyze why one version beat another\n\nThe `references\u002F` directory has additional documentation:\n\n- `references\u002Fschemas.md` — JSON structures for evals.json, grading.json, and friends\n- `references\u002Fagent-cli.md` — configuring the agent adapter: preset list, custom command templates, where the probe skill gets installed, and per-CLI differences\n\n## Bilingual Versions\n\nThis skill follows the bilingual skill-repository rules, and **bilingual is the default output** (see \"Language: Bilingual by Default, User Overrides\" above); both versions are independently usable. What follows covers organization, priority, synchronization, and distribution. Where these rules conflict with the skill-authoring instructions above, **follow the authoring instructions for skill implementation** while preserving the bilingual requirements below.\n\n### 1. Language Structure\n\nEvery skill repository MUST use the following directory structure:\n\n```text\nskill-name\u002F\n├── zh-CN\u002F\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       ├── scripts\u002F\n│       ├── references\u002F\n│       └── assets\u002F\n│\n├── en-US\u002F\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       ├── scripts\u002F\n│       ├── references\u002F\n│       └── assets\u002F\n│\n├── README.md\n```\n\n- `zh-CN\u002F`: Simplified Chinese version.\n- `en-US\u002F`: American English version.\n- Both language directories MUST contain an independently usable skill.\n- Both versions MUST use the same skill name.\n- Optional directories SHOULD only be created when needed.\n- Do **not** generate `LICENSE` or `.gitignore` for a skill. A skill is a capability package; licensing and ignore rules belong at the repository level, and dropping them into every skill directory just pollutes the install artifact. Add them only when the user explicitly asks.\n\n### 2. Development Priority\n\nSimplified Chinese is the primary development language.\n\n1. ALWAYS create and develop the Simplified Chinese version first.\n2. Complete implementation, verification, and revision of the Chinese version before translating it.\n3. Create or update the American English version based on the verified Chinese version.\n4. NEVER independently introduce functionality or behavioral changes in the American English version.\n5. Do not delay Chinese development while preparing the American English version.\n\n### 3. Content Synchronization\n\nThe two language versions MUST maintain functional and behavioral consistency.\n\n- Keep instructions, workflows, constraints, permissions, and safety requirements equivalent.\n- Keep scripts, assets, templates, and other functional resources synchronized.\n- American English wording MAY be adapted for natural readability without changing meaning.\n- Any functional change to the Chinese version MUST trigger an English synchronization review.\n- Bug fixes and security updates MUST be reflected in both versions.\n- Never silently remove or weaken requirements during translation.\n\nEvaluate per language as well: write test prompts in the target users' language, and treat results as valid only for that language version. A Chinese pass rate says nothing about the English version — real phrasing, terminology, and edge cases differ. Functional assertions (file structure, field names, script behavior) can usually be shared across both; qualitative feedback and trigger evals must not be.\n\n### 4. Metadata and Versioning\n\nEach `SKILL.md` MUST retain the standard Agent Skills metadata requirements.\n\nUse identical skill names and version numbers across both languages.\n\nLanguage metadata SHOULD be declared as follows:\n\nChinese:\n\n```yaml\nmetadata:\n  language: zh-CN\n```\n\nAmerican English:\n\n```yaml\nmetadata:\n  language: en-US\n```\n\nBoth versions MUST use the same version number when version metadata is maintained.\n\n### 5. Independence and Dependencies\n\n- Each language version MUST be independently installable and distributable.\n- Never reference files across language directories.\n- All resource references MUST use paths relative to the corresponding skill directory.\n- Do not require users to download both language versions.\n- Do not duplicate shared functional dependencies outside the individual skill directories.\n- Do not put repository-level files such as `LICENSE` or `.gitignore` inside a skill directory — they play no part in running the skill and only clutter the install artifact.\n\n### 6. README and Publishing\n\n- The repository-level `README.md` SHOULD provide an overview and clearly identify both language versions.\n- Publish each language version as an independent skill directory.\n- The publishing process MUST preserve the skill directory structure.\n- Do not assume that every Agent automatically discovers nested language directories.\n- Verify the target Agent's skill discovery and installation behavior before publishing.\n\n### 7. Rule Precedence\n\nThese rules govern bilingual organization, language priority, synchronization, and distribution only.\n\nThe dedicated skill-authoring instructions remain responsible for skill design, content creation, formatting, and validation.\n\nWhen conflicts arise, follow the dedicated skill-authoring instructions for skill implementation, while preserving the bilingual requirements defined here.\n\n---\n\nRepeating the core loop once more for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill (bilingual by default; the language the user asked for when they asked)\n- Run an agent-with-the-skill on the test prompts\n- With the user, evaluate the outputs:\n  - Generate `benchmark.json` and run `eval-viewer\u002Fgenerate_review.py` so the human can review\n  - Run the quantitative evals\n- Repeat until you and the user are satisfied\n- Sync both language versions, package the final skill, and hand it to the user\n\nIf you have a TodoList or similar, add these steps to it so nothing gets lost.\n\nGood luck.\n","# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nOne premise up front: **this skill is not tied to any single vendor, IDE, or CLI.** Anything that can run Python and invoke an agent CLI non-interactively can use it — Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Finch, or an agent you wrote yourself. The scripts pick an agent through one adapter layer, `scripts\u002Fagent_cli.py`, so switching tools never requires rewriting the skill. Users whose main tool is Claude will find notes for those environments below, but those are \"special cases for one tool\", not the main path.\n\nAt a high level, creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft (bilingual by default: Chinese first, then sync English once verified; only one language when the user asked for one)\n- Create a few test prompts and run an agent-with-access-to-the-skill on them\n- Help the user evaluate the results, both qualitatively and quantitatively\n  - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, use them as-is or modify what needs changing). Then explain them to the user — or, if they already existed, explain the ones that already exist\n  - Use `eval-viewer\u002Fgenerate_review.py` to show the user the results, and let them look at the quantitative metrics too\n- Rewrite the skill based on the user's evaluation of the results (and fix any glaring flaws the quantitative benchmarks make obvious)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process, then jump in and help them move forward. If they say \"I want to make a skill for X\", you can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and iterate. If they already have a draft, go straight to the eval\u002Fiterate loop.\n\nAlways stay flexible: if the user says \"I don't need a pile of evals, just think it through with me\", do that instead.\n\nOnce the skill is basically done (order stays flexible), you can also run the description improver — a separate script whose only job is improving triggering accuracy.\n\n## Language: Bilingual by Default, User Overrides\n\n**Produce bilingual skills by default**: `zh-CN\u002F\u003Cskill-name>\u002F` and `en-US\u002F\u003Cskill-name>\u002F`, each independently usable, structured as described in the Bilingual Versions section. Don't stop to ask \"Chinese or English?\" before starting — unless the user has stated a language preference, go straight to bilingual.\n\nSwitch to a single language only when:\n\n- The user names a language (\"Chinese only\", \"English is fine\", \"do Chinese now, English later\"). Do what they said; don't helpfully add a second version they didn't ask for.\n- The user says explicitly that this is internal, throwaway, or not worth maintaining twice.\n\nFor a single-language skill, pick the language the same way: the user's choice wins, otherwise follow the language of the conversation — and mention in one line at delivery that only the \u003Clanguage> version exists and the other can be added on request.\n\nEither way, **finish the implementation before translating**. Simplified Chinese is the primary development language: implement, verify, and revise in the Chinese version, then produce the English version from it. Never introduce functionality or behavioral changes independently in the English version.\n\n## Capture Intent\n\nStart by understanding what the user actually wants. The conversation may already contain a workflow they want to capture (e.g. \"turn this into a skill\"). In that case, extract answers from the conversation first — the tools used, the sequence of steps, the corrections the user made, the input\u002Foutput formats you observed. Fill the remaining gaps with questions, and get confirmation before moving on.\n\n1. What should this skill enable the agent to do?\n2. When should it trigger? (what phrases, what contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't. Suggest the appropriate default for the skill type, but let the user decide.\n\n## Interview and Research\n\nProactively ask about edge cases, input\u002Foutput formats, example files, success criteria, and dependencies. Get this ironed out before writing test prompts.\n\nCheck which MCP tools are available. If they help with research (searching docs, finding similar skills, looking up best practices), research in parallel — via subagents if you have them, inline otherwise. Come prepared with context to reduce the burden on the user.\n\n## Write the SKILL.md\n\nFrom the interview, fill in these parts:\n\n- **name**: the identifier, kebab-case, 64 characters max\n- **description**: when to trigger, what it does. This is the entire triggering mechanism — include both what the skill does AND specific contexts for when to use it. All \"when to use\" information goes here, not in the body. Note that agents have a general tendency to *undertrigger* — to skip a skill that would have helped. To counter that, descriptions can be a little **pushy**. Instead of \"How to build a simple dashboard to display company data\", write \"How to build a simple dashboard to display company data. Use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **metadata.language**: the language tag for this copy (see the Bilingual section)\n- **compatibility**: required tools and dependencies (optional, rarely needed)\n- **the body, and everything else**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name\u002F\n├── SKILL.md (required)\n│   ├── YAML frontmatter (name, description required)\n│   └── Markdown instructions\n└── Bundled Resources (optional)\n    ├── scripts\u002F    - executable code for deterministic\u002Frepetitive tasks\n    ├── references\u002F - docs loaded into context as needed\n    └── assets\u002F     - files used in output (templates, icons, fonts)\n```\n\nSkills are bilingual by default, so the real deliverable wraps one of these in a language directory — `zh-CN\u002Fskill-name\u002F` and `en-US\u002Fskill-name\u002F`, each containing the full structure above. See \"Bilingual Versions → 1. Language Structure\".\n\n#### Progressive Disclosure\n\nSkills load in three levels:\n1. **Metadata** (name + description) — always in context (~100 words)\n2. **SKILL.md body** — in context whenever the skill triggers (\u003C500 lines ideal)\n3. **Bundled resources** — as needed (unlimited; scripts can execute without loading)\n\nThese counts are rules of thumb; go longer if the content genuinely needs it.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines. As you approach that limit, add another layer of hierarchy and clear pointers telling the agent where to go next\n- Reference files clearly from SKILL.md, with guidance on when to read them\n- For reference files over 300 lines, include a table of contents\n\n**Domain organization**: when a skill covers multiple domains or frameworks, split by variant:\n\n```\ncloud-deploy\u002F\n├── SKILL.md (workflow + selection logic)\n└── references\u002F\n    ├── aws.md\n    ├── gcp.md\n    └── azure.md\n```\n\nThe agent reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nSkills must not contain malware, exploit code, or anything that could compromise system security. Once a skill is adopted, its contents should not surprise the user in intent. Don't go along with requests to build misleading skills, or skills designed for unauthorized access or data exfiltration — and don't pretend not to notice a problem just to keep the user happy. \"Roleplay as an XYZ\" is fine.\n\n#### Writing Patterns\n\nPrefer the imperative form in instructions.\n\n**Defining output formats** — like this:\n\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** — examples are valuable. You can format them like this (if \"Input\"\u002F\"Output\" labels don't fit the domain, rename them):\n\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n#### Writing Style\n\nExplain **why** something matters rather than piling on heavy-handed MUSTs. Today's models are smart, with good theory of mind: give them a good harness and they'll go beyond rote instructions. So write a draft, then read it again with fresh eyes and improve it.\n\nKeep the skill **general** rather than over-fitted to the handful of examples in front of you.\n\n### Test Cases\n\nAfter writing the draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user (don't feel bound to my exact wording): \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals\u002Fevals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next section, while the runs are in flight.\n\n```json\n{\n  \"skill_name\": \"example-skill\",\n  \"evals\": [\n    {\n      \"id\": 1,\n      \"prompt\": \"User's task prompt\",\n      \"expected_output\": \"Description of expected result\",\n      \"files\": []\n    }\n  ]\n}\n```\n\nSee `references\u002Fschemas.md` for the full schema, including the `assertions` field you'll add later.\n\n## Running and Evaluating Test Cases\n\nThis section is one continuous sequence — don't stop partway through.\n\nPut results in `\u003Cskill-name>-workspace\u002F`, a sibling of the skill directory. The layout is a contract, because the aggregator scans for exactly this shape — miss a level and it finds nothing:\n\n```text\n\u003Cskill-name>-workspace\u002F\n└── iteration-1\u002F\n    ├── csv-column-tidy\u002F            ← test case, descriptive name\n    │   ├── eval_metadata.json\n    │   ├── with_skill\u002F\n    │   │   ├── run-1\u002F\n    │   │   │   ├── outputs\u002F        ← produced files\n    │   │   │   ├── grading.json\n    │   │   │   └── timing.json\n    │   │   └── run-2\u002F              ← only when repeating a config\n    │   └── without_skill\u002F\n    │       └── run-1\u002F\n    │           ├── outputs\u002F\n    │           └── grading.json\n    └── pdf-table-extract\u002F\n        └── …\n```\n\nThe rules:\n- Test-case directories may — and should — be descriptively named rather than `eval-0`\n- **Every configuration needs that `run-\u003CN>\u002F` level**, and `grading.json` belongs inside the run directory\n- One run means `run-1`; repeat runs mean `run-1`, `run-2`, which the aggregator turns into mean ± stddev\n- Don't create all of it upfront — build as you go\n\n`python -m scripts.aggregate_benchmark` scans for `\u003Ccase>\u002F\u003Cconfig>\u002Frun-\u003CN>\u002Fgrading.json`. If the shape is wrong it exits with an error instead of writing an all-zero benchmark.\n\n### Step 1: Spawn every run in the same turn\n\nEach test case gets two runs — one with the skill, one as a baseline. The important part: don't run the with-skill cases first and come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \u003Cpath-to-skill>\n- Task: \u003Ceval prompt>\n- Input files: \u003Cthe eval's files, or \"none\">\n- Save outputs to: \u003Cworkspace>\u002Fiteration-\u003CN>\u002F\u003Ccase-name>\u002Fwith_skill\u002Frun-1\u002Foutputs\u002F\n- Outputs to save: \u003Cwhat the user actually cares about — e.g. \"the .docx file\", \"the final CSV\">\n```\n\n**Baseline run** (same prompt; what the baseline is depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, saved to `without_skill\u002Frun-1\u002Foutputs\u002F`\n- **Improving an existing skill**: the old version. Snapshot it before editing (`cp -r \u003Cskill-path> \u003Cworkspace>\u002Fskill-snapshot\u002F`, or `Copy-Item -Recurse` on Windows), then point the baseline run at the snapshot, saved to `old_skill\u002Frun-1\u002Foutputs\u002F`\n\nBilingual skills: `\u003Cpath-to-skill>` points at a **specific language directory** (e.g. `zh-CN\u002F\u003Cskill-name>`), one language per evaluation run, with test prompts written in that language. Each language gets its own full with-skill\u002Fbaseline comparison — don't mix them, and don't use the Chinese results to draw conclusions about the English version.\n\nWrite an `eval_metadata.json` for each test case (assertions can stay empty for now). Name each eval for what it tests — not just \"eval-0\". Use that name for the directory too. If this iteration uses new or modified prompts, create these files for every new eval directory; don't assume they carry over from the previous iteration.\n\n```json\n{\n  \"eval_id\": 0,\n  \"eval_name\": \"descriptive-name-here\",\n  \"prompt\": \"The user's task prompt\",\n  \"assertions\": []\n}\n```\n\n**On \"spawning\" a run**: it depends on your harness. With parallel subagents, give each run its own (for example Finch's `multi_agent_run`, or a task\u002Fsubagent tool in other CLIs). Without them, run the cases in series, or just work through the skill's instructions yourself in the main conversation. Either way, two things stay true: the with-skill and baseline runs must be a fair comparison, and each run's outputs must land in its own `outputs\u002F` directory.\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait. Use the time to draft quantitative assertions for each test case and explain them to the user. If `evals\u002Fevals.json` already has assertions, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — someone glancing at the benchmark report should immediately understand what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively; don't force assertions onto things that need human judgment.\n\nUpdate `eval_metadata.json` and `evals\u002Fevals.json` once the assertions are drafted. Also explain what the user will see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nEvery finished run should give you a token count and a duration. Whatever your harness exposes — a task completion notification, a log line, your own timing — write it to `timing.json` in that run's directory straight away:\n\n```json\n{\n  \"total_tokens\": 84852,\n  \"duration_ms\": 23332,\n  \"total_duration_seconds\": 23.3\n}\n```\n\nThis is easy to skip and impossible to recover later. **If you don't have exact numbers, don't invent them**: keep the fields you do have (even if it's only your own wall-clock time) and omit the rest. A missing column in the benchmark beats a fabricated one.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — have a grader agent (or yourself, in the main conversation) read `agents\u002Fgrader.md` and evaluate each assertion against the outputs; save results to `grading.json` in each run directory. The `grading.json` expectations array must use the field names `text`, `passed`, and `evidence` (not `name`\u002F`met`\u002F`details` or any other variant) — the viewer depends on those exact names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it: faster, more reliable, and reusable across iterations.\n\n2. **Aggregate into a benchmark** — run the aggregator from the skill directory:\n   ```bash\n   python -m scripts.aggregate_benchmark \u003Cworkspace>\u002Fiteration-N --skill-name \u003Cname>\n   ```\n   This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens per configuration, including mean ± stddev and the delta. If you write benchmark.json by hand, follow `references\u002Fschemas.md` exactly. Put each with-skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregates hide. See the \"Analyzing Benchmark Results\" section of `agents\u002Fanalyzer.md` for what to look for: assertions that pass no matter what (non-discriminating), high-variance evals (possibly flaky), and time\u002Ftoken tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n   ```bash\n   python \u003Cskill-creator-path>\u002Feval-viewer\u002Fgenerate_review.py \\\n     \u003Cworkspace>\u002Fiteration-N \\\n     --skill-name \"my-skill\" \\\n     --benchmark \u003Cworkspace>\u002Fiteration-N\u002Fbenchmark.json\n   ```\n   For iteration 2 and later, also pass `--previous-workspace \u003Cworkspace>\u002Fiteration-\u003CN-1>`.\n\n   **Environments with no display or browser** (remote servers, containers, sandboxes): use `--static \u003Coutput_path>` to write a standalone HTML file and hand the user the path to open. When the user clicks \"Submit All Reviews\", `feedback.json` downloads as a file; copy it back into the workspace directory so the next iteration picks it up.\n\n   Use `generate_review.py` to build the viewer — don't write your own HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. Come back here when you're done.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): last iteration's output, collapsed\n- **Formal Grades** (if grading ran): assertion pass\u002Ffail, collapsed\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage per configuration, with per-eval breakdowns and analyst observations.\n\nNavigate with the prev\u002Fnext buttons or arrow keys. When done, \"Submit All Reviews\" saves everything to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user says they're done, read `feedback.json`:\n\n```json\n{\n  \"reviews\": [\n    {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n    {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n    {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n  ],\n  \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus improvements on the cases where they raised something specific.\n\nShut down the viewer server when you're done with it (not applicable if you used `--static`).\n\n## Improving the Skill\n\nThis is the heart of the loop. The test cases ran, the user reviewed the results, and now you make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture: we're building skills meant to be used a million times (maybe literally, who knows), while iterating on only a handful of examples. That's fine for speed — the user knows these examples inside out and can judge new outputs quickly. But if the skill only works for those examples, it's useless. Rather than fiddly over-fitted tweaks, or oppressively constrictive MUSTs, try branching out: different metaphors, a different way of working. Experiments are cheap and you might land on something great.\n\n2. **Keep it lean.** Remove what isn't pulling its weight. Read the **transcripts**, not just the final outputs. If the skill is making the model waste time on unproductive work, delete the parts causing it and see what happens.\n\n3. **Explain the why.** Try hard to explain the **reason** behind everything you ask for. If you catch yourself writing ALWAYS or NEVER in all caps, or reaching for rigid structures, that's a yellow flag — reframe and explain the reasoning instead.\n\n4. **Look for repeated work across test cases.** Read the run transcripts and notice whether every run independently wrote a similar helper script or took the same multi-step approach. If all 3 cases produced a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts\u002F`, and tell the skill to use it. That saves every future invocation from reinventing the wheel.\n\nThis matters — the goal is real economic value at scale — and thinking time is not the bottleneck. Slow down and mull it over. Draft a revision, then look at it again with fresh eyes and improve it. Really try to get inside the user's head and understand what they want and need.\n\n### The iteration loop\n\nAfter improving:\n\n1. Apply the improvements to the skill\n2. Rerun all test cases into a new `iteration-\u003CN+1>\u002F` directory, including baseline runs. When creating a new skill, the baseline is always `without_skill` (no skill) and stays the same across iterations. When improving an existing skill, use judgment on what makes the better baseline: the version the user arrived with, or the previous iteration\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and say they're done\n5. Read the new feedback, improve again, repeat\n\nBilingual skills: iterate in the Chinese version until it's stable, then sync the finalized text to English and **run a separate verification pass on the English version** — translation drifts, so don't let English inherit the Chinese conclusions. Usually one English pass is enough.\n\nStop when:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n## Advanced: Blind Comparison\n\nWhen you want a more rigorous comparison between two versions of a skill (e.g. the user asks \"is the new version actually better?\"), there's a blind comparison system. See `agents\u002Fcomparator.md` and `agents\u002Fanalyzer.md` for details. The idea: hand two outputs to an independent agent without telling it which is which, let it judge quality, then analyze why the winner won.\n\nOptional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n## Description Optimization\n\nThe `description` field in the SKILL.md frontmatter is the primary mechanism determining whether an agent loads a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n  {\"query\": \"the user prompt\", \"should_trigger\": true},\n  {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic — something a user of this agent would actually type. Not abstract requests: concrete and specific, with detail. File paths, the user's own job and situation, column names and values, company names, URLs, a bit of backstory. Some can be all lowercase, include abbreviations, typos, or casual speech. Mix the lengths, and focus on edge cases rather than clean-cut ones (the user gets a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nThe **should-trigger** queries (8-10) need coverage: different phrasings of the same intent, some formal and some casual; cases where the user never names the skill or file type but clearly needs it; some uncommon use cases; and cases where this skill competes with another but should win.\n\nThe **should-not-trigger** queries (8-10) are most valuable as near-misses — queries that share keywords or concepts with the skill but actually need something else. Think adjacent domains, ambiguous phrasing where naive keyword matching would fire but shouldn't, and cases that touch the skill's territory where another tool is the better answer.\n\nThe key thing to avoid: should-not-trigger queries that are obviously irrelevant. \"Write a fibonacci function\" as a negative for a PDF skill is too easy — it tests nothing. Negatives have to be genuinely tricky.\n\n### Step 2: Review with the user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read `assets\u002Feval_review.html`\n2. Replace the placeholders:\n   - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no surrounding quotes — it's a JS variable assignment)\n   - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n   - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file and open it:\n   - macOS: `open \u002Ftmp\u002Feval_review_\u003Cskill-name>.html`\n   - Windows: `Start-Process \u003Cpath>`\n   - Linux: `xdg-open \u003Cpath>`\n4. The user can edit queries, toggle should-trigger, add or remove entries, then click \"Export Eval Set\"\n5. The file downloads to the Downloads folder — if there are several (e.g. `eval_set (1).json`), take the newest\n\nThis step matters: bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take a while — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run it:\n\n```bash\npython -m scripts.run_loop \\\n  --eval-set \u003Cpath-to-trigger-eval.json> \\\n  --skill-path \u003Cpath-to-skill> \\\n  --agent auto \\\n  --max-iterations 5 \\\n  --verbose\n```\n\n`--agent auto` picks the first supported CLI found on PATH. To use something else, or pass a model:\n\n```bash\n# a specific preset\npython -m scripts.run_loop ... --agent codex\n\n# any custom CLI: tell it how to receive the prompt\npython -m scripts.run_loop ... --agent-cmd \"my-agent --print {prompt}\"\n\n# that CLI reads the prompt from stdin\npython -m scripts.run_loop ... --agent-cmd \"my-agent --print\" --agent-transport stdin\n\n# model (only when the CLI supports one)\npython -m scripts.run_loop ... --model \u003Cmodel-id>\n```\n\n`{prompt}` is a placeholder. If your template has none, the prompt is appended as the final argument. The `SKILL_CREATOR_AGENT_CMD` environment variable works in place of `--agent-cmd`.\n\nThis handles the full loop automatically: it splits the eval set 60% train \u002F 40% held-out test, evaluates the current description (running each query 3 times for a reliable trigger rate), then asks the agent to propose improvements based on what failed. Each new description is re-evaluated on both splits, iterating up to 5 times. When it finishes it opens an HTML report showing the results per iteration and returns JSON whose `best_description` is selected by test score rather than train score, to avoid overfitting.\n\nWhile it runs, tail the output periodically and tell the user which iteration it's on and how the scores look.\n\n### How skill triggering works\n\nUnderstanding triggering helps you design better eval queries. Skills appear in the agent's skill list as name + description, and the agent decides purely from that description whether to consult the skill. Crucially, agents only consult skills for tasks they can't easily handle on their own. A simple one-step request like \"read this PDF\" may not trigger a skill even with a perfect description, because the agent can just do it. Complex, multi-step, or specialized requests reliably trigger skills when the description matches.\n\nSo eval queries need enough substance that the agent would actually benefit from the skill. \"Read file X\" is a poor test case — it won't trigger regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user the before\u002Fafter and report the scores.\n\nFor a bilingual skill, **run this once per language**: the two descriptions are worded differently and trigger differently, so a Chinese `best_description` cannot be translated into the English result. Write the eval queries in the target users' language too — Chinese queries for the zh-CN copy, English for the en-US copy. Running Chinese queries against an English description measures the wrong thing.\n\n## Package and Present\n\nTo hand the user a distributable skill package (only if your environment can give files back to the user; otherwise skip this):\n\n```bash\npython -m scripts.package_skill \u003Cpath\u002Fto\u002Fskill-folder>\n```\n\nAfter packaging, point the user at the resulting `.skill` file so they can install it.\n\nA bilingual skill means **one package per language directory**, keeping the identical output filename apart by directory (e.g. `dist\u002Fzh-CN\u002F\u003Cskill-name>.skill` and `dist\u002Fen-US\u002F\u003Cskill-name>.skill`) so one doesn't overwrite the other. Say clearly which package is which language. If the user asked for a single language, package only that one.\n\n## Adapting to Your Environment\n\nThe core workflow (draft → test → review → improve → repeat) is the same everywhere; only the mechanics change. Work out which environment you're in, then adjust. Three questions settle it: can you run subagents in parallel? Is there a display? Is an agent CLI available?\n\n### Parallel subagents available\n\nThe best case. Test cases really do run in parallel, baseline comparisons are meaningful, and quantitative benchmarking is worth doing.\n\n- Spawn two subagents per test case (with skill \u002F baseline) in the same turn\n- Have each subagent write its own `metrics.json` (tool call counts, output characters, errors encountered) for use during grading\n- If you hit severe timeout problems, running cases in series is acceptable\n\n### No subagents (single-threaded, e.g. a web chat or a single-process CLI)\n\n- Can't parallelize, so go one at a time. For each test case, read the skill's `SKILL.md` and then follow it to complete the prompt. Less rigorous than independent subagents (you wrote the skill and you're carrying all the context), but a useful sanity check — and the human review step compensates\n- **Skip baseline runs** — without independent execution, baseline comparison means nothing\n- **Skip quantitative benchmarking** — same reason. Put the effort into qualitative feedback instead\n\n### No browser or display\n\n- Generate the viewer with `--static \u003Coutput_path>` to write a standalone HTML file, and give the user the path to open themselves\n- If you can't show HTML at all, present results directly in the conversation: for each test case, the prompt and the output. If the output is a file (.docx, .xlsx), save it to the filesystem and tell the user where, so they can download and inspect it. Ask inline: \"How does this look? Anything you'd change?\"\n\n### No agent CLI available\n\nThe quantitative triggering features (turn the description into a template any CLI can consume) need a non-interactive agent CLI. Without one:\n\n- Skip the description-optimization section entirely\n- Test cases can still run, but only by hand in the main conversation, with scores judged by a human\n- Writing the skill, designing evals, and packaging are all unaffected\n\n### If Claude Code \u002F Claude.ai \u002F Cowork is your main tool\n\nThe upstream original was written for these environments. What's different here:\n\n- **Claude Code**: the full workflow works. `--agent claude` is one of the default presets and `auto` usually selects it. Packaged `.skill` files can be shared directly\n- **Claude.ai**: no subagents, and no non-interactive `claude` CLI, so follow the two reduced modes above. `package_skill.py` still works with nothing but Python and a filesystem\n- **Cowork**: has subagents, so the main workflow runs; no display, so use `--static` for the viewer. Note that agents in these environments tend to skip generating the viewer after tests finish, so one more time: **in every environment, generate the viewer with `generate_review.py` before evaluating or revising the skill yourself.** Use the provided script; don't write boutique HTML. The whole point is getting examples in front of the human as fast as possible\n\n### Updating an existing skill\n\nThe user may be asking you to update an existing skill rather than create a new one. If so:\n\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field and use them unchanged. If the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`)\n- **Copy to a writable location before editing.** The installed path may be read-only. Copy to a temp directory, edit there, and package from the copy\n- **When packaging manually, stage in a temp directory first**, then copy to the output location — direct writes may fail on permissions\n\n## Reference Files\n\nThe `agents\u002F` directory holds instructions for specialized subagents. Read them when you need to spawn the relevant one:\n\n- `agents\u002Fgrader.md` — how to evaluate assertions against outputs\n- `agents\u002Fcomparator.md` — how to do a blind A\u002FB comparison between two outputs\n- `agents\u002Fanalyzer.md` — how to analyze why one version beat another\n\nThe `references\u002F` directory has additional documentation:\n\n- `references\u002Fschemas.md` — JSON structures for evals.json, grading.json, and friends\n- `references\u002Fagent-cli.md` — configuring the agent adapter: preset list, custom command templates, where the probe skill gets installed, and per-CLI differences\n\n## Bilingual Versions\n\nThis skill follows the bilingual skill-repository rules, and **bilingual is the default output** (see \"Language: Bilingual by Default, User Overrides\" above); both versions are independently usable. What follows covers organization, priority, synchronization, and distribution. Where these rules conflict with the skill-authoring instructions above, **follow the authoring instructions for skill implementation** while preserving the bilingual requirements below.\n\n### 1. Language Structure\n\nEvery skill repository MUST use the following directory structure:\n\n```text\nskill-name\u002F\n├── zh-CN\u002F\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       ├── scripts\u002F\n│       ├── references\u002F\n│       └── assets\u002F\n│\n├── en-US\u002F\n│   └── skill-name\u002F\n│       ├── SKILL.md\n│       ├── scripts\u002F\n│       ├── references\u002F\n│       └── assets\u002F\n│\n├── README.md\n```\n\n- `zh-CN\u002F`: Simplified Chinese version.\n- `en-US\u002F`: American English version.\n- Both language directories MUST contain an independently usable skill.\n- Both versions MUST use the same skill name.\n- Optional directories SHOULD only be created when needed.\n- Do **not** generate `LICENSE` or `.gitignore` for a skill. A skill is a capability package; licensing and ignore rules belong at the repository level, and dropping them into every skill directory just pollutes the install artifact. Add them only when the user explicitly asks.\n\n### 2. Development Priority\n\nSimplified Chinese is the primary development language.\n\n1. ALWAYS create and develop the Simplified Chinese version first.\n2. Complete implementation, verification, and revision of the Chinese version before translating it.\n3. Create or update the American English version based on the verified Chinese version.\n4. NEVER independently introduce functionality or behavioral changes in the American English version.\n5. Do not delay Chinese development while preparing the American English version.\n\n### 3. Content Synchronization\n\nThe two language versions MUST maintain functional and behavioral consistency.\n\n- Keep instructions, workflows, constraints, permissions, and safety requirements equivalent.\n- Keep scripts, assets, templates, and other functional resources synchronized.\n- American English wording MAY be adapted for natural readability without changing meaning.\n- Any functional change to the Chinese version MUST trigger an English synchronization review.\n- Bug fixes and security updates MUST be reflected in both versions.\n- Never silently remove or weaken requirements during translation.\n\nEvaluate per language as well: write test prompts in the target users' language, and treat results as valid only for that language version. A Chinese pass rate says nothing about the English version — real phrasing, terminology, and edge cases differ. Functional assertions (file structure, field names, script behavior) can usually be shared across both; qualitative feedback and trigger evals must not be.\n\n### 4. Metadata and Versioning\n\nEach `SKILL.md` MUST retain the standard Agent Skills metadata requirements.\n\nUse identical skill names and version numbers across both languages.\n\nLanguage metadata SHOULD be declared as follows:\n\nChinese:\n\n```yaml\nmetadata:\n  language: zh-CN\n```\n\nAmerican English:\n\n```yaml\nmetadata:\n  language: en-US\n```\n\nBoth versions MUST use the same version number when version metadata is maintained.\n\n### 5. Independence and Dependencies\n\n- Each language version MUST be independently installable and distributable.\n- Never reference files across language directories.\n- All resource references MUST use paths relative to the corresponding skill directory.\n- Do not require users to download both language versions.\n- Do not duplicate shared functional dependencies outside the individual skill directories.\n- Do not put repository-level files such as `LICENSE` or `.gitignore` inside a skill directory — they play no part in running the skill and only clutter the install artifact.\n\n### 6. README and Publishing\n\n- The repository-level `README.md` SHOULD provide an overview and clearly identify both language versions.\n- Publish each language version as an independent skill directory.\n- The publishing process MUST preserve the skill directory structure.\n- Do not assume that every Agent automatically discovers nested language directories.\n- Verify the target Agent's skill discovery and installation behavior before publishing.\n\n### 7. Rule Precedence\n\nThese rules govern bilingual organization, language priority, synchronization, and distribution only.\n\nThe dedicated skill-authoring instructions remain responsible for skill design, content creation, formatting, and validation.\n\nWhen conflicts arise, follow the dedicated skill-authoring instructions for skill implementation, while preserving the bilingual requirements defined here.\n\n---\n\nRepeating the core loop once more for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill (bilingual by default; the language the user asked for when they asked)\n- Run an agent-with-the-skill on the test prompts\n- With the user, evaluate the outputs:\n  - Generate `benchmark.json` and run `eval-viewer\u002Fgenerate_review.py` so the human can review\n  - Run the quantitative evals\n- Repeat until you and the user are satisfied\n- Sync both language versions, package the final skill, and hand it to the user\n\nIf you have a TodoList or similar, add these steps to it so nothing gets lost.\n\nGood luck.\n",{"name":5,"metadata":24,"description":7},{"language":25},"en-US","main","e755255990a0250bbae1a416cea9388f10b6bf6a","multi-skill-creator\u002Fen-US\u002Fmulti-skill-creator",1,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills","https:\u002F\u002Fgithub.com\u002Fluestr","2026-11-14 01:15:26",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add luestr\u002Fskills --skill multi-skill-creator",{"tool":39,"command":40},"bunx","bunx skills add luestr\u002Fskills --skill multi-skill-creator",{"tool":42,"command":43},"pnpm","pnpm dlx skills add luestr\u002Fskills --skill multi-skill-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002FSKILL.md",true,[47,53,57,61,67,73,77,81,85,89,93,97,101,105,109,113,117,121],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"agents\u002Fanalyzer.md","REFERENCE","参考文档",10376,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fagents\u002Fanalyzer.md",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"agents\u002Fcomparator.md",7287,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fagents\u002Fcomparator.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"agents\u002Fgrader.md",9204,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fagents\u002Fgrader.md",{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"assets\u002Feval_review.html","ASSET","资产文件",7058,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fassets\u002Feval_review.html",{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"eval-viewer\u002Fgenerate_review.py","SCRIPT","脚本",16664,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Feval-viewer\u002Fgenerate_review.py",{"path":74,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":75,"sourceHtmlUrl":76},"eval-viewer\u002Fviewer.html",45000,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Feval-viewer\u002Fviewer.html",{"path":78,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fagent-cli.md",6817,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Freferences\u002Fagent-cli.md",{"path":82,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fschemas.md",13195,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Freferences\u002Fschemas.md",{"path":86,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002F__init__.py",0,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002F__init__.py",{"path":90,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fagent_cli.py",25892,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Fagent_cli.py",{"path":94,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":95,"sourceHtmlUrl":96},"scripts\u002Faggregate_benchmark.py",16481,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Faggregate_benchmark.py",{"path":98,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fgenerate_report.py",12887,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Fgenerate_report.py",{"path":102,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":103,"sourceHtmlUrl":104},"scripts\u002Fimprove_description.py",12475,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Fimprove_description.py",{"path":106,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fpackage_skill.py",4564,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Fpackage_skill.py",{"path":110,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fquick_validate.py",7248,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Fquick_validate.py",{"path":114,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Frun_eval.py",11722,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Frun_eval.py",{"path":118,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Frun_loop.py",16501,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Frun_loop.py",{"path":122,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002Futils.py",1677,"https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fmulti-skill-creator\u002Fen-US\u002Fmulti-skill-creator\u002Fscripts\u002Futils.py",[126,133,139,146,152,159],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":19},"01M7EESZM2QJKA5M0QS4M0WNGA","write-ublock-origin-filters","完整的 uBlock Origin (uBO) 静态过滤语法参考。编写 uBlock Origin 自定义过滤规则时使用此技能，涵盖广告拦截、隐私保护或内容过滤。包含基础网络过滤模式（||、*、^、|）、所有网络过滤选项（$domain、$third-party、$important、$redirect、$removeparam、$csp、$replace、$header、$method、$denyallow、$badfilter、$all 等）、内容类型选项（$script、$image、$stylesheet、$font、$media、$xhr、$popup、$document、$frame 等）、元素隐藏规则（## 选择器、实体匹配、主机名正则）、过程式元素隐藏过滤器（:has、:has-text、:matches-css、:upward、:xpath、:matches-path、:watch-attr 等）、动作操作符（:remove、:style、:remove-attr、:remove-class）、HTML 过滤器（##^）、响应头过滤（##^responseheader）、脚本注入（##+js()）以及预处理指令（!#include、!#if）。当用户提到 uBlock Origin 过滤规则、uBO 语法、广告拦截规则、元素隐藏规则、过程式选择器、脚本注入或希望编写\u002F调试任何 uBO 兼容过滤列表时触发。即使用户只是在编写或调试 uBlock Origin 过滤规则、创建自定义过滤列表或从 AdBlock Plus\u002FAdGuard 迁移过滤规则到 uBO，也应使用此技能。","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-ublock-origin-filters\u002Fzh-CN\u002Fwrite-ublock-origin-filters\u002FSKILL.md",[],[],{"skillNo":134,"name":128,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":19},"01M7EESN8NBTRJE793B87NBGA5","Complete uBlock Origin (uBO) static filter reference. Use this skill when writing or debugging uBO custom filters or filter lists for ad blocking, privacy or content filtering, or when migrating filters from AdBlock Plus\u002FAdGuard. Covers network patterns (||, *, ^, |) and options ($domain, $third-party, $important, $redirect, $removeparam, $csp, $replace, $header, $method, $badfilter, $all), content-type options ($script, $image, $stylesheet, $font, $media, $xhr, $popup, $document, $frame), cosmetic filters (##, CSS selectors, entity matching), procedural filters (:has, :has-text, :matches-css, :upward, :xpath, :matches-path, :watch-attr), action operators (:remove, :style, :remove-attr), HTML filters (##^), response-header filtering (##^responseheader), scriptlet injection (##+js()), and pre-parsing directives (!#include, !#if). Trigger whenever the user mentions uBO syntax, ad blocking rules, element hiding, procedural selectors, scriptlet injection, or a uBO-compatible filter list.","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-ublock-origin-filters\u002Fen-US\u002Fwrite-ublock-origin-filters\u002FSKILL.md",[],[],{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":19},"01M7EESH94GM6NWB3JAFRH7D8S","write-tampermonkey-scripts","引导 AI 代理规划、编写、调试、测试和维护 Tampermonkey 用户脚本。当用户请求用户脚本、浏览器页面自动化、DOM 增强、Tampermonkey 元数据、GM_* API、@match、@grant、@run-at、@connect、跨源请求、SPA 页面集成或脚本注入任务时使用此技能，即使用户没有明确提及 Tampermonkey。","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-tampermonkey-scripts\u002Fzh-CN\u002Fwrite-tampermonkey-scripts\u002FSKILL.md",[],[],{"skillNo":147,"name":141,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":19},"01M7EESCKXFQ793C4TCKSV0GZ1","Guide an AI agent through planning, writing, debugging, testing, and maintaining Tampermonkey userscripts. Use this skill whenever a user asks for a userscript, browser-page automation, DOM enhancement, Tampermonkey metadata, GM_* API, @match, @grant, @run-at, @connect, cross-origin request, SPA page integration, or script injection task, even when Tampermonkey is not named explicitly.","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-tampermonkey-scripts\u002Fen-US\u002Fwrite-tampermonkey-scripts\u002FSKILL.md",[],[],{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":19},"01M7EES6SHP4F6DTQYRJ944KMR","write-adguard-filters","编写 AdGuard 自定义过滤规则时使用此技能。涵盖基本规则语法、所有修饰符（$domain\u002F$third-party\u002F$important\u002F$redirect\u002F$replace\u002F$removeparam\u002F$cookie\u002F$csp 等）、外观规则（元素隐藏\u002FCSS\u002FExtended CSS 选择器）、HTML 过滤、JavaScript\u002F脚本片段规则、非基本规则修饰符、预处理器指令和调试技巧。当用户提及 AdGuard 过滤规则、广告拦截规则语法、过滤器列表编写、ABP 语法兼容、元素隐藏规则、Extended CSS 选择器（:has\u002F:contains\u002F:matches-css 等）时触发。即使用户只是在编写或调试任何类型的广告过滤规则，也应使用此技能。","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-adguard-filters\u002Fzh-CN\u002Fwrite-adguard-filters\u002FSKILL.md",[],[],{"skillNo":160,"name":154,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":19},"01M7EERZ661557QAD511EBSCCK","Complete AdGuard filtering rules syntax reference. Use this skill when writing AdGuard custom filters. Covers basic rule syntax, all modifiers ($domain\u002F$third-party\u002F$important\u002F$redirect\u002F$replace\u002F$removeparam\u002F$cookie\u002F$csp etc.), cosmetic rules (element hiding\u002FCSS\u002FExtended CSS selectors), HTML filtering, JavaScript\u002Fscriptlet rules, non-basic rule modifiers, preprocessor directives, and debugging. Trigger when user mentions AdGuard filtering rules, ad blocking rule syntax, filter list authoring, ABP syntax compatibility, element hiding rules, Extended CSS selectors (:has\u002F:contains\u002F:matches-css etc.). Use this skill even when the user is just writing or debugging any type of ad filtering rules.","https:\u002F\u002Fgithub.com\u002Fluestr\u002Fskills\u002Fblob\u002Fmain\u002Fwrite-adguard-filters\u002Fen-US\u002Fwrite-adguard-filters\u002FSKILL.md",[],[]]