[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FVT4RAX9BX9W7MQ6R2F39":3,"skill-same:01M71FVT4RAX9BX9W7MQ6R2F39":90},{"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":23,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M71FVT4RAX9BX9W7MQ6R2F39","skill-standards",null,"Skill authoring standards enforced across all creating and auditing skills. Loaded by other skills, not invoked directly.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31],"standards","skill standards","skill authoring","auditing skills","authoring","false","read","across","2026-11-10 10:12:30",false,"---\nname: skill-standards\nuser-invocable: false\ndescription: >-\n  Skill authoring standards enforced across all creating and auditing skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n\n\u003Cobjective>\nThe canonical standards for skill authoring — frontmatter, XML structure, naming, descriptions, progressive disclosure, skill types, reference patterns, code-fence and bash constraints, validation, and script testing.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nSkills conform to these standards when, at minimum: (a) SKILL.md is under 500 lines unless it qualifies for `\u003Ceager_foundation_exception>`, (b) the body uses pure XML structure with no markdown headings, (c) `\u003Cobjective>` and `\u003Csuccess_criteria>` tags are present, (d) the description matches the invocation path — directive when description-match activation applies, passive when invoked only by exact name or a parent capability — (e) the skill is independent of its caller, and (f) an `\u002Faudit-skill` run on the skill seals `approved`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill: it standardizes skill authoring and carries no standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Crule_catalog>\nEvery rule this skill and its references state has one stable identifier and one severity in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md`. Read it before recording or repairing a finding against these standards.\n\u003C\u002Frule_catalog>\n\n\u003Crepo_local_overlay>\nInside a repository, check for `spx\u002Flocal\u002Fskills.md` at the repository root. Read that file after this reference if it exists and apply it as the repo-local specialization (e.g., marketplace-specific naming conventions or additional constraints). A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cskill_organization>\n\nSkills follow a **reference pattern** to avoid duplication:\n\n1. **Foundational skill** (e.g., `\u002Ftest`) — core principles and domain-agnostic patterns.\n2. **Language-specific skills** (e.g., `\u002Fauthor-python-test`, `\u002Fauthor-typescript-test`) — reference the foundational skill, provide only language-specific implementations.\n3. **Reference skills** (e.g., `\u002Ftypescript-code-standards`, `\u002Fskill-standards`) — standards explicitly invoked by composing skills, never selected as standalone user workflows.\n\nFor language-specific skill prose that references a foundation, use the unqualified invocation name (`\u002Ftest`) so it resolves to whichever foundational skill is installed.\n\n**Skill-tool composition:** A skill may invoke another skill when the parent workflow explicitly composes that capability. Composition obeys these limits:\n\n1. The parent carries the runtime's skill-invocation capability in `allowed-tools` and names the exact installed skill to invoke.\n2. The target remains callable through the active runtime's skill-invocation surface; no runtime setting may block composed or reference-skill invocation.\n3. The parent owns sequencing, validates the returned shape, and merges the child result into its own output contract.\n4. A composition step invokes only capabilities required by the workflow; it never discovers or invokes adjacent skills speculatively.\n5. Reference-only prose may name foundational concepts without invocation, while reference skills are loaded through the runtime's skill-invocation capability when their full standards govern the work.\n\n**Caller independence:** A skill governs its own behavior and nothing else. It never names, describes, detects, constrains, refuses, branches on, or otherwise depends on its caller or invocation context. A description may state the skill's invocation contract — for example, that other skills load it and a user does not invoke it — because its behavior never depends on who the caller is. The dependency runs one way: a caller may know the skill it invokes; the skill never knows its callers.\n\n**The harness environment is not a caller.** The environment a skill runs in — an interactive session, a programmatic run, or a hosted runner — fixes the shell contract every command the skill instructs must meet, whoever invoked it. A skill that names the command form its environment accepts, such as one physical command line where a runner requires it, follows a property of its own run and depends on no caller. The same holds for the fallback location a skill selects for its payload scratch directory where the harness names none, such as the directory a hosted runner designates: the hosting environment fixes it, so naming it is a property of the run. Choosing a form by who invoked the skill, by the agent or skill that dispatched it, or by what its task message asks for remains caller dependence.\n\nContext placement, agent selection, and dispatch policy belong to the caller. A skill remains independently invocable even when the product normally reaches it through an agent or another skill. Correct an invalid invocation in the router, agent, or composing skill that made the decision; never add a dispatch gate or caller check to the invoked skill.\n\n**Composed skill dependencies.** A composing SKILL.md names each dependency with the instruction ``Use skill `{plugin}:{skill}`.`` and, on a harness that exposes a skill-composition tool, grants that tool as one complete `allowed-tools` item; on a harness without one it grants nothing for composition. Source authored for more than one harness never spells one harness's skill tool name.\n{!# Source-only maintainer guidance: in this marketplace the instruction is the`require_skill`directive and the grant is the`use_skill` tool token; the build\nrenders the target's name and removes an unavailable capability as one complete\nlist item. Generated guidance describes only the harness it ships to. #!}\n\n\u003C\u002Fskill_organization>\n\n{!% if target == 'claude' %!}\n\u003Cfrontmatter>\n\nEvery SKILL.md starts with YAML frontmatter. The canonical catalog of supported fields lives in the Claude Code docs at \u003Chttps:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fskills#frontmatter-reference>. Read the docs page when a question is about execution behavior; read this section when it is about how this marketplace authors skills.\n\n| Field                      | Required    | Constraint                                                                                                                                                                                                                     |\n| -------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `name`                     | No          | Lowercase letters, numbers, hyphens. ≤64 chars. Must match the directory name when set. If omitted, the directory name is used.                                                                                                |\n| `description`              | Recommended | Style follows the invocation path in `\u003Cdescriptions>`. Combined with `when_to_use` the listing is capped at 1,536 chars; put the key trigger first.                                                                            |\n| `when_to_use`              | No          | Extra trigger phrases or example requests appended to `description` in the skill listing. Shares the 1,536-char cap.                                                                                                           |\n| `argument-hint`            | No          | Free-text hint shown during `\u002F` autocomplete (e.g. `[issue-number]`).                                                                                                                                                          |\n| `arguments`                | No          | Named positional arguments for `$name` substitution in the body. Space-separated string or YAML list; names map to argument positions in order.                                                                                |\n| `allowed-tools`            | No          | Tools Claude may use without per-call approval while the skill is active. Space-separated string or YAML list. Restrict for audit and reference skills.                                                                        |\n| `disable-model-invocation` | No          | `true` to **block programmatic invocation entirely** — Claude cannot load the skill, including via the Skill tool, and the skill cannot be preloaded into subagents. Use for deploy-style user-only commands. Default `false`. |\n| `user-invocable`           | No          | `false` to hide from the `\u002F` autocomplete menu while keeping Claude able to invoke via the Skill tool. Description stays in context. Use for reference skills that other skills load programmatically. Default `true`.         |\n| `model`                    | Forbidden   | Skills retain the invoking session's configuration, including when a configured subagent invokes the skill.                                                                                                                    |\n| `effort`                   | Forbidden   | Skills retain the invoking session's reasoning configuration.                                                                                                                                                                  |\n| `context`                  | No          | `fork` to run the skill in a forked subagent context. Combine with `agent`.                                                                                                                                                    |\n| `agent`                    | No          | Subagent type to use when `context: fork` is set (`Explore`, `Plan`, `general-purpose`, or a custom agent). Defaults to `general-purpose`.                                                                                     |\n| `hooks`                    | No          | Hooks scoped to this skill's lifecycle. See the Claude Code hooks reference for shape.                                                                                                                                         |\n| `paths`                    | No          | Glob patterns that limit auto-activation to matching files. Comma-separated string or YAML list.                                                                                                                               |\n| `shell`                    | No          | `bash` (default) or `powershell` for the skill's inline and fenced command-injection blocks. The `powershell` value requires `CLAUDE_CODE_USE_POWERSHELL_TOOL=1`.                                                              |\n\n**Visibility vs invocability.** Two fields gate how a skill is reached. They are not aliases — pick deliberately. Automation re-entry — a scheduled wakeup, heartbeat, or `\u002Floop` — arrives as a user-style prompt because the harness offers no Claude-private heartbeat, so it follows the `User \u002F{skill}` column exactly:\n\n| Frontmatter                      | User `\u002F{skill}` | Claude (Skill tool) | Subagent preload | Automation re-entry | Description in context |\n| -------------------------------- | --------------- | ------------------- | ---------------- | ------------------- | ---------------------- |\n| *(default)*                      | Yes             | Yes                 | Yes              | Yes                 | Always                 |\n| `disable-model-invocation: true` | Yes             | **No**              | **No**           | Yes                 | Not in context         |\n| `user-invocable: false`          | **No**          | Yes                 | Yes              | **No**              | Always                 |\n\nPick the gate by role:\n\n- A reference skill another SKILL.md loads via the Skill tool, or a background-knowledge skill, uses `user-invocable: false` — hidden from the `\u002F` menu, still loadable by Claude and preloadable into subagents.\n- A user-only side-effecting command (a deploy command) uses `disable-model-invocation: true`. NEVER set it on a skill other skills or subagents must load: it blocks the Skill-tool call (surfacing `Skill \u003Cname> cannot be used with Skill tool due to disable-model-invocation`) AND blocks subagent preloading.\n- A skill any automation loop re-enters — a scheduled wakeup, heartbeat, or `\u002Floop` target — MUST be user-invocable (leave the default; never `user-invocable: false`). Automation fires as a user-style prompt, so `user-invocable: false` rejects it and no Claude-private heartbeat exists to bypass that. When a loop body is otherwise reference-like, expose a user-invocable entry the loop targets rather than gating the body. Such a loop body keeps a **passive** description — it is invoked by exact name (the timer or a parent skill), not by description-match, so a directive description would only cause false auto-activations. A user-invocable skill with a passive description is the correct shape here, not a defect.\n\nAudit skills (`audit-*`) must add `allowed-tools: Read, Grep, Glob` and only the specific Bash verb patterns their workflow runs — read-only verbs, and the `spx verification run` verbs that write the audit's own run journal — never bare `Bash`, plus `{{! tool('use_skill') !}}` when the audit composes another skill. An audit that passes payload files to run-recording commands adds the harness's file-write tool beside its read tools; the tool writes only payload files in the session scratch directory, and the audit changes no file beyond those payload files and the run journal its own recording commands write. Such an audit grants no Bash stage that builds a payload in the shell, and never grants `Edit`.\n\n**Directory match is mandatory.** `skills\u002Fauthor\u002F` → `name: author`. A mismatch breaks skill lookup.\n\n**Field `skills:` is NOT supported on SKILL.md.** It exists only on subagent definitions (`agents\u002F*.md`), where it preloads skill content as reference material into the subagent's startup context. The official docs page above lists every field a SKILL.md actually accepts; `skills:` is not among them. To make a reference skill available to another skill, set `user-invocable: false` on the reference and have the parent invoke it by installed name through the runtime's skill-invocation surface — there is no preload field on the consumer side.\n\n**Command-capability fields.** A SKILL.md carries every capability a slash command had — `argument-hint`\u002F`arguments`, `allowed-tools` restriction, plus `!`-dynamic context and `@` file references in the body. The authoring and audit rules for that surface live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md`; read it before authoring a skill that takes arguments, injects state, or restricts tools, and read its `\u003Cguard_block_partition>` when a dangerous-command guard blocks a command.\n\n\u003C\u002Ffrontmatter>\n{!% else %!}\n\u003Cfrontmatter>\n\nEvery Codex SKILL.md starts with YAML frontmatter and uses only fields accepted by Codex's current skill validator. `name` matches the skill directory, `description` states the selection contract, and tool restrictions grant only capabilities the workflow needs. Do not project Claude-only visibility, preload, heartbeat, hook, or invocation semantics onto Codex fields. Frontmatter declares no model or reasoning override; a skill retains its invoking session's configuration.\n\nReference skills stay hidden from ordinary user selection while remaining available to composed workflows through Codex's documented skill invocation surface. Audit skills change no file beyond the payload files they write in the session scratch directory and the `spx verification run` journal their own verbs write. A field or reachability behavior without a documented Codex contract is omitted.\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` before authoring arguments, dynamic context, tool restrictions, or file references for Codex, and read its `\u003Cguard_block_partition>` when a dangerous-command guard blocks a command.\n\n\u003C\u002Ffrontmatter>\n{!% endif %!}\n\n\u003Cnaming_conventions>\n\nThe `name` field is the user invocation path (`\u002F{skill-name}`). Match user speech patterns.\n\n**Rules:**\n\n- Use domain acronyms: `author` not `author-product-tree-artifacts`\n- Use terms users actually say: `test` not `python-unit-test-framework`\n- Think \"CD-ROM\" not \"Compact Disc Read Only Memory\"\n- Directory name MUST match: `skills\u002Fauthor\u002F` → `name: author`\n\n**Naming form:** invoked workflow skills use imperative verbs. Reference skills use noun phrases ending in the domain they standardize, such as `skill-standards` or `typescript-test-standards`.\n\n**Vocabulary precedence:** Skill-name grammar does not override declared methodology vocabulary. When a term can belong both to a skill-name form and to another taxonomy, read the source that declares that taxonomy and inspect file history before calling the term a naming defect.\n\nTreat generated runtime output and implementation names as lower-layer evidence, never as the authority for vocabulary classification.\n\n```yaml\n# ✅ Matches user speech\nname: author # Users say \"author a spec\"\nname: author-typescript-test # Users say \"author a TypeScript test\"\nname: bootstrap # Users say \"bootstrap the Product Tree\"\n\n# ❌ Nobody says these\nname: author-product-tree-artifacts # Too verbose\nname: typescript-unit-framework # Wrong order\n```\n\n\u003C\u002Fnaming_conventions>\n\n{!% if target == 'claude' %!}\n\u003Cdescriptions>\n\nThe description field governs skill selection. Claude has a character budget for all skill metadata — when exceeded, skills become invisible.\n\nThis section selects a description's style by invocation path. `\u002Fagent-prompt-standards` `\u003Cdescription_style>` governs the wording within that style: the directive form, the NEVER clause, artifact-before-language order, and user speech.\n\n**Description-match entry points** take a directive description.\n\n**Reference skills** carry a passive description, with the frontmatter `\u003Creference_skills>` requires.\n\n**Protocol and loop-body skills** that a parent skill loads, or that a timer fires by exact name (a heartbeat re-entry target), keep a passive description while staying user-invocable — they are never reached by description-match, so a directive description would only cause false auto-activations. See the gate-by-role rules in `\u003Cfrontmatter>`.\n\n**Audit skills** describe the audit they perform: the subject, judgment, and distinguishing criteria. Their descriptions contain no routing, dispatch, preload, agent, or execution-context statement. Audit skills stay model-invocable, carry the `allowed-tools` `\u003Cfrontmatter>` names for them, and never use `disable-model-invocation`.\n\n```yaml\ndescription: >-\n  Test-evidence audit methodology — judges test evidence against the assertions\n  it claims to verify, covering source ownership, coupling, falsifiability, and\n  full-chain coverage.\n```\n\n**Conflict resolution:** If Claude picks the wrong skill, descriptions are too similar. Make trigger terms distinct — \"sales data in Excel\" vs \"log files and system metrics\".\n\n\u003C\u002Fdescriptions>\n{!% else %!}\n\u003Cdescriptions>\n\nDescriptions state when Codex selects a skill and distinguish adjacent skills with concrete trigger terms. Use directive wording for description-match entry points and passive wording for references or protocols invoked by exact name. Keep the trigger first, avoid overlapping descriptions, and describe the skill's own subject rather than the caller that reaches it.\n\n\u003C\u002Fdescriptions>\n{!% endif %!}\n\n\u003Cxml_structure>\n\nSkills use **pure XML structure** — no markdown headings (`#`, `##`, `###`) anywhere in the body. Keep markdown formatting *within* content (bold, italic, lists, tables, code blocks, links).\n\n**Why pure XML:** unambiguous section boundaries, consistent cross-skill structure, better token efficiency, and more reliable runtime interpretation.\n\n**Required tags (every skill):**\n\n| Tag                  | Content                                                                                                                                                                                       |\n| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `\u003Cobjective>`        | The observable **output** the skill produces, in a definite shape — one sentence, not an actor or an activity, not a summary of the skill. See `\u002Fagent-prompt-standards` `\u003Cobjective_shape>`. |\n| `\u003Csuccess_criteria>` | The properties that prove the output is sound — not a re-list of the workflow steps.                                                                                                          |\n\n**Router-pattern tags** (skills that route to multiple workflows):\n\n| Tag                      | Content                                                          |\n| ------------------------ | ---------------------------------------------------------------- |\n| `\u003Cessential_principles>` | Principles that apply regardless of which workflow runs. Inline. |\n| `\u003Cintake>`               | Question to ask the user to determine routing.                   |\n| `\u003Crouting>`              | Table mapping responses to workflow files.                       |\n| `\u003Creference_index>`      | List of available reference files.                               |\n| `\u003Cworkflows_index>`      | List of available workflow files.                                |\n\n**Workflow-file tags** (files inside `workflows\u002F`):\n\n| Tag                  | Content                                                     |\n| -------------------- | ----------------------------------------------------------- |\n| `\u003Crequired_reading>` | Which reference files to load before running this workflow. |\n| `\u003Cprocess>`          | Step-by-step procedure.                                     |\n| `\u003Csuccess_criteria>` | When this workflow is complete.                             |\n\n**Conditional tags** (include when the skill's complexity or purpose calls for them):\n\n| Tag                    | When to include                                                                                                                      |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |\n| `\u003Cquick_start>`        | Tool skills with a meaningful fast path. **Omit** for foundation, gate, validator, and reference skills — completeness is the point. |\n| `\u003Ccontext>`            | Background needed before starting.                                                                                                   |\n| `\u003Cworkflow>`           | Sequential steps (non-router skills).                                                                                                |\n| `\u003Cadvanced_features>`  | Progressive disclosure for deep-dive topics.                                                                                         |\n| `\u003Cvalidation>`         | Verification checks.                                                                                                                 |\n| `\u003Cexamples>`           | Input\u002Foutput pairs.                                                                                                                  |\n| `\u003Canti_patterns>`      | Common mistakes to avoid.                                                                                                            |\n| `\u003Csecurity_checklist>` | Skills with security implications.                                                                                                   |\n| `\u003Ctesting>`            | Testing workflows or validation steps.                                                                                               |\n| `\u003Ccommon_patterns>`    | Reusable recipes.                                                                                                                    |\n| `\u003Creference_guides>`   | Pointers to detailed reference files.                                                                                                |\n| `\u003Cfailure_modes>`      | Named failures from actual usage — what happened, why, how to avoid.                                                                 |\n\nThis table is representative, not exhaustive: a skill may add semantically named domain sections beyond it (this file's `\u003Cfrontmatter>`, `\u003Cdescriptions>`, and reference-pointer sections such as `\u003Cplatform_constraints>` and `\u003Cscript_standards>` are examples).\n\n**Nesting:** XML tags can nest for hierarchical content.\n\n```text\n\u003Cexamples>\n  \u003Cexample number=\"1\">\n    \u003Cinput>User input\u003C\u002Finput>\n    \u003Coutput>Expected output\u003C\u002Foutput>\n  \u003C\u002Fexample>\n\u003C\u002Fexamples>\n```\n\n**Close every tag.** Unclosed tags break parsing.\n\n**`\u003Ccontext>` bash blocks fire on every skill load.** `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` `\u003Cdynamic_context>` carries the firing and filtering rules.\n\n**Semantic names:** `\u003Cworkflow>` not `\u003Csteps>`, `\u003Csuccess_criteria>` not `\u003Cdone>`, `\u003Canti_patterns>` not `\u003Cdont_do>`.\n\n**Reference tags in prose by name:** \"Using the schema in `\u003Cschema>` tags…\", \"Follow the workflow in `\u003Cworkflow>`…\". Makes structure self-documenting.\n\n**Intelligence rules** — match structure to complexity:\n\n| Skill class                      | Expected tags                                                                                                                                                           |\n| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Simple (single domain)           | `\u003Cobjective>`, `\u003Csuccess_criteria>`, optionally `\u003Cquick_start>`                                                                                                         |\n| Medium (multiple patterns)       | Required + `\u003Cworkflow>` and\u002For `\u003Cexamples>`                                                                                                                             |\n| Complex (multi-domain, API, sec) | Required + router pattern + appropriate conditional tags                                                                                                                |\n| Foundation \u002F gate \u002F validator    | Required + `\u003Cworkflow>`. **Omit** `\u003Cquick_start>` — no abbreviated path exists.                                                                                         |\n| Reference                        | Required; add `\u003Cworkflow>` only when the reference defines an ordered procedure. A declarative standards or vocabulary catalog omits procedural tags.                   |\n| Auditor (agent-preloaded)        | The canonical auditor skeleton — **read** `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fauditor-skeleton.md` when authoring or auditing an `audit-*` skill. **Omit** `\u003Cquick_start>`. |\n\nDon't over-engineer simple skills. Don't under-specify complex ones.\n\n\u003C\u002Fxml_structure>\n\n\u003Ceager_foundation_exception>\n\nWhen a foundation skill requires the same material on every fresh invocation, inline that canonical material and govern the total eager payload instead of the SKILL.md line count. The exception requires the same material on every invocation, removal of mandatory secondary reads, separate conditional detail, internal consistency, improved effectiveness, and a rendered payload of at most 40,000 Unicode code points measured by every audit. Never use it to inline optional detail or avoid routing.\n\n\u003C\u002Feager_foundation_exception>\n\n{!% if target == 'claude' %!}\n\u003Cprogressive_disclosure>\n\nSKILL.md is an overview. Reference files carry detail. Claude loads reference files only when needed.\n\n**Rules:**\n\n- Keep SKILL.md under 500 lines unless `\u003Ceager_foundation_exception>` applies.\n- References live in `references\u002F` one level deep from SKILL.md. Do not nest references that read other references — Claude may only partially read transitive files.\n- Reference files over 100 lines need a table of contents at the top, so partial reads still see the full scope.\n- Use forward slashes in every path — `references\u002Fguide.md`, never `references\\guide.md`. Works across platforms.\n\nApply `\u003Ceager_foundation_exception>`. A 500-line overview followed immediately by mandatory references is not progressive disclosure; total eagerly loaded content is the relevant cost.\n\n**Token efficiency:** simple task loads SKILL.md only (~500 tokens); medium loads SKILL.md + one reference (~1000); complex loads SKILL.md + multiple (~2000+).\n\n```text\n✅ One level deep\nSKILL.md → references\u002Fadvanced.md (complete info)\n         → references\u002Fexamples.md (complete info)\n\n❌ Nested\nSKILL.md → references\u002Fadvanced.md → references\u002Fdetails.md → actual info\n```\n\n**Name reference files descriptively** — `xml-structure-examples.md`, not `examples.md`. The filename is also a table-of-contents entry in `\u003Creference_index>`.\n\n**Every reference file must be cited.** A file in `references\u002F` that is not mentioned by SKILL.md or any workflow file is orphaned — it costs ~1,800+ tokens per speculative read (Claude tends to open siblings of cited references) and signals either dead content or a missing cross-reference. Either remove the file with `git rm` or add an explicit `\u003Crequired_reading>` from the workflow that needs it. Verify before committing: `grep -rn \"\u003Cfilename>\" \u003Cskill-dir>\u002F`.\n\n\u003C\u002Fprogressive_disclosure>\n{!% else %!}\n\u003Cprogressive_disclosure>\n\nKeep SKILL.md under 500 lines unless `\u003Ceager_foundation_exception>` applies. Move detailed patterns into descriptively named files one level below `references\u002F`. Cite every bundled reference from the skill or the workflow that requires it. Avoid nested reference chains, orphaned files, and duplicated standards.\n\nApply `\u003Ceager_foundation_exception>`. A 500-line overview followed immediately by mandatory references is not progressive disclosure; total eagerly loaded content is the relevant cost.\n\n\u003C\u002Fprogressive_disclosure>\n{!% endif %!}\n\n\u003Cconciseness>\n\nEvery sentence of a skill and its bundled files meets `\u002Fagent-prompt-standards` `\u003Cconciseness>`, which owns the sentence-removal test, what to omit and include, and concrete-over-abstract guidance.\n\n\u003C\u002Fconciseness>\n\n\u003Cskill_types>\n\nSix skill types. Each has a distinct purpose and primary output.\n\n| Type           | Purpose                      | Primary output                    | Key sections                                                                                                                                             |\n| -------------- | ---------------------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Builder**    | Create new artifacts         | Code, documents, widgets, configs | Required clarifications, output spec, domain standards, templates in `assets\u002F`                                                                           |\n| **Guide**      | Teach procedures             | Step-by-step workflows, tutorials | Numbered workflow, input→output example pairs, decision trees                                                                                            |\n| **Automation** | Execute multi-step processes | Processed files, transformed data | Tested scripts in `scripts\u002F`, error handling, dependencies, I\u002FO contracts                                                                                |\n| **Analyzer**   | Extract insights             | Reports, summaries, reviews       | Analysis scope, evaluation criteria, output format, synthesis                                                                                            |\n| **Validator**  | Enforce quality              | Pass\u002Ffail verdicts, scores        | Criteria with thresholds, scoring rubric, remediation guidance; `user-invocable: false` when invoked only by agents or explicit runtime skill invocation |\n| **Reference**  | Share domain knowledge       | Standards loaded by other skills  | `user-invocable: false`, passive description, read-only capabilities                                                                                     |\n\n**Type-selection rule of thumb:**\n\n- Creates new artifacts → Builder\n- Teaches how-to → Guide\n- Executes processes → Automation\n- Extracts insights → Analyzer\n- Checks quality → Validator\n- Shares knowledge multiple skills need → Reference\n\n\u003C\u002Fskill_types>\n\n\u003Creference_skills>\n\nReference skills hold shared domain knowledge that multiple skills need. Consuming workflows state each one as the instruction ``Use skill `{plugin}:{skill}`.`` per the composed-dependency rule in `\u003Cskill_organization>`. A `\u002F{skill-name}` mention in prose records the dependency but never loads the reference.\n\n**When to create a reference skill.** Two or more skills in the same plugin need the same domain knowledge (standards, patterns, anti-patterns, conventions). Alternatives fail: duplicating the content creates maintenance drift, and putting it in one skill's `references\u002F` directory makes it unreachable from the other skill's `${CLAUDE_SKILL_DIR}`.\n\n**Required frontmatter:**\n\n```yaml\n---\nname: {domain}-standards\nuser-invocable: false\ndescription: >-\n  {Domain} standards enforced across all skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n```\n\n- `user-invocable: false` — prevents false activations from user prompts.\n- Passive description (no `ALWAYS`\u002F`NEVER`) — directive descriptions trigger false activations for a reference.\n- `allowed-tools: Read` — reference skills only read. Add the harness's skill-composition tool only when explicitly composing another read-only reference skill.\n\n**How consuming skills reference it.** Name the reference skill in running text for traceability, then state the dependency as ``Use skill `{plugin}:{skill}`.`` before applying its rules. A bare `See \u002F{skill-name}` instruction is insufficient.\n\n```markdown\n# In author-typescript-test\u002FSKILL.md:\n\nUse skill `typescript:typescript-test-standards`. Apply its test file naming, execution-level, and reusable-pattern rules.\n\n# In audit-typescript-test\u002FSKILL.md:\n\nBefore auditing: Use skill `typescript:typescript-test-standards`. Apply its complete catalog of TypeScript test rules.\n```\n\n**Naming convention:** `{domain}-standards` for standards. Examples: `typescript-test-standards`, `skill-standards`, `agent-prompt-standards`.\n\n**Extraction completeness test.** When factoring a standards reference out of a builder\u002Fauditor pair, the extraction is complete only when the corresponding audit skill loads the new reference and nothing else for standards. If the auditor still reads files from the builder's `references\u002F` directory for standards, content is still stranded there — finish the move. The same rule catches partial extractions: a standards file in a creator skill's `references\u002F` directory that the auditor needs is a bug, not an architecture.\n\n\u003C\u002Freference_skills>\n\n\u003Ctemplates_and_variables>\n\nThe runtime variable scopes and bundled-file path examples live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fruntime-variables.md`. Read it before referencing bundled files.\n\n{!% if target == 'claude' %!}\nHook authoring patterns — the `SessionStart` + `$CLAUDE_ENV_FILE` value-propagation mechanism, hook `command:` paths, and the plugin `hooks\u002F` directory layout — live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplugin-hooks.md`, which also names `$CLAUDE_CODE_SESSION_ID` as the agent-published session identity a skill reads without a hook. Read it before wiring hook commands or consuming session identity from a skill.\n{!% else %!}\nCodex session-identity guidance for `$CODEX_THREAD_ID` lives in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplugin-hooks.md`. Read it before consuming session identity from a skill.\n{!% endif %!}\n\n\u003C\u002Ftemplates_and_variables>\n\n{!% if target == 'claude' %!}\n\u003Cplatform_constraints>\n\nTwo platform footguns affect skill authoring: dprint's `markup_fmt` handling of nested code fences, and Claude Code's bash-safety checker for `!` expansion. Read `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplatform-constraints.md` before using multi-backtick fences or `!` command syntax.\n\n\u003C\u002Fplatform_constraints>\n{!% else %!}\n\u003Cplatform_constraints>\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplatform-constraints.md` before using multi-backtick fences. Apply only constraints that the reference identifies for Codex.\n\n\u003C\u002Fplatform_constraints>\n{!% endif %!}\n\n\u003Cxml_tag_formatting>\n\n**Always add a blank line before a closing pseudo-XML tag that follows an unordered list.** Without it, markdown parsers indent the closing tag as part of the last list item.\n\n```text\n# ❌ WRONG\n\n\u003Csection>\n\n- Item 1\n- Item 2\n\u003C\u002Fsection>\n\n# ✅ CORRECT\n\n\u003Csection>\n\n- Item 1\n- Item 2\n\n\u003C\u002Fsection>\n```\n\n\u003C\u002Fxml_tag_formatting>\n\n\u003Cscript_standards>\n\nSkills that ship `scripts\u002F` must validate inputs with verbose, deterministic, actionable error messages and test every script before inclusion. The full validation-message and script-testing rules live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fscript-standards.md`. Read it before authoring a skill that bundles scripts.\n\n\u003C\u002Fscript_standards>\n\n\u003Cpath_boundary>\n\nA consumer's harness declares which directories a session may touch: the working directory, any additional working directories, the plugin's own files, and a scratch location. A skill instructs Claude, so every path a skill names becomes a path Claude writes — a skill that names a path outside that set directs the write out of the boundary the operator approved.\n\n**Scratch storage comes from a unique-per-invocation source, never a named path.** Use `mktemp -d` or `mktemp -t` in shell and `tempfile.mkdtemp` or `TemporaryDirectory` in Python. Each derives a unique directory from the environment's own temporary root, so no skill ever needs to spell a temporary path. Never write `\u002Ftmp`, `\u002Fvar\u002Ftmp`, `\u002Fprivate\u002Ftmp`, `\u002Fprivate\u002Fvar\u002Ftmp`, `~\u002Ftmp`, `$HOME\u002Ftmp`, `${HOME}\u002Ftmp`, or a `${TMPDIR:-\u002Ftmp}` fallback: a fixed path is identical across concurrent invocations, so two runs of the same skill overwrite each other, and it sits outside the declared set. `mktemp` already resolves an unset `TMPDIR`, so the fallback spelling buys nothing and reintroduces the literal. Naming the environment's root by variable is portable, but appending a segment to it is not — every invocation in one environment resolves the same root, so `$TMPDIR\u002Fagent.sock` collides exactly as `\u002Ftmp\u002Fagent.sock` does, and moving a fixed name between the two roots relocates the collision instead of removing it. Code that creates a scratch directory removes it on every exit path, including failure. Scratch Claude creates through a shell command stays in place: no skill directs Claude to run a deleting command. {!# scratch-path-allow #!}\n\n**A payload path is copied, never retyped.** An `audit-*` skill that passes payload files it writes with the file-write tool to run-recording commands requires four steps of the audit:\n\n1. Copy the scratch directory the harness names into each payload path character for character.\n2. When a file-write result reports a path that the scratch directory does not contain by whole path components, stop before the command that reads that file and name the reported path.\n3. Pass each run-recording command its payload path exactly as the file-write result reports it, written out literally as the argument, never held in a shell variable or expanded.\n4. When a command exits nonzero with a diagnostic that names its payload file as absent, run that command once more with the path copied from the file-write result; on a second failure, stop with the blocked result naming the run token.\n\nNo payload path is retyped from memory: a path rebuilt by hand differs from the written file by one character, and the command then reads no file. A file a bundled script writes at a path the skill names, such as a start input, has no file-write result: the audit passes it by that path written out literally, and a command whose diagnostic names that file as absent runs no second time.\n\n**A write outside the invocation checkout is confirmed before it happens, not resolved and taken.** A home-directory configuration path, another repository's checkout, or any location the operator did not name in the request needs confirmation that states the absolute destination. Being able to resolve a path is not authorization to write to it, and one confirmation covers one write — the next asks again. Prefer the in-checkout location whenever both exist, because a write there is reviewable in that repository's history.\n\nOne content may name a prohibited path: the rule prohibiting it. A standard listing the spellings an author may not write, or an audit row naming what to flag, states the rule rather than breaking it. Judge the surrounding intent — a path a skill presents as prohibited is not a violation, and a path a skill presents as a step to follow is one regardless of how it is fenced.\n\n**A permission prompt is a result, not an obstacle.** When a tool layer declines a path, that decline is the boundary working. Never document a way around it — a shell redirect standing in for a refused tool write, a broader permission substituted for a narrow one, a path rewritten to dodge a check. Name a path inside the boundary instead. A skill that teaches evasion converts one operator's approval into every future session's bypass.\n\n**An automated classifier's refusal admits one retrace-bound retry.** A decline names its source: the operator refusing a permission prompt, a guard — a hook or a dangerous-command guard — naming its rule, or the harness's permission classifier stating that it refused. Apart from the split rerun below, only a classifier refusal of a request the operator's instruction already authorized admits a retry, only where the skill directs one, and only after Claude retraces the request as sent, the classifier's reason, and each step that shaped the request. The retry carries only the correction the retrace found, never a rewording that hides the objection; a second refusal, and every other decline, is the result.\n\n**A dangerous-command guard block on a compound command admits one split rerun.** A block on a command holding one operation with every string written literally ends that command family, and so does a block on a command whose composition the parts cannot carry: a process substitution, a pipe between two operations, a background `&`, a subshell, or a list that mixes `&&` and `||`. A block on a compound command — lists separated by `;` or a newline, parts joined by `&&` alone or by `||` alone, and shell expansions — admits one rerun of its parts one at a time, in their original order, with every string written literally; a part the guard blocks on its own ends that part's family. `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` `\u003Cguard_block_partition>` defines the three outcomes and how each value resolves to a literal. The rerun needs no skill's direction and is the only retry a guard decline admits.\n\n\u003C\u002Fpath_boundary>\n","\u003Cobjective>\nThe canonical standards for skill authoring — frontmatter, XML structure, naming, descriptions, progressive disclosure, skill types, reference patterns, code-fence and bash constraints, validation, and script testing.\n\u003C\u002Fobjective>\n\n\u003Csuccess_criteria>\nSkills conform to these standards when, at minimum: (a) SKILL.md is under 500 lines unless it qualifies for `\u003Ceager_foundation_exception>`, (b) the body uses pure XML structure with no markdown headings, (c) `\u003Cobjective>` and `\u003Csuccess_criteria>` tags are present, (d) the description matches the invocation path — directive when description-match activation applies, passive when invoked only by exact name or a parent capability — (e) the skill is independent of its caller, and (f) an `\u002Faudit-skill` run on the skill seals `approved`.\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_note>\nThis is a reference skill: it standardizes skill authoring and carries no standalone workflow.\n\u003C\u002Freference_note>\n\n\u003Crule_catalog>\nEvery rule this skill and its references state has one stable identifier and one severity in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md`. Read it before recording or repairing a finding against these standards.\n\u003C\u002Frule_catalog>\n\n\u003Crepo_local_overlay>\nInside a repository, check for `spx\u002Flocal\u002Fskills.md` at the repository root. Read that file after this reference if it exists and apply it as the repo-local specialization (e.g., marketplace-specific naming conventions or additional constraints). A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cskill_organization>\n\nSkills follow a **reference pattern** to avoid duplication:\n\n1. **Foundational skill** (e.g., `\u002Ftest`) — core principles and domain-agnostic patterns.\n2. **Language-specific skills** (e.g., `\u002Fauthor-python-test`, `\u002Fauthor-typescript-test`) — reference the foundational skill, provide only language-specific implementations.\n3. **Reference skills** (e.g., `\u002Ftypescript-code-standards`, `\u002Fskill-standards`) — standards explicitly invoked by composing skills, never selected as standalone user workflows.\n\nFor language-specific skill prose that references a foundation, use the unqualified invocation name (`\u002Ftest`) so it resolves to whichever foundational skill is installed.\n\n**Skill-tool composition:** A skill may invoke another skill when the parent workflow explicitly composes that capability. Composition obeys these limits:\n\n1. The parent carries the runtime's skill-invocation capability in `allowed-tools` and names the exact installed skill to invoke.\n2. The target remains callable through the active runtime's skill-invocation surface; no runtime setting may block composed or reference-skill invocation.\n3. The parent owns sequencing, validates the returned shape, and merges the child result into its own output contract.\n4. A composition step invokes only capabilities required by the workflow; it never discovers or invokes adjacent skills speculatively.\n5. Reference-only prose may name foundational concepts without invocation, while reference skills are loaded through the runtime's skill-invocation capability when their full standards govern the work.\n\n**Caller independence:** A skill governs its own behavior and nothing else. It never names, describes, detects, constrains, refuses, branches on, or otherwise depends on its caller or invocation context. A description may state the skill's invocation contract — for example, that other skills load it and a user does not invoke it — because its behavior never depends on who the caller is. The dependency runs one way: a caller may know the skill it invokes; the skill never knows its callers.\n\n**The harness environment is not a caller.** The environment a skill runs in — an interactive session, a programmatic run, or a hosted runner — fixes the shell contract every command the skill instructs must meet, whoever invoked it. A skill that names the command form its environment accepts, such as one physical command line where a runner requires it, follows a property of its own run and depends on no caller. The same holds for the fallback location a skill selects for its payload scratch directory where the harness names none, such as the directory a hosted runner designates: the hosting environment fixes it, so naming it is a property of the run. Choosing a form by who invoked the skill, by the agent or skill that dispatched it, or by what its task message asks for remains caller dependence.\n\nContext placement, agent selection, and dispatch policy belong to the caller. A skill remains independently invocable even when the product normally reaches it through an agent or another skill. Correct an invalid invocation in the router, agent, or composing skill that made the decision; never add a dispatch gate or caller check to the invoked skill.\n\n**Composed skill dependencies.** A composing SKILL.md names each dependency with the instruction ``Use skill `{plugin}:{skill}`.`` and, on a harness that exposes a skill-composition tool, grants that tool as one complete `allowed-tools` item; on a harness without one it grants nothing for composition. Source authored for more than one harness never spells one harness's skill tool name.\n{!# Source-only maintainer guidance: in this marketplace the instruction is the`require_skill`directive and the grant is the`use_skill` tool token; the build\nrenders the target's name and removes an unavailable capability as one complete\nlist item. Generated guidance describes only the harness it ships to. #!}\n\n\u003C\u002Fskill_organization>\n\n{!% if target == 'claude' %!}\n\u003Cfrontmatter>\n\nEvery SKILL.md starts with YAML frontmatter. The canonical catalog of supported fields lives in the Claude Code docs at \u003Chttps:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fskills#frontmatter-reference>. Read the docs page when a question is about execution behavior; read this section when it is about how this marketplace authors skills.\n\n| Field                      | Required    | Constraint                                                                                                                                                                                                                     |\n| -------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `name`                     | No          | Lowercase letters, numbers, hyphens. ≤64 chars. Must match the directory name when set. If omitted, the directory name is used.                                                                                                |\n| `description`              | Recommended | Style follows the invocation path in `\u003Cdescriptions>`. Combined with `when_to_use` the listing is capped at 1,536 chars; put the key trigger first.                                                                            |\n| `when_to_use`              | No          | Extra trigger phrases or example requests appended to `description` in the skill listing. Shares the 1,536-char cap.                                                                                                           |\n| `argument-hint`            | No          | Free-text hint shown during `\u002F` autocomplete (e.g. `[issue-number]`).                                                                                                                                                          |\n| `arguments`                | No          | Named positional arguments for `$name` substitution in the body. Space-separated string or YAML list; names map to argument positions in order.                                                                                |\n| `allowed-tools`            | No          | Tools Claude may use without per-call approval while the skill is active. Space-separated string or YAML list. Restrict for audit and reference skills.                                                                        |\n| `disable-model-invocation` | No          | `true` to **block programmatic invocation entirely** — Claude cannot load the skill, including via the Skill tool, and the skill cannot be preloaded into subagents. Use for deploy-style user-only commands. Default `false`. |\n| `user-invocable`           | No          | `false` to hide from the `\u002F` autocomplete menu while keeping Claude able to invoke via the Skill tool. Description stays in context. Use for reference skills that other skills load programmatically. Default `true`.         |\n| `model`                    | Forbidden   | Skills retain the invoking session's configuration, including when a configured subagent invokes the skill.                                                                                                                    |\n| `effort`                   | Forbidden   | Skills retain the invoking session's reasoning configuration.                                                                                                                                                                  |\n| `context`                  | No          | `fork` to run the skill in a forked subagent context. Combine with `agent`.                                                                                                                                                    |\n| `agent`                    | No          | Subagent type to use when `context: fork` is set (`Explore`, `Plan`, `general-purpose`, or a custom agent). Defaults to `general-purpose`.                                                                                     |\n| `hooks`                    | No          | Hooks scoped to this skill's lifecycle. See the Claude Code hooks reference for shape.                                                                                                                                         |\n| `paths`                    | No          | Glob patterns that limit auto-activation to matching files. Comma-separated string or YAML list.                                                                                                                               |\n| `shell`                    | No          | `bash` (default) or `powershell` for the skill's inline and fenced command-injection blocks. The `powershell` value requires `CLAUDE_CODE_USE_POWERSHELL_TOOL=1`.                                                              |\n\n**Visibility vs invocability.** Two fields gate how a skill is reached. They are not aliases — pick deliberately. Automation re-entry — a scheduled wakeup, heartbeat, or `\u002Floop` — arrives as a user-style prompt because the harness offers no Claude-private heartbeat, so it follows the `User \u002F{skill}` column exactly:\n\n| Frontmatter                      | User `\u002F{skill}` | Claude (Skill tool) | Subagent preload | Automation re-entry | Description in context |\n| -------------------------------- | --------------- | ------------------- | ---------------- | ------------------- | ---------------------- |\n| *(default)*                      | Yes             | Yes                 | Yes              | Yes                 | Always                 |\n| `disable-model-invocation: true` | Yes             | **No**              | **No**           | Yes                 | Not in context         |\n| `user-invocable: false`          | **No**          | Yes                 | Yes              | **No**              | Always                 |\n\nPick the gate by role:\n\n- A reference skill another SKILL.md loads via the Skill tool, or a background-knowledge skill, uses `user-invocable: false` — hidden from the `\u002F` menu, still loadable by Claude and preloadable into subagents.\n- A user-only side-effecting command (a deploy command) uses `disable-model-invocation: true`. NEVER set it on a skill other skills or subagents must load: it blocks the Skill-tool call (surfacing `Skill \u003Cname> cannot be used with Skill tool due to disable-model-invocation`) AND blocks subagent preloading.\n- A skill any automation loop re-enters — a scheduled wakeup, heartbeat, or `\u002Floop` target — MUST be user-invocable (leave the default; never `user-invocable: false`). Automation fires as a user-style prompt, so `user-invocable: false` rejects it and no Claude-private heartbeat exists to bypass that. When a loop body is otherwise reference-like, expose a user-invocable entry the loop targets rather than gating the body. Such a loop body keeps a **passive** description — it is invoked by exact name (the timer or a parent skill), not by description-match, so a directive description would only cause false auto-activations. A user-invocable skill with a passive description is the correct shape here, not a defect.\n\nAudit skills (`audit-*`) must add `allowed-tools: Read, Grep, Glob` and only the specific Bash verb patterns their workflow runs — read-only verbs, and the `spx verification run` verbs that write the audit's own run journal — never bare `Bash`, plus `{{! tool('use_skill') !}}` when the audit composes another skill. An audit that passes payload files to run-recording commands adds the harness's file-write tool beside its read tools; the tool writes only payload files in the session scratch directory, and the audit changes no file beyond those payload files and the run journal its own recording commands write. Such an audit grants no Bash stage that builds a payload in the shell, and never grants `Edit`.\n\n**Directory match is mandatory.** `skills\u002Fauthor\u002F` → `name: author`. A mismatch breaks skill lookup.\n\n**Field `skills:` is NOT supported on SKILL.md.** It exists only on subagent definitions (`agents\u002F*.md`), where it preloads skill content as reference material into the subagent's startup context. The official docs page above lists every field a SKILL.md actually accepts; `skills:` is not among them. To make a reference skill available to another skill, set `user-invocable: false` on the reference and have the parent invoke it by installed name through the runtime's skill-invocation surface — there is no preload field on the consumer side.\n\n**Command-capability fields.** A SKILL.md carries every capability a slash command had — `argument-hint`\u002F`arguments`, `allowed-tools` restriction, plus `!`-dynamic context and `@` file references in the body. The authoring and audit rules for that surface live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md`; read it before authoring a skill that takes arguments, injects state, or restricts tools, and read its `\u003Cguard_block_partition>` when a dangerous-command guard blocks a command.\n\n\u003C\u002Ffrontmatter>\n{!% else %!}\n\u003Cfrontmatter>\n\nEvery Codex SKILL.md starts with YAML frontmatter and uses only fields accepted by Codex's current skill validator. `name` matches the skill directory, `description` states the selection contract, and tool restrictions grant only capabilities the workflow needs. Do not project Claude-only visibility, preload, heartbeat, hook, or invocation semantics onto Codex fields. Frontmatter declares no model or reasoning override; a skill retains its invoking session's configuration.\n\nReference skills stay hidden from ordinary user selection while remaining available to composed workflows through Codex's documented skill invocation surface. Audit skills change no file beyond the payload files they write in the session scratch directory and the `spx verification run` journal their own verbs write. A field or reachability behavior without a documented Codex contract is omitted.\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` before authoring arguments, dynamic context, tool restrictions, or file references for Codex, and read its `\u003Cguard_block_partition>` when a dangerous-command guard blocks a command.\n\n\u003C\u002Ffrontmatter>\n{!% endif %!}\n\n\u003Cnaming_conventions>\n\nThe `name` field is the user invocation path (`\u002F{skill-name}`). Match user speech patterns.\n\n**Rules:**\n\n- Use domain acronyms: `author` not `author-product-tree-artifacts`\n- Use terms users actually say: `test` not `python-unit-test-framework`\n- Think \"CD-ROM\" not \"Compact Disc Read Only Memory\"\n- Directory name MUST match: `skills\u002Fauthor\u002F` → `name: author`\n\n**Naming form:** invoked workflow skills use imperative verbs. Reference skills use noun phrases ending in the domain they standardize, such as `skill-standards` or `typescript-test-standards`.\n\n**Vocabulary precedence:** Skill-name grammar does not override declared methodology vocabulary. When a term can belong both to a skill-name form and to another taxonomy, read the source that declares that taxonomy and inspect file history before calling the term a naming defect.\n\nTreat generated runtime output and implementation names as lower-layer evidence, never as the authority for vocabulary classification.\n\n```yaml\n# ✅ Matches user speech\nname: author # Users say \"author a spec\"\nname: author-typescript-test # Users say \"author a TypeScript test\"\nname: bootstrap # Users say \"bootstrap the Product Tree\"\n\n# ❌ Nobody says these\nname: author-product-tree-artifacts # Too verbose\nname: typescript-unit-framework # Wrong order\n```\n\n\u003C\u002Fnaming_conventions>\n\n{!% if target == 'claude' %!}\n\u003Cdescriptions>\n\nThe description field governs skill selection. Claude has a character budget for all skill metadata — when exceeded, skills become invisible.\n\nThis section selects a description's style by invocation path. `\u002Fagent-prompt-standards` `\u003Cdescription_style>` governs the wording within that style: the directive form, the NEVER clause, artifact-before-language order, and user speech.\n\n**Description-match entry points** take a directive description.\n\n**Reference skills** carry a passive description, with the frontmatter `\u003Creference_skills>` requires.\n\n**Protocol and loop-body skills** that a parent skill loads, or that a timer fires by exact name (a heartbeat re-entry target), keep a passive description while staying user-invocable — they are never reached by description-match, so a directive description would only cause false auto-activations. See the gate-by-role rules in `\u003Cfrontmatter>`.\n\n**Audit skills** describe the audit they perform: the subject, judgment, and distinguishing criteria. Their descriptions contain no routing, dispatch, preload, agent, or execution-context statement. Audit skills stay model-invocable, carry the `allowed-tools` `\u003Cfrontmatter>` names for them, and never use `disable-model-invocation`.\n\n```yaml\ndescription: >-\n  Test-evidence audit methodology — judges test evidence against the assertions\n  it claims to verify, covering source ownership, coupling, falsifiability, and\n  full-chain coverage.\n```\n\n**Conflict resolution:** If Claude picks the wrong skill, descriptions are too similar. Make trigger terms distinct — \"sales data in Excel\" vs \"log files and system metrics\".\n\n\u003C\u002Fdescriptions>\n{!% else %!}\n\u003Cdescriptions>\n\nDescriptions state when Codex selects a skill and distinguish adjacent skills with concrete trigger terms. Use directive wording for description-match entry points and passive wording for references or protocols invoked by exact name. Keep the trigger first, avoid overlapping descriptions, and describe the skill's own subject rather than the caller that reaches it.\n\n\u003C\u002Fdescriptions>\n{!% endif %!}\n\n\u003Cxml_structure>\n\nSkills use **pure XML structure** — no markdown headings (`#`, `##`, `###`) anywhere in the body. Keep markdown formatting *within* content (bold, italic, lists, tables, code blocks, links).\n\n**Why pure XML:** unambiguous section boundaries, consistent cross-skill structure, better token efficiency, and more reliable runtime interpretation.\n\n**Required tags (every skill):**\n\n| Tag                  | Content                                                                                                                                                                                       |\n| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `\u003Cobjective>`        | The observable **output** the skill produces, in a definite shape — one sentence, not an actor or an activity, not a summary of the skill. See `\u002Fagent-prompt-standards` `\u003Cobjective_shape>`. |\n| `\u003Csuccess_criteria>` | The properties that prove the output is sound — not a re-list of the workflow steps.                                                                                                          |\n\n**Router-pattern tags** (skills that route to multiple workflows):\n\n| Tag                      | Content                                                          |\n| ------------------------ | ---------------------------------------------------------------- |\n| `\u003Cessential_principles>` | Principles that apply regardless of which workflow runs. Inline. |\n| `\u003Cintake>`               | Question to ask the user to determine routing.                   |\n| `\u003Crouting>`              | Table mapping responses to workflow files.                       |\n| `\u003Creference_index>`      | List of available reference files.                               |\n| `\u003Cworkflows_index>`      | List of available workflow files.                                |\n\n**Workflow-file tags** (files inside `workflows\u002F`):\n\n| Tag                  | Content                                                     |\n| -------------------- | ----------------------------------------------------------- |\n| `\u003Crequired_reading>` | Which reference files to load before running this workflow. |\n| `\u003Cprocess>`          | Step-by-step procedure.                                     |\n| `\u003Csuccess_criteria>` | When this workflow is complete.                             |\n\n**Conditional tags** (include when the skill's complexity or purpose calls for them):\n\n| Tag                    | When to include                                                                                                                      |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |\n| `\u003Cquick_start>`        | Tool skills with a meaningful fast path. **Omit** for foundation, gate, validator, and reference skills — completeness is the point. |\n| `\u003Ccontext>`            | Background needed before starting.                                                                                                   |\n| `\u003Cworkflow>`           | Sequential steps (non-router skills).                                                                                                |\n| `\u003Cadvanced_features>`  | Progressive disclosure for deep-dive topics.                                                                                         |\n| `\u003Cvalidation>`         | Verification checks.                                                                                                                 |\n| `\u003Cexamples>`           | Input\u002Foutput pairs.                                                                                                                  |\n| `\u003Canti_patterns>`      | Common mistakes to avoid.                                                                                                            |\n| `\u003Csecurity_checklist>` | Skills with security implications.                                                                                                   |\n| `\u003Ctesting>`            | Testing workflows or validation steps.                                                                                               |\n| `\u003Ccommon_patterns>`    | Reusable recipes.                                                                                                                    |\n| `\u003Creference_guides>`   | Pointers to detailed reference files.                                                                                                |\n| `\u003Cfailure_modes>`      | Named failures from actual usage — what happened, why, how to avoid.                                                                 |\n\nThis table is representative, not exhaustive: a skill may add semantically named domain sections beyond it (this file's `\u003Cfrontmatter>`, `\u003Cdescriptions>`, and reference-pointer sections such as `\u003Cplatform_constraints>` and `\u003Cscript_standards>` are examples).\n\n**Nesting:** XML tags can nest for hierarchical content.\n\n```text\n\u003Cexamples>\n  \u003Cexample number=\"1\">\n    \u003Cinput>User input\u003C\u002Finput>\n    \u003Coutput>Expected output\u003C\u002Foutput>\n  \u003C\u002Fexample>\n\u003C\u002Fexamples>\n```\n\n**Close every tag.** Unclosed tags break parsing.\n\n**`\u003Ccontext>` bash blocks fire on every skill load.** `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` `\u003Cdynamic_context>` carries the firing and filtering rules.\n\n**Semantic names:** `\u003Cworkflow>` not `\u003Csteps>`, `\u003Csuccess_criteria>` not `\u003Cdone>`, `\u003Canti_patterns>` not `\u003Cdont_do>`.\n\n**Reference tags in prose by name:** \"Using the schema in `\u003Cschema>` tags…\", \"Follow the workflow in `\u003Cworkflow>`…\". Makes structure self-documenting.\n\n**Intelligence rules** — match structure to complexity:\n\n| Skill class                      | Expected tags                                                                                                                                                           |\n| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Simple (single domain)           | `\u003Cobjective>`, `\u003Csuccess_criteria>`, optionally `\u003Cquick_start>`                                                                                                         |\n| Medium (multiple patterns)       | Required + `\u003Cworkflow>` and\u002For `\u003Cexamples>`                                                                                                                             |\n| Complex (multi-domain, API, sec) | Required + router pattern + appropriate conditional tags                                                                                                                |\n| Foundation \u002F gate \u002F validator    | Required + `\u003Cworkflow>`. **Omit** `\u003Cquick_start>` — no abbreviated path exists.                                                                                         |\n| Reference                        | Required; add `\u003Cworkflow>` only when the reference defines an ordered procedure. A declarative standards or vocabulary catalog omits procedural tags.                   |\n| Auditor (agent-preloaded)        | The canonical auditor skeleton — **read** `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fauditor-skeleton.md` when authoring or auditing an `audit-*` skill. **Omit** `\u003Cquick_start>`. |\n\nDon't over-engineer simple skills. Don't under-specify complex ones.\n\n\u003C\u002Fxml_structure>\n\n\u003Ceager_foundation_exception>\n\nWhen a foundation skill requires the same material on every fresh invocation, inline that canonical material and govern the total eager payload instead of the SKILL.md line count. The exception requires the same material on every invocation, removal of mandatory secondary reads, separate conditional detail, internal consistency, improved effectiveness, and a rendered payload of at most 40,000 Unicode code points measured by every audit. Never use it to inline optional detail or avoid routing.\n\n\u003C\u002Feager_foundation_exception>\n\n{!% if target == 'claude' %!}\n\u003Cprogressive_disclosure>\n\nSKILL.md is an overview. Reference files carry detail. Claude loads reference files only when needed.\n\n**Rules:**\n\n- Keep SKILL.md under 500 lines unless `\u003Ceager_foundation_exception>` applies.\n- References live in `references\u002F` one level deep from SKILL.md. Do not nest references that read other references — Claude may only partially read transitive files.\n- Reference files over 100 lines need a table of contents at the top, so partial reads still see the full scope.\n- Use forward slashes in every path — `references\u002Fguide.md`, never `references\\guide.md`. Works across platforms.\n\nApply `\u003Ceager_foundation_exception>`. A 500-line overview followed immediately by mandatory references is not progressive disclosure; total eagerly loaded content is the relevant cost.\n\n**Token efficiency:** simple task loads SKILL.md only (~500 tokens); medium loads SKILL.md + one reference (~1000); complex loads SKILL.md + multiple (~2000+).\n\n```text\n✅ One level deep\nSKILL.md → references\u002Fadvanced.md (complete info)\n         → references\u002Fexamples.md (complete info)\n\n❌ Nested\nSKILL.md → references\u002Fadvanced.md → references\u002Fdetails.md → actual info\n```\n\n**Name reference files descriptively** — `xml-structure-examples.md`, not `examples.md`. The filename is also a table-of-contents entry in `\u003Creference_index>`.\n\n**Every reference file must be cited.** A file in `references\u002F` that is not mentioned by SKILL.md or any workflow file is orphaned — it costs ~1,800+ tokens per speculative read (Claude tends to open siblings of cited references) and signals either dead content or a missing cross-reference. Either remove the file with `git rm` or add an explicit `\u003Crequired_reading>` from the workflow that needs it. Verify before committing: `grep -rn \"\u003Cfilename>\" \u003Cskill-dir>\u002F`.\n\n\u003C\u002Fprogressive_disclosure>\n{!% else %!}\n\u003Cprogressive_disclosure>\n\nKeep SKILL.md under 500 lines unless `\u003Ceager_foundation_exception>` applies. Move detailed patterns into descriptively named files one level below `references\u002F`. Cite every bundled reference from the skill or the workflow that requires it. Avoid nested reference chains, orphaned files, and duplicated standards.\n\nApply `\u003Ceager_foundation_exception>`. A 500-line overview followed immediately by mandatory references is not progressive disclosure; total eagerly loaded content is the relevant cost.\n\n\u003C\u002Fprogressive_disclosure>\n{!% endif %!}\n\n\u003Cconciseness>\n\nEvery sentence of a skill and its bundled files meets `\u002Fagent-prompt-standards` `\u003Cconciseness>`, which owns the sentence-removal test, what to omit and include, and concrete-over-abstract guidance.\n\n\u003C\u002Fconciseness>\n\n\u003Cskill_types>\n\nSix skill types. Each has a distinct purpose and primary output.\n\n| Type           | Purpose                      | Primary output                    | Key sections                                                                                                                                             |\n| -------------- | ---------------------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Builder**    | Create new artifacts         | Code, documents, widgets, configs | Required clarifications, output spec, domain standards, templates in `assets\u002F`                                                                           |\n| **Guide**      | Teach procedures             | Step-by-step workflows, tutorials | Numbered workflow, input→output example pairs, decision trees                                                                                            |\n| **Automation** | Execute multi-step processes | Processed files, transformed data | Tested scripts in `scripts\u002F`, error handling, dependencies, I\u002FO contracts                                                                                |\n| **Analyzer**   | Extract insights             | Reports, summaries, reviews       | Analysis scope, evaluation criteria, output format, synthesis                                                                                            |\n| **Validator**  | Enforce quality              | Pass\u002Ffail verdicts, scores        | Criteria with thresholds, scoring rubric, remediation guidance; `user-invocable: false` when invoked only by agents or explicit runtime skill invocation |\n| **Reference**  | Share domain knowledge       | Standards loaded by other skills  | `user-invocable: false`, passive description, read-only capabilities                                                                                     |\n\n**Type-selection rule of thumb:**\n\n- Creates new artifacts → Builder\n- Teaches how-to → Guide\n- Executes processes → Automation\n- Extracts insights → Analyzer\n- Checks quality → Validator\n- Shares knowledge multiple skills need → Reference\n\n\u003C\u002Fskill_types>\n\n\u003Creference_skills>\n\nReference skills hold shared domain knowledge that multiple skills need. Consuming workflows state each one as the instruction ``Use skill `{plugin}:{skill}`.`` per the composed-dependency rule in `\u003Cskill_organization>`. A `\u002F{skill-name}` mention in prose records the dependency but never loads the reference.\n\n**When to create a reference skill.** Two or more skills in the same plugin need the same domain knowledge (standards, patterns, anti-patterns, conventions). Alternatives fail: duplicating the content creates maintenance drift, and putting it in one skill's `references\u002F` directory makes it unreachable from the other skill's `${CLAUDE_SKILL_DIR}`.\n\n**Required frontmatter:**\n\n```yaml\n---\nname: {domain}-standards\nuser-invocable: false\ndescription: >-\n  {Domain} standards enforced across all skills. Loaded by other skills, not invoked directly.\nallowed-tools: Read\n---\n```\n\n- `user-invocable: false` — prevents false activations from user prompts.\n- Passive description (no `ALWAYS`\u002F`NEVER`) — directive descriptions trigger false activations for a reference.\n- `allowed-tools: Read` — reference skills only read. Add the harness's skill-composition tool only when explicitly composing another read-only reference skill.\n\n**How consuming skills reference it.** Name the reference skill in running text for traceability, then state the dependency as ``Use skill `{plugin}:{skill}`.`` before applying its rules. A bare `See \u002F{skill-name}` instruction is insufficient.\n\n```markdown\n# In author-typescript-test\u002FSKILL.md:\n\nUse skill `typescript:typescript-test-standards`. Apply its test file naming, execution-level, and reusable-pattern rules.\n\n# In audit-typescript-test\u002FSKILL.md:\n\nBefore auditing: Use skill `typescript:typescript-test-standards`. Apply its complete catalog of TypeScript test rules.\n```\n\n**Naming convention:** `{domain}-standards` for standards. Examples: `typescript-test-standards`, `skill-standards`, `agent-prompt-standards`.\n\n**Extraction completeness test.** When factoring a standards reference out of a builder\u002Fauditor pair, the extraction is complete only when the corresponding audit skill loads the new reference and nothing else for standards. If the auditor still reads files from the builder's `references\u002F` directory for standards, content is still stranded there — finish the move. The same rule catches partial extractions: a standards file in a creator skill's `references\u002F` directory that the auditor needs is a bug, not an architecture.\n\n\u003C\u002Freference_skills>\n\n\u003Ctemplates_and_variables>\n\nThe runtime variable scopes and bundled-file path examples live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fruntime-variables.md`. Read it before referencing bundled files.\n\n{!% if target == 'claude' %!}\nHook authoring patterns — the `SessionStart` + `$CLAUDE_ENV_FILE` value-propagation mechanism, hook `command:` paths, and the plugin `hooks\u002F` directory layout — live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplugin-hooks.md`, which also names `$CLAUDE_CODE_SESSION_ID` as the agent-published session identity a skill reads without a hook. Read it before wiring hook commands or consuming session identity from a skill.\n{!% else %!}\nCodex session-identity guidance for `$CODEX_THREAD_ID` lives in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplugin-hooks.md`. Read it before consuming session identity from a skill.\n{!% endif %!}\n\n\u003C\u002Ftemplates_and_variables>\n\n{!% if target == 'claude' %!}\n\u003Cplatform_constraints>\n\nTwo platform footguns affect skill authoring: dprint's `markup_fmt` handling of nested code fences, and Claude Code's bash-safety checker for `!` expansion. Read `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplatform-constraints.md` before using multi-backtick fences or `!` command syntax.\n\n\u003C\u002Fplatform_constraints>\n{!% else %!}\n\u003Cplatform_constraints>\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplatform-constraints.md` before using multi-backtick fences. Apply only constraints that the reference identifies for Codex.\n\n\u003C\u002Fplatform_constraints>\n{!% endif %!}\n\n\u003Cxml_tag_formatting>\n\n**Always add a blank line before a closing pseudo-XML tag that follows an unordered list.** Without it, markdown parsers indent the closing tag as part of the last list item.\n\n```text\n# ❌ WRONG\n\n\u003Csection>\n\n- Item 1\n- Item 2\n\u003C\u002Fsection>\n\n# ✅ CORRECT\n\n\u003Csection>\n\n- Item 1\n- Item 2\n\n\u003C\u002Fsection>\n```\n\n\u003C\u002Fxml_tag_formatting>\n\n\u003Cscript_standards>\n\nSkills that ship `scripts\u002F` must validate inputs with verbose, deterministic, actionable error messages and test every script before inclusion. The full validation-message and script-testing rules live in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fscript-standards.md`. Read it before authoring a skill that bundles scripts.\n\n\u003C\u002Fscript_standards>\n\n\u003Cpath_boundary>\n\nA consumer's harness declares which directories a session may touch: the working directory, any additional working directories, the plugin's own files, and a scratch location. A skill instructs Claude, so every path a skill names becomes a path Claude writes — a skill that names a path outside that set directs the write out of the boundary the operator approved.\n\n**Scratch storage comes from a unique-per-invocation source, never a named path.** Use `mktemp -d` or `mktemp -t` in shell and `tempfile.mkdtemp` or `TemporaryDirectory` in Python. Each derives a unique directory from the environment's own temporary root, so no skill ever needs to spell a temporary path. Never write `\u002Ftmp`, `\u002Fvar\u002Ftmp`, `\u002Fprivate\u002Ftmp`, `\u002Fprivate\u002Fvar\u002Ftmp`, `~\u002Ftmp`, `$HOME\u002Ftmp`, `${HOME}\u002Ftmp`, or a `${TMPDIR:-\u002Ftmp}` fallback: a fixed path is identical across concurrent invocations, so two runs of the same skill overwrite each other, and it sits outside the declared set. `mktemp` already resolves an unset `TMPDIR`, so the fallback spelling buys nothing and reintroduces the literal. Naming the environment's root by variable is portable, but appending a segment to it is not — every invocation in one environment resolves the same root, so `$TMPDIR\u002Fagent.sock` collides exactly as `\u002Ftmp\u002Fagent.sock` does, and moving a fixed name between the two roots relocates the collision instead of removing it. Code that creates a scratch directory removes it on every exit path, including failure. Scratch Claude creates through a shell command stays in place: no skill directs Claude to run a deleting command. {!# scratch-path-allow #!}\n\n**A payload path is copied, never retyped.** An `audit-*` skill that passes payload files it writes with the file-write tool to run-recording commands requires four steps of the audit:\n\n1. Copy the scratch directory the harness names into each payload path character for character.\n2. When a file-write result reports a path that the scratch directory does not contain by whole path components, stop before the command that reads that file and name the reported path.\n3. Pass each run-recording command its payload path exactly as the file-write result reports it, written out literally as the argument, never held in a shell variable or expanded.\n4. When a command exits nonzero with a diagnostic that names its payload file as absent, run that command once more with the path copied from the file-write result; on a second failure, stop with the blocked result naming the run token.\n\nNo payload path is retyped from memory: a path rebuilt by hand differs from the written file by one character, and the command then reads no file. A file a bundled script writes at a path the skill names, such as a start input, has no file-write result: the audit passes it by that path written out literally, and a command whose diagnostic names that file as absent runs no second time.\n\n**A write outside the invocation checkout is confirmed before it happens, not resolved and taken.** A home-directory configuration path, another repository's checkout, or any location the operator did not name in the request needs confirmation that states the absolute destination. Being able to resolve a path is not authorization to write to it, and one confirmation covers one write — the next asks again. Prefer the in-checkout location whenever both exist, because a write there is reviewable in that repository's history.\n\nOne content may name a prohibited path: the rule prohibiting it. A standard listing the spellings an author may not write, or an audit row naming what to flag, states the rule rather than breaking it. Judge the surrounding intent — a path a skill presents as prohibited is not a violation, and a path a skill presents as a step to follow is one regardless of how it is fenced.\n\n**A permission prompt is a result, not an obstacle.** When a tool layer declines a path, that decline is the boundary working. Never document a way around it — a shell redirect standing in for a refused tool write, a broader permission substituted for a narrow one, a path rewritten to dodge a check. Name a path inside the boundary instead. A skill that teaches evasion converts one operator's approval into every future session's bypass.\n\n**An automated classifier's refusal admits one retrace-bound retry.** A decline names its source: the operator refusing a permission prompt, a guard — a hook or a dangerous-command guard — naming its rule, or the harness's permission classifier stating that it refused. Apart from the split rerun below, only a classifier refusal of a request the operator's instruction already authorized admits a retry, only where the skill directs one, and only after Claude retraces the request as sent, the classifier's reason, and each step that shaped the request. The retry carries only the correction the retrace found, never a rewording that hides the objection; a second refusal, and every other decline, is the result.\n\n**A dangerous-command guard block on a compound command admits one split rerun.** A block on a command holding one operation with every string written literally ends that command family, and so does a block on a command whose composition the parts cannot carry: a process substitution, a pipe between two operations, a background `&`, a subshell, or a list that mixes `&&` and `||`. A block on a compound command — lists separated by `;` or a newline, parts joined by `&&` alone or by `||` alone, and shell expansions — admits one rerun of its parts one at a time, in their original order, with every string written literally; a part the guard blocks on its own ends that part's family. `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcommand-capabilities.md` `\u003Cguard_block_partition>` defines the three outcomes and how each value resolves to a literal. The rerun needs no skill's direction and is the only retry a guard decline admits.\n\n\u003C\u002Fpath_boundary>\n",{"name":5,"description":7,"allowed-tools":37,"user-invocable":33},"Read","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add outcomeeng\u002Fplugins --skill skill-standards",{"tool":52,"command":53},"bunx","bunx skills add outcomeeng\u002Fplugins --skill skill-standards",{"tool":55,"command":56},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill skill-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002FSKILL.md",true,[60,66,70,74,78,82,86],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Fauditor-skeleton.md","REFERENCE","参考文档",10640,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fauditor-skeleton.md",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fcommand-capabilities.md",11556,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fcommand-capabilities.md",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fplatform-constraints.md",1647,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fplatform-constraints.md",{"path":75,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fplugin-hooks.md",7462,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fplugin-hooks.md",{"path":79,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Frule-catalog.md",41509,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Frule-catalog.md",{"path":83,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fruntime-variables.md",2841,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fruntime-variables.md",{"path":87,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fscript-standards.md",2343,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Finstructions\u002Fskills\u002Fskill-standards\u002Freferences\u002Fscript-standards.md",[91,97,132,148,161,174],{"skillNo":92,"name":93,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":32},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[93],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":111,"publishedAt":32},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[103,106],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":133,"name":134,"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":32},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[139,140,141,142,143,119,130,144,145,131,146,147],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":32},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[158,159,160,24,29,30,31],"typescript","typescript test standards","test",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":170,"publishedAt":32},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[167],{"categoryNo":168,"categoryName":169,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000030","开发工程师",[158,171,172,173,24,29,30,31],"code","typescript code standards","code standards",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":32},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[181,24,182,183,158,184,185,31,30,186,29,187],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]