[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7AE0WA51QTYGKCBHB994XPW":3,"skill-same:01M7AE0WA51QTYGKCBHB994XPW":114},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":19,"publishedAt":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7AE0WA51QTYGKCBHB994XPW","skill-creator",null,"Create and improve skills through a draft, test, review, and rewrite loop. Use when creating a new skill, turning a workflow into a skill, editing or improving an existing skill, testing a skill against example prompts, or tightening a skill's description so it triggers on the right requests.","KalebCole\u002Fkaleb-marketplace","KalebCole","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F93733756?v=4","01M7AE01RJTRC6YA6VRHK6D63T","Kaleb Cole","01M7AE01SKC3QXW45EFD57E6V0",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: skill-creator\ndescription: >-\n  Create and improve skills through a draft, test, review, and rewrite loop.\n  Use when creating a new skill, turning a workflow into a skill, editing or\n  improving an existing skill, testing a skill against example prompts, or\n  tightening a skill's description so it triggers on the right requests.\nlicense: Apache-2.0\n---\n# Skill Creator\n\nCreate new skills and improve existing ones through a draft, test, review, improve loop.\n\nThe loop:\n- Decide what the skill should do and roughly how.\n- Write a draft.\n- Write 2-3 realistic test prompts and run them with the skill (and a baseline without it).\n- Review the results with the user in chat, qualitatively and with simple pass\u002Ffail checks where outputs are objectively verifiable.\n- Rewrite based on feedback and any glaring flaws.\n- Repeat until the user is happy, then widen the test set.\n\nFigure out where the user is in this loop and pick up from there. If they already have a draft, go straight to testing. If they say \"just vibe with me\", skip formal evals.\n\nMatch the user's technical level. Briefly define terms like \"assertion\" or \"baseline\" unless they clearly know them.\n\n## 1. Capture intent\n\nIf the conversation already contains the workflow (\"turn this into a skill\"), extract it first: tools used, step order, corrections the user made, input and output formats. Then confirm gaps:\n1. What should the skill let an agent do?\n2. When should it trigger (phrases, contexts)?\n3. What is the output format?\n4. Choose tests when outputs or workflow steps are objectively checkable. Skip formal tests when the user requests a draft-only or informal session. Do not ask the user to choose routine validation steps.\n\nAsk about unresolved edge cases, inputs, example files, success criteria and dependencies that would change the expected result. Use available connectors and docs to research so the user carries less of the load.\n\nBefore editing, copy the existing skill folder. Use that unchanged copy for the baseline runs.\n\n## 2. Write the skill to the Agent Skills standard (agentskills.io)\n\nEvery SKILL.md starts with YAML frontmatter, then markdown instructions. These fields and limits are the [Agent Skills spec](https:\u002F\u002Fagentskills.io\u002Fspecification):\n\n```\n---\nname: skill-name\ndescription: What this skill does and when to use it.\n---\n```\n\n- **name** (required): 1-64 characters. Unicode lowercase letters, digits, and hyphens only. Must not start or end with a hyphen, must not contain `--`, and must match the parent directory name. Name a new skill verb-first, for the action it performs (`schedule-interview`, not `interview-scheduling`), so the name reads as what the agent will do.\n- **description** (required): 1-1024 characters. What the skill does and when to use it, with keywords an agent can match. This is the only field an agent sees when deciding to load the skill, so it is the trigger. Cover each distinct use. Agents under-trigger, so phrase it to catch implicit requests (\"Use when the user asks to display metrics or trends in a dashboard\", not \"Build a dashboard\"). No lists of synonyms, no workflow details.\n- **license** (optional): a short license name, or the name of a bundled license file, such as `Apache-2.0` or `Proprietary. LICENSE.txt has complete terms`.\n- **compatibility** (optional): 1-500 characters when present. Environment requirements only, such as an intended product, system packages, or network access. Omit it when the skill has none.\n- **metadata** (optional): a map of string keys to string values for properties the spec does not define. Keep key names specific enough to avoid clashes. Example: `author: example-org` and `version: \"1.0\"`.\n- **allowed-tools** (optional): one space-separated string of pre-approved tools, such as `Bash(git:*) Bash(jq:*) Read`. Experimental, and support varies by agent.\n- **Body**: the instructions, in markdown. No required sections.\n\nFolder layout:\n\n```\nskill-name\u002F\n├── SKILL.md\n├── scripts\u002F     deterministic, repeatable code the skill runs\n├── references\u002F  docs loaded only when needed\n└── assets\u002F      templates and files used in output\n```\n\nProgressive disclosure: `name` and `description` load at startup, the body loads when the skill is triggered (keep it under 500 lines; the spec recommends under 5000 tokens), and bundled files load on demand. Point to each reference file with when to read it; give long references a table of contents. For multi-variant skills, keep the workflow in SKILL.md and one reference file per variant. Reference other files with paths relative to the skill root, one level deep.\n\n### What a skill is not\n\nA skill is a reusable, self-contained capability. Keep these out of it:\n- **No user name or agent persona.** The agent already knows who it works for. Write the task, not an identity.\n- **Project-management context.** No ticket numbers, map or backlog references, PR history, or \"built for ticket B3\".\n- **Scheduling and automation.** When or how often it runs belongs in the routine or caller that invokes it. The skill just does the job when loaded.\n- **Artificial stop points.** Don't write \"stop here\" or \"wait for approval before continuing\" unless the step genuinely needs a human decision (sending, submitting, paying); say why when it does.\n- **Secrets.** No tokens, passwords or account numbers; reference where they live (an env var name or a local file path).\n\n### Writing style\n\n- Imperative voice.\n- Explain why a step matters instead of shouting MUST\u002FNEVER. All-caps rules are a yellow flag; give the reason so the model can generalize.\n- Keep it general, not overfit to one example.\n- Show output formats as an exact template, and include short input\u002Foutput examples where they help.\n- Push deterministic, repeated work into `scripts\u002F` to save tokens and reduce drift.\n- Nothing in the skill should surprise the user if described; no malicious or deceptive skills.\n\n### Pruning\n\nDescribe only the functionality: how to do the job. Drop limits, caveats and scope notes that don't change behavior. Then prune the draft line by line:\n- **One source of truth.** Each meaning lives in one place, so changing a behavior is a one-place edit. Duplicates cost tokens and inflate a rule's prominence.\n- **The environment is a source of truth.** Don't restate what a script's `--help`, a schema, a config or the folder layout already says; point to the lookup. Write down only what the agent can't find by looking: unwritten conventions, the reason behind a choice, gotchas.\n- **Relevance.** Every line must still bear on what the skill does. Cut exposition, stale lines, and branches that belong in a reference file.\n- **No-ops.** Delete any sentence the model would obey by default (test: does it change behavior versus the default?). Delete the whole sentence, don't trim words. If a leading word is too weak to beat the default, use a stronger word.\n\n## 3. Test cases\n\nWrite 2-3 realistic test prompts from the confirmed requirements and save them to `evals\u002Fevals.json`. Select the cases and run isolated tests without asking the user to approve them. You may briefly state what the tests cover, but do not pause for a response.\n\nAsk a question only when an unresolved requirement would change the expected result. Follow applicable approval rules if a test needs live uploads, external changes, or other consequential actions.\n\n```json\n{\"skill_name\": \"example-skill\", \"evals\": [{\"id\": 1, \"prompt\": \"...\", \"expected_output\": \"...\", \"files\": []}]}\n```\n\n## 4. Run and grade\n\nPut results in `\u003Cskill-name>-workspace\u002Fiteration-N\u002F\u003Ceval-name>\u002F` next to the skill folder.\n\n- For each test, launch two background workers at the same time: one with the skill (`with_skill\u002Foutputs\u002F`) and a baseline (`without_skill\u002F` for a new skill, or the unchanged copy in `old_skill\u002F` when improving one). Launch them together so they finish together.\n- While they run, draft pass\u002Ffail checks (assertions) for the objectively verifiable parts, with descriptive names, and explain them to the user. Don't force checks onto subjective qualities.\n- As each worker finishes, record its duration and token use in `timing.json` when those figures are available.\n- Grade each run: script the checks where possible, otherwise judge against the outputs. Save `grading.json` with `text`, `passed`, `evidence` per check.\n- When the runs are independent, summarize pass rate, time and tokens for with-skill vs baseline, and patterns the averages hide (checks that pass either way, flaky tests, cost tradeoffs).\n\nIf the runs are not independent, report each check and the user's feedback. Skip numerical comparisons.\n\n## 5. Review in chat\n\nPresent results in the conversation: for each test, the prompt, a short description or excerpt of the output (attach output files), the check results, and then the overall comparison. Ask for feedback per test. An empty comment is acceptance only after the user confirms review is complete. Until then, a test with no feedback is not reviewed. Save the feedback to `iteration-N\u002Ffeedback.json` (`run_id`, `feedback`) so the next iteration can reference it.\n\n## 6. Improve and repeat\n\n- Generalize from the feedback. The skill will run on many prompts beyond these tests, so avoid narrow fixes; if something is stubborn, try a different framing or pattern.\n- Keep it lean. Read the run transcripts, not just outputs; cut instructions that make the model waste effort.\n- Explain the why behind each instruction.\n- If every run reinvented the same helper, bundle it in `scripts\u002F`.\n\nRerun all tests into `iteration-N+1\u002F` with baselines, review again, and stop when the user says they are happy, when they confirm review is complete and every comment is empty, or when progress stalls. Empty feedback alone does not stop the loop.\n\n## 7. Description check (optional)\n\nOffer to tune the description. Write ~20 realistic queries: 8-10 that should trigger and 8-10 near-misses that share keywords but need something else (obviously unrelated negatives test nothing). Use concrete, casual, varied phrasing. Review the list with the user in chat, then judge whether the description separates them; revise and show before\u002Fafter. Don't claim measured trigger accuracy unless you actually ran a trigger test.\n\n## 8. Pruning review\n\nBefore shipping, hand the draft to a fresh reviewer: a background worker with no conversation history that gets only the skill folder and the \"What a skill is not\" and \"Pruning\" sections above. The author tends to keep its own lines; a fresh reader sees what is redundant. Ask it to return a list of cuts and rewrites, each with the rule it violates, not a rewritten file. Apply the cuts that hold up, rerun the tests if behavior could change, and show the user the before and after line counts. Without isolated workers, do the pass yourself, reading the draft line by line against those sections.\n\n## 9. Ship\n\n- Updating an existing skill: keep its name and folder unchanged.\n- Save it with this agent's other skills, or in the skill's repository, and return the validated folder or link to the user.\n","# Skill Creator\n\nCreate new skills and improve existing ones through a draft, test, review, improve loop.\n\nThe loop:\n- Decide what the skill should do and roughly how.\n- Write a draft.\n- Write 2-3 realistic test prompts and run them with the skill (and a baseline without it).\n- Review the results with the user in chat, qualitatively and with simple pass\u002Ffail checks where outputs are objectively verifiable.\n- Rewrite based on feedback and any glaring flaws.\n- Repeat until the user is happy, then widen the test set.\n\nFigure out where the user is in this loop and pick up from there. If they already have a draft, go straight to testing. If they say \"just vibe with me\", skip formal evals.\n\nMatch the user's technical level. Briefly define terms like \"assertion\" or \"baseline\" unless they clearly know them.\n\n## 1. Capture intent\n\nIf the conversation already contains the workflow (\"turn this into a skill\"), extract it first: tools used, step order, corrections the user made, input and output formats. Then confirm gaps:\n1. What should the skill let an agent do?\n2. When should it trigger (phrases, contexts)?\n3. What is the output format?\n4. Choose tests when outputs or workflow steps are objectively checkable. Skip formal tests when the user requests a draft-only or informal session. Do not ask the user to choose routine validation steps.\n\nAsk about unresolved edge cases, inputs, example files, success criteria and dependencies that would change the expected result. Use available connectors and docs to research so the user carries less of the load.\n\nBefore editing, copy the existing skill folder. Use that unchanged copy for the baseline runs.\n\n## 2. Write the skill to the Agent Skills standard (agentskills.io)\n\nEvery SKILL.md starts with YAML frontmatter, then markdown instructions. These fields and limits are the [Agent Skills spec](https:\u002F\u002Fagentskills.io\u002Fspecification):\n\n```\n---\nname: skill-name\ndescription: What this skill does and when to use it.\n---\n```\n\n- **name** (required): 1-64 characters. Unicode lowercase letters, digits, and hyphens only. Must not start or end with a hyphen, must not contain `--`, and must match the parent directory name. Name a new skill verb-first, for the action it performs (`schedule-interview`, not `interview-scheduling`), so the name reads as what the agent will do.\n- **description** (required): 1-1024 characters. What the skill does and when to use it, with keywords an agent can match. This is the only field an agent sees when deciding to load the skill, so it is the trigger. Cover each distinct use. Agents under-trigger, so phrase it to catch implicit requests (\"Use when the user asks to display metrics or trends in a dashboard\", not \"Build a dashboard\"). No lists of synonyms, no workflow details.\n- **license** (optional): a short license name, or the name of a bundled license file, such as `Apache-2.0` or `Proprietary. LICENSE.txt has complete terms`.\n- **compatibility** (optional): 1-500 characters when present. Environment requirements only, such as an intended product, system packages, or network access. Omit it when the skill has none.\n- **metadata** (optional): a map of string keys to string values for properties the spec does not define. Keep key names specific enough to avoid clashes. Example: `author: example-org` and `version: \"1.0\"`.\n- **allowed-tools** (optional): one space-separated string of pre-approved tools, such as `Bash(git:*) Bash(jq:*) Read`. Experimental, and support varies by agent.\n- **Body**: the instructions, in markdown. No required sections.\n\nFolder layout:\n\n```\nskill-name\u002F\n├── SKILL.md\n├── scripts\u002F     deterministic, repeatable code the skill runs\n├── references\u002F  docs loaded only when needed\n└── assets\u002F      templates and files used in output\n```\n\nProgressive disclosure: `name` and `description` load at startup, the body loads when the skill is triggered (keep it under 500 lines; the spec recommends under 5000 tokens), and bundled files load on demand. Point to each reference file with when to read it; give long references a table of contents. For multi-variant skills, keep the workflow in SKILL.md and one reference file per variant. Reference other files with paths relative to the skill root, one level deep.\n\n### What a skill is not\n\nA skill is a reusable, self-contained capability. Keep these out of it:\n- **No user name or agent persona.** The agent already knows who it works for. Write the task, not an identity.\n- **Project-management context.** No ticket numbers, map or backlog references, PR history, or \"built for ticket B3\".\n- **Scheduling and automation.** When or how often it runs belongs in the routine or caller that invokes it. The skill just does the job when loaded.\n- **Artificial stop points.** Don't write \"stop here\" or \"wait for approval before continuing\" unless the step genuinely needs a human decision (sending, submitting, paying); say why when it does.\n- **Secrets.** No tokens, passwords or account numbers; reference where they live (an env var name or a local file path).\n\n### Writing style\n\n- Imperative voice.\n- Explain why a step matters instead of shouting MUST\u002FNEVER. All-caps rules are a yellow flag; give the reason so the model can generalize.\n- Keep it general, not overfit to one example.\n- Show output formats as an exact template, and include short input\u002Foutput examples where they help.\n- Push deterministic, repeated work into `scripts\u002F` to save tokens and reduce drift.\n- Nothing in the skill should surprise the user if described; no malicious or deceptive skills.\n\n### Pruning\n\nDescribe only the functionality: how to do the job. Drop limits, caveats and scope notes that don't change behavior. Then prune the draft line by line:\n- **One source of truth.** Each meaning lives in one place, so changing a behavior is a one-place edit. Duplicates cost tokens and inflate a rule's prominence.\n- **The environment is a source of truth.** Don't restate what a script's `--help`, a schema, a config or the folder layout already says; point to the lookup. Write down only what the agent can't find by looking: unwritten conventions, the reason behind a choice, gotchas.\n- **Relevance.** Every line must still bear on what the skill does. Cut exposition, stale lines, and branches that belong in a reference file.\n- **No-ops.** Delete any sentence the model would obey by default (test: does it change behavior versus the default?). Delete the whole sentence, don't trim words. If a leading word is too weak to beat the default, use a stronger word.\n\n## 3. Test cases\n\nWrite 2-3 realistic test prompts from the confirmed requirements and save them to `evals\u002Fevals.json`. Select the cases and run isolated tests without asking the user to approve them. You may briefly state what the tests cover, but do not pause for a response.\n\nAsk a question only when an unresolved requirement would change the expected result. Follow applicable approval rules if a test needs live uploads, external changes, or other consequential actions.\n\n```json\n{\"skill_name\": \"example-skill\", \"evals\": [{\"id\": 1, \"prompt\": \"...\", \"expected_output\": \"...\", \"files\": []}]}\n```\n\n## 4. Run and grade\n\nPut results in `\u003Cskill-name>-workspace\u002Fiteration-N\u002F\u003Ceval-name>\u002F` next to the skill folder.\n\n- For each test, launch two background workers at the same time: one with the skill (`with_skill\u002Foutputs\u002F`) and a baseline (`without_skill\u002F` for a new skill, or the unchanged copy in `old_skill\u002F` when improving one). Launch them together so they finish together.\n- While they run, draft pass\u002Ffail checks (assertions) for the objectively verifiable parts, with descriptive names, and explain them to the user. Don't force checks onto subjective qualities.\n- As each worker finishes, record its duration and token use in `timing.json` when those figures are available.\n- Grade each run: script the checks where possible, otherwise judge against the outputs. Save `grading.json` with `text`, `passed`, `evidence` per check.\n- When the runs are independent, summarize pass rate, time and tokens for with-skill vs baseline, and patterns the averages hide (checks that pass either way, flaky tests, cost tradeoffs).\n\nIf the runs are not independent, report each check and the user's feedback. Skip numerical comparisons.\n\n## 5. Review in chat\n\nPresent results in the conversation: for each test, the prompt, a short description or excerpt of the output (attach output files), the check results, and then the overall comparison. Ask for feedback per test. An empty comment is acceptance only after the user confirms review is complete. Until then, a test with no feedback is not reviewed. Save the feedback to `iteration-N\u002Ffeedback.json` (`run_id`, `feedback`) so the next iteration can reference it.\n\n## 6. Improve and repeat\n\n- Generalize from the feedback. The skill will run on many prompts beyond these tests, so avoid narrow fixes; if something is stubborn, try a different framing or pattern.\n- Keep it lean. Read the run transcripts, not just outputs; cut instructions that make the model waste effort.\n- Explain the why behind each instruction.\n- If every run reinvented the same helper, bundle it in `scripts\u002F`.\n\nRerun all tests into `iteration-N+1\u002F` with baselines, review again, and stop when the user says they are happy, when they confirm review is complete and every comment is empty, or when progress stalls. Empty feedback alone does not stop the loop.\n\n## 7. Description check (optional)\n\nOffer to tune the description. Write ~20 realistic queries: 8-10 that should trigger and 8-10 near-misses that share keywords but need something else (obviously unrelated negatives test nothing). Use concrete, casual, varied phrasing. Review the list with the user in chat, then judge whether the description separates them; revise and show before\u002Fafter. Don't claim measured trigger accuracy unless you actually ran a trigger test.\n\n## 8. Pruning review\n\nBefore shipping, hand the draft to a fresh reviewer: a background worker with no conversation history that gets only the skill folder and the \"What a skill is not\" and \"Pruning\" sections above. The author tends to keep its own lines; a fresh reader sees what is redundant. Ask it to return a list of cuts and rewrites, each with the rule it violates, not a rewritten file. Apply the cuts that hold up, rerun the tests if behavior could change, and show the user the before and after line counts. Without isolated workers, do the pass yourself, reading the draft line by line against those sections.\n\n## 9. Ship\n\n- Updating an existing skill: keep its name and folder unchanged.\n- Save it with this agent's other skills, or in the skill's repository, and return the validated folder or link to the user.\n",{"name":5,"license":15,"description":7},"main","af3b09a60dcde266a005d415120c1c38e345d646","plugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator",0,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace","https:\u002F\u002Fgithub.com\u002FKalebCole","https:\u002F\u002Fkalebcole.com\u002F","Hey, I'm Kaleb!\r\n\r\nI'm a software engineer at Microsoft in Seattle. I build and operate the platform behind Azure support tickets in sovereign clouds.","2026-11-12 07:50:10",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add KalebCole\u002Fkaleb-marketplace --skill skill-creator",{"tool":40,"command":41},"bunx","bunx skills add KalebCole\u002Fkaleb-marketplace --skill skill-creator",{"tool":43,"command":44},"pnpm","pnpm dlx skills add KalebCole\u002Fkaleb-marketplace --skill skill-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002FSKILL.md",true,[48,54,58,62,68,73,77,82,86,90,94,98,102,106,110],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"agents\u002Fanalyzer.md","REFERENCE","参考文档",10376,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fagents\u002Fanalyzer.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"agents\u002Fcomparator.md",7287,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fagents\u002Fcomparator.md",{"path":59,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":60,"sourceHtmlUrl":61},"agents\u002Fgrader.md",9049,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fagents\u002Fgrader.md",{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"assets\u002Feval_review.html","ASSET","资产文件",7058,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fassets\u002Feval_review.html",{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":16},"LICENSE.txt","LICENSE","许可证",11345,{"path":74,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fschemas.md",12051,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Freferences\u002Fschemas.md",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":28,"sourceHtmlUrl":81},"scripts\u002F__init__.py","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002F__init__.py",{"path":83,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":84,"sourceHtmlUrl":85},"scripts\u002Faggregate_benchmark.py",14668,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Faggregate_benchmark.py",{"path":87,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":88,"sourceHtmlUrl":89},"scripts\u002Fgenerate_report.py",12861,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Fgenerate_report.py",{"path":91,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":92,"sourceHtmlUrl":93},"scripts\u002Fimprove_description.py",10890,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Fimprove_description.py",{"path":95,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Fpackage_skill.py",4234,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Fpackage_skill.py",{"path":99,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":100,"sourceHtmlUrl":101},"scripts\u002Fquick_validate.py",3972,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Fquick_validate.py",{"path":103,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Frun_eval.py",11441,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Frun_eval.py",{"path":107,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Frun_loop.py",13605,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Frun_loop.py",{"path":111,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":112,"sourceHtmlUrl":113},"scripts\u002Futils.py",1661,"https:\u002F\u002Fgithub.com\u002FKalebCole\u002Fkaleb-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fkaleb-skills\u002Fskills\u002Fskill-creator\u002Fscripts\u002Futils.py",[]]