[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DA3C2RTK8R5TQ9YZVBYT1D":3,"skill-same:01M6DA3C2RTK8R5TQ9YZVBYT1D":91},{"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":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6DA3C2RTK8R5TQ9YZVBYT1D","team-creation",null,"Create or extend scion agent team templates from a high-level description of roles and workflow. Use when the user describes a multi-agent team, panel, crew, pipeline, or any scenario requiring coordinated LLM agents with distinct roles. Also use when adding new roles to an existing team, modifying workflows, or restructuring agent coordination. Produces ready-to-use template directories in .scion\u002Ftemplates\u002F by default, or in a custom path if specified.","GoogleCloudPlatform\u002Fscion","GoogleCloudPlatform","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2810941?v=4","01M6DA2FX07AS0KCQ4FBRS84A2","Google Cloud Platform","01M6DA2G1EA6A2E5MKG6THG0KK",2114,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fteam-creation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"team","team creation","creation","ready","new","when","extend","path","directories","agent coordination","scenario","roles","agent team","default","workflow","use","user","multi-agent","coordination","template","crew","llm agents","templates","pipeline","create","workflows","2026-11-10 10:12:30",false,"---\nname: team-creation\ndescription: >-\n  Create or extend scion agent team templates from a high-level description of roles and workflow.\n  Use when the user describes a multi-agent team, panel, crew, pipeline, or any scenario\n  requiring coordinated LLM agents with distinct roles. Also use when adding new roles to an\n  existing team, modifying workflows, or restructuring agent coordination. Produces ready-to-use\n  template directories in .scion\u002Ftemplates\u002F by default, or in a custom path if specified.\n---\n\n# Scion Team Creation & Extension Skill\n\nYou create and extend **scion agent templates** — the blueprints that define specialized agent roles. Given a description of a team (roles, responsibilities, workflow), you produce template directories that can be used to start agents with `scion start \u003Cname> --type \u003Ctemplate>`.\n\nWhen extending an existing team, review the current templates to understand the established patterns, naming, and workflow before making changes.\n\n## Template Directory Structure\n\nEach template lives in `.scion\u002Ftemplates\u002F\u003Ctemplate-name>\u002F` and contains:\n\n```\n.scion\u002Ftemplates\u002F\u003Ctemplate-name>\u002F\n├── scion-agent.yaml       # REQUIRED: template metadata and config\n├── agents.md              # REQUIRED: agent behavioral instructions\n├── system-prompt.md       # REQUIRED: role persona and expertise framing\n└── skills\u002F                # OPTIONAL: harness skills (agentskills.io standard)\n    └── \u003Cskill-name>\u002F\n        └── SKILL.md\n```\n\nCustom templates automatically **inherit** from the built-in `default` template, which provides shell configs, git setup, and base scion infrastructure. You do NOT need to create a `home\u002F` directory or duplicate any infrastructure files.\n\n### Template Naming\n\n- Directory names use **kebab-case**: `panel-judge`, `code-reviewer`, `team-lead`\n- Names should be descriptive of the role, not the project\n\n## Required File Formats\n\n### scion-agent.yaml\n\nEvery template MUST have this file. Minimal valid config:\n\n```yaml\nschema_version: \"1\"\ndescription: \"Short description of this agent role\"\nagent_instructions: agents.md\nsystem_prompt: system-prompt.md\n```\n\nOptional fields you may include when the role requires them:\n\n```yaml\nmax_turns: 50              # Maximum conversation turns\nmax_duration: \"30m\"        # Maximum wall-clock time (e.g. \"1h\", \"30m\")\n\nenv:\n  ROLE: \"reviewer\"\n\nservices:\n  - name: chromium\n    command: [\"chromium\", \"--headless\", \"--no-sandbox\", \"--remote-debugging-port=9222\"]\n    restart: always\n    ready_check:\n      type: tcp\n      target: \"localhost:9222\"\n      timeout: \"10s\"\n\nskills:\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest\"\n  - uri: \"skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0\"\n    optional: true\n```\n\n### Fields to Never Use\n\nThese fields are deprecated or cause broken agent startup — never include them in generated `scion-agent.yaml` files:\n\n| Field | Reason |\n|---|---|\n| `harness` | Deprecated — causes runtime error |\n| `harness_config` | Unnecessary; project defaults apply automatically |\n| `explicit_workspace` | Causes interactive theme prompt instead of running |\n| `config_dir` | Breaks harness startup |\n\nA minimal valid `scion-agent.yaml` needs only `schema_version`, `description`, and `agent_instructions`. Add only the fields listed under \"Optional fields\" above.\n\n### agents.md (Agent Instructions)\n\nThis file contains the behavioral instructions injected into the agent's context. \n\nThe primary contents should focus on task and job work describing what the agent should do, how it should behave, and any constraints on its work.\n\nDo **not** include instructions on how to use the scion CLI (starting agents, messaging, `scion look`, etc.) — every agent automatically receives base CLI operating instructions from the platform.\n\n### system-prompt.md (Optional)\n\nFrames the agent's persona, expertise, and perspective — *who* the agent is, while `agents.md` shapes *what* it does. Example:\n\n```markdown\n# Expert Code Reviewer\n\nYou are a senior software engineer with deep expertise in code quality,\nsecurity, and maintainability. You approach code review methodically,\nprioritizing correctness and clarity over style preferences.\n```\n\nIf the role doesn't need a distinct persona, omit this file and remove the `system_prompt` line from `scion-agent.yaml`.\n\nThis file can contain broad direction around skillsets.\n\n## Harness Skills\n\nTemplates can include a `skills\u002F` directory containing reusable skill definitions that follow the [agentskills.io](https:\u002F\u002Fagentskills.io\u002F) standard. Each skill is a subdirectory with a `SKILL.md` file:\n\n```\nskills\u002F\n└── my-skill\u002F\n    └── SKILL.md\n```\n\nA `SKILL.md` file has YAML frontmatter with `name` and `description`, followed by markdown content:\n\n```markdown\n---\nname: my-skill\ndescription: >-\n  Short description of what this skill does and when the agent should use it.\n---\n\nSkill instructions and reference material here.\n```\n\nDuring agent provisioning, Scion automatically merges skills from the template into the correct harness-specific location (e.g. `.claude\u002Fskills\u002F` for Claude, `.gemini\u002Fskills\u002F` for Gemini). The agent's LLM harness discovers and loads these skills at runtime.\n\nUse skills to package domain knowledge, tool-usage patterns, or specialized workflows that a role needs. Skills are portable across harnesses and reusable across templates.\n\n## Registry Skills (URI References)\n\nIn addition to local `skills\u002F` directories, templates can declare skill dependencies from the skill bank registry using URI references in `scion-agent.yaml`. These skills are downloaded and installed at provision time.\n\n### URI Format\n\n```\nskill:\u002F\u002F\u003Cregistry>\u002F\u003Cscope>\u002F\u003Cname>@\u003Cversion>\n```\n\n- **registry**: The registry host (typically `scion`)\n- **scope**: Where the skill lives — `core` (platform skills), `global` (hub-wide), `project\u002F\u003Cid>` (project-scoped), or `user\u002F\u003Cid>` (user-scoped)\n- **name**: The skill name\n- **version**: Version constraint — an exact version (`1.0.0`), a range (`^1.0`), or `latest`\n\nExamples:\n- `skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest` — a global-scope skill from the Hub\n- `skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0` — a core platform skill\n- `skill:\u002F\u002Fscion\u002Fproject\u002Fmy-custom-skill@1.0.0` — a project-scoped skill\n\n### Declaring Skills in scion-agent.yaml\n\nAdd a `skills:` list to `scion-agent.yaml`:\n\n```yaml\nskills:\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest\"\n  - uri: \"skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0\"\n    optional: true        # provisioning succeeds even if this can't be resolved\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fcode-reviewer@latest\"\n    as: \"review\"          # install under a different directory name\n```\n\nEach entry supports three fields:\n- **`uri`** (required): The skill URI\n- **`optional`** (default `false`): When `true`, provisioning continues even if the skill can't be resolved. When `false`, unresolvable skills cause provisioning to fail.\n- **`as`** (optional): Install the skill under a different directory name than its registry name\n\n### When to Use URI References vs Local Skills\n\n- **URI references**: Use for published, shared skills from the skill bank — skills that exist independently of this template and may be updated separately. Good for widely-useful skills like `idea-refine`, domain-specific utilities, or skills maintained by other teams.\n- **Local `skills\u002F` directory**: Use for skills specific to this template's workflow that aren't published to the registry. Also for skills you want to customize beyond what the registry version provides.\n\nIf a skill is useful to multiple templates and is published to the registry, reference it by URI rather than copying the `SKILL.md` locally. Local skills take precedence over registry skills of the same name, so you can always override a URI-referenced skill with a local version if needed.\n\n## The Orchestrator Pattern\n\nEvery team MUST have exactly one **orchestrator** (also called lead, supervisor, or coordinator). This is the agent the user starts directly — it then creates and manages the other agents.\n\nThe orchestrator's `agents.md` should focus on:\n\n- **What templates are available** and what each role does\n- **The workflow**: when to start which agents, what tasks to give them, how to handle their results\n- **Communication patterns**: what information flows between roles and when\n- **Completion criteria**: how the orchestrator knows the overall task is done\n\nWorkers don't communicate directly with each other — the orchestrator reads output from one and relays relevant information to others.\n\n### Orchestrator agents.md Structure\n\n```markdown\n## Role: Team Orchestrator\n\nYou are the orchestrator for [team description]. Your job is to:\n1. [high-level workflow step 1]\n2. [high-level workflow step 2]\n\n## Available Agent Roles\n\n- `\u003Ctemplate-1>`: [what this role does, expected input, what it produces]\n- `\u003Ctemplate-2>`: [what this role does, expected input, what it produces]\n\n## Workflow\n\n[Step-by-step instructions: when to create agents, what to tell them,\nhow to handle results, when the overall task is complete.]\n```\n\n## Creating a New Team\n\n### 1. Analyze the Description\n\nIdentify from the user's description:\n- **Roles**: What distinct agent types are needed?\n- **Workflow**: How do the agents interact? Sequential pipeline, parallel work, debate, review cycle?\n- **Orchestration**: Who starts whom? Who collects results?\n\n### 2. Design the Team Structure\n\n- Identify one role as the **orchestrator** — the entry point the user will start\n- All other roles are **workers** — started and managed by the orchestrator\n- Map out the communication flow\n\n### 3. Create Templates\n\nFor each role, create the template directory with its files. Write worker templates first, then the orchestrator (since it references worker template names).\n\n### 4. Add Skills When Appropriate\n\nIf a role needs specialized domain knowledge or tool-usage patterns that would benefit from being a discrete, reusable skill file rather than inline in `agents.md`:\n\n- **For skills already published in the registry**: Add a URI reference in `scion-agent.yaml` under `skills:`. This is preferred — it avoids duplicating skill content and picks up registry updates automatically.\n- **For custom skills specific to this template**: Create a `SKILL.md` file in the template's `skills\u002F` directory.\n\n### 5. Validate\n\n- [ ] Every template has `scion-agent.yaml` with `schema_version: \"1\"`\n- [ ] The orchestrator references the correct template names\n- [ ] Template directory names are kebab-case\n- [ ] The workflow matches the user's intent\n- [ ] No CLI usage instructions are duplicated in templates\n- [ ] For skills referenced by URI: verify the URI format is correct (`skill:\u002F\u002Fregistry\u002Fscope\u002Fname@version`)\n- [ ] Required skills (non-optional) will cause provisioning to fail if unresolvable — mark skills `optional: true` if the team can function without them\n\n## Extending an Existing Team\n\nWhen adding to or modifying an existing team:\n\n### 1. Review Current State\n\nRead the existing templates in `.scion\u002Ftemplates\u002F` to understand:\n- The current roles and their responsibilities\n- The orchestrator's workflow and how it references workers\n- Naming conventions and patterns already established\n- Any existing skills in template `skills\u002F` directories\n- Skill may be hard copied between templates if they are relevant to more than one type.\n\n### 2. Determine the Change\n\n- **Adding a role**: Create a new worker template, then update the orchestrator's `agents.md` to reference it — add the new template to the \"Available Agent Roles\" section and integrate it into the workflow.\n- **Modifying a role**: Update the existing template's `agents.md` and\u002For `system-prompt.md`. Check if the orchestrator's workflow needs adjustment.\n- **Changing workflow**: Update the orchestrator's `agents.md` workflow section. May require changes to worker instructions if handoff patterns change.\n- **Adding capabilities**: Consider whether the new capability belongs as inline instructions in `agents.md` or as a discrete skill in the template's `skills\u002F` directory.\n\n### 3. Maintain Consistency\n\n- Follow the naming conventions already in use\n- Keep the communication patterns consistent (workers report to orchestrator)\n- Update the orchestrator whenever worker templates change\n\n## Gotchas\n\n- **Don't duplicate CLI usage instructions**. Every agent already receives base scion CLI instructions from the platform.\n- **Don't create `home\u002F` directories** in custom templates. The default template provides all infrastructure.\n- **Template names = directory names**. The `description` in `scion-agent.yaml` is cosmetic; the `--type` value is the directory name.\n- **Skills are harness-portable**. Write `SKILL.md` content without assuming a specific harness — scion mounts skills into the correct location automatically.\n- **URI skills resolve at provision time**. Agents must be connected to a Hub with the skill in its registry. Use `optional: true` for skills that are nice-to-have but not essential.\n- **Local skills take precedence**. If a template's `skills\u002F` directory contains a skill with the same name as a URI-referenced skill, the local version wins.\n- **Never set `harness`, `harness_config`, `explicit_workspace`, or `config_dir`** — these fields are deprecated or cause broken agent startup. Omit them entirely. Project defaults handle harness selection automatically.\n","# Scion Team Creation & Extension Skill\n\nYou create and extend **scion agent templates** — the blueprints that define specialized agent roles. Given a description of a team (roles, responsibilities, workflow), you produce template directories that can be used to start agents with `scion start \u003Cname> --type \u003Ctemplate>`.\n\nWhen extending an existing team, review the current templates to understand the established patterns, naming, and workflow before making changes.\n\n## Template Directory Structure\n\nEach template lives in `.scion\u002Ftemplates\u002F\u003Ctemplate-name>\u002F` and contains:\n\n```\n.scion\u002Ftemplates\u002F\u003Ctemplate-name>\u002F\n├── scion-agent.yaml       # REQUIRED: template metadata and config\n├── agents.md              # REQUIRED: agent behavioral instructions\n├── system-prompt.md       # REQUIRED: role persona and expertise framing\n└── skills\u002F                # OPTIONAL: harness skills (agentskills.io standard)\n    └── \u003Cskill-name>\u002F\n        └── SKILL.md\n```\n\nCustom templates automatically **inherit** from the built-in `default` template, which provides shell configs, git setup, and base scion infrastructure. You do NOT need to create a `home\u002F` directory or duplicate any infrastructure files.\n\n### Template Naming\n\n- Directory names use **kebab-case**: `panel-judge`, `code-reviewer`, `team-lead`\n- Names should be descriptive of the role, not the project\n\n## Required File Formats\n\n### scion-agent.yaml\n\nEvery template MUST have this file. Minimal valid config:\n\n```yaml\nschema_version: \"1\"\ndescription: \"Short description of this agent role\"\nagent_instructions: agents.md\nsystem_prompt: system-prompt.md\n```\n\nOptional fields you may include when the role requires them:\n\n```yaml\nmax_turns: 50              # Maximum conversation turns\nmax_duration: \"30m\"        # Maximum wall-clock time (e.g. \"1h\", \"30m\")\n\nenv:\n  ROLE: \"reviewer\"\n\nservices:\n  - name: chromium\n    command: [\"chromium\", \"--headless\", \"--no-sandbox\", \"--remote-debugging-port=9222\"]\n    restart: always\n    ready_check:\n      type: tcp\n      target: \"localhost:9222\"\n      timeout: \"10s\"\n\nskills:\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest\"\n  - uri: \"skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0\"\n    optional: true\n```\n\n### Fields to Never Use\n\nThese fields are deprecated or cause broken agent startup — never include them in generated `scion-agent.yaml` files:\n\n| Field | Reason |\n|---|---|\n| `harness` | Deprecated — causes runtime error |\n| `harness_config` | Unnecessary; project defaults apply automatically |\n| `explicit_workspace` | Causes interactive theme prompt instead of running |\n| `config_dir` | Breaks harness startup |\n\nA minimal valid `scion-agent.yaml` needs only `schema_version`, `description`, and `agent_instructions`. Add only the fields listed under \"Optional fields\" above.\n\n### agents.md (Agent Instructions)\n\nThis file contains the behavioral instructions injected into the agent's context. \n\nThe primary contents should focus on task and job work describing what the agent should do, how it should behave, and any constraints on its work.\n\nDo **not** include instructions on how to use the scion CLI (starting agents, messaging, `scion look`, etc.) — every agent automatically receives base CLI operating instructions from the platform.\n\n### system-prompt.md (Optional)\n\nFrames the agent's persona, expertise, and perspective — *who* the agent is, while `agents.md` shapes *what* it does. Example:\n\n```markdown\n# Expert Code Reviewer\n\nYou are a senior software engineer with deep expertise in code quality,\nsecurity, and maintainability. You approach code review methodically,\nprioritizing correctness and clarity over style preferences.\n```\n\nIf the role doesn't need a distinct persona, omit this file and remove the `system_prompt` line from `scion-agent.yaml`.\n\nThis file can contain broad direction around skillsets.\n\n## Harness Skills\n\nTemplates can include a `skills\u002F` directory containing reusable skill definitions that follow the [agentskills.io](https:\u002F\u002Fagentskills.io\u002F) standard. Each skill is a subdirectory with a `SKILL.md` file:\n\n```\nskills\u002F\n└── my-skill\u002F\n    └── SKILL.md\n```\n\nA `SKILL.md` file has YAML frontmatter with `name` and `description`, followed by markdown content:\n\n```markdown\n---\nname: my-skill\ndescription: >-\n  Short description of what this skill does and when the agent should use it.\n---\n\nSkill instructions and reference material here.\n```\n\nDuring agent provisioning, Scion automatically merges skills from the template into the correct harness-specific location (e.g. `.claude\u002Fskills\u002F` for Claude, `.gemini\u002Fskills\u002F` for Gemini). The agent's LLM harness discovers and loads these skills at runtime.\n\nUse skills to package domain knowledge, tool-usage patterns, or specialized workflows that a role needs. Skills are portable across harnesses and reusable across templates.\n\n## Registry Skills (URI References)\n\nIn addition to local `skills\u002F` directories, templates can declare skill dependencies from the skill bank registry using URI references in `scion-agent.yaml`. These skills are downloaded and installed at provision time.\n\n### URI Format\n\n```\nskill:\u002F\u002F\u003Cregistry>\u002F\u003Cscope>\u002F\u003Cname>@\u003Cversion>\n```\n\n- **registry**: The registry host (typically `scion`)\n- **scope**: Where the skill lives — `core` (platform skills), `global` (hub-wide), `project\u002F\u003Cid>` (project-scoped), or `user\u002F\u003Cid>` (user-scoped)\n- **name**: The skill name\n- **version**: Version constraint — an exact version (`1.0.0`), a range (`^1.0`), or `latest`\n\nExamples:\n- `skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest` — a global-scope skill from the Hub\n- `skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0` — a core platform skill\n- `skill:\u002F\u002Fscion\u002Fproject\u002Fmy-custom-skill@1.0.0` — a project-scoped skill\n\n### Declaring Skills in scion-agent.yaml\n\nAdd a `skills:` list to `scion-agent.yaml`:\n\n```yaml\nskills:\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fidea-refine@latest\"\n  - uri: \"skill:\u002F\u002Fscion\u002Fcore\u002Fscion@^1.0\"\n    optional: true        # provisioning succeeds even if this can't be resolved\n  - uri: \"skill:\u002F\u002Fscion\u002Fglobal\u002Fcode-reviewer@latest\"\n    as: \"review\"          # install under a different directory name\n```\n\nEach entry supports three fields:\n- **`uri`** (required): The skill URI\n- **`optional`** (default `false`): When `true`, provisioning continues even if the skill can't be resolved. When `false`, unresolvable skills cause provisioning to fail.\n- **`as`** (optional): Install the skill under a different directory name than its registry name\n\n### When to Use URI References vs Local Skills\n\n- **URI references**: Use for published, shared skills from the skill bank — skills that exist independently of this template and may be updated separately. Good for widely-useful skills like `idea-refine`, domain-specific utilities, or skills maintained by other teams.\n- **Local `skills\u002F` directory**: Use for skills specific to this template's workflow that aren't published to the registry. Also for skills you want to customize beyond what the registry version provides.\n\nIf a skill is useful to multiple templates and is published to the registry, reference it by URI rather than copying the `SKILL.md` locally. Local skills take precedence over registry skills of the same name, so you can always override a URI-referenced skill with a local version if needed.\n\n## The Orchestrator Pattern\n\nEvery team MUST have exactly one **orchestrator** (also called lead, supervisor, or coordinator). This is the agent the user starts directly — it then creates and manages the other agents.\n\nThe orchestrator's `agents.md` should focus on:\n\n- **What templates are available** and what each role does\n- **The workflow**: when to start which agents, what tasks to give them, how to handle their results\n- **Communication patterns**: what information flows between roles and when\n- **Completion criteria**: how the orchestrator knows the overall task is done\n\nWorkers don't communicate directly with each other — the orchestrator reads output from one and relays relevant information to others.\n\n### Orchestrator agents.md Structure\n\n```markdown\n## Role: Team Orchestrator\n\nYou are the orchestrator for [team description]. Your job is to:\n1. [high-level workflow step 1]\n2. [high-level workflow step 2]\n\n## Available Agent Roles\n\n- `\u003Ctemplate-1>`: [what this role does, expected input, what it produces]\n- `\u003Ctemplate-2>`: [what this role does, expected input, what it produces]\n\n## Workflow\n\n[Step-by-step instructions: when to create agents, what to tell them,\nhow to handle results, when the overall task is complete.]\n```\n\n## Creating a New Team\n\n### 1. Analyze the Description\n\nIdentify from the user's description:\n- **Roles**: What distinct agent types are needed?\n- **Workflow**: How do the agents interact? Sequential pipeline, parallel work, debate, review cycle?\n- **Orchestration**: Who starts whom? Who collects results?\n\n### 2. Design the Team Structure\n\n- Identify one role as the **orchestrator** — the entry point the user will start\n- All other roles are **workers** — started and managed by the orchestrator\n- Map out the communication flow\n\n### 3. Create Templates\n\nFor each role, create the template directory with its files. Write worker templates first, then the orchestrator (since it references worker template names).\n\n### 4. Add Skills When Appropriate\n\nIf a role needs specialized domain knowledge or tool-usage patterns that would benefit from being a discrete, reusable skill file rather than inline in `agents.md`:\n\n- **For skills already published in the registry**: Add a URI reference in `scion-agent.yaml` under `skills:`. This is preferred — it avoids duplicating skill content and picks up registry updates automatically.\n- **For custom skills specific to this template**: Create a `SKILL.md` file in the template's `skills\u002F` directory.\n\n### 5. Validate\n\n- [ ] Every template has `scion-agent.yaml` with `schema_version: \"1\"`\n- [ ] The orchestrator references the correct template names\n- [ ] Template directory names are kebab-case\n- [ ] The workflow matches the user's intent\n- [ ] No CLI usage instructions are duplicated in templates\n- [ ] For skills referenced by URI: verify the URI format is correct (`skill:\u002F\u002Fregistry\u002Fscope\u002Fname@version`)\n- [ ] Required skills (non-optional) will cause provisioning to fail if unresolvable — mark skills `optional: true` if the team can function without them\n\n## Extending an Existing Team\n\nWhen adding to or modifying an existing team:\n\n### 1. Review Current State\n\nRead the existing templates in `.scion\u002Ftemplates\u002F` to understand:\n- The current roles and their responsibilities\n- The orchestrator's workflow and how it references workers\n- Naming conventions and patterns already established\n- Any existing skills in template `skills\u002F` directories\n- Skill may be hard copied between templates if they are relevant to more than one type.\n\n### 2. Determine the Change\n\n- **Adding a role**: Create a new worker template, then update the orchestrator's `agents.md` to reference it — add the new template to the \"Available Agent Roles\" section and integrate it into the workflow.\n- **Modifying a role**: Update the existing template's `agents.md` and\u002For `system-prompt.md`. Check if the orchestrator's workflow needs adjustment.\n- **Changing workflow**: Update the orchestrator's `agents.md` workflow section. May require changes to worker instructions if handoff patterns change.\n- **Adding capabilities**: Consider whether the new capability belongs as inline instructions in `agents.md` or as a discrete skill in the template's `skills\u002F` directory.\n\n### 3. Maintain Consistency\n\n- Follow the naming conventions already in use\n- Keep the communication patterns consistent (workers report to orchestrator)\n- Update the orchestrator whenever worker templates change\n\n## Gotchas\n\n- **Don't duplicate CLI usage instructions**. Every agent already receives base scion CLI instructions from the platform.\n- **Don't create `home\u002F` directories** in custom templates. The default template provides all infrastructure.\n- **Template names = directory names**. The `description` in `scion-agent.yaml` is cosmetic; the `--type` value is the directory name.\n- **Skills are harness-portable**. Write `SKILL.md` content without assuming a specific harness — scion mounts skills into the correct location automatically.\n- **URI skills resolve at provision time**. Agents must be connected to a Hub with the skill in its registry. Use `optional: true` for skills that are nice-to-have but not essential.\n- **Local skills take precedence**. If a template's `skills\u002F` directory contains a skill with the same name as a URI-referenced skill, the local version wins.\n- **Never set `harness`, `harness_config`, `explicit_workspace`, or `config_dir`** — these fields are deprecated or cause broken agent startup. Omit them entirely. Project defaults handle harness selection automatically.\n",{"name":5,"description":7},"main","d2283cad8aa80efb245b118b91c4accb684e287e","resources\u002Fplatform_skills\u002Fteam-creation",310,"https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform","https:\u002F\u002Fcloud.google.com","2026-11-13 02:20:49",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add GoogleCloudPlatform\u002Fscion --skill team-creation",{"tool":69,"command":70},"bunx","bunx skills add GoogleCloudPlatform\u002Fscion --skill team-creation",{"tool":72,"command":73},"pnpm","pnpm dlx skills add GoogleCloudPlatform\u002Fscion --skill team-creation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fteam-creation\u002FSKILL.md",true,[77,83,87],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"agents\u002Fopenai.yaml","REFERENCE","参考文档",239,"https:\u002F\u002Fgithub.com\u002Ftsergeytovarov\u002Fai-settings\u002Fblob\u002Fmain\u002Fskills\u002Fpopovs\u002Fproduct-spec-pipeline\u002Fagents\u002Fopenai.yaml",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"CHANGELOG.md",1144,"https:\u002F\u002Fgithub.com\u002Ftsergeytovarov\u002Fai-settings\u002Fblob\u002Fmain\u002Fskills\u002Fpopovs\u002Fproduct-spec-pipeline\u002FCHANGELOG.md",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fproduct-spec-template.md",2936,"https:\u002F\u002Fgithub.com\u002Ftsergeytovarov\u002Fai-settings\u002Fblob\u002Fmain\u002Fskills\u002Fpopovs\u002Fproduct-spec-pipeline\u002Freferences\u002Fproduct-spec-template.md",[92,126,150,168,179,196],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":50},"01M6DA385P0S838W8ZXQ7SVDFM","scion-web-serving","How to serve a web page, app, API or other HTTP service from inside your agent so a person or program can reach it through the Hub's port proxy: scion expose and unexpose, the URL to hand over, what the proxy carries, and scion tunnel for full apps. The link serves web protocols only; for a non-HTTP port, point the person to scion tunnel. Use before running scion expose. For web pages and apps, also read references\u002Fweb-apps.md.","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-web-serving\u002FSKILL.md",[],[99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,39,115,116,117,118,119,120,121,122,123,124,125],"scion web serving","web","serving","app","references","what the","protocols","how","proxy","page","hub","read","pages","tunnel","only","service","http","full","api","running","point","for","how to","apps","URL","program","hand",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":50},"01M6DA35JGKREZP9ZM2ZYH0J7M","scion-scheduler","Schedule one-shot and recurring events for agents using the Scion CLI. Covers when to use scheduled events vs inline message delays, recurring cron schedules, lifecycle management, and the blocked-wait pairing rule.","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-scheduler\u002FSKILL.md",[],[133,134,135,136,137,138,39,139,140,141,120,142,143,29,144,145,146,147,148,149],"scheduler","scion scheduler","recurring","message","cli","lifecycle","management","schedule","cron","schedules","scheduled","inline","when to use","rule","wait","pairing","events",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":50},"01M6DA328HMWYY0R65MVVJJG3S","scion-messaging","Use when sending messages to users or agents with scion message, choosing conversations and mentions, or interpreting incoming messages. Covers user-facing formatting, agent delivery, and reading conversation history.","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-messaging\u002FSKILL.md",[],[157,158,39,136,159,160,161,162,163,164,165,166,167,40,29],"messaging","scion messaging","conversation","delivery","history","conversations","messages","users","with","reading","formatting",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":50},"01M6DA2YXJ384EVWJX6RPHDZ9R","scion-conversation","How to use the scion conversation command for managing conversations. Covers listing, creating, viewing, participant management, and message retrieval. Complements the scion-messaging skill.","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-conversation\u002FSKILL.md",[],[159,175,157,136,176,106,39,139,162,120,121,177,178],"scion conversation","command","listing","retrieval",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":50},"01M6DA2WCR1XJK9A3NSV2VGP56","scion-cli-operations","Operational constraints for Scion agents running in containerized sandboxes. Covers prohibited commands and hub-only API access. Complements the scion CLI reference and messaging skills.","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-cli-operations\u002FSKILL.md",[],[137,186,187,157,109,188,113,189,190,117,191,118,120,192,193,194,195],"operations","scion cli operations","commands","reference","access","constraints","cli reference","sandboxes","operational constraints","containerized",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":50},"01M6DA2SNFM7QDR29R12HZGNQH","scion-agent-manage","Manage concurrent LLM-based code agents with scion - orchestrate parallel agents with isolated workspaces, troubleshoot and recover stuck agents","https:\u002F\u002Fgithub.com\u002FGoogleCloudPlatform\u002Fscion\u002Fblob\u002Fmain\u002Fresources\u002Fplatform_skills\u002Fscion-agent-manage\u002FSKILL.md",[202],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[204,205,206,207,208,209,210,211,212,165],"manage","scion agent manage","parallel","orchestrate","workspaces","troubleshoot","parallel agents","code","code agents"]