[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C47BXKBHWB506J1QF7B27A":3,"skill-same:01M6C47BXKBHWB506J1QF7B27A":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6C47BXKBHWB506J1QF7B27A","skill-creator",null,"Guide for creating new skills in this system with proper frontmatter format. Use when adding new skills, updating skill templates, or reviewing skill structure. DO NOT USE FOR: general agent or instruction file customization (use agent-customization) or modifying existing skill logic\u002Fcontent.","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fskill-creator\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36],"skill creator","content","file","templates","system","format","customization","guide","use","2026-11-10 10:12:30",false,"---\nname: skill-creator\ndescription: \"Guide for creating new skills in this system with proper frontmatter format. Use when adding new skills, updating skill templates, or reviewing skill structure. DO NOT USE FOR: general agent or instruction file customization (use agent-customization) or modifying existing skill logic\u002Fcontent.\"\n---\n\n# Skill Creator\n\nGuide for creating new skills with proper structure and VS Code 1.108+ compatible frontmatter.\n\n## When to Use\n\n- Creating a new skill for the project\n- Reviewing existing skills for compliance\n- Updating skill templates\n- Onboarding contributors to skill creation\n\n## Built-in Creation Commands (VS Code 1.110+)\n\n> If you are on VS Code 1.108 or 1.109, skip this section and proceed directly to [Required Frontmatter Format](#required-frontmatter-format) below.\n\nVS Code 1.110 ships built-in slash commands for scaffolding customization files:\n\n- `\u002Fcreate-skill` — generates a new skill file\n- `\u002Fcreate-agent` — generates a new `.agent.md` file\n- `\u002Fcreate-prompt` — generates a new `.prompt.md` file\n- `\u002Fcreate-instruction` — generates a new `.instructions.md` file\n\n**Recommended workflow**: Use the built-in `\u002Fcreate-skill` (or equivalent) to generate the initial scaffold, then apply this skill to validate and refine the output against project conventions:\n\n- Kebab-case `name` in frontmatter (e.g., `my-skill`, not `MySkill`)\n- `description` must include usage triggers (\"Use when ...\" phrasing) for discoverability\n- Directory structure: `skills\u002F{skill-name}\u002FSKILL.md`\n- Required frontmatter fields: `name` and `description` only — no unsupported fields\n\n## Required Frontmatter Format\n\n```markdown\n---\nname: skill-name-kebab-case\ndescription: What the skill does AND when to use it. This description triggers skill discovery in chat.\n---\n```\n\n**Important**:\n\n- `name` and `description` are the only supported frontmatter fields\n- No `allowed-tools` or other fields—they will be ignored\n- Description should include usage triggers for discoverability\n\n## Directory Structure\n\n```\nskills\u002F\n└── {skill-name}\u002F\n    ├── SKILL.md          # Required: Main skill file with frontmatter\n    ├── reference.md      # Optional: Detailed reference material\n    ├── templates.md      # Optional: Code\u002Fdocument templates\n    └── examples\u002F         # Optional: Example files\n        └── ...\n```\n\n## Discovery in VS Code (1.108+)\n\n- Skill discovery in chat is available in VS Code 1.108+\n- Ensure agent skills are enabled via `chat.useAgentSkills`\n- Discovery quality depends on clear trigger phrasing in `description` (for example: \"Use when ...\")\n\n## Minimal vs Full Skill Pattern\n\nUse the smallest structure that solves the need:\n\n- **Minimal Skill**: Single `SKILL.md` with frontmatter, \"When to Use,\" and concise process\u002Fchecklist\n- **Full Skill**: `SKILL.md` plus supporting references\u002Ftemplates\u002Fexamples when topic depth or reuse requires it\n\nStart minimal, then split into supporting files only when the core document becomes hard to navigate.\n\n## Skill Template\n\n```markdown\n---\nname: {skill-name}\ndescription: {What it does}. Use when {trigger conditions}. DO NOT USE FOR: {scenarios where adjacent skills are better} (use {other-skill}).\n---\n\n# {Skill Title}\n\nBrief overview of the skill's purpose.\n\n## When to Use\n\n- Bullet list of situations\n- That trigger this skill\n- Be specific for discoverability\n\n## Core Content\n\nMain guidance, principles, or process.\n\n### Subsections as Needed\n\nOrganize by user goals, not by internal structure.\n\n## Project-Specific Configuration\n\n[CUSTOMIZE] Add project-specific details:\n\n- Configuration files to modify\n- Team conventions to follow\n- Tools and paths used\n\n## Quick Reference\n\n| Item        | Description       |\n| ----------- | ----------------- |\n| Key concept | Brief explanation |\n\n## See Also\n\n- [Related supporting file](.\u002Frelated-file.md)\n- External reference links\n\n## Gotchas\n\n| Trigger                                        | Gotcha                    | Fix                     |\n| ---------------------------------------------- | ------------------------- | ----------------------- |\n| {observable condition that causes the failure} | {what goes wrong and why} | {actionable correction} |\n```\n\n## Description Quality Checklist\n\nBefore finalizing a skill's `description:` field, verify:\n\n1. **Length target**: ≤60 words total (positive triggers + negative signals combined)\n2. **Positive triggers**: includes \"Use when...\" with 2–3 specific, distinct scenarios — not generic summary language\n3. **Negative signals**: includes \"DO NOT USE FOR:...\" with at least one adjacent skill pointer, e.g. `(use {other-skill})`\n4. **Collision check**: before finalizing, use `grep_search` with query `your-trigger-word` and `includePattern: \"skills\u002F*\u002FSKILL.md\"` to check for naming collisions with existing skills. Add explicit \"DO NOT USE FOR:\" signals to **both** sides of any conflict.\n\n## Writing Guidelines\n\n### Prescription Budget (Claude 5)\n\nBefore adding imperative guardrails to a skill — MUST\u002FNEVER lists, step-by-step behavioral coaching, forbidden-command enumerations — read `Documents\u002FDesign\u002Fcontext-engineering-claude-5.md`: prescription written for older models degrades Claude 5 output. Keep contracts exact (schemas, marker grammars, enum literals, gate definitions); trim coaching the model no longer needs.\n\n### Description Field (Critical for Discovery)\n\nThe description determines when the skill appears in suggestions.\n\n**Good descriptions**:\n\n```yaml\ndescription: 4-phase debugging process for complex issues. Use when debugging failures, investigating flaky tests, or tracking root causes. DO NOT USE FOR: writing new tests (use test-driven-development), React component test patterns (use ui-testing), or E2E test setup (use webapp-testing).\n\ndescription: Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), or debugging failures (use systematic-debugging).\n```\n\n**Bad descriptions**:\n\n```yaml\ndescription: Debugging guide.  # Too vague, poor discoverability\n\ndescription: This skill helps with testing things.  # Unclear scope\n```\n\n### Frontmatter Validation\n\n| Field         | Required | Rule                                                     | Validation Guidance                                                                                                   |\n| ------------- | -------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `name`        | Yes      | kebab-case                                               | Use lowercase words separated by hyphens (for example: `test-driven-development`)                                     |\n| `description` | Yes      | Include what it does + usage triggers + negative signals | Include \"Use when ...\" for positive triggers and \"DO NOT USE FOR: ... (use {skill})\" for at least one negative signal |\n| Other fields  | No       | Unsupported                                              | Do not add extra fields (for example `allowed-tools`) because they are ignored                                        |\n\n### Content Principles\n\n1. **Be actionable**: Provide steps, not just concepts\n2. **Use `[CUSTOMIZE]` markers**: For project-specific placeholders\n3. **Keep SKILL.md concise**: Route to supporting files for details\n4. **Template-generic language**: No repo-specific references\n5. **Include \"When to Use\"**: Explicit trigger conditions\n\n### Gotchas Section Guidelines\n\n- **Always include ≥1 gotcha**: No skill should ship without at least one entry\n- **Trigger precision**: Use observable conditions, not abstract categories (\"Using `clickElement` on canvas\" not \"Wrong tool usage\")\n- **Fix specificity**: Provide actionable commands, skill section references, or concrete alternatives — not \"use the right approach\"\n- **Use prose alternatives**: When a gotcha needs more than 2 sentences, use a callout block or guardrail section instead of cramming it into a table cell\n- **Downstream convention**: When agents discover new gotchas while working in a downstream repo, append them to `.github\u002Finstructions\u002Flocal-gotchas.instructions.md` under a `## {skill-name}` heading with format `\u003C!-- gotcha-status: new -->` — Process-Review will scan and route them upstream\n\n  Example entry in `local-gotchas.instructions.md`:\n\n  ```markdown\n  ## brainstorming\n\n  \u003C!-- gotcha-status: new -->\n\n  | Trigger                                | Gotcha                            | Fix                                        |\n  | -------------------------------------- | --------------------------------- | ------------------------------------------ |\n  | Asking for options without constraints | Produces unbounded solution space | Add scope constraints before brainstorming |\n  ```\n\n  The `\u003C!-- gotcha-status: new -->` marker goes on the line immediately before the table header it annotates (not inside the table body).\n  Each gotcha entry must be its own single-row table — do not combine multiple entries in one table, as the `\u003C!-- gotcha-status: ... -->` marker tracks state per table, not per row.\n\n### Customization Markers\n\nUse `[CUSTOMIZE]` for sections that need project adaptation:\n\n```markdown\n## Project Configuration\n\n[CUSTOMIZE] Add your project's specific:\n\n- File paths and locations\n- Naming conventions\n- Team-specific practices\n```\n\n## Skill Sizing Guidelines\n\n| Size   | SKILL.md Lines | Supporting Files | Use Case                    |\n| ------ | -------------- | ---------------- | --------------------------- |\n| Small  | 50-100         | 0                | Simple process or checklist |\n| Medium | 100-200        | 0-1              | Standard methodology        |\n| Large  | 150-250        | 1-3              | Complex topic with patterns |\n\n**Rule**: If SKILL.md exceeds 300 lines, split into supporting files.\n\n## Supplement Skills\n\nA **supplement skill** layers project-specific constraints, themes, or identity guidance on top of an existing hub skill. When a project has one, load both together — the hub skill provides universal principles and the supplement narrows them for the project.\n\n**Naming convention**: `skills\u002F{project}-{hub-skill-name}\u002FSKILL.md` — for example, `windgust-frontend-design` supplements `frontend-design`.\n\n**Supplement ≠ replacement**: A supplement adds to the hub skill; it does not replace it. Load both together. If your supplement contradicts hub skill guidance, the benefit of shared defaults is lost.\n\n**Description convention**: Supplement descriptions should explicitly reference the hub skill they extend — for example: \"Supplements `frontend-design` with {project} brand identity...\".\n\nSee the `frontend-design` skill for a worked example and a minimal supplement SKILL.md template.\n\n## Validation Checklist\n\nBefore committing a new skill:\n\n- [ ] Frontmatter has only `name` and `description`\n- [ ] `name` is kebab-case\n- [ ] `description` includes usage triggers\n- [ ] \"When to Use\" section is present\n- [ ] `[CUSTOMIZE]` markers for project-specific content\n- [ ] No hardcoded paths or repo-specific references\n- [ ] Supporting files are referenced from SKILL.md\n- [ ] Content is actionable, not just conceptual\n- [ ] Gotchas section present with at least one entry\n\n## Example: Complete Skill\n\n```markdown\n---\nname: code-review\ndescription: Structured code review process with security and maintainability focus. Use when reviewing PRs, conducting code audits, or establishing review standards. DO NOT USE FOR: line-by-line debugging assistance (use systematic-debugging) or writing test cases from scratch (use test-driven-development).\n---\n\n# Code Review Skill\n\nSystematic approach to reviewing code changes.\n\n## When to Use\n\n- Reviewing pull requests\n- Conducting security audits\n- Establishing team review standards\n- Self-review before submitting PRs\n\n## Review Process\n\n### 1. Understand Context\n\n- Read PR description and linked issues\n- Understand the goal before reading code\n\n### 2. High-Level Review\n\n- Does the approach make sense?\n- Are there architectural concerns?\n\n### 3. Detailed Review\n\n- Security: Input validation, auth, data exposure\n- Correctness: Edge cases, error handling\n- Maintainability: Readability, naming, complexity\n\n### 4. Provide Feedback\n\n- Be specific and actionable\n- Suggest alternatives, don't just criticize\n- Distinguish blocking vs. non-blocking\n\n## Project Standards\n\n[CUSTOMIZE] Add your team's review requirements:\n\n- Required reviewers by area\n- Review checklist items\n- Auto-merge criteria\n```\n\n## Gotchas\n\n| Trigger                                                                       | Gotcha                                                                   | Fix                                                                                  |\n| ----------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |\n| Using extra frontmatter fields (`allowed-tools`, `applyTo`, custom keys)      | Only `name` and `description` are supported; extras are silently ignored | Use only `name` and `description` in frontmatter                                     |\n| Writing a vague description: `description: Debugging guide.`                  | Skill never appears in suggestions — description fails semantic matching | Include \"Use when...\" with 2–3 specific observable triggers                          |\n| Omitting \"DO NOT USE FOR:...\" negative signals                                | Skill collides with adjacent skills; wrong one is chosen                 | Include at least one `DO NOT USE FOR:` pointer with the alternative skill name       |\n| Not running a collision check before finalizing                               | New skill's trigger words shadow an existing skill                       | `grep_search` trigger phrases across `skills\u002F*\u002FSKILL.md` before finalizing   |\n| Using camelCase or PascalCase for `name` (`MySkill`)                          | Naming convention violation; potential discovery failure                 | Use kebab-case (`my-skill`) for the `name` frontmatter field                         |\n| Creating `references\u002F`, `examples\u002F`, and `templates\u002F` directories immediately | File bloat; harder to navigate and maintain                              | Start with Minimal structure; split only when core document becomes hard to navigate |\n| Creating a supplement that contradicts or overrides the hub skill's defaults  | Loses shared hub-skill defaults; teams diverge without a shared baseline | Layer on top — supplements narrow or extend hub guidance, never replace; load both together      |\n","# Skill Creator\n\nGuide for creating new skills with proper structure and VS Code 1.108+ compatible frontmatter.\n\n## When to Use\n\n- Creating a new skill for the project\n- Reviewing existing skills for compliance\n- Updating skill templates\n- Onboarding contributors to skill creation\n\n## Built-in Creation Commands (VS Code 1.110+)\n\n> If you are on VS Code 1.108 or 1.109, skip this section and proceed directly to [Required Frontmatter Format](#required-frontmatter-format) below.\n\nVS Code 1.110 ships built-in slash commands for scaffolding customization files:\n\n- `\u002Fcreate-skill` — generates a new skill file\n- `\u002Fcreate-agent` — generates a new `.agent.md` file\n- `\u002Fcreate-prompt` — generates a new `.prompt.md` file\n- `\u002Fcreate-instruction` — generates a new `.instructions.md` file\n\n**Recommended workflow**: Use the built-in `\u002Fcreate-skill` (or equivalent) to generate the initial scaffold, then apply this skill to validate and refine the output against project conventions:\n\n- Kebab-case `name` in frontmatter (e.g., `my-skill`, not `MySkill`)\n- `description` must include usage triggers (\"Use when ...\" phrasing) for discoverability\n- Directory structure: `skills\u002F{skill-name}\u002FSKILL.md`\n- Required frontmatter fields: `name` and `description` only — no unsupported fields\n\n## Required Frontmatter Format\n\n```markdown\n---\nname: skill-name-kebab-case\ndescription: What the skill does AND when to use it. This description triggers skill discovery in chat.\n---\n```\n\n**Important**:\n\n- `name` and `description` are the only supported frontmatter fields\n- No `allowed-tools` or other fields—they will be ignored\n- Description should include usage triggers for discoverability\n\n## Directory Structure\n\n```\nskills\u002F\n└── {skill-name}\u002F\n    ├── SKILL.md          # Required: Main skill file with frontmatter\n    ├── reference.md      # Optional: Detailed reference material\n    ├── templates.md      # Optional: Code\u002Fdocument templates\n    └── examples\u002F         # Optional: Example files\n        └── ...\n```\n\n## Discovery in VS Code (1.108+)\n\n- Skill discovery in chat is available in VS Code 1.108+\n- Ensure agent skills are enabled via `chat.useAgentSkills`\n- Discovery quality depends on clear trigger phrasing in `description` (for example: \"Use when ...\")\n\n## Minimal vs Full Skill Pattern\n\nUse the smallest structure that solves the need:\n\n- **Minimal Skill**: Single `SKILL.md` with frontmatter, \"When to Use,\" and concise process\u002Fchecklist\n- **Full Skill**: `SKILL.md` plus supporting references\u002Ftemplates\u002Fexamples when topic depth or reuse requires it\n\nStart minimal, then split into supporting files only when the core document becomes hard to navigate.\n\n## Skill Template\n\n```markdown\n---\nname: {skill-name}\ndescription: {What it does}. Use when {trigger conditions}. DO NOT USE FOR: {scenarios where adjacent skills are better} (use {other-skill}).\n---\n\n# {Skill Title}\n\nBrief overview of the skill's purpose.\n\n## When to Use\n\n- Bullet list of situations\n- That trigger this skill\n- Be specific for discoverability\n\n## Core Content\n\nMain guidance, principles, or process.\n\n### Subsections as Needed\n\nOrganize by user goals, not by internal structure.\n\n## Project-Specific Configuration\n\n[CUSTOMIZE] Add project-specific details:\n\n- Configuration files to modify\n- Team conventions to follow\n- Tools and paths used\n\n## Quick Reference\n\n| Item        | Description       |\n| ----------- | ----------------- |\n| Key concept | Brief explanation |\n\n## See Also\n\n- [Related supporting file](.\u002Frelated-file.md)\n- External reference links\n\n## Gotchas\n\n| Trigger                                        | Gotcha                    | Fix                     |\n| ---------------------------------------------- | ------------------------- | ----------------------- |\n| {observable condition that causes the failure} | {what goes wrong and why} | {actionable correction} |\n```\n\n## Description Quality Checklist\n\nBefore finalizing a skill's `description:` field, verify:\n\n1. **Length target**: ≤60 words total (positive triggers + negative signals combined)\n2. **Positive triggers**: includes \"Use when...\" with 2–3 specific, distinct scenarios — not generic summary language\n3. **Negative signals**: includes \"DO NOT USE FOR:...\" with at least one adjacent skill pointer, e.g. `(use {other-skill})`\n4. **Collision check**: before finalizing, use `grep_search` with query `your-trigger-word` and `includePattern: \"skills\u002F*\u002FSKILL.md\"` to check for naming collisions with existing skills. Add explicit \"DO NOT USE FOR:\" signals to **both** sides of any conflict.\n\n## Writing Guidelines\n\n### Prescription Budget (Claude 5)\n\nBefore adding imperative guardrails to a skill — MUST\u002FNEVER lists, step-by-step behavioral coaching, forbidden-command enumerations — read `Documents\u002FDesign\u002Fcontext-engineering-claude-5.md`: prescription written for older models degrades Claude 5 output. Keep contracts exact (schemas, marker grammars, enum literals, gate definitions); trim coaching the model no longer needs.\n\n### Description Field (Critical for Discovery)\n\nThe description determines when the skill appears in suggestions.\n\n**Good descriptions**:\n\n```yaml\ndescription: 4-phase debugging process for complex issues. Use when debugging failures, investigating flaky tests, or tracking root causes. DO NOT USE FOR: writing new tests (use test-driven-development), React component test patterns (use ui-testing), or E2E test setup (use webapp-testing).\n\ndescription: Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), or debugging failures (use systematic-debugging).\n```\n\n**Bad descriptions**:\n\n```yaml\ndescription: Debugging guide.  # Too vague, poor discoverability\n\ndescription: This skill helps with testing things.  # Unclear scope\n```\n\n### Frontmatter Validation\n\n| Field         | Required | Rule                                                     | Validation Guidance                                                                                                   |\n| ------------- | -------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `name`        | Yes      | kebab-case                                               | Use lowercase words separated by hyphens (for example: `test-driven-development`)                                     |\n| `description` | Yes      | Include what it does + usage triggers + negative signals | Include \"Use when ...\" for positive triggers and \"DO NOT USE FOR: ... (use {skill})\" for at least one negative signal |\n| Other fields  | No       | Unsupported                                              | Do not add extra fields (for example `allowed-tools`) because they are ignored                                        |\n\n### Content Principles\n\n1. **Be actionable**: Provide steps, not just concepts\n2. **Use `[CUSTOMIZE]` markers**: For project-specific placeholders\n3. **Keep SKILL.md concise**: Route to supporting files for details\n4. **Template-generic language**: No repo-specific references\n5. **Include \"When to Use\"**: Explicit trigger conditions\n\n### Gotchas Section Guidelines\n\n- **Always include ≥1 gotcha**: No skill should ship without at least one entry\n- **Trigger precision**: Use observable conditions, not abstract categories (\"Using `clickElement` on canvas\" not \"Wrong tool usage\")\n- **Fix specificity**: Provide actionable commands, skill section references, or concrete alternatives — not \"use the right approach\"\n- **Use prose alternatives**: When a gotcha needs more than 2 sentences, use a callout block or guardrail section instead of cramming it into a table cell\n- **Downstream convention**: When agents discover new gotchas while working in a downstream repo, append them to `.github\u002Finstructions\u002Flocal-gotchas.instructions.md` under a `## {skill-name}` heading with format `\u003C!-- gotcha-status: new -->` — Process-Review will scan and route them upstream\n\n  Example entry in `local-gotchas.instructions.md`:\n\n  ```markdown\n  ## brainstorming\n\n  \u003C!-- gotcha-status: new -->\n\n  | Trigger                                | Gotcha                            | Fix                                        |\n  | -------------------------------------- | --------------------------------- | ------------------------------------------ |\n  | Asking for options without constraints | Produces unbounded solution space | Add scope constraints before brainstorming |\n  ```\n\n  The `\u003C!-- gotcha-status: new -->` marker goes on the line immediately before the table header it annotates (not inside the table body).\n  Each gotcha entry must be its own single-row table — do not combine multiple entries in one table, as the `\u003C!-- gotcha-status: ... -->` marker tracks state per table, not per row.\n\n### Customization Markers\n\nUse `[CUSTOMIZE]` for sections that need project adaptation:\n\n```markdown\n## Project Configuration\n\n[CUSTOMIZE] Add your project's specific:\n\n- File paths and locations\n- Naming conventions\n- Team-specific practices\n```\n\n## Skill Sizing Guidelines\n\n| Size   | SKILL.md Lines | Supporting Files | Use Case                    |\n| ------ | -------------- | ---------------- | --------------------------- |\n| Small  | 50-100         | 0                | Simple process or checklist |\n| Medium | 100-200        | 0-1              | Standard methodology        |\n| Large  | 150-250        | 1-3              | Complex topic with patterns |\n\n**Rule**: If SKILL.md exceeds 300 lines, split into supporting files.\n\n## Supplement Skills\n\nA **supplement skill** layers project-specific constraints, themes, or identity guidance on top of an existing hub skill. When a project has one, load both together — the hub skill provides universal principles and the supplement narrows them for the project.\n\n**Naming convention**: `skills\u002F{project}-{hub-skill-name}\u002FSKILL.md` — for example, `windgust-frontend-design` supplements `frontend-design`.\n\n**Supplement ≠ replacement**: A supplement adds to the hub skill; it does not replace it. Load both together. If your supplement contradicts hub skill guidance, the benefit of shared defaults is lost.\n\n**Description convention**: Supplement descriptions should explicitly reference the hub skill they extend — for example: \"Supplements `frontend-design` with {project} brand identity...\".\n\nSee the `frontend-design` skill for a worked example and a minimal supplement SKILL.md template.\n\n## Validation Checklist\n\nBefore committing a new skill:\n\n- [ ] Frontmatter has only `name` and `description`\n- [ ] `name` is kebab-case\n- [ ] `description` includes usage triggers\n- [ ] \"When to Use\" section is present\n- [ ] `[CUSTOMIZE]` markers for project-specific content\n- [ ] No hardcoded paths or repo-specific references\n- [ ] Supporting files are referenced from SKILL.md\n- [ ] Content is actionable, not just conceptual\n- [ ] Gotchas section present with at least one entry\n\n## Example: Complete Skill\n\n```markdown\n---\nname: code-review\ndescription: Structured code review process with security and maintainability focus. Use when reviewing PRs, conducting code audits, or establishing review standards. DO NOT USE FOR: line-by-line debugging assistance (use systematic-debugging) or writing test cases from scratch (use test-driven-development).\n---\n\n# Code Review Skill\n\nSystematic approach to reviewing code changes.\n\n## When to Use\n\n- Reviewing pull requests\n- Conducting security audits\n- Establishing team review standards\n- Self-review before submitting PRs\n\n## Review Process\n\n### 1. Understand Context\n\n- Read PR description and linked issues\n- Understand the goal before reading code\n\n### 2. High-Level Review\n\n- Does the approach make sense?\n- Are there architectural concerns?\n\n### 3. Detailed Review\n\n- Security: Input validation, auth, data exposure\n- Correctness: Edge cases, error handling\n- Maintainability: Readability, naming, complexity\n\n### 4. Provide Feedback\n\n- Be specific and actionable\n- Suggest alternatives, don't just criticize\n- Distinguish blocking vs. non-blocking\n\n## Project Standards\n\n[CUSTOMIZE] Add your team's review requirements:\n\n- Required reviewers by area\n- Review checklist items\n- Auto-merge criteria\n```\n\n## Gotchas\n\n| Trigger                                                                       | Gotcha                                                                   | Fix                                                                                  |\n| ----------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |\n| Using extra frontmatter fields (`allowed-tools`, `applyTo`, custom keys)      | Only `name` and `description` are supported; extras are silently ignored | Use only `name` and `description` in frontmatter                                     |\n| Writing a vague description: `description: Debugging guide.`                  | Skill never appears in suggestions — description fails semantic matching | Include \"Use when...\" with 2–3 specific observable triggers                          |\n| Omitting \"DO NOT USE FOR:...\" negative signals                                | Skill collides with adjacent skills; wrong one is chosen                 | Include at least one `DO NOT USE FOR:` pointer with the alternative skill name       |\n| Not running a collision check before finalizing                               | New skill's trigger words shadow an existing skill                       | `grep_search` trigger phrases across `skills\u002F*\u002FSKILL.md` before finalizing   |\n| Using camelCase or PascalCase for `name` (`MySkill`)                          | Naming convention violation; potential discovery failure                 | Use kebab-case (`my-skill`) for the `name` frontmatter field                         |\n| Creating `references\u002F`, `examples\u002F`, and `templates\u002F` directories immediately | File bloat; harder to navigate and maintain                              | Start with Minimal structure; split only when core document becomes hard to navigate |\n| Creating a supplement that contradicts or overrides the hub skill's defaults  | Loses shared hub-skill defaults; teams diverge without a shared baseline | Layer on top — supplements narrow or extend hub guidance, never replace; load both together      |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fskill-creator",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill skill-creator",{"tool":55,"command":56},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill skill-creator",{"tool":58,"command":59},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill skill-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fskill-creator\u002FSKILL.md",true,[],[64,96,121,137,161,182],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":76,"publishedAt":37},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[70,73],{"categoryNo":71,"categoryName":72,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,36],"testing","webapp testing","webapp","canvas","tdd","workflow","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":37},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[103,104,105,106,107,108,109,110,111,112,113,114,91,115,116,117,118,36,119,120],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":37},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[128,129,130,105,131,132,133,134,112,135,92,36,136],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":147,"publishedAt":37},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[143,144],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":145,"categoryName":146,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[148,149,105,150,151,108,152,109,112,153,154,155,156,157,158,117,118,159,160,36],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":175,"publishedAt":37},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[167,168,169,172],{"categoryNo":71,"categoryName":72,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":170,"categoryName":171,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":173,"categoryName":174,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[77,176,177,178,179,180,80,82,83,84,86,87,88,89,90,181,93,94,36,79],"ui","ui testing","frontend","design","writing","testing patterns",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":190,"publishedAt":37},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[188,189],{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":173,"categoryName":174,"taxonomyType":25,"taxonomyTypeDesc":26},[176,191,178,179,105,82,192,112,193,194,195,196,197,117,198,199,36,200],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]