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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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