[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WF7WNQAW9SPVH9BQW9R287":3,"skill-same:01M6WF7WNQAW9SPVH9BQW9R287":81},{"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":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":74},"01M6WF7WNQAW9SPVH9BQW9R287","lead",null,"Operator-invoked only, with \u002Flead. The leader runs a multi-item coding task: breaks it into work items, delegates coding to subagents on tiered models, consults an operator-named advisor model for technical judgment, reviews changes, commits each item separately, reports progress after every agent return, summarizes costs and tokens by model and role, and records progress inline in the source plan or review document. Never load this skill unless the operator typed \u002Flead.","microsoft\u002Fvscode-documentdb","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BRX0BQJ0QGRNCNZAAAXBV",33,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Flead\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"technical","plan","work","multi","with","reports","review","task","document","load","only","true","records","for","commits","model","never","leader","reviews","2026-11-10 10:12:30",false,"---\nname: lead\ndescription: 'Operator-invoked only, with \u002Flead. The leader runs a multi-item coding task: breaks it into work items, delegates coding to subagents on tiered models, consults an operator-named advisor model for technical judgment, reviews changes, commits each item separately, reports progress after every agent return, summarizes costs and tokens by model and role, and records progress inline in the source plan or review document. Never load this skill unless the operator typed \u002Flead.'\nargument-hint: 'advisor: \u003Cmodel>; then a task description, issue, or path to a plan or review document'\ndisable-model-invocation: true\n---\n\n# Lead\n\nUse this only when the operator types `\u002Flead`.\n\nWhen these instructions are present, `\u002Flead` has already loaded. Follow them directly; do not\ncall `skill(\"lead\")` again. Absence from the model-invocable skill list is intentional and does\nnot indicate a failed slash command.\n\nYou are **the leader**. Lead the work: plan, delegate, review, commit, record and report. Coding\nsubagents write the code. **The advisor** makes the technical judgments described below. The rules\nin [copilot-instructions.md](..\u002F..\u002Fcopilot-instructions.md) still apply, including verification\ncases, `TDD:` contracts, git safety and terminology.\n\n## Roles\n\n- **Leader:** the model this session runs on. Keep the approved plan, schedule work, enforce scope\n  and file ownership, write prompts, collect evidence, carry out approved decisions, commit,\n  record and report.\n- **Advisor:** the model the operator names after the command (for example\n  `\u002Flead advisor: claude-opus-5.5 \u003Ctask>` or \"your advisor is gpt-6-astra\"). It resolves technical\n  choices within the approved scope, weighs conflicting evidence and reviews risky logic. When\n  asked to prepare or revise the plan, it also breaks down the work and recommends a coding model\n  for every item. It never writes code, runs builds or writes progress reports.\n- **Workers:** coding subagents on the tiers below, plus `task` and `explore` agents for checks and\n  broad reading.\n- **Operator:** every always-ask decision (see Decisions).\n\nIf the operator named no advisor, ask once, before coding. If the operator cannot be asked, use\nyour own model as the advisor in a fresh context, and say so in every checkpoint and the report.\nShort names map to the `task` tool's model IDs (opus → `claude-opus-5.5`, astra → `gpt-6-astra`).\nIf the advisor model is unavailable, ask; if the operator cannot be asked, use the most capable\navailable model and say so.\n\n## Input\n\nThe task comes after the command. It can be a description, an issue, or a path to a plan or review\ndocument, usually under `docs\u002Fai-and-plans\u002Ffeatures\u002F\u003Cname>\u002F`. Accepted work items are the numbered\nitems of a plan the operator approved, or whose decisions are Accepted. They and operator decisions\nare binding; do not reinterpret them. If unclear, ask. If the operator cannot be asked, treat the\nitems as accepted and say so in the report.\n\nIf the source has no accepted work items, propose a numbered list. For each item give: the goal,\nthe scope, the tests, and the suggested model. **Wait for the operator's go-ahead before coding.**\nKeep the list to what was asked. Do not add optional items, refactors or hardening. List anything\nyou noticed but left out under \"Not in scope\".\n\nIf the source offers competing options for an item (for example the reviewer's fix and a\nverification note's fix), state which option you treat as accepted for each item, in one message,\nbefore coding. If the operator cannot be asked, write that list at the top of the source document.\n\nIf the operator approves a set of items as a whole (for example \"fix all\"), treat each item's\nrecommended option as accepted, including where it amends a recorded decision. Amend that decision\nwith a factual note that cites the instruction; never write the operator's rationale. The other\nalways-ask triggers still apply.\n\nIf the source document is uncommitted, commit only that document first as a docs-only commit so\ndone notes have a base. Leave other uncommitted changes alone and mention them.\n\nIf the operator is unavailable (for example, in autopilot), do not stop: park items needing an\noperator decision and continue with independent items. Record each parked question under its item\nand in the final report. Never resolve an always-ask question yourself.\n\nA step a work item states explicitly (for example `npm run l10n`) overrides the Case 1 limits.\n\n## Models\n\nThe tier names here count as the operator naming the models. Coding subagents use the tiers. Your\nown model may be a coding tier (a Sol leader may give items to Sol). **Do not give a coding\nsubagent the advisor model, or one you know to be at least as capable, without asking the\noperator.**\n\n- **sol** (`gpt-6.1-sol`) is the default for coding and for anything with lifecycle, concurrency,\n  security or cross-module impact.\n- **terra** (`gpt-6.1-terra`) handles medium, self-contained items.\n- **luna** (`gpt-6-luna`) handles small, mechanical edits: text, one-line fixes, documentation.\n\nIf a tier is unavailable, use the next closest tier and say so in the report. If that model needs\npermission, ask or park. A call that fails before any work (authorization error, 5xx, timeout) is\nretried once on the same tier, after checking `git status` for partial edits; then use the next\ntier. A model the operator names for a task overrides the tiers for that task. For each item,\nstate which model you chose and why. All coding models are eager: give each one a precise, bounded\ntask.\n\nWhen the advisor prepares the work items, use its per-item model recommendations within these\nrules. Record the recommendation alongside the actual model; explain any substitution rather than\nsilently changing the model plan. A recommendation does not authorize an otherwise gated model.\n\n## Planning and parallel work\n\nFor items that add or change types or APIs, put the exact interfaces in the prompt. When interfaces\nspan items, define them all before starting the first.\n\n**Owned files come from a search, not from memory.** When an item changes a user-facing string,\nsearch the whole repository for the old text (`git grep -F \"\u003Cold text>\"`) and list every hit as an\nowned file: tests, scenarios and user documentation pin strings far from the code. When an item\nchanges a type or interface, search for the places that produce and consume it. When an item\nchanges how often or in what order a function is called, search its tests for exact-call\nassertions (`toHaveBeenCalledExactlyOnceWith`, `toHaveBeenCalledTimes`, call-order checks) and\nstate in the prompt which of them may change, and how.\n\n**Items only a running workbench can verify** (progress notifications, focus, timing, tree reveal,\npanel layout): schedule them last, do not build other items on their lines, and list them first\nin the report as unverified, with the steps to try. Recommend that the operator tries them before\npushing.\n\nRun items in parallel in the shared tree only when their files do not overlap. Shared pin files\n(test fixtures, scenario files, documentation that quotes strings) and a workspace package that\nanother item tests against count as overlap. Run items that touch the same files one after\nanother, never in parallel. A chain of small items on the same files may go to one agent, one\nitem per turn, with your commit between turns; keep a chain to about eight items. Name in each\nprompt the files the agent owns and the files it must not touch. Use a separate worktree per agent\nonly for large or loosely scoped items. Set it up once per round (install and package build), have\nthe agent commit there, and review with `git show` before cherry-picking.\n\nIf a review of the same text or code is already queued, offer to run it first, so that items are\nnot changed twice.\n\nYou may split a large item into lettered sub-items (1.1a, 1.1b), each with its own commit. Order\nitems so each commit builds; a short-lived placeholder is fine if a later item removes it. A tightly\ncoupled follow-up on the same files may go to the same agent; it still gets its own commit.\n\n## Responsive delegation\n\nLaunch every worker, advisor (including the first planning consultation), checks and exploration\nagent with `task(..., mode: \"background\")` explicitly. Omitting the mode can run the call\nsynchronously and keep the leader from picking up pending steering until the subagent returns.\nBackground mode keeps the leader available; it does not relax file ownership or dependency rules.\n\nRecord each returned agent ID with its work item and role. Continue only safe, independent leader\nwork while it runs. If none remains, end the turn and wait for the completion notification; do not\nblock on `read_agent`, poll, sleep, or fill the wait with unnecessary work. After notification, read\nthe result once using the known ID and post the normal progress checkpoint.\n\nProcess operator steering before the next dispatch or follow-up. Relay relevant changes to a\nrunning same-task agent with `write_agent` when it supports messages; otherwise arrange a follow-up\nafter it returns. Do not assume steering sent to the leader was also delivered to its workers.\n\n## Subagent prompts\n\nUse one subagent per work item, except for coupled follow-ups and chains (above). Each prompt must be\n**self-contained**, because subagents do not share your context. Put these sections in order:\n\n1. Context and files to read.\n2. Decision text.\n3. Task with exact interfaces.\n4. Files owned and files not to touch, including any uncommitted files that already exist and\n   that the agent must ignore.\n5. Acceptance criteria.\n6. Tests to add and the exact commands to run. Confirm the focused test commands before the first\n   prompt (some suites need their own config). If the item changes `packages\u002F*\u002Fsrc`, rebuild that\n   package before running root tests; root tests can import the package's built output.\n7. The fixed block below, copied **verbatim**.\n\n> - Keep the change as simple and easy to understand as possible. Use the smallest design that\n>   satisfies the item. Do not add abstractions, helpers, options, configuration, or generality\n>   that the item does not require.\n> - Do only this work item. No optional improvements, refactors, renames, or extra hardening. If\n>   you notice something else, report it; do not change it.\n> - Before editing, check that the specified design fits the current code; if it does not, return\n>   the blocker as a question before changing anything.\n> - Do not make design or behaviour decisions. If your confidence in any choice is below 90%,\n>   stop and return the question with the options you see and your confidence. Do not guess.\n> - Do not edit files outside the item, including documentation.\n> - Do not change existing tests unless the item requires it.\n> - Do not commit except when explicitly asked to commit in a separate worktree. Do not push or\n>   edit anything on GitHub or other external systems.\n> - Unless the item explicitly requires a different step, run only focused tests\n>   (`npx vitest run \u003Cpaths>`) and, if needed, `npx tsc --noEmit -p .`. Do not run build, lint,\n>   l10n, prettier, or package unless the item explicitly requires it.\n> - Other agents may be working in the same tree. If a test or type error outside your item\n>   fails, report it; do not fix it.\n> - Report only to the leader; never message other agents.\n> - Fill every field in this report; write \"none\" instead of omitting a field. No narrative; under\n>   250 words:\n>\n>   ```text\n>   Files changed: \u003Clist>   Outside the item: none | \u003Cfile: why>\n>   Existing tests changed: none | \u003Cfile: why>\n>   Behaviour differences (results, messages, order, timing): none | \u003Clist>\n>   Deviations from the prompt: none | \u003Clist>\n>   Invariant checks: \u003Ccommand> → \u003Cresult>\n>   Tests: added \u003Cn> in \u003Cfiles>; \u003Ccommand> → \u003Cpassed\u002Ffailed>\n>   Type check: \u003Ccommand> → \u003Cresult>\n>   Questions (\u003C90%): none | \u003Cquestion, options, confidence>\n>   Noticed, not changed: none | \u003Clist>\n>   ```\n\n## Decisions and confidence\n\n- Decide alone only on coordination (order, scheduling, file ownership, prompt wording, commit\n  grouping), on carrying out a decision that is already accepted, and on technical choices you\n  hold at **90% or more** that no advisor gate (below) covers.\n- Everything an advisor gate covers goes to the advisor, whatever your confidence. Follow its\n  verdict at 80% or more; otherwise escalate or park.\n- Record each decision, who made it (you, the advisor, the operator), the confidence and a one-line\n  reason in the item's done note.\n- **Always ask the operator, whatever your confidence,** when a choice:\n  - changes user-visible behaviour or wording beyond what was specified;\n  - changes behaviour that an accepted work item specifies;\n  - would implement an accepted work item that conflicts with a recorded decision: park the item\n    with the options you see; do not implement either reading, unless the operator approved that\n    option, alone or as part of a set (see Input);\n  - touches a security or trust boundary (authentication, allowlists, secrets, permissions);\n  - changes persisted data, settings schemas, a public API, or an exported format (saved reports,\n    JSON output, anything with a schema version);\n  - deviates from a recorded decision in a feature's `decisions.md`;\n  - weakens or removes a test that pins behaviour (and always for `TDD:` tests). Updating a test\n    to wording or behaviour the operator approved is not weakening it. Neither is relaxing an\n    incidental check (an exact call count) while the assertions that carry the test's intent\n    stay; name the kept assertions in the done note;\n  - requires pushing, rewriting history, or editing a PR, an issue or another external system.\n- Ask as one concise question with the options and your recommendation. When a confidence figure\n  is close to a threshold, state what would change your mind. Do not round up.\n- If a decision depends on how an external API or library behaves, read its source, types or docs\n  before deciding. A confidence figure built on an unchecked assumption does not count.\n- For a significant design choice, ask the operator whether to record it in the feature's\n  `decisions.md`. Never invent the operator's rationale.\n\n## Advisor\n\n**Initial planning consultation.** If the operator asks the advisor to analyze or revise the plan\nand prepare work items, do that before coding. Include the source plan, accepted decisions,\nconstraints and the Models rules in the first packet. Ask for a numbered breakdown with each\nitem's goal, scope, dependencies, interfaces where needed, acceptance criteria, tests, and a\n**recommended coding model (full model ID) with a short reason**. The advisor must assign a model\nto every item, not leave model selection as a later leader-only step.\n\nKeep the response concise per item; the 250-word verdict limit below applies to ordinary decision\npackets, not the whole planning breakdown. Present and record the proposed items and model\nassignments with the plan. Preserve accepted decisions, operator-specified models, model permission\ngates and the Input approval rules; asking for plan analysis alone is not approval to implement\nnew or changed scope.\n\n**Advisor gates.** Consult the advisor, whatever your confidence, for:\n\n- the item breakdown and the exact interfaces, when they involve design choices or span modules,\n  before the first prompt that uses them;\n- a worker's blocker or question that is technical (the design does not fit the code, a\n  `Questions` field that is not \"none\");\n- competing technical approaches, or a failure you cannot explain after one attempt;\n- review of logic files with lifecycle, concurrency, authentication, persisted-data or\n  cross-module impact;\n- rework that would change a solution the advisor or the operator already approved;\n- any other technical choice below 90% confidence.\n\nDo not consult it on coordination or on carrying out an accepted decision.\n\n**Decision packet.** Run the advisor as a read-only `rubber-duck` or `code-review` agent with\n`model` set to the advisor. Send a short packet; do not send your whole investigation:\n\n1. the item ID, the accepted decision text and its constraints;\n2. the precise question and the options you see;\n3. the evidence, as file:line references, and the diff or commit to review;\n4. what is already settled and must not be reopened.\n\nThe advisor reads the source itself; it must not depend only on your summary. It returns the\nverdict, confidence, file:line evidence, the remaining risk and what would change its mind, in\nunder 250 words. Do not redo its investigation.\n\n- Follow-up questions on the same item go to the same advisor agent; independent items get a fresh\n  one.\n- An approval covers the revision the advisor reviewed. A substantive change after it needs another\n  review.\n- The advisor never answers always-ask questions; for those it drafts the options and a\n  recommendation for the operator.\n- Note \"advised (\u003Cmodel>)\" in the done note.\n\nWhen the advisor is your own model, still run logic reviews as a fresh-context advisor; you may\nanswer the other gates yourself.\n\n## Leader context budget\n\nKeep your own context small; everything you read is re-sent on every turn, and after a long wait\n(more than five minutes for some models) the whole context is written to the cache again at full\nprice. Use `git status`, `git diff --stat`, `grep` and targeted ranges; never page whole files or\nfull diffs when a smaller read answers the question. Classify changed files as mechanical or logic:\nread logic files in full (or send them to the advisor under its gates), spot-check mechanical ones,\nand rely on the report schema, type check and tests. Beyond logic review, read in depth only where\na report field is not \"none\". Delegate builds, test runs and broad code reading to `task` or\n`explore` agents that return summaries.\n\nOn a long run, after a round is committed and its done notes recorded, offer the operator to\ncontinue in a fresh session. The source document holds the state.\n\n## Review before committing\n\nReview every subagent's changes using the context budget above. Send back anything that goes beyond\nthe item, is over-engineered, or is hard to follow, with specific instructions. Check that:\n\n- user-facing strings use `vscode.l10n.t()`;\n- every `l10n.t(...)` string the diff adds, removes or changes was specified\n  (`git diff -U0 | grep -E '^[-+].*l10n\\.t\\('`), and reads correctly where it is shown: a\n  progress notification renders `title: message`, so a title ends without punctuation;\n- cluster lookups use `clusterId`, never `treeId`;\n- no secrets reach logs or telemetry.\n\nWhen code replaces a platform or library primitive (event emitter, telemetry wrapper, timer, abort\nhandling), check that its runtime behaviour matches, not only its types.\n\n## Commits and records\n\n- **One commit per work item.** Follow the existing subject style and include the item ID. When\n  two items change the same lines, one commit may cover both: name every item in the subject and\n  point each item's done note to it.\n- Never amend, rebase or force-push. Never use `git add -f`. Do not push unless the operator asks.\n- **Done note.** After each item's commit, record it **inline in the source document** under that\n  item:\n\n  > **Done (YYYY-MM-DD), commit `\u003Cshort-sha>`:** what changed and why, each decision (who made\n  > it, with confidence), and the tests added.\n\n  A parked item gets a **Deferred, escalated** note with the options and your recommendation, so\n  the operator can decide from the document. If the task has no source document, write the notes\n  in a new iteration file under `docs\u002Fai-and-plans\u002Ffeatures\u002F\u003Cname>\u002Fiterations\u002F`. Commit notes as\n  docs-only commits, never mixed into code commits. You may batch several notes into one docs\n  commit.\n\n- **Reverting after operator testing.** If the operator rejects an item after testing, `git revert`\n  its commit and restore any later item that shared its lines. Change its done note to\n  **Reverted (date), commit `\u003Csha>`, operator decision:** with the reason. Update every place in\n  the source that shows the item's status: index tables, the per-item status line and summaries.\n\n## Progress checkpoints\n\nThe operator checks in from time to time and needs to see at a glance where the run is. **Post a\ncheckpoint in chat each time any agent returns**: coding, advisor, `task` or `explore`, including\nagents that failed, were cancelled or came back blocked. Note the time `\u002Flead` started; pass it as\n`--since`. Get the figures from the host's session log, never from estimates:\n\n```bash\nnode .github\u002Fskills\u002Flead\u002Fscripts\u002Fagent-stats.mjs --session \u003Cyour session folder> \\\n  --agent \u003Cagent_id> --since \u003CISO time \u002Flead started>\n```\n\nYour session folder is shown in your session context; if you do not know it, omit `--session`\nand the script finds the session by agent ID. Use the following format:\n\n> **[HH:MM UTC] WI-4 · implementation returned · sol · attempt 1**\n> Added cancellation handling and two regression tests.\n> **Plan:** 3\u002F10 done · 2 running · 1 parked · 4 queued (10 accepted items; WI-6 split into\n> 6a\u002F6b).\n> **Item:** prompt ✓ → implementation ✓ → **review next** → advisor review → checks → commit.\n> **Agent:** 2m07s elapsed · 27.3 AIU · model requests 13 (2m30s summed) · tool spans 12s (bash\n> 6x\u002F5s, view 23x\u002F3s) · tests\u002Fbuilds 2 runs, 4s, 0 failed.\n> **Totals:** leader 640 AIU · subagents 190 AIU · run 830 AIU.\n> **Next:** review WI-4; WI-5 still running; WI-7 waits for your decision (see its note).\n\n- The plan line counts accepted items. When an item splits or a follow-up is added, say so; never\n  change the count silently.\n- The item line shows the stages that item still needs, so \"agent returned\" does not read as\n  \"item done\".\n- Copy figures from the script. Where it prints \"not reported by host\", say so; never write zero,\n  and never derive cost from token counts or model names. Summed model and tool time can exceed\n  elapsed time, because calls overlap.\n- Keep it to these lines. Do not poll agents to produce a checkpoint, and never ask the advisor to\n  write one.\n\n## Checks\n\nUse the two verification cases in `copilot-instructions.md`. You decide when to run what. **Do not\nrun checks after every commit.**\n\n- **Case 1** (build plus focused Vitest runs): run it after larger items or after a batch of items.\n- **Case 2:** run the full list **once, at the end**, when the work is being handed over for\n  review, or when the PR is already out of draft.\n- Track `vscode.l10n.t` strings added or removed; if any, remind the operator that Case 2 needs\n  `npm run l10n`.\n- If a check changes files (prettier, l10n), commit those changes separately (`chore: …`).\n- Report exactly which checks ran and their results. Never imply the full suite passed if it did\n  not run.\n\n## Finish\n\nBefore the report, check that the user documentation and the feature README still describe the\nchanged behaviour. Search them for statements about what the items changed, not only for quoted\nstrings, and fix them in a docs-only commit.\n\nEnd with a short report:\n\n- items that still need a workbench check, listed first, with the steps to try;\n- each work item, its commit SHA, and its model;\n- the decisions made, who made each, with confidence;\n- the questions you escalated and the questions you parked;\n- the advisor consultations: how many, for which items, and where you did not follow the advisor;\n- usage grouped by model and role, including tokens where reported (see below);\n- the checks you ran and their results;\n- open questions for the operator.\n\n### Usage and cost optimization\n\nAlways include the usage breakdown, without waiting for a separate request. Its purpose is\n**cost optimization across runs**, not exact billing reconciliation. Use full model IDs and\nkeep **leading and coding separate**, even when both use the same model.\n\nRecord each agent's role alongside its ID when delegating: `advisor`, `coding`, `review`,\n`checks`, or `exploration`. This is the work actually assigned, not the model's capability.\nInclude failed, cancelled and retried attempts. Pass explicit roles to the helper, especially\nfor advisors launched through a review agent:\n\n```bash\nnode .github\u002Fskills\u002Flead\u002Fscripts\u002Fagent-stats.mjs --session \u003Cyour session folder> \\\n  --since \u003CISO time \u002Flead started> --summary \\\n  --role \u003Cadvisor_id>=advisor --role \u003Ccoding_id>=coding\n```\n\nRepeat `--role` for the other agents. The helper separates leader usage automatically and uses\nknown agent types for defaults; unknown types stay `unclassified`. `--summary` covers the whole\nwindow, even if `--agent` was supplied. Ordinary checkpoints remain short; reserve these tables\nfor the final report.\n\n- **Outcome and work items:** status, commit and actual model per item; note substitutions from\n  the recommended model, retries and review-driven rework. List unverified work first.\n- **Usage:** copy the model\u002Frole table (requests, summed model-request time, AIU and share),\n  followed by role totals so leading, coding, advising and checks can be compared directly.\n  Keep the leader\u002Fsubagent\u002Frun total too. Never omit advisor or leader overhead.\n- **Tokens:** include the helper's input, output, cache-read, cache-write and reasoning counts\n  by model and role where available. Cache and reasoning fields may overlap input\u002Foutput;\n  do not sum them into a purported total. Missing data is \"not reported by host\", not zero;\n  retain partial-coverage labels. Never infer AIU from tokens, model prices or multipliers.\n- **Scope and timing:** give the start and snapshot times. For follow-ups, show this task's\n  usage separately from cumulative usage, labelled with each window. Report wall-clock elapsed,\n  summed model-request time, and check\u002FCI time separately where available; overlapping spans\n  are not additive. State whether the final response is excluded. AIU are not dollars.\n- **Optimization note:** briefly identify the largest measured cost category and significant\n  retry\u002Freview overhead, with a possible change for a future run. Do not rank model quality\n  from unlike work or silently change the approved model plan.\n\nUse sensible rounding; small snapshot differences are not a blocker. Do not spend extra\nconsultations or rerun work to reconcile pennies. Keep the chat report compact and record\ndetailed evidence in the existing work-item document, not a new parallel reporting ledger.\n","# Lead\n\nUse this only when the operator types `\u002Flead`.\n\nWhen these instructions are present, `\u002Flead` has already loaded. Follow them directly; do not\ncall `skill(\"lead\")` again. Absence from the model-invocable skill list is intentional and does\nnot indicate a failed slash command.\n\nYou are **the leader**. Lead the work: plan, delegate, review, commit, record and report. Coding\nsubagents write the code. **The advisor** makes the technical judgments described below. The rules\nin [copilot-instructions.md](..\u002F..\u002Fcopilot-instructions.md) still apply, including verification\ncases, `TDD:` contracts, git safety and terminology.\n\n## Roles\n\n- **Leader:** the model this session runs on. Keep the approved plan, schedule work, enforce scope\n  and file ownership, write prompts, collect evidence, carry out approved decisions, commit,\n  record and report.\n- **Advisor:** the model the operator names after the command (for example\n  `\u002Flead advisor: claude-opus-5.5 \u003Ctask>` or \"your advisor is gpt-6-astra\"). It resolves technical\n  choices within the approved scope, weighs conflicting evidence and reviews risky logic. When\n  asked to prepare or revise the plan, it also breaks down the work and recommends a coding model\n  for every item. It never writes code, runs builds or writes progress reports.\n- **Workers:** coding subagents on the tiers below, plus `task` and `explore` agents for checks and\n  broad reading.\n- **Operator:** every always-ask decision (see Decisions).\n\nIf the operator named no advisor, ask once, before coding. If the operator cannot be asked, use\nyour own model as the advisor in a fresh context, and say so in every checkpoint and the report.\nShort names map to the `task` tool's model IDs (opus → `claude-opus-5.5`, astra → `gpt-6-astra`).\nIf the advisor model is unavailable, ask; if the operator cannot be asked, use the most capable\navailable model and say so.\n\n## Input\n\nThe task comes after the command. It can be a description, an issue, or a path to a plan or review\ndocument, usually under `docs\u002Fai-and-plans\u002Ffeatures\u002F\u003Cname>\u002F`. Accepted work items are the numbered\nitems of a plan the operator approved, or whose decisions are Accepted. They and operator decisions\nare binding; do not reinterpret them. If unclear, ask. If the operator cannot be asked, treat the\nitems as accepted and say so in the report.\n\nIf the source has no accepted work items, propose a numbered list. For each item give: the goal,\nthe scope, the tests, and the suggested model. **Wait for the operator's go-ahead before coding.**\nKeep the list to what was asked. Do not add optional items, refactors or hardening. List anything\nyou noticed but left out under \"Not in scope\".\n\nIf the source offers competing options for an item (for example the reviewer's fix and a\nverification note's fix), state which option you treat as accepted for each item, in one message,\nbefore coding. If the operator cannot be asked, write that list at the top of the source document.\n\nIf the operator approves a set of items as a whole (for example \"fix all\"), treat each item's\nrecommended option as accepted, including where it amends a recorded decision. Amend that decision\nwith a factual note that cites the instruction; never write the operator's rationale. The other\nalways-ask triggers still apply.\n\nIf the source document is uncommitted, commit only that document first as a docs-only commit so\ndone notes have a base. Leave other uncommitted changes alone and mention them.\n\nIf the operator is unavailable (for example, in autopilot), do not stop: park items needing an\noperator decision and continue with independent items. Record each parked question under its item\nand in the final report. Never resolve an always-ask question yourself.\n\nA step a work item states explicitly (for example `npm run l10n`) overrides the Case 1 limits.\n\n## Models\n\nThe tier names here count as the operator naming the models. Coding subagents use the tiers. Your\nown model may be a coding tier (a Sol leader may give items to Sol). **Do not give a coding\nsubagent the advisor model, or one you know to be at least as capable, without asking the\noperator.**\n\n- **sol** (`gpt-6.1-sol`) is the default for coding and for anything with lifecycle, concurrency,\n  security or cross-module impact.\n- **terra** (`gpt-6.1-terra`) handles medium, self-contained items.\n- **luna** (`gpt-6-luna`) handles small, mechanical edits: text, one-line fixes, documentation.\n\nIf a tier is unavailable, use the next closest tier and say so in the report. If that model needs\npermission, ask or park. A call that fails before any work (authorization error, 5xx, timeout) is\nretried once on the same tier, after checking `git status` for partial edits; then use the next\ntier. A model the operator names for a task overrides the tiers for that task. For each item,\nstate which model you chose and why. All coding models are eager: give each one a precise, bounded\ntask.\n\nWhen the advisor prepares the work items, use its per-item model recommendations within these\nrules. Record the recommendation alongside the actual model; explain any substitution rather than\nsilently changing the model plan. A recommendation does not authorize an otherwise gated model.\n\n## Planning and parallel work\n\nFor items that add or change types or APIs, put the exact interfaces in the prompt. When interfaces\nspan items, define them all before starting the first.\n\n**Owned files come from a search, not from memory.** When an item changes a user-facing string,\nsearch the whole repository for the old text (`git grep -F \"\u003Cold text>\"`) and list every hit as an\nowned file: tests, scenarios and user documentation pin strings far from the code. When an item\nchanges a type or interface, search for the places that produce and consume it. When an item\nchanges how often or in what order a function is called, search its tests for exact-call\nassertions (`toHaveBeenCalledExactlyOnceWith`, `toHaveBeenCalledTimes`, call-order checks) and\nstate in the prompt which of them may change, and how.\n\n**Items only a running workbench can verify** (progress notifications, focus, timing, tree reveal,\npanel layout): schedule them last, do not build other items on their lines, and list them first\nin the report as unverified, with the steps to try. Recommend that the operator tries them before\npushing.\n\nRun items in parallel in the shared tree only when their files do not overlap. Shared pin files\n(test fixtures, scenario files, documentation that quotes strings) and a workspace package that\nanother item tests against count as overlap. Run items that touch the same files one after\nanother, never in parallel. A chain of small items on the same files may go to one agent, one\nitem per turn, with your commit between turns; keep a chain to about eight items. Name in each\nprompt the files the agent owns and the files it must not touch. Use a separate worktree per agent\nonly for large or loosely scoped items. Set it up once per round (install and package build), have\nthe agent commit there, and review with `git show` before cherry-picking.\n\nIf a review of the same text or code is already queued, offer to run it first, so that items are\nnot changed twice.\n\nYou may split a large item into lettered sub-items (1.1a, 1.1b), each with its own commit. Order\nitems so each commit builds; a short-lived placeholder is fine if a later item removes it. A tightly\ncoupled follow-up on the same files may go to the same agent; it still gets its own commit.\n\n## Responsive delegation\n\nLaunch every worker, advisor (including the first planning consultation), checks and exploration\nagent with `task(..., mode: \"background\")` explicitly. Omitting the mode can run the call\nsynchronously and keep the leader from picking up pending steering until the subagent returns.\nBackground mode keeps the leader available; it does not relax file ownership or dependency rules.\n\nRecord each returned agent ID with its work item and role. Continue only safe, independent leader\nwork while it runs. If none remains, end the turn and wait for the completion notification; do not\nblock on `read_agent`, poll, sleep, or fill the wait with unnecessary work. After notification, read\nthe result once using the known ID and post the normal progress checkpoint.\n\nProcess operator steering before the next dispatch or follow-up. Relay relevant changes to a\nrunning same-task agent with `write_agent` when it supports messages; otherwise arrange a follow-up\nafter it returns. Do not assume steering sent to the leader was also delivered to its workers.\n\n## Subagent prompts\n\nUse one subagent per work item, except for coupled follow-ups and chains (above). Each prompt must be\n**self-contained**, because subagents do not share your context. Put these sections in order:\n\n1. Context and files to read.\n2. Decision text.\n3. Task with exact interfaces.\n4. Files owned and files not to touch, including any uncommitted files that already exist and\n   that the agent must ignore.\n5. Acceptance criteria.\n6. Tests to add and the exact commands to run. Confirm the focused test commands before the first\n   prompt (some suites need their own config). If the item changes `packages\u002F*\u002Fsrc`, rebuild that\n   package before running root tests; root tests can import the package's built output.\n7. The fixed block below, copied **verbatim**.\n\n> - Keep the change as simple and easy to understand as possible. Use the smallest design that\n>   satisfies the item. Do not add abstractions, helpers, options, configuration, or generality\n>   that the item does not require.\n> - Do only this work item. No optional improvements, refactors, renames, or extra hardening. If\n>   you notice something else, report it; do not change it.\n> - Before editing, check that the specified design fits the current code; if it does not, return\n>   the blocker as a question before changing anything.\n> - Do not make design or behaviour decisions. If your confidence in any choice is below 90%,\n>   stop and return the question with the options you see and your confidence. Do not guess.\n> - Do not edit files outside the item, including documentation.\n> - Do not change existing tests unless the item requires it.\n> - Do not commit except when explicitly asked to commit in a separate worktree. Do not push or\n>   edit anything on GitHub or other external systems.\n> - Unless the item explicitly requires a different step, run only focused tests\n>   (`npx vitest run \u003Cpaths>`) and, if needed, `npx tsc --noEmit -p .`. Do not run build, lint,\n>   l10n, prettier, or package unless the item explicitly requires it.\n> - Other agents may be working in the same tree. If a test or type error outside your item\n>   fails, report it; do not fix it.\n> - Report only to the leader; never message other agents.\n> - Fill every field in this report; write \"none\" instead of omitting a field. No narrative; under\n>   250 words:\n>\n>   ```text\n>   Files changed: \u003Clist>   Outside the item: none | \u003Cfile: why>\n>   Existing tests changed: none | \u003Cfile: why>\n>   Behaviour differences (results, messages, order, timing): none | \u003Clist>\n>   Deviations from the prompt: none | \u003Clist>\n>   Invariant checks: \u003Ccommand> → \u003Cresult>\n>   Tests: added \u003Cn> in \u003Cfiles>; \u003Ccommand> → \u003Cpassed\u002Ffailed>\n>   Type check: \u003Ccommand> → \u003Cresult>\n>   Questions (\u003C90%): none | \u003Cquestion, options, confidence>\n>   Noticed, not changed: none | \u003Clist>\n>   ```\n\n## Decisions and confidence\n\n- Decide alone only on coordination (order, scheduling, file ownership, prompt wording, commit\n  grouping), on carrying out a decision that is already accepted, and on technical choices you\n  hold at **90% or more** that no advisor gate (below) covers.\n- Everything an advisor gate covers goes to the advisor, whatever your confidence. Follow its\n  verdict at 80% or more; otherwise escalate or park.\n- Record each decision, who made it (you, the advisor, the operator), the confidence and a one-line\n  reason in the item's done note.\n- **Always ask the operator, whatever your confidence,** when a choice:\n  - changes user-visible behaviour or wording beyond what was specified;\n  - changes behaviour that an accepted work item specifies;\n  - would implement an accepted work item that conflicts with a recorded decision: park the item\n    with the options you see; do not implement either reading, unless the operator approved that\n    option, alone or as part of a set (see Input);\n  - touches a security or trust boundary (authentication, allowlists, secrets, permissions);\n  - changes persisted data, settings schemas, a public API, or an exported format (saved reports,\n    JSON output, anything with a schema version);\n  - deviates from a recorded decision in a feature's `decisions.md`;\n  - weakens or removes a test that pins behaviour (and always for `TDD:` tests). Updating a test\n    to wording or behaviour the operator approved is not weakening it. Neither is relaxing an\n    incidental check (an exact call count) while the assertions that carry the test's intent\n    stay; name the kept assertions in the done note;\n  - requires pushing, rewriting history, or editing a PR, an issue or another external system.\n- Ask as one concise question with the options and your recommendation. When a confidence figure\n  is close to a threshold, state what would change your mind. Do not round up.\n- If a decision depends on how an external API or library behaves, read its source, types or docs\n  before deciding. A confidence figure built on an unchecked assumption does not count.\n- For a significant design choice, ask the operator whether to record it in the feature's\n  `decisions.md`. Never invent the operator's rationale.\n\n## Advisor\n\n**Initial planning consultation.** If the operator asks the advisor to analyze or revise the plan\nand prepare work items, do that before coding. Include the source plan, accepted decisions,\nconstraints and the Models rules in the first packet. Ask for a numbered breakdown with each\nitem's goal, scope, dependencies, interfaces where needed, acceptance criteria, tests, and a\n**recommended coding model (full model ID) with a short reason**. The advisor must assign a model\nto every item, not leave model selection as a later leader-only step.\n\nKeep the response concise per item; the 250-word verdict limit below applies to ordinary decision\npackets, not the whole planning breakdown. Present and record the proposed items and model\nassignments with the plan. Preserve accepted decisions, operator-specified models, model permission\ngates and the Input approval rules; asking for plan analysis alone is not approval to implement\nnew or changed scope.\n\n**Advisor gates.** Consult the advisor, whatever your confidence, for:\n\n- the item breakdown and the exact interfaces, when they involve design choices or span modules,\n  before the first prompt that uses them;\n- a worker's blocker or question that is technical (the design does not fit the code, a\n  `Questions` field that is not \"none\");\n- competing technical approaches, or a failure you cannot explain after one attempt;\n- review of logic files with lifecycle, concurrency, authentication, persisted-data or\n  cross-module impact;\n- rework that would change a solution the advisor or the operator already approved;\n- any other technical choice below 90% confidence.\n\nDo not consult it on coordination or on carrying out an accepted decision.\n\n**Decision packet.** Run the advisor as a read-only `rubber-duck` or `code-review` agent with\n`model` set to the advisor. Send a short packet; do not send your whole investigation:\n\n1. the item ID, the accepted decision text and its constraints;\n2. the precise question and the options you see;\n3. the evidence, as file:line references, and the diff or commit to review;\n4. what is already settled and must not be reopened.\n\nThe advisor reads the source itself; it must not depend only on your summary. It returns the\nverdict, confidence, file:line evidence, the remaining risk and what would change its mind, in\nunder 250 words. Do not redo its investigation.\n\n- Follow-up questions on the same item go to the same advisor agent; independent items get a fresh\n  one.\n- An approval covers the revision the advisor reviewed. A substantive change after it needs another\n  review.\n- The advisor never answers always-ask questions; for those it drafts the options and a\n  recommendation for the operator.\n- Note \"advised (\u003Cmodel>)\" in the done note.\n\nWhen the advisor is your own model, still run logic reviews as a fresh-context advisor; you may\nanswer the other gates yourself.\n\n## Leader context budget\n\nKeep your own context small; everything you read is re-sent on every turn, and after a long wait\n(more than five minutes for some models) the whole context is written to the cache again at full\nprice. Use `git status`, `git diff --stat`, `grep` and targeted ranges; never page whole files or\nfull diffs when a smaller read answers the question. Classify changed files as mechanical or logic:\nread logic files in full (or send them to the advisor under its gates), spot-check mechanical ones,\nand rely on the report schema, type check and tests. Beyond logic review, read in depth only where\na report field is not \"none\". Delegate builds, test runs and broad code reading to `task` or\n`explore` agents that return summaries.\n\nOn a long run, after a round is committed and its done notes recorded, offer the operator to\ncontinue in a fresh session. The source document holds the state.\n\n## Review before committing\n\nReview every subagent's changes using the context budget above. Send back anything that goes beyond\nthe item, is over-engineered, or is hard to follow, with specific instructions. Check that:\n\n- user-facing strings use `vscode.l10n.t()`;\n- every `l10n.t(...)` string the diff adds, removes or changes was specified\n  (`git diff -U0 | grep -E '^[-+].*l10n\\.t\\('`), and reads correctly where it is shown: a\n  progress notification renders `title: message`, so a title ends without punctuation;\n- cluster lookups use `clusterId`, never `treeId`;\n- no secrets reach logs or telemetry.\n\nWhen code replaces a platform or library primitive (event emitter, telemetry wrapper, timer, abort\nhandling), check that its runtime behaviour matches, not only its types.\n\n## Commits and records\n\n- **One commit per work item.** Follow the existing subject style and include the item ID. When\n  two items change the same lines, one commit may cover both: name every item in the subject and\n  point each item's done note to it.\n- Never amend, rebase or force-push. Never use `git add -f`. Do not push unless the operator asks.\n- **Done note.** After each item's commit, record it **inline in the source document** under that\n  item:\n\n  > **Done (YYYY-MM-DD), commit `\u003Cshort-sha>`:** what changed and why, each decision (who made\n  > it, with confidence), and the tests added.\n\n  A parked item gets a **Deferred, escalated** note with the options and your recommendation, so\n  the operator can decide from the document. If the task has no source document, write the notes\n  in a new iteration file under `docs\u002Fai-and-plans\u002Ffeatures\u002F\u003Cname>\u002Fiterations\u002F`. Commit notes as\n  docs-only commits, never mixed into code commits. You may batch several notes into one docs\n  commit.\n\n- **Reverting after operator testing.** If the operator rejects an item after testing, `git revert`\n  its commit and restore any later item that shared its lines. Change its done note to\n  **Reverted (date), commit `\u003Csha>`, operator decision:** with the reason. Update every place in\n  the source that shows the item's status: index tables, the per-item status line and summaries.\n\n## Progress checkpoints\n\nThe operator checks in from time to time and needs to see at a glance where the run is. **Post a\ncheckpoint in chat each time any agent returns**: coding, advisor, `task` or `explore`, including\nagents that failed, were cancelled or came back blocked. Note the time `\u002Flead` started; pass it as\n`--since`. Get the figures from the host's session log, never from estimates:\n\n```bash\nnode .github\u002Fskills\u002Flead\u002Fscripts\u002Fagent-stats.mjs --session \u003Cyour session folder> \\\n  --agent \u003Cagent_id> --since \u003CISO time \u002Flead started>\n```\n\nYour session folder is shown in your session context; if you do not know it, omit `--session`\nand the script finds the session by agent ID. Use the following format:\n\n> **[HH:MM UTC] WI-4 · implementation returned · sol · attempt 1**\n> Added cancellation handling and two regression tests.\n> **Plan:** 3\u002F10 done · 2 running · 1 parked · 4 queued (10 accepted items; WI-6 split into\n> 6a\u002F6b).\n> **Item:** prompt ✓ → implementation ✓ → **review next** → advisor review → checks → commit.\n> **Agent:** 2m07s elapsed · 27.3 AIU · model requests 13 (2m30s summed) · tool spans 12s (bash\n> 6x\u002F5s, view 23x\u002F3s) · tests\u002Fbuilds 2 runs, 4s, 0 failed.\n> **Totals:** leader 640 AIU · subagents 190 AIU · run 830 AIU.\n> **Next:** review WI-4; WI-5 still running; WI-7 waits for your decision (see its note).\n\n- The plan line counts accepted items. When an item splits or a follow-up is added, say so; never\n  change the count silently.\n- The item line shows the stages that item still needs, so \"agent returned\" does not read as\n  \"item done\".\n- Copy figures from the script. Where it prints \"not reported by host\", say so; never write zero,\n  and never derive cost from token counts or model names. Summed model and tool time can exceed\n  elapsed time, because calls overlap.\n- Keep it to these lines. Do not poll agents to produce a checkpoint, and never ask the advisor to\n  write one.\n\n## Checks\n\nUse the two verification cases in `copilot-instructions.md`. You decide when to run what. **Do not\nrun checks after every commit.**\n\n- **Case 1** (build plus focused Vitest runs): run it after larger items or after a batch of items.\n- **Case 2:** run the full list **once, at the end**, when the work is being handed over for\n  review, or when the PR is already out of draft.\n- Track `vscode.l10n.t` strings added or removed; if any, remind the operator that Case 2 needs\n  `npm run l10n`.\n- If a check changes files (prettier, l10n), commit those changes separately (`chore: …`).\n- Report exactly which checks ran and their results. Never imply the full suite passed if it did\n  not run.\n\n## Finish\n\nBefore the report, check that the user documentation and the feature README still describe the\nchanged behaviour. Search them for statements about what the items changed, not only for quoted\nstrings, and fix them in a docs-only commit.\n\nEnd with a short report:\n\n- items that still need a workbench check, listed first, with the steps to try;\n- each work item, its commit SHA, and its model;\n- the decisions made, who made each, with confidence;\n- the questions you escalated and the questions you parked;\n- the advisor consultations: how many, for which items, and where you did not follow the advisor;\n- usage grouped by model and role, including tokens where reported (see below);\n- the checks you ran and their results;\n- open questions for the operator.\n\n### Usage and cost optimization\n\nAlways include the usage breakdown, without waiting for a separate request. Its purpose is\n**cost optimization across runs**, not exact billing reconciliation. Use full model IDs and\nkeep **leading and coding separate**, even when both use the same model.\n\nRecord each agent's role alongside its ID when delegating: `advisor`, `coding`, `review`,\n`checks`, or `exploration`. This is the work actually assigned, not the model's capability.\nInclude failed, cancelled and retried attempts. Pass explicit roles to the helper, especially\nfor advisors launched through a review agent:\n\n```bash\nnode .github\u002Fskills\u002Flead\u002Fscripts\u002Fagent-stats.mjs --session \u003Cyour session folder> \\\n  --since \u003CISO time \u002Flead started> --summary \\\n  --role \u003Cadvisor_id>=advisor --role \u003Ccoding_id>=coding\n```\n\nRepeat `--role` for the other agents. The helper separates leader usage automatically and uses\nknown agent types for defaults; unknown types stay `unclassified`. `--summary` covers the whole\nwindow, even if `--agent` was supplied. Ordinary checkpoints remain short; reserve these tables\nfor the final report.\n\n- **Outcome and work items:** status, commit and actual model per item; note substitutions from\n  the recommended model, retries and review-driven rework. List unverified work first.\n- **Usage:** copy the model\u002Frole table (requests, summed model-request time, AIU and share),\n  followed by role totals so leading, coding, advising and checks can be compared directly.\n  Keep the leader\u002Fsubagent\u002Frun total too. Never omit advisor or leader overhead.\n- **Tokens:** include the helper's input, output, cache-read, cache-write and reasoning counts\n  by model and role where available. Cache and reasoning fields may overlap input\u002Foutput;\n  do not sum them into a purported total. Missing data is \"not reported by host\", not zero;\n  retain partial-coverage labels. Never infer AIU from tokens, model prices or multipliers.\n- **Scope and timing:** give the start and snapshot times. For follow-ups, show this task's\n  usage separately from cumulative usage, labelled with each window. Report wall-clock elapsed,\n  summed model-request time, and check\u002FCI time separately where available; overlapping spans\n  are not additive. State whether the final response is excluded. AIU are not dollars.\n- **Optimization note:** briefly identify the largest measured cost category and significant\n  retry\u002Freview overhead, with a possible change for a future run. Do not rank model quality\n  from unlike work or silently change the approved model plan.\n\nUse sensible rounding; small snapshot differences are not a blocker. Do not spend extra\nconsultations or rerun work to reconcile pennies. Keep the chat report compact and record\ndetailed evidence in the existing work-item document, not a new parallel reporting ledger.\n",{"name":5,"description":7,"argument-hint":51,"disable-model-invocation":52},"advisor: \u003Cmodel>; then a task description, issue, or path to a plan or review document",true,"main","a2ea119b85b92857e68374e35a300362ab5f44c3",".github\u002Fskills\u002Flead",22,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 05:21:32",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":52},[64,67,70],{"tool":65,"command":66},"npx","npx skills add microsoft\u002Fvscode-documentdb --skill lead",{"tool":68,"command":69},"bunx","bunx skills add microsoft\u002Fvscode-documentdb --skill lead",{"tool":71,"command":72},"pnpm","pnpm dlx skills add microsoft\u002Fvscode-documentdb --skill lead","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Flead\u002FSKILL.md",[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"scripts\u002Fagent-stats.mjs","SCRIPT","脚本",14001,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Flead\u002Fscripts\u002Fagent-stats.mjs",[82,120,144,171,199,217],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":96,"publishedAt":46},"01M69BSZH60F9JW3N87ZBSKTW8","writing-release-notes","Generates release notes and changelog entries for the DocumentDB extension for Visual Studio Code, and announces releases on GitHub Discussions. Use when preparing version releases, creating patch update notes, writing changelog entries, documenting new features and fixes, or posting a release or patch release announcement to Discussions. Handles both major\u002Fminor versions (new file) and patch updates (append to existing file).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwriting-release-notes\u002FSKILL.md",[88,91],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"notes","release","release notes","writing","writing release notes","github","update","visual studio code","visual studio","code","new","when","updates","studio","patch","changelog","announcement","release announcement","releases","features","append","posting","fixes",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":46},"01M69BSXPVQWSQVYNT6QK38VN1","webview-trpc-messaging","Implements tRPC-based communication between VS Code extension host and React webviews. Use when creating new webview procedures (queries, mutations, subscriptions), adding a new webview router, wiring up a webview controller, using the tRPC client from React components, applying telemetry middleware (telemetryMiddlewareBody), or supporting AbortSignal-based cancellation in webview operations.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwebview-trpc-messaging\u002FSKILL.md",[],[127,128,129,130,106,131,132,133,134,135,107,136,137,108,138,139,140,141,142,143],"webview trpc messaging","messaging","trpc","telemetry","components","react","react components","middleware","up","host","use","wiring","router","queries","controller","mutations","communication",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":154,"publishedAt":46},"01M69BSV4V52VBDF3RZ3E6Y61T","ux-pr-review","Prepare and run an agent-assisted UX \u002F workflow review of a pull request. Use when the operator says \"I'm about to work on a UX PR review, please prepare\", \"prepare a UX review for PR","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fux-pr-review\u002FSKILL.md",[150,151],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":152,"categoryName":153,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000032","设计师",[155,156,157,33,158,159,160,161,162,163,164,40,165,137,108,166,29,167,168,169,170],"ux pr review","pr","pr review","ux","pull request","prepare","workflow","run","pull","ux review","work on","workflow review","please","request","about","operator",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":46},"01M69BSRV752CSC1NBMFWDCKB5","tree-cluster-architecture","Patterns for cluster nodes and tree data providers in vscode-documentdb. Use when adding or changing a cluster tree item, discovery provider, Connections\u002FAzure\u002FDiscovery tree hierarchy, tree\u002Flist mode, cluster identity, treeId\u002FclusterId lookup, Collection View import\u002Fexport resolution, reveal behavior, credentials, shell actions, or copy connection string support.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftree-cluster-architecture\u002FSKILL.md",[],[178,179,180,181,182,183,184,185,186,187,108,188,189,190,191,192,193,194,195,196,197,198],"tree cluster architecture","architecture","tree","cluster","azure","support","vscode","identity","actions","mode","collection","hierarchy","credentials","reveal","export","data","list","patterns","Providers","STRING","import",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":46},"01M69BSPMFSH3FAR4R5TGDB468","telemetry-instrumentation","Instrumentation patterns for telemetry in the vscode-documentdb extension. Use when adding telemetry to a feature, enriching existing telemetry with properties or measurements, linking related events with correlation IDs, instrumenting commands or tree views, suppressing noisy events, or deciding what data points to capture. Also use when asked to \"add telemetry\" or \"improve telemetry\" for any feature.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftelemetry-instrumentation\u002FSKILL.md",[],[206,130,207,184,208,209,108,210,211,193,195,212,213,180,214,40,137,215,31,216],"telemetry instrumentation","instrumentation","ids","improve","linking","commands","add","events","feature","Existing","properties",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":224,"publishedAt":46},"01M69BSMRAT64W6F3F15FVQ9QK","skill-creator","Guide for creating effective GitHub Copilot skills (.github\u002Fskills\u002F) in this repository. Use when creating a new skill, updating an existing skill, or when asked about skill structure, format, or best practices for the vscode-documentdb project.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fskill-creator\u002FSKILL.md",[223],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[225,226,227,102,228,184,229,40,230,107,137,215,108,231,232,233,169,234,235,236],"skill creator","creator","github copilot","best practices","copilot","project","structure","github copilot skills","copilot skills","format","repository","new skill"]