[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BJ1PV3RT2VTC0PVVXJMC1":3,"skill-same:01M69BJ1PV3RT2VTC0PVVXJMC1":55},{"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":18,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":6,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":54},"01M69BJ1PV3RT2VTC0PVVXJMC1","amplifier-config",null,"Explain, inspect, troubleshoot, and safely modify Amplifier CLI configuration — providers, settings scopes, bundles, routing, skills, and source overrides. Use when someone describes desired Amplifier CLI behavior and needs effective-value provenance, a safe change plan, implementation, or outcome-based verification.","microsoft\u002Famplifier-app-cli","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BHYVWVEWQF0DY6W6TMESV",19,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Famplifier-config\u002FSKILL.md",[],[19,20,21,22,23,24,25],"config","amplifier config","cli","safe","troubleshoot","change","routing","2026-11-10 10:12:30",false,"---\nname: amplifier-config\ndescription: >-\n  Explain, inspect, troubleshoot, and safely modify Amplifier CLI\n  configuration — providers, settings scopes, bundles, routing, skills, and\n  source overrides. Use when someone describes desired Amplifier CLI behavior\n  and needs effective-value provenance, a safe change plan, implementation, or\n  outcome-based verification.\nuser-invocable: true\nversion: 0.1.0\nlicense: MIT\n---\n\n# Amplifier CLI Configuration Consultant\n\nTranslate desired Amplifier CLI behavior into the smallest correct configuration change. This skill owns the CLI-facing workflow. Portable bundle, routing, skill, and provider systems are dependencies to consult through their owning documentation and implementation, not domains this skill independently defines. Work from the current installation and effective CLI configuration, not remembered defaults or frozen examples.\n\n## Request\n\n$ARGUMENTS\n\nTreat `$ARGUMENTS` as the explicit request when present and use the current conversation for relevant context. If the desired behavior, scope, or permission to edit is unclear, ask one focused question before proceeding.\n\nIn an interactive CLI session, invoke this skill with `\u002Famplifier-config \u003Crequest>`. In headless use, send a natural-language request that identifies the skill or explicitly call `load_skill` with `skill_name: amplifier-config` and pass the request as `arguments`. Do not assume a slash command embedded in a headless prompt will be dispatched as an interactive command.\n\n## Operational contract\n\n### 1. Classify the configuration plane\n\nBefore recommending anything, identify every affected plane and keep them distinct:\n\n1. **Current\u002Fmain-session provider selection** — which configured provider instance and model answer the root conversation, including launch selection, configured defaults, and session pinning.\n2. **Spawned\u002Fdelegated routing** — how sub-agents, delegated sessions, recipe steps, and other spawned work select providers or models through roles and preferences.\n3. **CLI bundle composition** — which portable providers, tools, hooks, agents, behaviors, context, modes, and skills the CLI composes and mounts.\n4. **Persisted scope, precedence, and source overrides** — the canonical `global`, `project`, and `local` settings scopes; composition provenance; and source replacement of installed modules or bundles.\n5. **Runtime session state** — temporary selection or pinning in the active CLI session, kept separate from persisted `global`, `project`, and `local` settings.\n6. **CLI skill discovery** — where the CLI discovers a skill from, which same-named skill wins, and whether it is available in the active session.\n7. **Provider-module-specific fields** — settings consumed by a portable provider module composed into the CLI, whose meaning and supported values belong to that resolved module and version.\n\nA request may cross planes. Name those crossings explicitly rather than treating Amplifier configuration as one flat YAML document.\n\n### 2. Establish current authoritative semantics\n\nNever rely on memory for exact commands, paths, schemas, precedence, or version-sensitive behavior.\n\n- **CLI, session, command, provider-pinning, and spawn-precedence questions:** delegate to `app-cli:cli-expert`. Ask it about the installed version and use its version-matched evidence. If it is unavailable, report that limitation and inspect the installed CLI help and owned documentation; do not silently substitute remembered behavior.\n- **Portable bundle composition or internals:** consult the owning foundation or bundle documentation and any available specialist for the resolved installed source\u002Fversion; this skill only explains how the CLI composes the result.\n- **Portable routing:** inspect the active CLI routing configuration, installed routing documentation, and the routing implementation that owns the current semantics. Do not assume a matrix format from an old example.\n- **Portable provider-specific keys:** resolve the provider module the CLI actually uses, then inspect that version's documentation, schema, validation code, or source. Do not transfer fields between provider modules merely because their names sound similar.\n\nRecord which source supports each consequential claim. If sources conflict or current evidence is incomplete, surface the uncertainty instead of inventing a rule.\n\n### 3. Inspect before editing\n\nInspect the effective configuration and provenance before proposing or applying a change:\n\n- Determine the active bundle\u002Fsession context and the effective mounted items.\n- Trace each relevant effective value back through its contributing declarations and resolved source\u002Fversion.\n- Distinguish saved configuration from runtime or session-only state.\n- Identify same-named or repeated provider, bundle, skill, and source entries that could affect resolution.\n- Redact API keys, tokens, credentials, cookies, authorization headers, and other secret values in all output, diffs, logs, and delegated prompts.\n- Preserve literal `${ENV_VAR}` references. Never resolve, print, replace, or quote their secret runtime values.\n\nDo not edit based only on a plausible source file; first prove that the file contributes to the observed effective value.\n\n### 4. Preserve the stable conceptual boundary\n\nThe root\u002Fmain session's provider selection and spawned-session routing are separate configuration planes. A routing matrix for spawned work must not be presented as the mechanism that necessarily selects the model answering the current root conversation.\n\nThis distinction is stable; its exact commands, supported selectors, precedence details, session boundaries, and orchestration behavior are version-sensitive. Verify those details for the installed version with `app-cli:cli-expert` and the owning routing source before acting.\n\n## Workflow\n\nFollow this sequence and do not skip directly to editing.\n\n### Orient\n\nRestate the desired behavior in testable terms. Classify the affected planes, intended persisted scope (`global`, `project`, or `local`), any separate runtime-session effect, and whether the user asked only for an explanation or explicitly asked to apply a change.\n\n### Inspect\n\nGather current, authoritative evidence from effective configuration, provenance, installed source versions, and the domain owners described above. Redact secrets immediately.\n\n### Explain\n\nExplain what currently controls the behavior, why the observed result occurs, and where any proposed change belongs. **An explanation or troubleshooting request never authorizes mutation.**\n\n### Plan\n\nPropose the smallest supported change. Prefer supported CLI operations discovered from the installed version. Use direct YAML editing only when the current authoritative sources show it is necessary or the supported interface cannot express the change.\n\nAn explicit request to apply authorizes only a narrow, non-destructive edit in the requested canonical scope whose target and intent are unambiguous. Before any broad change, `global`-scope change, routing change, provider-default change, bundle-source change, destructive change, or similarly high-blast-radius edit:\n\n1. Show the exact target.\n2. Show a redacted proposed diff.\n3. Explain blast radius and session\u002Frestart implications.\n4. Provide a rollback procedure.\n5. Obtain explicit confirmation.\n\nIf the requested behavior can be achieved at a narrower scope, prefer that scope and explain the trade-off.\n\n### Apply\n\nWhen authorized:\n\n- Re-read every target immediately before editing to detect concurrent or intervening changes.\n- Use a supported command from the installed CLI whenever it can express the change safely; do not create a secret-bearing backup merely because a supported command may update a settings file.\n- Use direct file editing only when current authoritative evidence shows it is necessary. Make a minimal diff and preserve comments, formatting where practical, ordering that carries meaning, and unrelated user changes.\n- When rollback genuinely requires a backup, create one privately beside the target, preserve or tighten the target's permissions, and report only its path. Never print, diff, log, or delegate the backup's contents, and do not make unnecessary extra copies of files that may contain secrets.\n- Write a direct edit to a private temporary file beside the target, preserve the target's ownership and permissions (or tighten permissions when needed), then atomically replace the target. Clean up temporary artifacts on failure.\n- Never edit managed caches, site-packages, generated installations, or editable-install cache contents. Use supported source-override mechanisms and work from a real checkout when source changes are needed.\n- Never broaden scope merely to make an edit easier.\n\n### Verify\n\nParsing or schema validation is necessary when available but is never sufficient. Verify the requested outcome:\n\n- Re-inspect effective configuration and provenance after the change.\n- Exercise the affected root-session behavior in an appropriate fresh session when the session boundary requires it.\n- For routing changes, test with a fresh spawned session and capture which configured provider\u002Fmodel was actually selected.\n- For bundle, source, or skill changes, confirm discovery and effective mounting rather than only checking that a file exists.\n- Explain what takes effect immediately, what is limited to the current conversation, and what requires a new session, reload, remount, or process restart according to current authoritative evidence.\n- Report actual commands\u002Factions and redacted results. Do not claim success from a configuration parse alone.\n\nIf outcome verification cannot be completed, stop and state exactly what remains unverified and what evidence would close the gap.\n\n## Output contract\n\nFor substantive inspection, troubleshooting, planning, or mutation work, use all seven fields below and omit none. A concise conceptual answer that does not inspect state, propose a change, or perform work may answer directly without this template.\n\n1. **Desired behavior** — a testable restatement.\n2. **Affected planes** — one or more classified planes.\n3. **Effective-value provenance trace** — observed value, contributing declaration(s), resolved source\u002Fversion, and runtime\u002Fsession state; redact secrets.\n4. **Proposed changes** or **Applied changes** — exact targets and minimal redacted diff or a clear `none` for explanation-only work.\n5. **Validation evidence** — effective-config inspection plus observed runtime outcome where applicable.\n6. **Uncertainties** — conflicts, unavailable authorities, or unverified behavior; use `none` only when supported by evidence.\n7. **Rollback** — exact safe reversal for applied or proposed mutations; use `not applicable` for explanation-only work.\n\nCite current source locations or owning components in the explanation, but do not encode those discovered paths as permanent universal rules.\n\n## Compact example: `primary`, `coding`, and `fast`\n\nSuppose three entries all use `provider-example`, with neutral model names `example-model-primary`, `example-model-coding`, and `example-model-fast`.\n\n- Give each provider instance a unique explicit ID such as `primary`, `coding`, and `fast`; repeated instances cannot be safely distinguished by the shared module name alone.\n- Root\u002Fmain-session default selection belongs to provider priority, explicit launch selection, or session pinning policy as supported by the installed version—not to the spawned-session routing matrix.\n- Spawned role mapping should target explicit configured provider IDs when the current routing semantics require instance selection.\n- Never infer a provider instance from a model-name suffix. Similar strings are not evidence of a routing relationship.\n\nBefore recommending syntax or changing this setup, verify the exact current rules with `app-cli:cli-expert` and the installed routing source, then inspect the effective configuration and prove the root and spawned outcomes separately.\n","# Amplifier CLI Configuration Consultant\n\nTranslate desired Amplifier CLI behavior into the smallest correct configuration change. This skill owns the CLI-facing workflow. Portable bundle, routing, skill, and provider systems are dependencies to consult through their owning documentation and implementation, not domains this skill independently defines. Work from the current installation and effective CLI configuration, not remembered defaults or frozen examples.\n\n## Request\n\n$ARGUMENTS\n\nTreat `$ARGUMENTS` as the explicit request when present and use the current conversation for relevant context. If the desired behavior, scope, or permission to edit is unclear, ask one focused question before proceeding.\n\nIn an interactive CLI session, invoke this skill with `\u002Famplifier-config \u003Crequest>`. In headless use, send a natural-language request that identifies the skill or explicitly call `load_skill` with `skill_name: amplifier-config` and pass the request as `arguments`. Do not assume a slash command embedded in a headless prompt will be dispatched as an interactive command.\n\n## Operational contract\n\n### 1. Classify the configuration plane\n\nBefore recommending anything, identify every affected plane and keep them distinct:\n\n1. **Current\u002Fmain-session provider selection** — which configured provider instance and model answer the root conversation, including launch selection, configured defaults, and session pinning.\n2. **Spawned\u002Fdelegated routing** — how sub-agents, delegated sessions, recipe steps, and other spawned work select providers or models through roles and preferences.\n3. **CLI bundle composition** — which portable providers, tools, hooks, agents, behaviors, context, modes, and skills the CLI composes and mounts.\n4. **Persisted scope, precedence, and source overrides** — the canonical `global`, `project`, and `local` settings scopes; composition provenance; and source replacement of installed modules or bundles.\n5. **Runtime session state** — temporary selection or pinning in the active CLI session, kept separate from persisted `global`, `project`, and `local` settings.\n6. **CLI skill discovery** — where the CLI discovers a skill from, which same-named skill wins, and whether it is available in the active session.\n7. **Provider-module-specific fields** — settings consumed by a portable provider module composed into the CLI, whose meaning and supported values belong to that resolved module and version.\n\nA request may cross planes. Name those crossings explicitly rather than treating Amplifier configuration as one flat YAML document.\n\n### 2. Establish current authoritative semantics\n\nNever rely on memory for exact commands, paths, schemas, precedence, or version-sensitive behavior.\n\n- **CLI, session, command, provider-pinning, and spawn-precedence questions:** delegate to `app-cli:cli-expert`. Ask it about the installed version and use its version-matched evidence. If it is unavailable, report that limitation and inspect the installed CLI help and owned documentation; do not silently substitute remembered behavior.\n- **Portable bundle composition or internals:** consult the owning foundation or bundle documentation and any available specialist for the resolved installed source\u002Fversion; this skill only explains how the CLI composes the result.\n- **Portable routing:** inspect the active CLI routing configuration, installed routing documentation, and the routing implementation that owns the current semantics. Do not assume a matrix format from an old example.\n- **Portable provider-specific keys:** resolve the provider module the CLI actually uses, then inspect that version's documentation, schema, validation code, or source. Do not transfer fields between provider modules merely because their names sound similar.\n\nRecord which source supports each consequential claim. If sources conflict or current evidence is incomplete, surface the uncertainty instead of inventing a rule.\n\n### 3. Inspect before editing\n\nInspect the effective configuration and provenance before proposing or applying a change:\n\n- Determine the active bundle\u002Fsession context and the effective mounted items.\n- Trace each relevant effective value back through its contributing declarations and resolved source\u002Fversion.\n- Distinguish saved configuration from runtime or session-only state.\n- Identify same-named or repeated provider, bundle, skill, and source entries that could affect resolution.\n- Redact API keys, tokens, credentials, cookies, authorization headers, and other secret values in all output, diffs, logs, and delegated prompts.\n- Preserve literal `${ENV_VAR}` references. Never resolve, print, replace, or quote their secret runtime values.\n\nDo not edit based only on a plausible source file; first prove that the file contributes to the observed effective value.\n\n### 4. Preserve the stable conceptual boundary\n\nThe root\u002Fmain session's provider selection and spawned-session routing are separate configuration planes. A routing matrix for spawned work must not be presented as the mechanism that necessarily selects the model answering the current root conversation.\n\nThis distinction is stable; its exact commands, supported selectors, precedence details, session boundaries, and orchestration behavior are version-sensitive. Verify those details for the installed version with `app-cli:cli-expert` and the owning routing source before acting.\n\n## Workflow\n\nFollow this sequence and do not skip directly to editing.\n\n### Orient\n\nRestate the desired behavior in testable terms. Classify the affected planes, intended persisted scope (`global`, `project`, or `local`), any separate runtime-session effect, and whether the user asked only for an explanation or explicitly asked to apply a change.\n\n### Inspect\n\nGather current, authoritative evidence from effective configuration, provenance, installed source versions, and the domain owners described above. Redact secrets immediately.\n\n### Explain\n\nExplain what currently controls the behavior, why the observed result occurs, and where any proposed change belongs. **An explanation or troubleshooting request never authorizes mutation.**\n\n### Plan\n\nPropose the smallest supported change. Prefer supported CLI operations discovered from the installed version. Use direct YAML editing only when the current authoritative sources show it is necessary or the supported interface cannot express the change.\n\nAn explicit request to apply authorizes only a narrow, non-destructive edit in the requested canonical scope whose target and intent are unambiguous. Before any broad change, `global`-scope change, routing change, provider-default change, bundle-source change, destructive change, or similarly high-blast-radius edit:\n\n1. Show the exact target.\n2. Show a redacted proposed diff.\n3. Explain blast radius and session\u002Frestart implications.\n4. Provide a rollback procedure.\n5. Obtain explicit confirmation.\n\nIf the requested behavior can be achieved at a narrower scope, prefer that scope and explain the trade-off.\n\n### Apply\n\nWhen authorized:\n\n- Re-read every target immediately before editing to detect concurrent or intervening changes.\n- Use a supported command from the installed CLI whenever it can express the change safely; do not create a secret-bearing backup merely because a supported command may update a settings file.\n- Use direct file editing only when current authoritative evidence shows it is necessary. Make a minimal diff and preserve comments, formatting where practical, ordering that carries meaning, and unrelated user changes.\n- When rollback genuinely requires a backup, create one privately beside the target, preserve or tighten the target's permissions, and report only its path. Never print, diff, log, or delegate the backup's contents, and do not make unnecessary extra copies of files that may contain secrets.\n- Write a direct edit to a private temporary file beside the target, preserve the target's ownership and permissions (or tighten permissions when needed), then atomically replace the target. Clean up temporary artifacts on failure.\n- Never edit managed caches, site-packages, generated installations, or editable-install cache contents. Use supported source-override mechanisms and work from a real checkout when source changes are needed.\n- Never broaden scope merely to make an edit easier.\n\n### Verify\n\nParsing or schema validation is necessary when available but is never sufficient. Verify the requested outcome:\n\n- Re-inspect effective configuration and provenance after the change.\n- Exercise the affected root-session behavior in an appropriate fresh session when the session boundary requires it.\n- For routing changes, test with a fresh spawned session and capture which configured provider\u002Fmodel was actually selected.\n- For bundle, source, or skill changes, confirm discovery and effective mounting rather than only checking that a file exists.\n- Explain what takes effect immediately, what is limited to the current conversation, and what requires a new session, reload, remount, or process restart according to current authoritative evidence.\n- Report actual commands\u002Factions and redacted results. Do not claim success from a configuration parse alone.\n\nIf outcome verification cannot be completed, stop and state exactly what remains unverified and what evidence would close the gap.\n\n## Output contract\n\nFor substantive inspection, troubleshooting, planning, or mutation work, use all seven fields below and omit none. A concise conceptual answer that does not inspect state, propose a change, or perform work may answer directly without this template.\n\n1. **Desired behavior** — a testable restatement.\n2. **Affected planes** — one or more classified planes.\n3. **Effective-value provenance trace** — observed value, contributing declaration(s), resolved source\u002Fversion, and runtime\u002Fsession state; redact secrets.\n4. **Proposed changes** or **Applied changes** — exact targets and minimal redacted diff or a clear `none` for explanation-only work.\n5. **Validation evidence** — effective-config inspection plus observed runtime outcome where applicable.\n6. **Uncertainties** — conflicts, unavailable authorities, or unverified behavior; use `none` only when supported by evidence.\n7. **Rollback** — exact safe reversal for applied or proposed mutations; use `not applicable` for explanation-only work.\n\nCite current source locations or owning components in the explanation, but do not encode those discovered paths as permanent universal rules.\n\n## Compact example: `primary`, `coding`, and `fast`\n\nSuppose three entries all use `provider-example`, with neutral model names `example-model-primary`, `example-model-coding`, and `example-model-fast`.\n\n- Give each provider instance a unique explicit ID such as `primary`, `coding`, and `fast`; repeated instances cannot be safely distinguished by the shared module name alone.\n- Root\u002Fmain-session default selection belongs to provider priority, explicit launch selection, or session pinning policy as supported by the installed version—not to the spawned-session routing matrix.\n- Spawned role mapping should target explicit configured provider IDs when the current routing semantics require instance selection.\n- Never infer a provider instance from a model-name suffix. Similar strings are not evidence of a routing relationship.\n\nBefore recommending syntax or changing this setup, verify the exact current rules with `app-cli:cli-expert` and the installed routing source, then inspect the effective configuration and prove the root and spawned outcomes separately.\n",{"name":5,"license":15,"version":31,"description":7,"user-invocable":32},"0.1.0",true,"main","631c4bdbcf3dcd2da20456ad6ccef386e778c101","amplifier_app_cli\u002Fdata\u002Fskills\u002Famplifier-config",28,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 01:45:24",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":32},[44,47,50],{"tool":45,"command":46},"npx","npx skills add microsoft\u002Famplifier-app-cli --skill amplifier-config",{"tool":48,"command":49},"bunx","bunx skills add microsoft\u002Famplifier-app-cli --skill amplifier-config",{"tool":51,"command":52},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-app-cli --skill amplifier-config","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Famplifier-config\u002FSKILL.md",[],[56,70,78,88],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":26},"01M69BJ9BX3FSEPSFADNZFTZBA","ten-lane-highway","Become the Highway Manager: drive many parallel \u002Fgoal lanes continuously toward a defined outcome, refilling lanes on every manager cycle so none sit idle. Use when the user wants continuous parallel throughput toward an outcome: \"run the highway\", \"\u002Fhighway\", \"10-lane highway\", \"keep N lanes full\", \"keep re-feeding lanes as they drain\", \"drive this for me in parallel\", \"do them all and monitor\", \"keep the lanes full\", \"work the whole list in parallel until done\". NOT for a one-shot batch that launches once and drains together — use goal-batch. NOT for bounded edits that each end in their own PR — use mass-change. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002FSKILL.md",[],[63,64,65,66,67,68,24,69,21],"ten lane highway","goalify","git","run","monitor","pr","tmux",{"skillNo":71,"name":64,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":26},"01M69BJ71F38DR2QASW4HZ8K2Q","Compose and lint a \u002Fgoal stop-condition from the current conversation, catching known termination-failure patterns before showing it to the user. Use when the user wants to turn the current task into a \u002Fgoal loop, asks to \"goalify this\", wants a stop condition for autonomous work, says \"write a goal condition\", \"make this a \u002Fgoal\", \"turn this into a goal\", or asks for help wording a condition for \u002Fgoal.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002FSKILL.md",[],[64,76,77],"help","lint",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":26},"01M69BJ51WJSADYHSFYAGMNDK3","goal-batch","Batch independent work into isolated \u002Fgoal lanes. Triggers: \"run these in parallel\", \"goal-batch\", \"launch lanes for these\", \"work these N tasks simultaneously\", \"batch these as goals\". Show the plan; require explicit user approval before launch; verify results before landing. Not for bounded per-PR edits (mass-change) or continuous refill-on-drain work (ten-lane-highway).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoal-batch\u002FSKILL.md",[],[85,66,86,68,24,87],"goal batch","tasks","launch",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":26},"01M69BJ3GMC0R27M16QKP33XYZ","doctor","Diagnose an Amplifier CLI environment through the CLI doctor agent. USE WHEN a user requests CLI runtime, settings or missing-capability inspection. DO NOT USE for project bugs or other hosts.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fdoctor\u002FSKILL.md",[],[90,21,95],"diagnose"]