@qa-gentic/stlc-agents 1.0.5 → 1.0.7

package/skills/qa-stlc/generate-test-cases.md

@@ -1,176 +0,0 @@
-# Skill: Generate Test Cases from Azure DevOps Work Item
-
-> **Read `AGENT-BEHAVIOR.md` before this skill.** The behavior rules there override any
-> inference. This skill provides the step-by-step workflow only.
-
-Use this skill when asked to generate, create, or write test cases for an Azure DevOps
-PBI, Bug, User Story, or Feature.
-
----
-
-## 🚨 HARD STOP RULES — Read Before Anything Else
-
-**HARD STOP 0 — Never infer delivery destination.**
-Generating test cases ≠ creating them in ADO. Show the user what you plan to create.
-Get explicit confirmation. Do not auto-submit.
-
-**HARD STOP 1 — Never create test cases for an Epic.**
-Test cases in ADO are always scoped to PBIs, Bugs, or Features — never to Epics.
-If the user provides an Epic ID and asks for test cases:
-- Call `fetch_work_item` with the Epic ID — the tool will return `"error": "epic_not_supported"`.
-- Inform the user explicitly:
-  > "Manual test cases cannot be created or linked to an Epic in ADO.
-  > Test cases must be attached to individual Features, PBIs, or Bugs.
-  > Would you like me to use `fetch_epic_hierarchy` to identify the child Features
-  > and PBIs/Bugs, then create test cases for those instead?"
-- Do NOT call `create_and_link_test_cases` with an Epic ID under any circumstances.
-
-**HARD STOP 2 — Always ask for user confirmation before creating test cases for a Feature.**
-When the target work item is a Feature, the server will return `"confirmation_required": true`.
-At that point, **stop and ask the user**:
-> "I'm about to create {N} manual test case(s) linked to Feature #{id} — "{title}".
-> Please confirm (yes / no) before I proceed."
-Do not call `create_and_link_test_cases` again until the user replies affirmatively.
-If the user replies 'no' or 'cancel', abort and inform them no test cases were created.
-
-## ⛔ Mandatory Pre-Flight: Deduplication Protocol
-
-Before executing any step below, run the deduplication protocol:
-`skills/deduplication-protocol.md`
-
-The protocol is **work-item-scoped**: PHASE 1 runs once per `work_item_id` and its results
-are cached. If this skill is invoked for the same `work_item_id` that another agent already
-processed, skip PHASE 1 and read from `CACHE[work_item_id]` directly.
-A different `work_item_id` always triggers a fresh PHASE 1.
-
----
-
-## Steps
-
-### Step 1 — Fetch the work item and existing test cases
-
-**1A — Fetch the work item:**
-Call `fetch_work_item` with the work item ID, organization URL, and project name.
-
-The response contains:
-- `work_item` — title, acceptance_criteria, description, repro_steps (for Bugs), story_points, priority, area_path, iteration_path
-- `parent_feature` — parent Feature if present
-- `existing_test_cases_count` — count of already-linked test cases (use as a signal only)
-- `coverage_hints` — keys derived from AC text flagging areas that need coverage
-
-**1B — Fetch existing test case titles (always, before generating):**
-`existing_test_cases_count` is a count, not the actual titles. Two concurrent runs against the
-same work item will duplicate test cases unless you fetch the real titles first.
-
-```
-qa-test-case-manager:get_linked_test_cases(
-  organization_url : ...
-  project_name     : ...
-  work_item_id     : <same ID>
-)
-```
-
-The response contains a `linked_test_cases` list with `id`, `title`, `state`, `priority`.
-**Skip any test case whose title (or a near-identical paraphrase) already exists in this list.**
-If `existing_test_cases_count` is 0 you may skip the call.
-
-### Step 2 — Determine complexity
-Use `story_points` and the count of distinct acceptance criteria:
-- **Simple** (3–6 TCs): ≤ 2 points or ≤ 2 AC items
-- **Medium** (6–12 TCs): 3–5 points or 3–5 AC items
-- **Complex** (12–18 TCs): > 5 points or > 5 AC items
-
-Add +1 TC for each `coverage_hint` not already addressed.
-
-### Step 3 — Apply the granularity rule
-Ask: "Does this step naturally flow into the next as part of one user journey?" If yes,
-merge into ONE test case with multiple steps. Avoid micro-interaction test cases.
-
-- ✗ BAD: TC="Slide-out opens", TC="File picker appears"
-- ✓ GOOD: TC="User opens profile and initiates photo update" (multi-step)
-
-### Step 4 — Design test cases covering all applicable categories
-
-| Category | Description |
-|---|---|
-| Happy paths | Successful end-to-end flows |
-| Success feedback | Toast/confirmation messages after success |
-| Post-action state | UI reflects the change (photo displayed, count updated) |
-| Validation errors | Invalid input, wrong format, missing required fields |
-| Boundary conditions | Test AT the exact limit stated in ACs (exactly 5 MB, not 4 MB or 6 MB) |
-| Edge cases | Empty state, default state, fallback display (initials avatar) |
-| Negative scenarios | Failure states, error toasts, state unchanged after failure |
-| Data persistence | Data survives page refresh or re-login |
-| Computed/derived state | Values derived from other fields update correctly |
-| Platform-specific | Mobile/webview scenarios when mentioned in ACs |
-| Cancel flows | Cancel/discard discards changes without saving |
-
-Apply every hint in `coverage_hints`. Skip titles already in the `linked_test_cases` list from Step 1B.
-
-### Step 4B — Delivery gate (mandatory — do not skip)
-
-Before calling `create_and_link_test_cases`, present the following to the user and wait:
-
-```
-I've designed {N} test cases for work item #{id} — "{title}".
-
-Here is the list:
-  1. {TC title}
-  2. {TC title}
-  ...
-
-**Do you want me to create these in ADO now? (yes / no)**
-
-Note:
-- Saying yes here only creates test cases — it does not generate Gherkin or Playwright code.
-- If you also want Gherkin or Playwright code, say so separately.
-```
-
-**Do not call `create_and_link_test_cases` until the user replies "yes".**
-**Do not carry this confirmation forward to any other artifact.**
-
-### Step 5 — Create and link
-Call `create_and_link_test_cases` with your test cases. Do NOT specify `area_path` —
-it is automatically inherited from the parent work item.
-
-Each test case:
-- `title` — clear, specific, describes what is being tested
-- `steps` — array of `{ action, expected_result }` — at least 2 steps per TC
-- `priority` — 1=Critical, 2=High (default), 3=Medium, 4=Low
-
-## Example tool call
-
-```json
-{
-  "work_item_id": 12345,
-  "organization_url": "https://dev.azure.com/myorg",
-  "project_name": "MyProject",
-  "test_cases": [
-    {
-      "title": "TC_12345_01 — User uploads valid profile photo and sees success confirmation",
-      "priority": 2,
-      "steps": [
-        {"action": "Navigate to My Profile slide-out", "expected_result": "Profile section opens showing current photo or initials"},
-        {"action": "Click Update Photo and select a valid JPG file under 5 MB", "expected_result": "Image preview is shown in the crop editor"},
-        {"action": "Adjust crop area and click Save", "expected_result": "Success toast 'Profile photo updated' is displayed and photo appears in the header"}
-      ]
-    }
-  ]
-}
-```
-
----
-
-## Explicit Delivery Rules — No Inference
-
-| Decision | Rule |
-|---|---|
-| Generate test cases | Always: show the proposed list first |
-| Create in ADO | Requires explicit "yes" at Step 4B gate |
-| User says "no" at gate | Abort; report "No test cases created" |
-| User confirms Feature test cases | Separate confirmation at HARD STOP 2 — not carried from Step 4B |
-| Generate Gherkin next | Must be a separate user request — not triggered by this skill |
-| Generate Playwright next | Must be a separate user request — not triggered by this skill |
-| Save locally | Only if user explicitly says "save" or "download" |
-
-**Each artifact delivery is independent. A yes/no for one does not answer any other.**

package/skills/qa-stlc/write-helix-files.md

@@ -1,374 +0,0 @@
----
-name: write-helix-files
-description: >
-  Use this skill whenever generated Playwright TypeScript files (locators,
-  page objects, step definitions, feature files, healing infrastructure) need
-  to be placed into a local Helix-QA project on disk. Triggers after
-  generate-playwright-code or scaffold_locator_repository has produced a
-  'files' dict. Always calls inspect_helix_project first to determine whether
-  the framework exists, then picks the correct write mode automatically.
-compatibility:
-  tools:
-    - qa-helix-writer:inspect_helix_project
-    - qa-helix-writer:list_helix_tree
-    - qa-helix-writer:read_helix_file
-    - qa-helix-writer:write_helix_files
-    - qa-helix-writer:update_helix_file
-    - qa-playwright-generator:generate_playwright_code
-    - qa-playwright-generator:scaffold_locator_repository
-    - qa-playwright-generator:pre_validate_cucumber_steps
----
-
-# Write Helix Files Skill
-
-## 🚨 HARD STOP RULES — Read Before Anything Else
-
-**HARD STOP 1 — NEVER use `create_file` as a fallback.**
-`create_file` bypasses deduplication, interface-adaptation rewrites, and file routing.
-If `write_helix_files` returns an error, diagnose and fix the payload — do NOT route
-around the tool. If the error cannot be resolved, surface it to the user verbatim.
-
-**HARD STOP 2 — NEVER create a new locator or step file when one already exists.**
-Before writing, call `list_helix_tree` to check what files are already on disk.
-If `src/locators/<foo>.locators.ts` already exists → it is the only correct target.
-Do NOT create `src/locators/<foo>-bar.locators.ts` or any variant filename.
-`write_helix_files` will merge new keys into the existing file automatically.
-
-**HARD STOP 3 — Step definitions MUST use Cucumber expressions, not regex.**
-`write_helix_files` runs a parenthesis-balance validator on every `*.steps.ts` file.
-Regex step patterns (e.g. `/^I click "([^"]*)"$/`) contain un-paired parentheses and
-will fail this check. Before submitting, verify every `When/Then/Given` block matches
-the Cucumber expression format:
-
-```typescript
-// ✅ Correct — Cucumber expression
-When('the user enters {string} in the username field', async function (value: string) {
-```
-
-```typescript
-// ❌ Rejected — regex pattern
-When(/^the user enters "([^"]*)" in the username field$/, async function (value: string) {
-```
-
-If `generate_playwright_code` produced regex patterns, use `pre_validate_cucumber_steps`
-to identify them, then convert to Cucumber expressions before calling `write_helix_files`.
-
----
-
-Place files produced by `qa-playwright-generator` into a local Helix-QA
-project. The skill handles two situations automatically:
-
-| Situation | What happens |
-|---|---|
-| Framework does not exist yet | Scaffold infrastructure + write test files |
-| Framework already exists | Merge only the new work item's test files; never touch infrastructure |
-
----
-
-## Helix-QA Directory Layout
-
-```
-<helix_root>/
-├── src/
-│   ├── locators/                   ← <kebab>.locators.ts          (merged per file)
-│   ├── pages/                      ← <Page>.page.ts               (merged per file)
-│   ├── test/
-│   │   ├── features/               ← <feature>.feature            (overwritten)
-│   │   └── steps/                  ← <feature>.steps.ts           (merged per file)
-│   ├── utils/
-│   │   └── locators/               ← LocatorHealer.ts etc.        (protected)
-│   └── config/
-│       └── cucumber.config.ts      ← profile blocks appended      (deduplicated)
-└── package.json
-```
-
----
-
-## Decision Flow
-
-```
-inspect_helix_project(helix_root)
-         │
-         ├─ framework_state: "absent" or "partial"
-         │        │
-         │        └─ scaffold_locator_repository(...)
-         │                   │
-         │                   └─ write_helix_files(..., mode="scaffold_and_tests")
-         │                      Writes infra files that don't exist + test files
-         │
-         └─ framework_state: "present"
-                  │
-                  └─ write_helix_files(..., mode="tests_only")
-                     Merges only locators / page / steps / feature
-                     Infrastructure files are NEVER touched
-```
-
----
-
-## Step-by-Step Workflow
-
-### Step 1 — Confirm helix_root
-
-Ask the user for the absolute path to the Helix-QA project root if not provided.
-This is the directory containing `package.json` and `src/`.
-
----
-
-### Step 2 — Inspect framework state
-
-```
-qa-helix-writer:inspect_helix_project(helix_root)
-```
-
-Read the response:
-
-```json
-{
-  "framework_state": "present",
-  "existing_infra":  ["LocatorHealer.ts", "LocatorRepository.ts", ...],
-  "missing_infra":   [],
-  "recommendation":  "tests_only",
-  "message":         "Helix-QA framework is present. ..."
-}
-```
-
-**Act on `recommendation` directly — do not ask the user to choose the mode.**
-
----
-
-### Step 3A — Framework absent or partial → scaffold first
-
-Only when `recommendation` is `"scaffold_and_tests"`:
-
-```
-# Generate infrastructure
-qa-playwright-generator:scaffold_locator_repository(
-  output_dir               = "src/utils/locators",
-  enable_ai_vision         = true,
-  repository_path          = "test-results/locator-repository.json",
-  dashboard_port           = 7890,
-  enable_timing_healing    = true,
-  enable_visual_regression = true,
-  enable_devtools_healer   = true
-)
-```
-
-Then proceed to Step 4 with `mode="scaffold_and_tests"`.
-
----
-
-### Step 3B — Framework present → skip scaffold
-
-When `recommendation` is `"tests_only"`, skip Step 3A entirely.
-Proceed to Step 4 with `mode="tests_only"`.
-
----
-
-### Step 4 — Read existing feature file before generating
-
-**MANDATORY before calling `generate_playwright_code`.**
-
-If a `.feature` file already exists on disk for this work item, read it first:
-
-```
-qa-helix-writer:read_helix_file(
-  helix_root    = "<helix_root>",
-  relative_path = "src/test/features/<feature>.feature"
-)
-```
-
-If `exists: true`, extract the following from the response and pass as generation context:
-
-1. **Existing scenario titles** — the generator MUST use these verbatim for any scenario it generates that covers the same test intent. Never produce a title that differs only by a word ("all 6" vs "all available") — that creates a phantom duplicate.
-2. **Existing step phrasings** — for steps the generator would otherwise write in a slightly different form (e.g. `the user logs in with "X" and "Y"` vs `the user logs in with username "X" and password "Y"`), use the existing phrasing exactly. Semantic equivalence is not enough; step text must match character-for-character for deduplication to work.
-3. **Scenarios to skip** — if the generator would produce a scenario whose steps are semantically equivalent to an existing one (same action, same data, same assertions — just different wording), omit it entirely from the generated output. Do not generate it at all; the helix writer cannot perform semantic reasoning.
-
-If `exists: false`, skip this step — the file will be created fresh.
-
----
-
-### Step 5 — Generate test files
-
-Run `generate_playwright_code` for the work item's Gherkin feature:
-
-```
-qa-playwright-generator:generate_playwright_code(
-  gherkin_content   = <validated .feature file content>,
-  page_class_name   = "<PageClass>",
-  app_name          = "<app>",
-  healing_strategy  = "role-label-text-ai",
-  enable_visual_regression = true,
-  enable_timing_healing    = true
-)
-```
-
----
-
-### Step 6 — Write files
-
-```
-qa-helix-writer:write_helix_files(
-  helix_root = "<helix_root>",
-  files      = <files dict from generate_playwright_code>,
-  mode       = "<recommendation from Step 2>"
-)
-```
-
-The tool handles everything automatically:
-
-**File routing:**
-
-| Generator key | Helix destination |
-|---|---|
-| `src/pages/<k>/locators.ts` | `src/locators/<k>.locators.ts` |
-| `src/pages/<k>/<k>.page.ts` | `src/pages/<k>.page.ts` |
-| `src/test/steps/<k>.steps.ts` | `src/test/steps/<k>.steps.ts` |
-| `*.feature` | `src/test/features/<k>.feature` |
-| `config/cucumber.js (add this profile)` | `src/config/cucumber.config.ts` (appended) |
-| `src/utils/locators/Locator*.ts` | `src/utils/locators/<file>` |
-
-**Deduplication per file type:**
-
-| File | Behaviour when file already exists |
-|---|---|
-| `locators.ts` | New const-object keys appended; existing keys skipped |
-| `*.steps.ts` | New step blocks appended; steps with matching regex skipped |
-| `*.page.ts` | New async methods appended; existing method names skipped |
-| `*.feature` | New scenario blocks appended; scenarios with matching titles skipped (existing step wording preserved) |
-| `cucumber.config.ts` | Profile block appended; duplicate profile names skipped |
-| Infrastructure `*.ts` | Protected in `tests_only`; written-if-absent in `scaffold_and_tests` |
-
-**Interface adaptation (applied automatically):**
-
-| Generated code | Rewritten to |
-|---|---|
-| `repo.updateHealed(k, s, …)` | `repo.setHealed(k, s)` |
-| `repo.getBBox(key)` | `null` |
-| `repo.incrementSuccess/Failure(…)` | removed |
-| `repo.queueSuggestion(…)` | removed |
-| `repo.updateBoundingBox(…)` | removed |
-| `fixture().logger` | `this.logger` |
-| `fixture().locatorRepository` | `this.repo` |
-| `fixture().page` | `this.page` |
-| `import { Logger } from "winston"` | `import { HealerLogger }` |
-| `EnvironmentManager` | Helix `environment` singleton |
-
----
-
-### Step 7 — Verify the response
-
-```json
-{
-  "summary": { "requested": 4, "written": 4, "skipped": 0 },
-  "deduplication": {
-    "src/locators/checkout.locators.ts": {
-      "type": "locators",
-      "added_keys":   ["checkoutBtn", "summaryTotal"],
-      "skipped_keys": ["submitBtn", "cancelBtn"]
-    },
-    "src/test/steps/checkout.steps.ts": {
-      "type": "steps",
-      "added_patterns":   ["user completes checkout"],
-      "skipped_patterns": ["user logs in"]
-    }
-  }
-}
-```
-
-Report the `deduplication` summary to the user so they can confirm which
-symbols were added vs skipped.
-
-**Skipped reasons to handle:**
-
-| Reason | Action |
-|---|---|
-| `"empty content"` | Normal — generator produced no content for that file |
-| `"profile '…' already exists"` | Normal — no action needed |
-| `"infrastructure file already exists"` | Normal in `tests_only` mode |
-| `"infrastructure file — skipped in tests_only mode"` | Normal |
-| Any `OSError` | Report path and error to user |
-
----
-
-## Scaffold vs Regenerate Infrastructure
-
-**First-time setup** (`framework_state` is `"absent"` or `"partial"`):
-
-```
-scaffold_locator_repository(...)   # generate 6 infra files
-write_helix_files(..., mode="scaffold_and_tests")
-# Writes missing infra files + test files
-```
-
-**Intentional infrastructure regeneration** (user explicitly requests it):
-
-```
-write_helix_files(..., mode="scaffold_and_tests", force_scaffold=true)
-# Overwrites ALL infra files — use deliberately
-```
-
-**Never** call with `force_scaffold=true` unless the user has explicitly asked
-to regenerate the healing infrastructure.
-
----
-
-## Quality Gates
-
-Before calling `write_helix_files`:
-
-- [ ] `inspect_helix_project` has been called and `recommendation` noted.
-- [ ] `list_helix_tree` has been called — existing file names recorded to prevent new-file creation.
-- [ ] **Existing `*.feature` file read** (`read_helix_file`) and its scenario titles + step phrasings were passed to the generator as context (Step 4 above). If this was skipped, STOP — regenerate with the existing file as context before writing.
-- [ ] **`pre_validate_cucumber_steps` called with `existing_steps_ts_contents`** — read every existing `*.steps.ts` in `src/test/steps/` via `read_helix_file` and pass as the `existing_steps_ts_contents` map. This enables check 6 (cross-file duplicate detection). Skipping this is the most common source of redundant step definitions across files.
-- [ ] `pre_validate_cucumber_steps` returned `valid: true` and `errors` is empty.
-- [ ] Every `*.steps.ts` in the `files` dict uses Cucumber expression syntax (not regex).
-- [ ] `mode` matches `recommendation` — never override without user instruction.
-- [ ] `force_scaffold` is `false` unless the user explicitly asked to regenerate.
-- [ ] The `files` dict comes directly from `generate_playwright_code` or
-      `scaffold_locator_repository` — never manually constructed.
-- [ ] After writing, the `deduplication` field has been reviewed and reported.
-
----
-
-## Failure Recovery Procedure
-
-When `write_helix_files` returns an error:
-
-### 1 — Parenthesis / bracket balance error in a steps file
-
-**Symptom:** Tool returns a message about parenthesis balance, bracket imbalance,
-or validator failure on a `*.steps.ts` file.
-
-**Root cause:** The step definitions contain regex patterns. Regex uses un-paired
-parentheses (`(`, `)`) that the file validator counts as unbalanced.
-
-**Fix:**
-1. Call `pre_validate_cucumber_steps` on the failing steps file content — it identifies
-   every offending pattern and provides a ready-to-paste Cucumber expression replacement.
-2. Convert any regex patterns to Cucumber expressions:
-   - `"([^"]*)"` → `{string}`
-   - `(\d+)` → `{int}`
-   - `/^…$/` wrapper → plain quoted string
-3. Retry `write_helix_files` with the corrected `files` dict.
-4. Do NOT call `create_file` at any point.
-
-### 2 — `OSError` / path error
-
-**Symptom:** Tool returns an `OSError`, `FileNotFoundError`, or similar path message.
-
-**Fix:** Report the exact path and error to the user. Do not attempt to create the
-directory or file manually unless the user explicitly instructs it.
-
-### 3 — Any other tool error
-
-**Fix:** Report the raw error text to the user verbatim. Ask: "How would you like
-to proceed?" Do not attempt any workaround autonomously.
-
----
-
-## Known Tool Limitations (Document These for Future Agent Runs)
-
-| Limitation | Description | Workaround |
-|---|---|---|
-| Parenthesis validator | Rejects step files with regex step patterns; error message names regex preprocessor as cause and prescribes Cucumber expressions | Use `pre_validate_cucumber_steps` before submitting to catch and fix offending patterns |
-| `update_helix_file` for single-file edits | Use `qa-helix-writer:update_helix_file` for targeted single-file changes instead of re-submitting the full `files` dict | Pass `relative_path` and the new content directly; set `force_overwrite=true` only when replacing existing content |

package/src/cmd-init.js

@@ -1,92 +0,0 @@
-/**
- * cmd-init.js — `qa-stlc init`
- *
- * Full bootstrap: install Python agents + skills + MCP config.
- */
-"use strict";
-
-const { execSync, spawnSync } = require("child_process");
-const path = require("path");
-const fs   = require("fs");
-
-const cmdSkills    = require("./cmd-skills");
-const cmdMcpConfig = require("./cmd-mcp-config");
-
-const C = {
-  reset: "\x1b[0m", bold: "\x1b[1m",
-  green: "\x1b[32m", cyan: "\x1b[36m",
-  yellow: "\x1b[33m", red: "\x1b[31m", dim: "\x1b[2m",
-};
-const ok   = (m) => console.log(`${C.green}✓${C.reset}  ${m}`);
-const info = (m) => console.log(`${C.cyan}→${C.reset}  ${m}`);
-const warn = (m) => console.log(`${C.yellow}⚠${C.reset}  ${m}`);
-const die  = (m) => { console.error(`${C.red}✗${C.reset}  ${m}`); process.exit(1); };
-
-module.exports = async function init(opts) {
-  console.log(`\n${C.bold}QA STLC Agents — init${C.reset}\n`);
-
-  // ── 1. Check Python ──────────────────────────────────────────────────────
-  const python = opts.python || "python3";
-  info(`Checking Python (${python})…`);
-  const pyCheck = spawnSync(python, ["--version"], { encoding: "utf8" });
-  if (pyCheck.status !== 0) {
-    die(`Python not found at '${python}'. Install Python 3.10+ or pass --python <path>.`);
-  }
-  const pyVersion = (pyCheck.stdout || pyCheck.stderr || "").trim();
-  const match = pyVersion.match(/Python (\d+)\.(\d+)/);
-  if (!match || parseInt(match[1]) < 3 || parseInt(match[2]) < 10) {
-    die(`Python 3.10+ required, found: ${pyVersion}`);
-  }
-  ok(`${pyVersion} found.`);
-
-  // ── 2. pip install qa-gentic-stlc-agents ────────────────────────────────────────
-  info("Installing qa-gentic-stlc-agents (pip)…");
-  const pip = spawnSync(python, ["-m", "pip", "install", "qa-gentic-stlc-agents>=1.0.1", "--quiet"], {
-    stdio: "inherit",
-    encoding: "utf8",
-  });
-  if (pip.status !== 0) {
-    die("pip install failed. Run manually: pip install qa-gentic-stlc-agents");
-  }
-  ok("qa-gentic-stlc-agents installed.");
-
-  // ── 3. Install skills ────────────────────────────────────────────────────
-  info("Installing skills…");
-  const skillTarget = opts.vscode ? "both" : "claude";
-  await cmdSkills({ target: skillTarget });
-
-  // ── 4. Write MCP config ──────────────────────────────────────────────────
-  info("Writing MCP config…");
-  await cmdMcpConfig({
-    vscode: opts.vscode || false,
-    print: false,
-    python: python,
-    playwrightPort: "8931",
-  });
-
-  // ── 5. Done ──────────────────────────────────────────────────────────────
-  const mcpLocation   = opts.vscode ? ".vscode/mcp.json" : ".mcp.json";
-  const skillsLocation = opts.vscode
-    ? ".github/copilot-instructions/  (reload VS Code window to activate)"
-    : ".claude/skills/";
-
-  console.log(`
-${C.bold}Setup complete.${C.reset}
-
-  ${C.dim}MCP config :${C.reset} ${mcpLocation}
-  ${C.dim}Skills     :${C.reset} ${skillsLocation}
-
-${C.bold}Start Playwright MCP${C.reset} ${C.dim}(keep running in a separate terminal):${C.reset}
-
-  ${C.cyan}npx @playwright/mcp@latest --port 8931${C.reset}
-
-${C.bold}STLC Workflow${C.reset} ${C.dim}— use agents in this order:${C.reset}
-
-  ${C.dim}1 →${C.reset} ${C.yellow}qa-test-case-manager${C.reset}     ${C.dim}ADO work item ID → create manual test cases in ADO${C.reset}
-  ${C.dim}2 →${C.reset} ${C.yellow}qa-gherkin-generator${C.reset}     ${C.dim}Epic / Feature / PBI → BDD .feature file attached to ADO${C.reset}
-  ${C.dim}3 →${C.reset} ${C.yellow}qa-playwright-generator${C.reset}  ${C.dim}Gherkin + live page snapshot → self-healing Playwright TypeScript${C.reset}
-  ${C.dim}4 →${C.reset} ${C.yellow}qa-helix-writer${C.reset}          ${C.dim}Generated files → merged into Helix-QA project on disk${C.reset}
-
-${C.dim}Skills reference all four steps — ask your agent: "@generate-playwright-code"${C.reset}
-`);
-};