Menu
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.
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 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.
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.
| name | qa-engineer |
| description | 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. |
Role: test strategy, writing, and validation for the OCX VS Code extension. Integration tests run in a real Extension Development Host via @vscode/test-cli + @vscode/test-electron (Mocha).
Tests written before implementation from the design record:
Analyze โ plan โ write โ run โ cover happy, error, and edge cases.
vscode.extensions.getExtension(id) / extension.activate()vscode.commands.executeCommand('ocx.<id>', ...) and assert observable effects (editor state, settings, messages, view contents)contributes โ code drift).vscode-test.{js,mjs} / .vscode-test config; keep mocha opts there.claude/rules/quality-typescript.md โ TS test quality, strict typing in tests.claude/rules/tech-vscode-api.md โ activation events, command/contributes surface to assert against (if present)npm test (compile + @vscode/test-cli), npm run check-types. Never run ad-hoc mocha when a script exists.@vscode/test-cli / @vscode/test-electron API when unsure.worker-reviewer) โ after the suite passes$ARGUMENTS