[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71E5BXYDZZT0E3R78QVBFS5":3,"skill-same:01M71E5BXYDZZT0E3R78QVBFS5":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M71E5BXYDZZT0E3R78QVBFS5","skill-builder",null,"Create, revise, migrate, and evaluate production-quality Agent Skills packages with standards-compliant SKILL.md frontmatter, focused instructions, progressive disclosure, safe supporting resources, and trigger and behavior tests. Use when the user asks to build, improve, standardize, or audit a skill or SKILL.md for Alpha, Cursor, Claude Code, Codex, or another Agent Skills-compatible host. Do not use merely to install, list, or invoke an existing skill.","lukegob10\u002Falpha","lukegob10","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F70302814?v=4","01M71E4WK7A0NNE7QK5R168HKH","01M71E4WKWRSR78QAC66WCCQDT",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Fskill-builder\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"Skill Builder","builder","existing skill","revise","frontmatter","list","a skill","install","safe","audit","packages","create","code","migrate","when","invoke","host","improve","alpha","resources","2026-11-10 10:12:30",false,"---\r\nname: skill-builder\r\ndescription: >-\r\n    Create, revise, migrate, and evaluate production-quality Agent Skills packages with standards-compliant SKILL.md\r\n    frontmatter, focused instructions, progressive disclosure, safe supporting resources, and trigger and behavior tests.\r\n    Use when the user asks to build, improve, standardize, or audit a skill or SKILL.md for Alpha, Cursor, Claude Code,\r\n    Codex, or another Agent Skills-compatible host. Do not use merely to install, list, or invoke an existing skill.\r\n---\r\n\r\n# Skill Builder\r\n\r\nBuild the requested skill as a complete, usable package. Treat the skill's activation metadata, instructions, resources,\r\nand validation evidence as one behavior contract. Prefer the portable Agent Skills format; add host-specific extensions\r\nonly when the target host and benefit are explicit.\r\n\r\n## Operating rules\r\n\r\n- Follow the user's requested scope. Create or edit files when they asked for a skill; do not stop at a tutorial or a\r\n  placeholder. If they asked only for advice, a plan, or an audit, do not mutate files.\r\n- Respect the current execution mode, approval policy, workspace boundaries, and repository instructions. A skill never\r\n  grants tools, permissions, network access, or write authority that the host did not already provide.\r\n- Preserve exact wording the user explicitly supplied for the skill. Do not silently rewrite contractual text, templates,\r\n  commands, or policy language.\r\n- Inspect an existing skill package before revising it. Preserve working behavior and unrelated user content unless the\r\n  request explicitly replaces them.\r\n- Infer decisions from the request, repository, and existing conventions. Ask only about an unresolved choice that would\r\n  materially change the artifact, such as its target host, storage scope, or destructive behavior.\r\n- Produce the smallest complete package. Do not add boilerplate files, dependencies, scripts, or metadata with no\r\n  demonstrated purpose.\r\n\r\n## 1. Establish the contract\r\n\r\nDetermine these facts before authoring:\r\n\r\n1. The single job the skill should make repeatable.\r\n2. What is in scope and which adjacent requests must not activate it.\r\n3. The target host or hosts, distribution scope, and destination.\r\n4. Whether invocation should be implicit, explicit, or both.\r\n5. Expected inputs, outputs, side effects, tools, environment, and prerequisites.\r\n6. Failure, cancellation, permission-denial, and safe-stop behavior.\r\n7. Observable acceptance criteria and the cheapest meaningful validation.\r\n\r\nWrite every new project skill to `.agents\u002Fskills\u002F\u003Cname>\u002F` by default, including skills created for Alpha. Write a\r\npersonal skill to `$HOME\u002F.agents\u002Fskills\u002F\u003Cname>\u002F` only when the user requests personal scope. Do not create new skills\r\nunder `.alpha\u002Fskills\u002F`; that location remains readable only for compatibility with existing Alpha skills. Modify an\r\nexisting skill in place rather than relocating it unless the user asks for migration. Use another host-specific\r\ndirectory only when the user explicitly requests that placement.\r\n\r\nWhen location, frontmatter extensions, or cross-host behavior matters, read\r\n[the standard and host profiles](references\u002Fstandard-and-hosts.md). Resolve that path from this skill's base directory.\r\nVerify current primary documentation before relying on a host-specific field not covered there.\r\n\r\n## 2. Inspect before designing\r\n\r\nInspect only the evidence needed to make the skill fit its environment:\r\n\r\n- Repository instructions and the nearest existing skills.\r\n- The target host's current discovery locations and frontmatter support.\r\n- Commands, package managers, tools, templates, and validation already used by the project.\r\n- Existing failures or repeated manual workflows the skill is intended to prevent.\r\n\r\nGround the skill in real expertise. Prefer a successful task trace, user corrections, runbooks, schemas, code, review\r\nhistory, incidents, or representative input and output files over generic model knowledge. Extract the sequence that\r\nworked, non-obvious constraints, and recurring failure modes. If the required domain knowledge is unavailable, identify\r\nthe gap instead of inventing a confident procedure.\r\n\r\nDo not copy another vendor's built-in creator or a large example wholesale. Extract compatible principles and write for\r\nthe user's actual workflow. If a current external contract changes the design, use primary documentation and record the\r\nsource and retrieval date in a relevant reference or design note.\r\n\r\n## 3. Design before writing\r\n\r\n### Choose a focused identity\r\n\r\n- Use a descriptive, action-oriented name.\r\n- The directory name and `name` must match.\r\n- Use 1–64 lowercase ASCII letters, digits, and single hyphens. Do not use leading, trailing, or consecutive hyphens.\r\n- Avoid vague names such as `helper`, `tools`, or `utils`.\r\n\r\n### Write the activation contract first\r\n\r\nThe `description` is routing logic, not marketing copy. It must:\r\n\r\n- State what the skill does.\r\n- State when it should activate using concrete task terms.\r\n- Name important exclusions when adjacent requests could cause false positives.\r\n- Put the strongest trigger terms first and remain useful if a host truncates it.\r\n- Stay between 1 and 1024 characters.\r\n\r\nDraft at least three positive trigger prompts and three negative or adjacent prompts before finalizing the description.\r\nUse them to tighten boundaries rather than stuffing every example into the metadata.\r\n\r\n### Select the right degree of freedom\r\n\r\n- Use prose instructions when several approaches are valid and context determines the choice.\r\n- Use a decision table, pseudocode, or templates when a preferred pattern allows controlled variation.\r\n- Use a script only when deterministic behavior, repeated parsing, or fragile mechanics justify it.\r\n\r\nInstruction-only is the default. A script must make the skill more reliable than generated commands, not move the hard\r\nreasoning into opaque code.\r\n\r\n### Plan progressive disclosure\r\n\r\nKeep `SKILL.md` to the essential workflow. Add only what the task needs:\r\n\r\n```text\r\nskill-name\u002F\r\n├── SKILL.md\r\n├── references\u002F   # Detailed material read on demand\r\n├── scripts\u002F      # Deterministic executable helpers\r\n└── assets\u002F       # Templates and static inputs\r\n```\r\n\r\nLink supporting files directly from `SKILL.md` and explain when to read or run each one. Avoid chains of references.\r\nKeep each reference focused so the agent need not load unrelated material.\r\n\r\n## 4. Author standards-compliant frontmatter\r\n\r\nStart `SKILL.md` on its first line with YAML frontmatter:\r\n\r\n```yaml\r\n---\r\nname: example-skill\r\ndescription: Perform the specific workflow. Use when the user asks for its concrete outcome. Do not use for adjacent work.\r\n---\r\n```\r\n\r\nThe portable baseline requires `name` and `description`. Add only supported optional standard fields when they carry real\r\ninformation:\r\n\r\n- `license`: SPDX identifier or a short reference to bundled terms.\r\n- `compatibility`: environment or product requirements, at most 500 characters.\r\n- `metadata`: string-to-string values for tooling or provenance.\r\n- `allowed-tools`: experimental and host-dependent. Never treat it as a security boundary.\r\n\r\nQuote YAML scalars when punctuation, `#`, `:`, booleans, numbers, or multiline syntax could change their meaning. Parse\r\nthe completed frontmatter instead of judging it by appearance.\r\n\r\nKeep a portable package to standard fields. Put host-only metadata in the host's supported extension mechanism only when\r\nthe requested target needs it. For example, Alpha can use `modeSlugs`, Claude Code has invocation fields, and Codex can\r\nuse `agents\u002Fopenai.yaml`. Never assume another host will ignore unknown keys; some packaging flows reject them.\r\n\r\n## 5. Write executable instructions\r\n\r\nThe body should tell a capable agent what it cannot safely infer. Use imperative, testable instructions and organize them\r\naround the work:\r\n\r\n1. Preconditions and evidence to inspect.\r\n2. Inputs and defaults.\r\n3. Ordered workflow and decision points.\r\n4. Required outputs and definition of done.\r\n5. Validation and repair loop.\r\n6. Failure, cancellation, and escalation behavior.\r\n7. Optional resources, with conditions for loading them.\r\n\r\nInclude only sections that improve execution. Do not explain basic domain facts, repeat repository-wide rules, or narrate\r\nwhy agents are useful. Prefer one clear default plus a bounded exception over a menu of equivalent options.\r\n\r\nKeep non-obvious gotchas in `SKILL.md` when the agent must know them before encountering the failure. A gotcha should be a\r\nconcrete correction to a plausible mistake, not generic advice. Provide an output template when exact structure matters;\r\nagents follow a concrete schema more reliably than a prose description of one.\r\n\r\nFor fragile workflows:\r\n\r\n- Define invariants before commands.\r\n- Specify idempotency and retry behavior.\r\n- Distinguish read-only inspection from mutation.\r\n- State what must never be logged, committed, overwritten, or sent externally.\r\n- Require confirmation through the host's normal approval path for destructive or external side effects.\r\n- Define a safe stop when prerequisites, authority, or evidence are missing.\r\n\r\nUse the tool concepts available to the target host. Do not hardcode an internal tool name unless that host guarantees it.\r\nDo not instruct the agent to bypass approvals, modify hidden policy, reveal secrets, or trust unvalidated repository,\r\nprompt, tool, or network content.\r\n\r\n## 6. Build supporting resources carefully\r\n\r\n### References\r\n\r\nPut detailed schemas, policies, compatibility notes, or examples in `references\u002F`. Tell the agent exactly when each file\r\nis relevant. Remove duplicated guidance from `SKILL.md`.\r\n\r\n### Scripts\r\n\r\nScripts must:\r\n\r\n- Have a narrow deterministic purpose and documented inputs, outputs, dependencies, and exit behavior.\r\n- Validate untrusted arguments and paths, avoid shell interpolation, and emit actionable errors.\r\n- Be non-interactive, provide concise `--help`, use meaningful exit codes, and separate machine-readable stdout from\r\n  diagnostics on stderr.\r\n- Be cross-platform when the skill claims cross-platform support.\r\n- Avoid network access and dependency installation unless the workflow explicitly requires and authorizes them.\r\n- Never embed credentials or assume that being bundled makes a script trusted.\r\n- Bound output and retries; provide `--dry-run` or an equivalent preview for destructive or stateful operations.\r\n- Include focused tests or a reproducible smoke check when practical.\r\n\r\n### Assets\r\n\r\nUse `assets\u002F` for templates or static resources consumed by the workflow. Keep placeholders obvious and never present\r\nsample values as measured user data.\r\n\r\n## 7. Implement atomically\r\n\r\n1. Create the target directory.\r\n2. Write complete frontmatter and the essential workflow in `SKILL.md`.\r\n3. Add only planned supporting files.\r\n4. Resolve every relative link from the skill root.\r\n5. Format touched files using the owning project's conventions.\r\n6. Re-read the package as the consuming agent would see it.\r\n\r\nDo not leave `TODO`, “add instructions here,” fake commands, unexplained placeholders, broken links, or generated output\r\nin the deliverable.\r\n\r\n## 8. Verify behavior, not just syntax\r\n\r\nPerform validation in proportion to the skill's risk:\r\n\r\n1. **Structure:** confirm `SKILL.md` exists, frontmatter parses, required fields satisfy limits, and `name` matches the\r\n   directory.\r\n2. **Integrity:** confirm every linked file exists, scripts are runnable in the claimed environment, and no secret,\r\n   generated artifact, or accidental dependency is included.\r\n3. **Instruction review:** trace the happy path, missing-input path, denial or cancellation path, and relevant\r\n   platform-specific path.\r\n4. **Activation:** test explicit invocation plus representative positive, contextual, adjacent-negative, and unrelated\r\n   prompts. Check both missed activation and over-triggering.\r\n5. **Outcome:** verify the produced artifact and required process invariants with deterministic checks where possible.\r\n6. **Host discovery:** use the target host's validator or discovery flow when available. If it cannot be run, say so.\r\n7. **Regression hygiene:** inspect the final diff and rerun focused checks after repairs.\r\n\r\nUse `skills-ref validate \u003Cskill-directory>` when that standard validator is already available or installation is\r\nauthorized. It validates the portable profile and may reject supported host extensions as unknown fields; do not remove\r\nintentional host metadata merely to make that validator pass. Use the target host's parser or discovery flow for those\r\nfields. Static validation does not replace host discovery or behavior tests. For a critical or repeatedly used skill,\r\nread [the evaluation guide](references\u002Fevaluation.md) and create a small regression suite.\r\n\r\nNever claim a skill loaded, triggered, or passed a check that was not actually run. A parsed Markdown file proves format,\r\nnot routing quality or workflow correctness.\r\n\r\n## 9. Hand off the skill\r\n\r\nReport:\r\n\r\n- The skill name, purpose, scope, and exact path.\r\n- The important activation and compatibility choices.\r\n- Supporting files added and why.\r\n- Checks actually run and their results.\r\n- Any host-specific behavior, untested assumption, or residual risk.\r\n\r\nKeep the summary concise. The files are the deliverable; do not duplicate the entire skill in chat.\r\n","# Skill Builder\r\n\r\nBuild the requested skill as a complete, usable package. Treat the skill's activation metadata, instructions, resources,\r\nand validation evidence as one behavior contract. Prefer the portable Agent Skills format; add host-specific extensions\r\nonly when the target host and benefit are explicit.\r\n\r\n## Operating rules\r\n\r\n- Follow the user's requested scope. Create or edit files when they asked for a skill; do not stop at a tutorial or a\r\n  placeholder. If they asked only for advice, a plan, or an audit, do not mutate files.\r\n- Respect the current execution mode, approval policy, workspace boundaries, and repository instructions. A skill never\r\n  grants tools, permissions, network access, or write authority that the host did not already provide.\r\n- Preserve exact wording the user explicitly supplied for the skill. Do not silently rewrite contractual text, templates,\r\n  commands, or policy language.\r\n- Inspect an existing skill package before revising it. Preserve working behavior and unrelated user content unless the\r\n  request explicitly replaces them.\r\n- Infer decisions from the request, repository, and existing conventions. Ask only about an unresolved choice that would\r\n  materially change the artifact, such as its target host, storage scope, or destructive behavior.\r\n- Produce the smallest complete package. Do not add boilerplate files, dependencies, scripts, or metadata with no\r\n  demonstrated purpose.\r\n\r\n## 1. Establish the contract\r\n\r\nDetermine these facts before authoring:\r\n\r\n1. The single job the skill should make repeatable.\r\n2. What is in scope and which adjacent requests must not activate it.\r\n3. The target host or hosts, distribution scope, and destination.\r\n4. Whether invocation should be implicit, explicit, or both.\r\n5. Expected inputs, outputs, side effects, tools, environment, and prerequisites.\r\n6. Failure, cancellation, permission-denial, and safe-stop behavior.\r\n7. Observable acceptance criteria and the cheapest meaningful validation.\r\n\r\nWrite every new project skill to `.agents\u002Fskills\u002F\u003Cname>\u002F` by default, including skills created for Alpha. Write a\r\npersonal skill to `$HOME\u002F.agents\u002Fskills\u002F\u003Cname>\u002F` only when the user requests personal scope. Do not create new skills\r\nunder `.alpha\u002Fskills\u002F`; that location remains readable only for compatibility with existing Alpha skills. Modify an\r\nexisting skill in place rather than relocating it unless the user asks for migration. Use another host-specific\r\ndirectory only when the user explicitly requests that placement.\r\n\r\nWhen location, frontmatter extensions, or cross-host behavior matters, read\r\n[the standard and host profiles](references\u002Fstandard-and-hosts.md). Resolve that path from this skill's base directory.\r\nVerify current primary documentation before relying on a host-specific field not covered there.\r\n\r\n## 2. Inspect before designing\r\n\r\nInspect only the evidence needed to make the skill fit its environment:\r\n\r\n- Repository instructions and the nearest existing skills.\r\n- The target host's current discovery locations and frontmatter support.\r\n- Commands, package managers, tools, templates, and validation already used by the project.\r\n- Existing failures or repeated manual workflows the skill is intended to prevent.\r\n\r\nGround the skill in real expertise. Prefer a successful task trace, user corrections, runbooks, schemas, code, review\r\nhistory, incidents, or representative input and output files over generic model knowledge. Extract the sequence that\r\nworked, non-obvious constraints, and recurring failure modes. If the required domain knowledge is unavailable, identify\r\nthe gap instead of inventing a confident procedure.\r\n\r\nDo not copy another vendor's built-in creator or a large example wholesale. Extract compatible principles and write for\r\nthe user's actual workflow. If a current external contract changes the design, use primary documentation and record the\r\nsource and retrieval date in a relevant reference or design note.\r\n\r\n## 3. Design before writing\r\n\r\n### Choose a focused identity\r\n\r\n- Use a descriptive, action-oriented name.\r\n- The directory name and `name` must match.\r\n- Use 1–64 lowercase ASCII letters, digits, and single hyphens. Do not use leading, trailing, or consecutive hyphens.\r\n- Avoid vague names such as `helper`, `tools`, or `utils`.\r\n\r\n### Write the activation contract first\r\n\r\nThe `description` is routing logic, not marketing copy. It must:\r\n\r\n- State what the skill does.\r\n- State when it should activate using concrete task terms.\r\n- Name important exclusions when adjacent requests could cause false positives.\r\n- Put the strongest trigger terms first and remain useful if a host truncates it.\r\n- Stay between 1 and 1024 characters.\r\n\r\nDraft at least three positive trigger prompts and three negative or adjacent prompts before finalizing the description.\r\nUse them to tighten boundaries rather than stuffing every example into the metadata.\r\n\r\n### Select the right degree of freedom\r\n\r\n- Use prose instructions when several approaches are valid and context determines the choice.\r\n- Use a decision table, pseudocode, or templates when a preferred pattern allows controlled variation.\r\n- Use a script only when deterministic behavior, repeated parsing, or fragile mechanics justify it.\r\n\r\nInstruction-only is the default. A script must make the skill more reliable than generated commands, not move the hard\r\nreasoning into opaque code.\r\n\r\n### Plan progressive disclosure\r\n\r\nKeep `SKILL.md` to the essential workflow. Add only what the task needs:\r\n\r\n```text\r\nskill-name\u002F\r\n├── SKILL.md\r\n├── references\u002F   # Detailed material read on demand\r\n├── scripts\u002F      # Deterministic executable helpers\r\n└── assets\u002F       # Templates and static inputs\r\n```\r\n\r\nLink supporting files directly from `SKILL.md` and explain when to read or run each one. Avoid chains of references.\r\nKeep each reference focused so the agent need not load unrelated material.\r\n\r\n## 4. Author standards-compliant frontmatter\r\n\r\nStart `SKILL.md` on its first line with YAML frontmatter:\r\n\r\n```yaml\r\n---\r\nname: example-skill\r\ndescription: Perform the specific workflow. Use when the user asks for its concrete outcome. Do not use for adjacent work.\r\n---\r\n```\r\n\r\nThe portable baseline requires `name` and `description`. Add only supported optional standard fields when they carry real\r\ninformation:\r\n\r\n- `license`: SPDX identifier or a short reference to bundled terms.\r\n- `compatibility`: environment or product requirements, at most 500 characters.\r\n- `metadata`: string-to-string values for tooling or provenance.\r\n- `allowed-tools`: experimental and host-dependent. Never treat it as a security boundary.\r\n\r\nQuote YAML scalars when punctuation, `#`, `:`, booleans, numbers, or multiline syntax could change their meaning. Parse\r\nthe completed frontmatter instead of judging it by appearance.\r\n\r\nKeep a portable package to standard fields. Put host-only metadata in the host's supported extension mechanism only when\r\nthe requested target needs it. For example, Alpha can use `modeSlugs`, Claude Code has invocation fields, and Codex can\r\nuse `agents\u002Fopenai.yaml`. Never assume another host will ignore unknown keys; some packaging flows reject them.\r\n\r\n## 5. Write executable instructions\r\n\r\nThe body should tell a capable agent what it cannot safely infer. Use imperative, testable instructions and organize them\r\naround the work:\r\n\r\n1. Preconditions and evidence to inspect.\r\n2. Inputs and defaults.\r\n3. Ordered workflow and decision points.\r\n4. Required outputs and definition of done.\r\n5. Validation and repair loop.\r\n6. Failure, cancellation, and escalation behavior.\r\n7. Optional resources, with conditions for loading them.\r\n\r\nInclude only sections that improve execution. Do not explain basic domain facts, repeat repository-wide rules, or narrate\r\nwhy agents are useful. Prefer one clear default plus a bounded exception over a menu of equivalent options.\r\n\r\nKeep non-obvious gotchas in `SKILL.md` when the agent must know them before encountering the failure. A gotcha should be a\r\nconcrete correction to a plausible mistake, not generic advice. Provide an output template when exact structure matters;\r\nagents follow a concrete schema more reliably than a prose description of one.\r\n\r\nFor fragile workflows:\r\n\r\n- Define invariants before commands.\r\n- Specify idempotency and retry behavior.\r\n- Distinguish read-only inspection from mutation.\r\n- State what must never be logged, committed, overwritten, or sent externally.\r\n- Require confirmation through the host's normal approval path for destructive or external side effects.\r\n- Define a safe stop when prerequisites, authority, or evidence are missing.\r\n\r\nUse the tool concepts available to the target host. Do not hardcode an internal tool name unless that host guarantees it.\r\nDo not instruct the agent to bypass approvals, modify hidden policy, reveal secrets, or trust unvalidated repository,\r\nprompt, tool, or network content.\r\n\r\n## 6. Build supporting resources carefully\r\n\r\n### References\r\n\r\nPut detailed schemas, policies, compatibility notes, or examples in `references\u002F`. Tell the agent exactly when each file\r\nis relevant. Remove duplicated guidance from `SKILL.md`.\r\n\r\n### Scripts\r\n\r\nScripts must:\r\n\r\n- Have a narrow deterministic purpose and documented inputs, outputs, dependencies, and exit behavior.\r\n- Validate untrusted arguments and paths, avoid shell interpolation, and emit actionable errors.\r\n- Be non-interactive, provide concise `--help`, use meaningful exit codes, and separate machine-readable stdout from\r\n  diagnostics on stderr.\r\n- Be cross-platform when the skill claims cross-platform support.\r\n- Avoid network access and dependency installation unless the workflow explicitly requires and authorizes them.\r\n- Never embed credentials or assume that being bundled makes a script trusted.\r\n- Bound output and retries; provide `--dry-run` or an equivalent preview for destructive or stateful operations.\r\n- Include focused tests or a reproducible smoke check when practical.\r\n\r\n### Assets\r\n\r\nUse `assets\u002F` for templates or static resources consumed by the workflow. Keep placeholders obvious and never present\r\nsample values as measured user data.\r\n\r\n## 7. Implement atomically\r\n\r\n1. Create the target directory.\r\n2. Write complete frontmatter and the essential workflow in `SKILL.md`.\r\n3. Add only planned supporting files.\r\n4. Resolve every relative link from the skill root.\r\n5. Format touched files using the owning project's conventions.\r\n6. Re-read the package as the consuming agent would see it.\r\n\r\nDo not leave `TODO`, “add instructions here,” fake commands, unexplained placeholders, broken links, or generated output\r\nin the deliverable.\r\n\r\n## 8. Verify behavior, not just syntax\r\n\r\nPerform validation in proportion to the skill's risk:\r\n\r\n1. **Structure:** confirm `SKILL.md` exists, frontmatter parses, required fields satisfy limits, and `name` matches the\r\n   directory.\r\n2. **Integrity:** confirm every linked file exists, scripts are runnable in the claimed environment, and no secret,\r\n   generated artifact, or accidental dependency is included.\r\n3. **Instruction review:** trace the happy path, missing-input path, denial or cancellation path, and relevant\r\n   platform-specific path.\r\n4. **Activation:** test explicit invocation plus representative positive, contextual, adjacent-negative, and unrelated\r\n   prompts. Check both missed activation and over-triggering.\r\n5. **Outcome:** verify the produced artifact and required process invariants with deterministic checks where possible.\r\n6. **Host discovery:** use the target host's validator or discovery flow when available. If it cannot be run, say so.\r\n7. **Regression hygiene:** inspect the final diff and rerun focused checks after repairs.\r\n\r\nUse `skills-ref validate \u003Cskill-directory>` when that standard validator is already available or installation is\r\nauthorized. It validates the portable profile and may reject supported host extensions as unknown fields; do not remove\r\nintentional host metadata merely to make that validator pass. Use the target host's parser or discovery flow for those\r\nfields. Static validation does not replace host discovery or behavior tests. For a critical or repeatedly used skill,\r\nread [the evaluation guide](references\u002Fevaluation.md) and create a small regression suite.\r\n\r\nNever claim a skill loaded, triggered, or passed a check that was not actually run. A parsed Markdown file proves format,\r\nnot routing quality or workflow correctness.\r\n\r\n## 9. Hand off the skill\r\n\r\nReport:\r\n\r\n- The skill name, purpose, scope, and exact path.\r\n- The important activation and compatibility choices.\r\n- Supporting files added and why.\r\n- Checks actually run and their results.\r\n- Any host-specific behavior, untested assumption, or residual risk.\r\n\r\nKeep the summary concise. The files are the deliverable; do not duplicate the entire skill in chat.\r\n",{"name":5,"description":7},"main","bdda1ce57d76bafc4622250fecd1a936beb06160","src\u002Fassets\u002Fskills\u002Fskill-builder",1,"https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha","https:\u002F\u002Fgithub.com\u002Flukegob10","2026-11-12 02:29:22",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add lukegob10\u002Falpha --skill skill-builder",{"tool":61,"command":62},"bunx","bunx skills add lukegob10\u002Falpha --skill skill-builder",{"tool":64,"command":65},"pnpm","pnpm dlx skills add lukegob10\u002Falpha --skill skill-builder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Fskill-builder\u002FSKILL.md",true,[69,75],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fevaluation.md","REFERENCE","参考文档",8087,"https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Fskill-builder\u002Freferences\u002Fevaluation.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fstandard-and-hosts.md",7903,"https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Fskill-builder\u002Freferences\u002Fstandard-and-hosts.md",[80,102,127,152,159,179],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":43},"01M71E59YCND235ZE1H81B2ZPV","rich-documents","Create or revise a rich HTML document in Alpha's built-in HTML previewer for a substantial spec, review, or quantitative report, or when explicitly requested. Respect plain text, Markdown, existing output destinations, and ordinary short answers or code fixes.","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Frich-documents\u002FSKILL.md",[],[87,88,89,26,90,91,92,93,35,37,94,95,96,41,97,98,99,100,101,34],"rich","rich documents","documents","markdown","text","output","review","document","Existing","short","report","spec","for","fixes","plain",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":114,"publishedAt":43},"01M71E585QAQCYMJF0GW521X1Z","review-agent","Review a specified code change for actionable defects and return prioritized findings without editing. Use when explicitly asked to use this skill, including a delegated review of working changes, a commit, or a branch against its base. Investigating a reported failure belongs to debug.","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Freview-agent\u002FSKILL.md",[108,109],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[115,93,116,117,118,119,120,121,99,122,37,123,124,125,126,35],"review agent","change","use","base","editing","actionable","defects","changes","branch","code change","debug","commit",{"skillNo":128,"name":125,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":136,"publishedAt":43},"01M71E55MFBZP2S27286B0S45Z","Investigate a concrete bug with an unclear cause using reproduction, hypotheses, and runtime evidence. Use for an explicit debugging investigation, unexplained or intermittent incorrect behavior, or the same failure persisting after an attempted fix. Skip routine commands, ordinary implementation, code review, general debugging questions, and isolated build\u002Ftest errors whose cause and correction are already clear. Mentioning a bug, error, log, or test alone does not trigger this skill.","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fsrc\u002Fassets\u002Fskills\u002Fdebug\u002FSKILL.md",[132,135],{"categoryNo":133,"categoryName":134,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},[125,137,138,139,140,141,93,142,35,143,117,144,145,146,147,148,149,99,150,151],"questions","build","test","investigate","with","evidence","debugging","errors","general","fix","trigger","code review","runtime","log","error",{"skillNo":153,"name":154,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":43},"01M71E54DERK8A9CDYT48CNJ59","skill","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002Fevals\u002Fjavascript\u002Falpha-skill-workflow\u002Fskill\u002FSKILL.md",[157],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[],{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":43},"01M71E52MJKF29S6JPX8JSZ8M9","evals-context","Provides context for Alpha's retained evaluation infrastructure and extension quality suites. Use when a task mentions evals, evaluation runs, eval exercises, benchmark campaigns, or VS Code extension certification.","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002F.alpha\u002Fskills\u002Fevals-context\u002FSKILL.md",[],[166,167,168,37,117,169,41,99,170,35,171,172,173,174,175,176,177,178],"context","evals context","evals","eval","campaigns","infrastructure","certification","benchmark","extension","Evaluation","quality","exercises","task",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":43},"01M71E4Z98E8AETCFR2ZARXSDS","alpha-conflict-resolution","Provides comprehensive guidelines for resolving merge conflicts intelligently using git history and commit context. Use when tasks involve merge conflicts, rebasing, PR conflicts, or git conflict resolution. This skill analyzes commit messages, git blame, and code intent to make intelligent resolution decisions.","https:\u002F\u002Fgithub.com\u002Flukegob10\u002Falpha\u002Fblob\u002Fmain\u002F.alpha\u002Fskills\u002Falpha-conflict-resolution\u002FSKILL.md",[185],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[41,187,188,189,190,191,192,193,194,166,195,196,197,198,126,199,35,37,200,201],"alpha conflict resolution","conflict resolution","conflict","resolution","commit messages","history","Using git","make","git","merge","intent","conflicts","tasks","messages","pr conflicts"]