CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

launch

Launch Code OSS (VS Code from sources) into an isolated throwaway profile with unique debug ports so you can drive it with @playwright/cli AND attach a Node debugger via dap-cli in the same session. Use when working on VS Code itself and you want to interact with the running workbench, automate chat or UI flows, test UI features, take screenshots, set breakpoints in the renderer / extension host / main process, or combine UI driving with debugging.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is exceptionally actionable with executable commands for both bash and PowerShell, a clear launch-to-drive-to-debug-to-cleanup sequence, and strong validation/feedback loops. Its weaknesses are verbosity from narrative digressions and a progressive-disclosure defect: the repeatedly referenced `playwrightScripts/focus-chat-input.ts` is missing from the bundle, and deep Windows-auth/troubleshooting detail is inlined rather than split into reference files.

Suggestions

Fix or correct the `playwrightScripts/focus-chat-input.ts` reference: the file is absent from the bundle despite being central to the focus-chat, Monaco-paste, and parallel-instance workflows. Ship it (e.g. under scripts/) or update every path that points to it.

Move the Windows shared-storage authentication internals and the full troubleshooting catalog into one-level-deep reference files (e.g. references/windows-auth.md, references/troubleshooting.md), keeping SKILL.md focused on the core launch, drive, debug, and cleanup flows.

Trim narrative asides to one-line notes - the pre-fix Windows seeding anecdote, the PLAYWRIGHT_CLI_SESSION env-var alternative, and the 'Why a helper script and not just docs' rationale - to cut token cost without losing the operative guidance.

DimensionReasoningScore

Conciseness

The body (~495 lines) contains no basic-concept padding, but includes several narrative digressions that could be tightened: the pre-fix Windows behavior anecdote ("before this seeding existed every launch handed Code OSS an empty shared dir"), the extended PLAYWRIGHT_CLI_SESSION env-var footnote, the "Why a helper script and not just docs" three-trap rationale, and the macOS Mach-ports caveat. This fits anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened'); it is well above anchor 2's generic padding but short of anchor 4's trimmable-to-near-lean state.

3 / 5

Actionability

Guidance is fully executable and copy-paste ready: complete bash and PowerShell launcher invocations with every flag, the JSON output contract with a worked example, a port-to-process-to-tool table, `node -p 'JSON.parse(...)'` capture snippets, and a concrete symptom-to-fix troubleshooting list. This matches anchor 5 ('copy-paste ready code or commands; specific examples cover the common cases') rather than anchor 4's 'minor gaps'.

5 / 5

Workflow Clarity

The multi-step flow is explicitly sequenced with validation checkpoints: launch blocks until CDP is ready and exits non-zero with a log tail on failure; "Inspect the launched window before proceeding" mandates visual screenshot verification before interacting; the missing sign-in flow defines explicit user choice points and a wait-for-exit step to avoid relaunch races; and the troubleshooting section provides error-recovery feedback loops. This matches anchor 5's 'explicit validation steps; feedback loops for error recovery'.

5 / 5

Progressive Disclosure

Sectioning is good and script references are one level deep and clearly signaled, but scoring against the actual bundle reveals that `playwrightScripts/focus-chat-input.ts` - referenced in the core focusing, pasting, and parallel-instance flows - does not exist in the bundle (only scripts/launch.sh, launch.ps1, monaco-paste.ts/sh, updateSettings.ts, waitForCdp.ts, bootstrap/, and cleanup/ are present). Additionally, deep reference material (Windows shared-storage internals, the full troubleshooting catalog) is inlined in a single ~500-line SKILL.md with no references/ split. The broken central reference and heavy inlining place this at anchor 3 rather than anchor 4's 'minor organization gaps'.

3 / 5

Total

16

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it names a precise niche, enumerates concrete capabilities, and gives an explicit 'Use when' clause with natural trigger phrases. The only deductions are the second-person voice ("you can drive", "you want") and a few missing natural synonyms such as Copilot or extension development.

DimensionReasoningScore

Specificity

Quotes like "Launch Code OSS (VS Code from sources) into an isolated throwaway profile with unique debug ports", "drive it with @playwright/cli", and "set breakpoints in the renderer / extension host / main process" list multiple concrete, comprehensive actions (anchor 5), but the second-person phrasing ("so you can drive it", "you want to interact") triggers the rubric's one-point specificity penalty. It is clearly above anchor 3's '1-2 concrete actions' level, so 4.

4 / 5

Completeness

The 'what' is explicit ("Launch Code OSS... into an isolated throwaway profile with unique debug ports so you can drive it with @playwright/cli AND attach a Node debugger via dap-cli") and the 'when' is explicit with concrete trigger phrases ("Use when working on VS Code itself and you want to interact with the running workbench, automate chat or UI flows..."). This directly matches the anchor-5 example pattern of both what and when with concrete triggers; anchor 4 would require a less explicit 'when'.

5 / 5

Trigger Term Quality

Natural phrases a user would actually say are well covered: "working on VS Code itself", "automate chat or UI flows", "test UI features", "take screenshots", "set breakpoints", "combine UI driving with debugging". A few natural synonyms are missing (e.g. Copilot, extension development, 'debug VS Code'), which matches anchor 4 rather than the comprehensive synonym-and-extension coverage of anchor 5.

4 / 5

Distinctiveness Conflict Risk

"VS Code from sources", "Code OSS", "@playwright/cli", "dap-cli", and "extension host" carve out a clear niche (developing/automating/debugging VS Code itself) that no generic skill would trigger for. Minimal conflict risk, matching anchor 5; it is not merely 'mostly distinct' as in anchor 4.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

microsoft/vscode

Path

.agents/skills/launch/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.