[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BFE1ZTD4BANN26WKED1YC":3,"skill-same:01M69BFE1ZTD4BANN26WKED1YC":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M69BFE1ZTD4BANN26WKED1YC","lsp-setup",null,"Set up Language Server Protocol (LSP) servers for Copilot CLI by detecting the repository language stack, selecting trusted servers, and merging user or project configuration. Use when the user asks to install or configure a language server, enable code intelligence, or diagnose missing CLI definitions, references, hover, or rename support, including warnings from .memory\u002Flsp-status.md. Do not use for routine coding, VS Code or other editor language-service configuration, MCP setup, or static-analysis indexing.","microsoft\u002Fdevsquad-copilot","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BE5EMENJJPPKFFE4AVZPN",50,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Flsp-setup\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35],"setup","lsp setup","MCP","cli","memory","support","editor","hover","status","copilot","diagnose","code","2026-11-10 10:12:30",false,"---\nname: lsp-setup\ndescription: \"Set up Language Server Protocol (LSP) servers for Copilot CLI by detecting the repository language stack, selecting trusted servers, and merging user or project configuration. Use when the user asks to install or configure a language server, enable code intelligence, or diagnose missing CLI definitions, references, hover, or rename support, including warnings from .memory\u002Flsp-status.md. Do not use for routine coding, VS Code or other editor language-service configuration, MCP setup, or static-analysis indexing.\"\n---\n\n# LSP Setup for Copilot CLI\n\nConfigure language servers for the languages actually used in the repository. Keep installation and configuration changes subject to explicit approval.\n\n## Workflow\n\n### 1. Establish client and current state\n\n1. Confirm that the target is Copilot CLI. If the request concerns VS Code language services, explain that CLI LSP configuration does not configure the editor and direct the user to the relevant language extension.\n2. Read `.memory\u002Flsp-status.md` if present. Treat it as a session-start snapshot of configuration file presence, not server health or language coverage.\n3. Inspect `.github\u002Flsp.json` and `~\u002F.copilot\u002Flsp-config.json` when present and access is permitted. Use `\u002Flsp` output to identify effective servers, including plugin-provided ones. Ask the user to run interactive slash commands if the current tools cannot execute them.\n4. Resolve configuration precedence by server name: project configuration overrides plugin configuration, which overrides user configuration. Preserve unrelated entries and intentionally disabled servers. Report malformed configuration before attempting a merge.\n5. If the required languages already have working servers, report that no changes are needed. If an existing server fails, diagnose its configuration or startup error before proposing another installation.\n\n### 2. Detect and confirm the language stack\n\n1. Inspect build\u002Fdependency manifests and source file extensions, excluding DevSquad scaffolding, documentation examples, templates, vendored dependencies, generated files, and build output. Do not infer a language from documentation examples alone.\n2. If no stack can be established and the user has neither requested setup nor explicitly selected languages, defer setup without installing software or creating configuration. Envisioning, specification, and planning can proceed without LSP. Revisit setup when implementation introduces source files or manifests.\n3. If the user explicitly requests setup in a repository with no stack evidence, ask which languages they intend to use. Do not choose the application stack on their behalf. If they already explicitly chose languages, offer optional setup for those languages with approval.\n4. For polyglot repositories, identify the languages with meaningful source presence and any subproject roots.\n5. Present the evidence or explicitly chosen languages and proposed language set. Confirm which languages the user wants supported before making changes.\n\n### 3. Resolve trusted servers and installation methods\n\n1. Determine the host OS, available package managers, existing server binaries, and required language runtimes.\n2. Select a maintained server for each confirmed language using official server and ecosystem documentation. Resolve the package name, supported runtime versions, installation method, and exact stdio launch command from those sources.\n3. Reuse an existing compatible installation. Do not assume every server accepts `--stdio`, invent package names, or install a new package manager without separate approval.\n4. If a server or platform is unsupported or cannot be verified, explain the limitation and leave that language unchanged. Offer a documented alternative when available.\n\n### 4. Choose scope and approve the change\n\n1. Present the available scopes and ask the user to choose:\n\n   | Scope | Location | Effect |\n   |-------|----------|--------|\n   | Project | `.github\u002Flsp.json` | Shared with repository contributors; each machine still needs the server installed |\n   | User | `~\u002F.copilot\u002Flsp-config.json` | Applies to this user's projects on this machine |\n\n2. Prefer the existing project configuration location when updating project settings. Check current CLI documentation before changing a legacy root-level `lsp.json`; do not create a second competing project configuration silently.\n3. Explain overrides, disabled entries, and portability constraints. Keep machine-specific absolute paths and secrets out of shared configuration. Changing an intentionally disabled server requires explicit approval.\n4. Show the exact installation commands and proposed configuration changes. Obtain approval before installing software, updating an existing server entry, or writing configuration. Do not modify application dependency manifests merely to install development language servers.\n\n### 5. Install and merge configuration\n\n1. Run only approved installation commands. On failure, report the actual error and request approval for any alternative command; do not silently switch installers or elevate privileges.\n2. Confirm that the server executable is accessible in the environment that launches Copilot CLI (`command -v` on POSIX or `Get-Command` on PowerShell).\n3. Re-read the destination before writing. Add or update only approved keys under `lspServers`, preserving other servers and fields. If the file changed since approval, reconcile the new content before proceeding.\n4. Validate the resulting JSON and required server fields. Use the server's documented arguments and language IDs. For monorepos, set `rootUri` when the server needs a subproject root.\n\n### 6. Reload and verify runtime behavior\n\n1. Ask the user to run `\u002Flsp reload` in Copilot CLI to load the updated configuration, then `\u002Flsp` to inspect effective server status. Check `\u002Flsp help` if the installed CLI does not support reload; restart only when required by that version.\n2. Run `\u002Flsp test SERVER-NAME` for each configured server, or ask the user to run it and provide the result. Inspect `\u002Flsp logs` when startup fails.\n3. Verify a definition or reference lookup on a known symbol in a saved source file of each configured language. If source files do not exist yet, defer this check without creating application code solely for verification. A reachable executable and valid JSON alone do not establish working code intelligence.\n4. Report configuration validity, server startup results, and code-navigation verification separately. For an explicitly chosen stack without code, state that navigation verification is pending until source files exist; startup may also remain unverified if the server requires project files. Report failures and checks awaiting user execution without claiming fully working code intelligence.\n5. Explain that `.memory\u002Flsp-status.md` refreshes at the next session start. Do not treat its older snapshot as the result of `\u002Flsp reload`.\n\n## Configuration Shape\n\nUse the following structure as a template, replacing placeholders with verified values:\n\n```json\n{\n  \"lspServers\": {\n    \"server-name\": {\n      \"command\": \"server-binary\",\n      \"args\": [\"documented-stdio-argument\"],\n      \"fileExtensions\": {\n        \".ext\": \"language-id\"\n      }\n    }\n  }\n}\n```\n\n1. Use server keys containing only alphanumeric characters, underscores, and hyphens.\n2. Map extensions, including the leading dot, to the server's supported language IDs. Omit `args` or use an empty array when no arguments are required.\n3. Preserve optional fields such as `env`, `rootUri`, `initializationOptions`, and timeouts when merging. Follow current CLI documentation for supported fields.\n4. Preserve entries such as `\"server-name\": { \"disabled\": true }` unless the user approves enabling or replacing them.\n5. Consult [GitHub's LSP setup documentation](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fhow-tos\u002Fcopilot-cli\u002Fset-up-copilot-cli\u002Fadd-lsp-servers) and [LSP configuration precedence](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fconcepts\u002Fagents\u002Fcopilot-cli\u002Flsp-servers) for current client behavior.\n","# LSP Setup for Copilot CLI\n\nConfigure language servers for the languages actually used in the repository. Keep installation and configuration changes subject to explicit approval.\n\n## Workflow\n\n### 1. Establish client and current state\n\n1. Confirm that the target is Copilot CLI. If the request concerns VS Code language services, explain that CLI LSP configuration does not configure the editor and direct the user to the relevant language extension.\n2. Read `.memory\u002Flsp-status.md` if present. Treat it as a session-start snapshot of configuration file presence, not server health or language coverage.\n3. Inspect `.github\u002Flsp.json` and `~\u002F.copilot\u002Flsp-config.json` when present and access is permitted. Use `\u002Flsp` output to identify effective servers, including plugin-provided ones. Ask the user to run interactive slash commands if the current tools cannot execute them.\n4. Resolve configuration precedence by server name: project configuration overrides plugin configuration, which overrides user configuration. Preserve unrelated entries and intentionally disabled servers. Report malformed configuration before attempting a merge.\n5. If the required languages already have working servers, report that no changes are needed. If an existing server fails, diagnose its configuration or startup error before proposing another installation.\n\n### 2. Detect and confirm the language stack\n\n1. Inspect build\u002Fdependency manifests and source file extensions, excluding DevSquad scaffolding, documentation examples, templates, vendored dependencies, generated files, and build output. Do not infer a language from documentation examples alone.\n2. If no stack can be established and the user has neither requested setup nor explicitly selected languages, defer setup without installing software or creating configuration. Envisioning, specification, and planning can proceed without LSP. Revisit setup when implementation introduces source files or manifests.\n3. If the user explicitly requests setup in a repository with no stack evidence, ask which languages they intend to use. Do not choose the application stack on their behalf. If they already explicitly chose languages, offer optional setup for those languages with approval.\n4. For polyglot repositories, identify the languages with meaningful source presence and any subproject roots.\n5. Present the evidence or explicitly chosen languages and proposed language set. Confirm which languages the user wants supported before making changes.\n\n### 3. Resolve trusted servers and installation methods\n\n1. Determine the host OS, available package managers, existing server binaries, and required language runtimes.\n2. Select a maintained server for each confirmed language using official server and ecosystem documentation. Resolve the package name, supported runtime versions, installation method, and exact stdio launch command from those sources.\n3. Reuse an existing compatible installation. Do not assume every server accepts `--stdio`, invent package names, or install a new package manager without separate approval.\n4. If a server or platform is unsupported or cannot be verified, explain the limitation and leave that language unchanged. Offer a documented alternative when available.\n\n### 4. Choose scope and approve the change\n\n1. Present the available scopes and ask the user to choose:\n\n   | Scope | Location | Effect |\n   |-------|----------|--------|\n   | Project | `.github\u002Flsp.json` | Shared with repository contributors; each machine still needs the server installed |\n   | User | `~\u002F.copilot\u002Flsp-config.json` | Applies to this user's projects on this machine |\n\n2. Prefer the existing project configuration location when updating project settings. Check current CLI documentation before changing a legacy root-level `lsp.json`; do not create a second competing project configuration silently.\n3. Explain overrides, disabled entries, and portability constraints. Keep machine-specific absolute paths and secrets out of shared configuration. Changing an intentionally disabled server requires explicit approval.\n4. Show the exact installation commands and proposed configuration changes. Obtain approval before installing software, updating an existing server entry, or writing configuration. Do not modify application dependency manifests merely to install development language servers.\n\n### 5. Install and merge configuration\n\n1. Run only approved installation commands. On failure, report the actual error and request approval for any alternative command; do not silently switch installers or elevate privileges.\n2. Confirm that the server executable is accessible in the environment that launches Copilot CLI (`command -v` on POSIX or `Get-Command` on PowerShell).\n3. Re-read the destination before writing. Add or update only approved keys under `lspServers`, preserving other servers and fields. If the file changed since approval, reconcile the new content before proceeding.\n4. Validate the resulting JSON and required server fields. Use the server's documented arguments and language IDs. For monorepos, set `rootUri` when the server needs a subproject root.\n\n### 6. Reload and verify runtime behavior\n\n1. Ask the user to run `\u002Flsp reload` in Copilot CLI to load the updated configuration, then `\u002Flsp` to inspect effective server status. Check `\u002Flsp help` if the installed CLI does not support reload; restart only when required by that version.\n2. Run `\u002Flsp test SERVER-NAME` for each configured server, or ask the user to run it and provide the result. Inspect `\u002Flsp logs` when startup fails.\n3. Verify a definition or reference lookup on a known symbol in a saved source file of each configured language. If source files do not exist yet, defer this check without creating application code solely for verification. A reachable executable and valid JSON alone do not establish working code intelligence.\n4. Report configuration validity, server startup results, and code-navigation verification separately. For an explicitly chosen stack without code, state that navigation verification is pending until source files exist; startup may also remain unverified if the server requires project files. Report failures and checks awaiting user execution without claiming fully working code intelligence.\n5. Explain that `.memory\u002Flsp-status.md` refreshes at the next session start. Do not treat its older snapshot as the result of `\u002Flsp reload`.\n\n## Configuration Shape\n\nUse the following structure as a template, replacing placeholders with verified values:\n\n```json\n{\n  \"lspServers\": {\n    \"server-name\": {\n      \"command\": \"server-binary\",\n      \"args\": [\"documented-stdio-argument\"],\n      \"fileExtensions\": {\n        \".ext\": \"language-id\"\n      }\n    }\n  }\n}\n```\n\n1. Use server keys containing only alphanumeric characters, underscores, and hyphens.\n2. Map extensions, including the leading dot, to the server's supported language IDs. Omit `args` or use an empty array when no arguments are required.\n3. Preserve optional fields such as `env`, `rootUri`, `initializationOptions`, and timeouts when merging. Follow current CLI documentation for supported fields.\n4. Preserve entries such as `\"server-name\": { \"disabled\": true }` unless the user approves enabling or replacing them.\n5. Consult [GitHub's LSP setup documentation](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fhow-tos\u002Fcopilot-cli\u002Fset-up-copilot-cli\u002Fadd-lsp-servers) and [LSP configuration precedence](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fconcepts\u002Fagents\u002Fcopilot-cli\u002Flsp-servers) for current client behavior.\n",{"name":5,"description":7},"main","fb93f96b64ff15238a7f20e7f611211ee0720fba",".github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Flsp-setup",12,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot","https:\u002F\u002Faka.ms\u002Fdevsquad-copilot","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 10:09:48",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add microsoft\u002Fdevsquad-copilot --skill lsp-setup",{"tool":57,"command":58},"bunx","bunx skills add microsoft\u002Fdevsquad-copilot --skill lsp-setup",{"tool":60,"command":61},"pnpm","pnpm dlx skills add microsoft\u002Fdevsquad-copilot --skill lsp-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Flsp-setup\u002FSKILL.md",true,[],[66,82,93,104,121,140],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":73,"publishedAt":36},"01M69BG4STFRJMC0FT9K81Y6W0","work-item-workflow","Work item workflow for implementation. Use when starting work on a GitHub issue or Azure DevOps work item to verify assignee, dependencies, priority, and capacity. Do not use for creating new work items (use work-item-creation), for suggesting the next task (use next-task), or when the work source is only tasks.md without an issue\u002Fwork item.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Fwork-item-workflow\u002FSKILL.md",[72],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[74,75,76,77,78,79,80,81],"work item workflow","workflow","github","azure devops","capacity","azure","tasks","next task",{"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":88,"publishedAt":36},"01M69BG2HPKFCG18SYZA7W35AK","work-item-creation","Rules and checklist for creating work items on GitHub Issues or Azure DevOps. Use when you need to create issues, user stories, tasks, epics, or features on the board. Do not use for platform configuration (use board-config), managing workflow of existing tasks (use work-item-workflow), or for comments on work items.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Fwork-item-creation\u002FSKILL.md",[],[89,76,75,77,90,79,80,91,92],"work item creation","config","create","github issues",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":36},"01M69BG04YGG1CR7MZWGQ7X9MG","triage-workflow","Label-based state machine for triaging issues and work items. Manages state transitions, generates durable triage artifacts, and supports resumable sessions. Use when triaging GitHub issues or Azure DevOps work items. Do not use for creating new work items from scratch (use work-item-creation) or for managing implementation workflow of already-triaged items (use work-item-workflow).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Ftriage-workflow\u002FSKILL.md",[99],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[101,75,102,77,79,92,103,76],"triage workflow","triage","sessions",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":36},"01M69BFXK0ZC2JZEERD6TFTQ8G","test-discipline","Testing practices for behavior-focused, refactor-resistant tests. Use when implementing features, fixing bugs, refactoring, or adding or reviewing tests to ensure they verify intent through public interfaces and avoid tautological assertions. Also use when adding regression tests after bug fixes. Consulted by the implement agent during coding and by the review agent when validating test quality. Do not use for test strategy decisions (use complexity-analysis), for failure triage and root-cause analysis (use debugging-recovery, then after root cause is localized use test-discipline to add the reproducing regression test and fix), or for integration test infrastructure setup.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Ftest-discipline\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[114,115,116,117,118,102,24,119,120],"test discipline","test","testing","review","implement","infrastructure","debugging",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":130,"publishedAt":36},"01M69BFTZDV68JM4CB1C9TGFD3","security-review","Security assessment workflow in two modes: architectural (design) and code (implementation). Use when a security trigger is detected during planning (architectural mode) or implementation\u002Freview (code mode). Covers STRIDE, OWASP, dependency scanning, Azure compliance, and GitHub security alerts. Do not use for general code quality (use devsquad.review), for threat modeling as a standalone activity, or for compliance audits.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Fsecurity-review\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[131,132,117,133,75,134,135,136,76,79,137,35,138,139],"security review","security","threat modeling","security alerts","code quality","azure compliance","assessment","planning","design",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":36},"01M69BFRCVSVDN7RXAZJSSZ4TW","reasoning","Record decisions and justifications during SDD agent execution, and pass structured context between agents via handoff envelope. Use when an agent needs to document decisions made (Reasoning Log) or perform a handoff to another agent. Do not use for architecture documentation (use ADRs), complexity analysis (use complexity-analysis), or debug logs.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fdevsquad-copilot\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fdevsquad\u002Fskills\u002Freasoning\u002FSKILL.md",[],[142,147,148,149,150,151],"architecture","complexity analysis","documentation","debug","handoff"]