القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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