Menu
Use when writing code, fixing a bug, implementing a feature, or improving code structure in the VS Code extension. Invoked for typed implementation work inside `src/`, `src/test/`, build config, or other source surfaces. Trigger: /builder.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the extension adopts a new technology (a library, framework, protocol, or service โ e.g. Solr, a language server, a webview UI framework) and you want reusable per-technology expertise. Generates a path-scoped rule + a specialist agent (+ optional skill) so future tasks get current, project-specific guidance on that tech. Trigger: /add-tech-specialist.
Use when a task involves a design spec, ADR, one-way-door decision, or evaluating trade-offs between architectural approaches for the VS Code extension. Invoke before implementation when requirements span modules or a decision is hard to reverse. Trigger: /architect.
Use for code review, quality audits, SOLID/DRY consistency checks, pattern audits across the VS Code extension codebase, lint/type-check, or verifying anti-pattern compliance across a scope. Trigger: /code-check.
Use when the user says "commit", "/commit", "save progress", or asks to land working changes on a feature branch. Working-phase posture โ minimises commit count, can amend rolling Checkpoints, offers a one-time PR prompt. Conventional Commits.
Use when designing test suites, writing integration/acceptance tests, validating an implementation against a spec, or planning test coverage before implementation for the VS Code extension. Trigger: /qa-engineer.
| name | builder |
| description | Use when writing code, fixing a bug, implementing a feature, or improving code structure in the VS Code extension. Invoked for typed implementation work inside `src/`, `src/test/`, build config, or other source surfaces. Trigger: /builder. |
Role: turn plans into working, tested, production-ready code for the OCX VS Code extension (TypeScript).
Follow contract-first TDD phases:
quality-typescript.md, tech-*.md auto-load on matching paths; load explicitly for cross-module work). Grep before you invent.throw new Error("not implemented"). Gate: npm run check-types.npm run check (lint + types + build) before marking complete..claude/rules/quality-typescript.md โ TS strict baseline, module system, anti-patterns.claude/rules/tech-vscode-api.md โ command/activation/disposable patterns, contributes parity (if present).claude/rules/tech-esbuild.md โ bundle contract: dist/extension.js, cjs, vscode external (if present).claude/rules.md โ full catalog for cross-cutting concernscontext.subscriptionsactivate() cheap; declare narrow activationEventspackage.json contributes IDs in sync with code (commands, settings, views)strict TS โ no any escape hatches, no @ts-ignore without justificationvscode external in the bundle; never import VS Code internalsmcp__context7__resolve-library-id + get-library-docs) โ query current APIs (@types/vscode, esbuild, @vscode/test-cli) before guessing. Training-data API knowledge decays fast.npm run to discover; key gates: npm run check-types, npm run lint, npm test, npm run check.specialist-vscode-api / specialist-esbuild for deep API questions.package.json firstnpm run check before marking completeworker-reviewer) โ code review$ARGUMENTS