@sun-asterisk/sungen 3.2.2 → 3.2.3-beta.3

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture-mobile.md

@@ -1,184 +0,0 @@
----
-name: sungen-capture-mobile
-description: 'Capture a live mobile app screen via Appium MCP — locator tree + screenshot for visual context. Auto-loaded by create-test when the screen is @platform:mobile/android/ios.'
-user-invocable: false
----
-
-## Purpose
-
-Launch a mobile app on a device/emulator, capture **one locator tree** (`generate_locators`) and **one screenshot**, and save them as visual context for test generation. The mobile analogue of `sungen-capture-live` — same job, Appium MCP instead of Playwright MCP.
-
-Use when the target is a native/Flutter/React-Native app (`@platform:android` or `@platform:ios`) running on a connected device or emulator.
-
----
-
-## Prerequisites
-
-- `appium-mcp` connected (see `/mcp`). It runs Appium **embedded** — no separate server needed.
-- A device/emulator booted: `adb devices` shows one for Android; a Simulator for iOS.
-- The app **installed** on the device (`adb install -r <app>.apk` for Android).
-- The screen's `Path:` (in `<screen>/features/*.feature` or `spec.md`) gives the app entry as
-  `<appPackage>/<appActivity>` (Android) or bundleId (iOS), e.g. `com.kngroup.media.converter/.MainActivity`.
-
----
-
-## Steps
-
-### 1. Resolve target app + entry
-
-Resolve in this order:
-1. `Path:` line in the feature / `App ID` in `spec.md` → split into `appPackage` + `appActivity`.
-   A dual-id Path (`<pkg>/<activity> | <iosBundleId>`) → take the part for the OS you are exploring
-   (left of `|` = Android pkg/activity, right = iOS bundle id).
-2. If missing → ask the user: *"What is the appPackage/appActivity (Android) or bundleId (iOS)?"*
-3. **Navigation recipe** — read the feature's `Background:` (the in-app web-path analog). Line 1
-   `Given User is on [Home] screen` is the launcher/landing screen the app opens on; each following
-   `When/And User tap [...]` (or gesture) is one hop toward the target screen. You will **replay**
-   these in step 4.5 so you scan the screen this feature targets — not the launcher. An anchor-only
-   Background (no nav steps) ⇒ the target IS the launcher screen ⇒ no navigation needed.
-
-### 2. Select device
-
-`select_device` with `platform: android` (or `ios`). If exactly one device, it auto-selects.
-If several, list them and ask the user which `deviceUdid`.
-
-### 3. Create the session
-
-`appium_session_management` `action=create`, `platform=android`, capabilities (JSON string):
-```
-appium:appPackage, appium:appActivity, appium:udid,
-appium:noReset=true, appium:autoGrantPermissions=true, appium:newCommandTimeout=300
-```
-For iOS, call `prepare_ios_simulator` first, then create with `appium:bundleId`.
-
-### 4. ⚠️ Wait for the screen to actually render
-
-**This is the #1 gotcha for Flutter / RN apps.** Right after launch the app often shows a blank
-splash — and the locator tree will contain **zero usable elements** (just an empty `FrameLayout`).
-Do **not** capture yet. Take a quick `appium_screenshot`; if it's blank/splash, wait and re-check
-until real content is drawn. Only then capture. (A Flutter app on a loading screen looks "invisible"
-to Appium; the same app on a rendered screen exposes its full Semantics tree.)
-
-### 4.5. ⚠️ Navigate to the target screen (replay the navigation recipe)
-
-**This is what makes capture land on the RIGHT screen** — the mobile equivalent of `page.goto(url)`
-on web. After the launcher screen has rendered, replay the `Background:` nav steps so Appium ends up
-on the screen this feature targets, *then* capture there.
-
-For each nav step **after** the `Given User is on [Home] screen` anchor, in order:
-1. `generate_locators` (or `appium_get_page_source`) on the CURRENT screen.
-2. Resolve the step's `[Label]` against the live tree — prefer `accessibility id`, then visible
-   `text`/`content-desc`, then an `xpath` on a distinctive substring. Gestures (`scroll to [X]`,
-   `swipe …`) follow `sungen-mobile-gestures`.
-3. Perform the tap/gesture, then **wait for the next screen to render** (same blank-splash guard as
-   step 4) before the next step.
-
-After the LAST step you are on the target screen — capture HERE (steps 5–6).
-
-- **Anchor-only Background** (no nav steps) ⇒ the target IS the launcher screen ⇒ skip this step.
-- **A step won't resolve** (its `[Label]` matches no element) ⇒ **STOP. Do not capture the wrong
-  screen.** Screenshot where you are and report: *"recipe step N: [Label] not found — fix the
-  Background nav path."* Fail loud (run-test would fail at the same step anyway).
-- **No recipe yet** (guided-stub Background, but the target is NOT the launcher) ⇒ drive to the
-  screen interactively off the live tree (if unsure which control leads there, ask the user), then
-  **report the exact nav steps you took** so create-test/add-screen can write them into the
-  Background. Do **not** edit the `.feature` yourself — Gherkin authorship stays with those commands.
-
-### 5. Capture the locator tree (primary AI context)
-
-Call **`generate_locators`** — this is the mobile equivalent of the web accessibility snapshot. It
-returns priority-ranked locators per interactable element: `accessibility id`, `id`, platform-native
-(`-android uiautomator` / `-ios predicate string`), and `xpath`, plus `content-desc`/`text`,
-`clickable`, `enabled`. This is what `sungen-tc-generation` and `sungen-selector-keys` consume.
-
-If the tree is huge, also `appium_get_page_source` (saved to a file) and grep it — never dump the
-full XML inline.
-
-### 6. Screenshot
-
-`appium_screenshot` → save to:
-```
-qa/screens/<screen>/requirements/ui/mobile-<timestamp>.png
-```
-`<timestamp>` = `YYYYMMDD-HHMM` local (e.g. `mobile-20260605-1645.png`).
-
-### 7. Detect discrepancies vs spec
-
-If `spec.md` exists, cross-check `generate_locators` labels against spec sections (fields in spec but
-not on screen, and vice-versa). Report; do **not** auto-edit `spec.md`.
-
-### 8. End the session
-
-`appium_session_management` `action=delete` to free the device. Always clean up.
-
-### 9. Report back
-
-> Captured mobile screen `<appPackage>`:
-> - Reached via: <N nav steps replayed from the Background recipe, or "launcher screen — no nav">
-> - Locators: <N> interactable elements (M with accessibility-id)
-> - Screenshot: `requirements/ui/mobile-<timestamp>.png`
-> - Discrepancies vs spec: <count, or "none">
-> - Discovered nav steps (only if the recipe was empty): <the taps you took, for create-test/add-screen to write into the Background>
-
-Hand back to the calling command.
-
----
-
-## Cross-platform discovery (`@platform:mobile` — explore one OS, layer the rest)
-
-When the screen is **`@platform:mobile`** (write-once-run-both), discover the **shared** cases first,
-then peel off only what is genuinely OS-specific. You do **not** need to explore both OSes up front —
-Flutter/RN expose the same Semantics on each, so one exploration covers most of it.
-
-1. **Explore whichever OS has a device up** (Android or iOS — symmetric for Flutter). Capture the tree.
-2. **Classify each component** into THREE buckets (not two):
-   - **Shared-exact** → a stable `accessibility id` equal on both OSes (Flutter Semantics → same value on
-     Android `content-desc` AND iOS `name`) → flat `type: accessibility-id` key in `<screen>.feature`.
-   - **Shared-variant** → SAME step/assertion on both OSes but the LOCATOR differs (composite
-     `content-desc` vs `-ios predicate`; partial/dynamic text via `descriptionContains` vs predicate
-     `CONTAINS`; a different attribute) → STILL `<screen>.feature`, with `android:`/`ios:` variant keys in
-     selectors.yaml. **A native locator alone is NOT a reason to split** — default for composite/partial text.
-   - **Sub-feature** → ONLY for genuine SCENARIO divergence: an element on ONE OS only, divergent
-     steps/flow, an OS-exclusive gesture/permission/dialog flow, or a case needing a per-platform
-     `nth`/`scope` (a variant can't diverge those). → `<screen>-android.feature` / `<screen>-ios.feature`.
-3. **Report the classification** so create-test/run-test scaffolds the right thing:
-   - `<screen>.feature`         `@platform:mobile`  ← shared-exact AND shared-variant (the vast majority)
-   - `<screen>-android.feature` `@platform:android` ← ONLY scenario-divergent Android cases
-   - `<screen>-ios.feature`     `@platform:ios`     ← ONLY scenario-divergent iOS cases
-4. **Verifying the other OS needs no second exploration** — just running the shared spec there
-   (`MOBILE_PLATFORM=both`) IS the check. Re-capture on the 2nd OS only for components that fail, and
-   move those into that OS's sub-feature. (Asking devs to add a Semantics label to an unlabeled element
-   converts an OS-specific case back into a shared one — prefer that when feasible.)
-
-## Selector-quality notes (carry into selectors.yaml)
-
-- **Prefer `accessibility id`** (Android `content-desc` / iOS `accessibilityIdentifier`) — most stable.
-- For **Flutter**, the Semantics label surfaces as `content-desc` ⇒ it usually equals the **visible
-  text**, so it is **locale-dependent** ("Good afternoon!", "English"). Keep such values in test-data
-  and use `{{variable}}` + locale overlays (see `sungen-locale`).
-- **Composite nodes**: cards may concatenate child text into one `content-desc` with `\n` → prefer an
-  xpath `contains(@content-desc,'…')` on a distinctive substring.
-- **Duplicate labels** → use `nth`. **Unlabelled controls** (search fields, icon buttons) → fall back
-  to `xpath` / class.
-
----
-
-## What this skill does NOT do
-
-- Does not run tests or generate `selectors.yaml` (that's `/sungen:run-test` + `sungen-selector-fix-mobile`)
-- Does not generate Gherkin (that's `sungen-tc-generation`) — it may *report* discovered nav steps,
-  but writing them into the Background is create-test/add-screen's job
-- Does not handle login/auth state (mobile auth is a separate concern — deep link / test build)
-- Captures **the feature's target screen** per invocation — reached by replaying the Background
-  navigation recipe (step 4.5), not just the launcher. For a *different* screen, give it its own
-  feature + recipe and re-invoke.
-
----
-
-## Relationship to other capture skills
-
-- `sungen-capture-figma` / `sungen-capture-local` — design/image sources (platform-agnostic)
-- `sungen-capture-live` — web (Playwright MCP)
-- `sungen-capture-mobile` — this skill, mobile (Appium MCP)
-
-All write to `requirements/ui/` and report back to the caller.

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture-mode-figma-mcp.md

@@ -1,82 +0,0 @@
-# Capture mode: figma-mcp
-
-Pull **structured design data** (layout, typography, colors, component tree, design tokens) and a **PNG screenshot** from a Figma frame URL via the **Figma Dev Mode MCP**, so `sungen-tc-generation` can author Gherkin + test-data before a live domain exists. Use when the project is pre-launch or Figma is the source of truth and the live build lags the design.
-
-## Prerequisites
-
-- **Figma MCP server** (`https://mcp.figma.com/mcp`, HTTP transport) connected in `.mcp.json` — `sungen init` scaffolds this. On first use, Claude Code opens a browser for Figma OAuth. Official tools: `get_design_context`, `get_variable_defs`, `get_screenshot`.
-- Figma account signed in with access to the file. **Dev/Full seats** get per-minute rate limits; **Starter/View seats** get monthly tool-call limits.
-- A Figma URL with both **fileKey** and **nodeId**.
-
-If the MCP is not connected, **do not fail silently** — tell the user:
-> "Figma MCP not detected. Run `sungen init` to scaffold the config, or manually add `figma` with `url: https://mcp.figma.com/mcp` to `.mcp.json`. Then sign in when Claude Code prompts."
-
-Then stop.
-
-## Steps
-
-### 1. Resolve Figma URL
-
-Prefer in this order:
-1. `Figma URL` field in `requirements/spec.md` (Overview section)
-2. If empty/missing → `AskUserQuestion`: *"Paste the Figma frame URL"* (free text)
-
-Accept any of these shapes:
-```
-https://www.figma.com/file/<fileKey>/<title>?node-id=<nodeId>
-https://www.figma.com/design/<fileKey>/<title>?node-id=<nodeId>
-https://www.figma.com/proto/<fileKey>/<title>?node-id=<nodeId>
-```
-Parse: `fileKey` = segment after `/file/`, `/design/`, or `/proto/`; `nodeId` = the `node-id` query param (pass `-` or `:` through as-is). If `node-id` is missing, ask the user to select a frame in Figma and copy the **frame URL** (not the file root).
-
-### 2. Fetch design context
-
-Call **both** in parallel:
-```
-get_design_context({ fileKey, nodeId })
-get_variable_defs({ fileKey, nodeId })
-```
-`get_design_context` → layout, typography, colors, component structure, spacing. `get_variable_defs` → named design tokens.
-
-### 3. Fetch screenshot
-
-```
-get_screenshot({ fileKey, nodeId })
-```
-Save the PNG to `requirements/ui/figma-<sanitized-nodeId>.png` (replace `:` and `-` with `_`, e.g. `42-15` → `figma-42_15.png`).
-
-### 4. Write metadata dump
-
-Combine design context + variables into `requirements/ui/figma-meta.md`:
-```markdown
-# Figma Capture — <nodeId>
-**Source:** <full Figma URL>
-**Captured:** <ISO date>
-## Components
-<component names + variants>
-## Typography
-<font families, sizes, weights, line heights>
-## Colors
-<color tokens + raw hex>
-## Spacing & Layout
-<spacing tokens, auto-layout specs>
-## Text Content
-<visible text strings — used by tc-generation to populate test-data>
-```
-Consumed by `sungen-tc-generation` as a secondary source alongside `spec.md`.
-
-### 5. Report back
-
-> Captured Figma frame `<nodeId>`: Components N · Text strings M · Design tokens K · Screenshot `requirements/ui/figma-<nodeId>.png` · Metadata `requirements/ui/figma-meta.md`
-
-Then hand back to the calling command.
-
-## Error handling
-
-| Error | Action |
-|---|---|
-| MCP tool not available | Print setup instructions, stop, do not fall back silently |
-| `fileKey` missing from URL | Ask user to paste a valid frame URL |
-| `nodeId` missing from URL | Ask user to right-click a frame in Figma → *Copy link to selection* |
-| `get_design_context` 403 | Ask user to check Dev Mode seat on that file |
-| `get_screenshot` returns no image | Continue with metadata only; warn no PNG was captured |

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture-mode-figma-pat.md

@@ -1,117 +0,0 @@
-# Capture mode: figma-pat
-
-Figma URL → `spec_figma.md` envelope + LLM-synthesized narrative from cached raw node JSON. This mode is the active one when any of these is true: a sungen command was invoked with `--figma`, `requirements/spec_figma.md` exists, or the user says "generate from Figma".
-
-## Prerequisites
-
-- [ ] `sungen figma auth check` succeeds — PAT is stored and valid
-- [ ] Figma file URL is available (shared file or frame link)
-- [ ] If auth missing → run `sungen figma auth set` and follow the walkthrough
-
-**Never paste the PAT into any transcript, spec file, or commit.**
-
-## Two-Layer Architecture
-
-`spec_figma.md` has two layers separated by the `<!-- SYNTHESIS-BELOW -->` marker:
-
-| Layer | Producer | Overwrite Rule |
-|---|---|---|
-| **Envelope** (above marker) | sungen CLI | Regenerated each `sungen figma` run — deterministic |
-| **Narrative** (below marker) | This mode (LLM) | Replaced on re-synthesis — everything from marker to EOF |
-
-The envelope contains: YAML frontmatter, Frame metadata, Screenshots. The narrative is synthesized by YOU from the cached raw Figma node JSON.
-
-## Inputs You Read
-
-The scaffolder persists a raw (unfiltered) Figma node tree to:
-```
-.sungen/figma-cache/<fileKey>/<versionId>/<nodeId>-raw.json
-```
-Read this file + the envelope frontmatter of `requirements/spec_figma.md` + any PNGs under `requirements/ui/`. You MUST NOT call the Figma REST API directly — the PAT is not available to you.
-
-## Synthesis Task
-
-Append 7 narrative sections below `<!-- SYNTHESIS-BELOW -->`. Each is inferred from the raw node tree (names, types, `characters`, layout bounds, auto-layout direction, componentProperties):
-
-### 1. Purpose
-One paragraph. What screen is this? Primary user goal? Infer from frame name + top-level text + dominant CTA.
-
-### 2. ASCII Layout
-Rough spatial sketch using box characters. Reflect top-bottom / left-right ordering from absoluteBoundingBox. Keep under ~20 lines:
-```
-┌──────────────────────────────────────┐
-│ [Logo]                     [Sign In] │
-├──────────────────────────────────────┤
-│  Welcome back                        │
-│  ┌────────────────────────────────┐  │
-│  │ email@example.com              │  │
-│  └────────────────────────────────┘  │
-│  [ Continue ]                        │
-└──────────────────────────────────────┘
-```
-
-### 3. Regions
-Bulleted list of major layout regions (header, sidebar, main, footer, modal…) with a one-line purpose each. Use auto-layout frames as region hints.
-
-### 4. Actions
-Every interactive element the user can trigger (button, link, icon-button, menu-item, toggle…):
-```
-- **<Action name>** — <what it does> (source: <node name>)
-```
-
-### 5. Form Fields
-Every input. Include label, type (text/email/password/select/checkbox/radio/textarea/date), required hint if inferable, placeholder:
-```
-| Label | Type | Required | Placeholder |
-|---|---|---|---|
-```
-Omit (write `_none_`) if no inputs exist.
-
-### 6. Data Columns
-If the screen shows a table/list/card grid — enumerate the columns/fields per row. Otherwise `_none_`.
-
-### 7. Navigation
-Outgoing links, tab bars, breadcrumbs, back buttons — anything that moves to another screen. Include explicit nav components and implicit CTAs that navigate.
-
-## Synthesis Workflow
-
-1. Read `requirements/spec_figma.md` — note `file_key`, `node_id`, `figma_version_id` from frontmatter
-2. Read `.sungen/figma-cache/<file_key>/<figma_version_id>/<safe_node_id>-raw.json` (colons in node_id become underscores)
-3. Traverse the tree. Collect names, types, `characters`, `componentProperties`, `absoluteBoundingBox`
-4. Produce the 7 sections above
-5. **Locate the insertion point** in `spec_figma.md`:
-   - **If `<!-- SYNTHESIS-BELOW -->` is present** → replace everything from the marker (inclusive) to EOF with: the marker line, a blank line, then the 7 sections.
-   - **If the marker is NOT present** (older file or hand-edited) → locate the last non-empty line of the envelope (usually the end of `## Screenshots`), append a blank line, then the marker, another blank line, then the 7 sections. Do NOT delete any envelope content.
-   - **If the file is missing entirely** → advise the user to re-run `sungen add --screen <screen> --figma <url> --refresh` to regenerate the envelope first. Do not fabricate one.
-6. Preserve the envelope (frontmatter + Frame + Screenshots) byte-for-byte. Never touch content above the marker.
-
-## Re-synthesis
-
-- If the envelope's `figma_version_id` changed → envelope is fresh; re-run synthesis
-- If only the narrative is stale → truncate from marker to EOF and regenerate
-- Never edit content ABOVE the marker — that is the scaffolder's territory
-
-## Selector Heuristics (for downstream `run-test`)
-
-During `run-test` Phase 0, provisional selectors can be seeded from the raw JSON:
-
-| Figma Signal | Provisional YAML Entry |
-|---|---|
-| Node name ends `Button`, has text | `role: button` + `name: "<text>"` |
-| Node name ends `Input`/`Field` | `placeholder: "<placeholder text>"` |
-| Node name ends `Link`, has text | `role: link` + `name: "<text>"` |
-| componentProperties has `data-testid` | `testid: <value>` |
-| Plain text leaf (outside interactive) | `text: "<content>"` |
-| Node name ends `Icon` | `role: img` + `name: "<accessible name>"` |
-
-Every provisional entry MUST carry:
-```
-# @needs-live-verify source=figma node_id=<id>
-```
-Provisional selectors feed `selectors.yaml` as candidates. `run-test` Phase 0 verifies them against the live page and overwrites incorrect entries.
-
-## Security
-
-- Never include the PAT in `spec_figma.md`, selectors, test data, or any committed file
-- Never log or echo the PAT in terminal output
-- Read only from `.sungen/figma-cache/` and screen directories — never from `.env`

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture-mode-live.md

@@ -1,60 +0,0 @@
-# Capture mode: live
-
-Navigate a running application, take **one accessibility snapshot** and **one screenshot**, and save them as visual context for test generation. Use when the app is live (dev, staging, or production with read-only access) and you want tests grounded in the actual rendered UI. Handles auth gracefully: if the page redirects to login, ask the user to sign in manually rather than injecting cookies.
-
-## Prerequisites
-
-- Playwright MCP connected.
-- Dev/staging server reachable (or a public URL).
-- `playwright.config.ts` exists at the project root (for `baseURL` fallback).
-
-## Steps
-
-### 1. Resolve target URL
-
-1. `Live URL` field in `requirements/spec.md` (Overview section)
-2. `baseURL` from `playwright.config.ts` + `URL Path` from `spec.md`
-3. Neither → `AskUserQuestion`: *"Paste the full URL for the page to scan"*
-
-### 2. Navigate
-
-`browser_navigate` to the resolved URL.
-
-### 3. Handle auth redirect
-
-If the page redirects to a login route (URL contains `/login`, `/signin`, `/auth`, or content indicates a login screen):
-1. Tell the user which login URL they landed on.
-2. `AskUserQuestion`:
-   - **I'll log in manually** — wait for confirmation, then re-navigate to the target URL
-   - **Skip live scan** — switch to mode `local`
-   - **Cancel**
-3. **Never** inject cookies or localStorage via `browser_evaluate` / `browser_run_code`. Auth belongs to the user.
-
-### 4. Snapshot
-
-Take **ONE** `browser_snapshot`. This accessibility tree is the primary AI context — roles, names, text, structure that tc-generation uses to identify sections and fields.
-
-### 5. Screenshot (recommended)
-
-Take **ONE** `browser_take_screenshot` with `fullPage: true`. Save to `requirements/ui/live-<timestamp>.png`, where `<timestamp>` is `YYYYMMDD-HHMM` local time (e.g. `live-20260421-1430.png`).
-
-### 6a. Verify unauthenticated redirect target (flow capture only)
-
-When capturing for a **flow** with security scenarios (e.g. "unauthenticated user cannot access X"):
-1. Open a **fresh incognito/unauthenticated** context (no storage state).
-2. `browser_navigate` to the protected route.
-3. Record the **actual redirect URL** — do NOT assume `/login`; it may be `/register`, `/`, etc.
-4. Report the redirect target: *"Unauthenticated access to `/dashboard` redirects to `/register`"*.
-5. The caller must use the **actual redirect URL** in Gherkin assertions, never an assumed one.
-
-Skip if the flow has no security scenarios or the user says to skip.
-
-### 6. Detect discrepancies vs spec
-
-If `spec.md` exists, cross-check the snapshot against spec sections: fields in spec but not in snapshot → *missing in UI*; elements in snapshot but not in spec → *missing in spec*. Report findings but **do not** auto-edit `spec.md`.
-
-### 7. Report back
-
-> Captured live page `<URL>`: Snapshot N interactive elements · Screenshot `requirements/ui/live-<timestamp>.png` · Discrepancies vs spec: <count or "none">
-
-Hand back to the calling command. Scans **exactly one** page per invocation.

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture-mode-local.md

@@ -1,38 +0,0 @@
-# Capture mode: local
-
-Use **pre-existing images** in `requirements/ui/` as visual context. No network, no MCP, no live site — works for any design tool (Figma export, Sketch, Penpot, Zeplin, hand-drawn, staging screenshots). This is the **baseline fallback**: if the live domain is down and Figma MCP isn't configured, this always works as long as the user drops images in the folder.
-
-## Steps
-
-### 1. List available images
-
-Glob `requirements/ui/*.{png,jpg,jpeg,webp,gif}` and report count + filenames. Filter out metadata files (e.g. `figma-meta.md` written by mode figma-mcp) — those are read by `tc-generation` separately, not treated as images here.
-
-### 2. Handle empty folder
-
-If no images found:
-1. Tell the user the folder is empty, with the full path so they can open it in Finder.
-2. `AskUserQuestion`:
-   - **I'll drop images now** — wait for confirmation, then re-glob
-   - **Switch to Figma** — switch to mode `figma-mcp`
-   - **Switch to live page scan** — switch to mode `live`
-   - **Cancel** — abort create-test
-3. If "drop images now", wait for confirmation (e.g. "done") then re-run step 1.
-
-### 3. Read images for context
-
-Use the `Read` tool on each image — Claude Code reads PNG/JPG/WebP directly as visual context. For large sets (>10 images), ask which are primary and which are states/variants to avoid loading too much at once.
-
-### 4. Summarize
-
-> Loaded N image(s) from `requirements/ui/`:
-> - `<filename-1>` — <one-line description of what's visible>
-> - `<filename-2>` — <one-line description>
-
-Hand back to the calling command.
-
-## File naming hints for users
-
-Nudge users toward consistent filenames (don't enforce):
-- `<section>-default.png` / `-error.png` / `-loading.png` / `-empty.png` — section states
-- `full-page.png` / `viewport.png` — whole screen (auto-generated by `sungen add --capture`)

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-capture.md

@@ -1,35 +0,0 @@
----
-name: sungen-capture
-description: 'Acquire visual/design context for test generation from one of four sources (modes): figma-mcp, figma-pat, live, local. Auto-loaded by create-test/add-screen when a visual source is needed, or when --figma flag / spec_figma.md is present. Router skill — read only the mode file you need.'
-user-invocable: false
----
-
-## Purpose
-
-Bring **visual + design context** into test generation so `sungen-tc-generation` can author Gherkin + test-data grounded in the real UI. This is a **router**: pick exactly **one mode** for the run, then read only that mode's file. Do **not** read all four.
-
-This skill never generates Gherkin or `selectors.yaml` — it only acquires context and reports back to the calling command.
-
-## Pick the mode
-
-| Mode | Read | Use when | Needs |
-|---|---|---|---|
-| **figma-mcp** | `mode-figma-mcp.md` | Pre-launch / Figma is source of truth, **Figma Dev Mode MCP** connected | Figma MCP + frame URL |
-| **figma-pat** | `mode-figma-pat.md` | `--figma` flag was used, or `requirements/spec_figma.md` exists (synthesize narrative from cached raw node JSON) | `sungen figma auth` PAT |
-| **live** | `mode-live.md` | App is running (dev/staging/prod read-only) and you want the actual rendered UI | Playwright MCP + reachable URL |
-| **local** | `mode-local.md` | Images already dropped in `requirements/ui/` (any design tool, screenshots, mockups) — baseline fallback, no network | nothing |
-
-### How the mode is chosen (when the caller didn't specify)
-
-1. `requirements/spec_figma.md` exists → **figma-pat** (PAT flow already ran during `add-screen`).
-2. `requirements/ui/` has images → **local**.
-3. Neither → ask the user which source (figma-mcp / live / local), then load that one mode file.
-
-Modes are **mutually exclusive per run**, but the user can run `create-test` again with a different mode to layer context. All modes write to `requirements/ui/` and report back.
-
-## What this skill (any mode) does NOT do
-
-- Does not generate Gherkin — that's `sungen-tc-generation`.
-- Does not write `selectors.yaml` — that's `/sungen:run-test`.
-- Does not inject auth/cookies — the user logs in manually (see `live`).
-- Does not crawl or generate images.

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-dashboard.md

@@ -1,121 +0,0 @@
----
-name: sungen-dashboard
-description: 'Build a single-file HTML dashboard summarising test cases & Playwright results. Auto-loaded by /sungen:dashboard.'
-user-invocable: false
----
-
-## Purpose
-
-Generate `qa/dashboard/index.html` — a single-file, share-ready test report covering all (or selected) screens and flows. The HTML embeds the snapshot data inline, so it can be emailed, Slacked, or committed and opened by anyone via `file://` without any server.
-
-**This skill delegates all heavy work to the `sungen dashboard` CLI.** The CLI is the source of truth for parsing logic — do NOT re-parse files in AI. Your role is only to:
-
-1. Invoke the CLI.
-2. Show its output verbatim.
-3. Help the user decide next actions.
-
----
-
-## Architecture
-
-```
-User → /sungen:dashboard [screen...]
-       │
-       ▼
-  sungen dashboard CLI  (deterministic — no AI tokens)
-  ├─ Discovery: qa/screens/* + qa/flows/*
-  ├─ Reuse delivery parsers (.feature, .spec.ts, test-data.yaml, results.json)
-  ├─ Build DashboardSnapshot JSON
-  ├─ Write qa/dashboard/history/<runId>.json (max 20 retained, oldest pruned)
-  ├─ Inject payload into pre-built HTML template
-  └─ Write qa/dashboard/index.html (~1MB, fully self-contained)
-```
-
-Source modules: `src/dashboard/*.ts` + `src/exporters/json-exporter.ts`.
-UI source: `dashboard/` (built once, ships in npm package as `dist/dashboard/templates/index.html`).
-
----
-
-## Required sources (CLI tolerates missing files)
-
-| # | Source | Path | Required? |
-|---|--------|------|-----------|
-| 1 | Feature file | `qa/screens/<name>/features/<name>.feature` (or `qa/flows/...`) | Yes — screens without a feature are skipped |
-| 2 | Test data | `qa/screens/<name>/test-data/<name>.yaml` | Optional — `{{vars}}` fall back to literal |
-| 3 | Compiled spec | `specs/generated/<name>/<name>.spec.ts` | Optional — flagged as "Not compiled" if missing |
-| 4 | Test results | `specs/generated/<name>/<name>-test-result.json` (or `test-results/results.json`) | Optional — TCs show as "Pending" if missing |
-
-Unlike `sungen delivery`, the dashboard CLI is **forgiving** — it always renders whatever data is available. Pre-flight is implicit, not blocking.
-
----
-
-## Output structure
-
-```
-qa/dashboard/
-├── index.html                      # share-ready single-file report
-└── history/
-    ├── 2026-04-26T...Z.json        # past snapshots, oldest → newest
-    ├── 2026-04-27T...Z.json
-    └── …                           # max 20, older pruned automatically
-```
-
-Both should be committed to git so collaborators see the same trend lines.
-
----
-
-## Dashboard views
-
-| View | What it shows |
-|------|---------------|
-| **Overview** | Stat cards (total/passed/failed/pending), pass-rate donut, priority bar chart, trend mini-chart, per-screen progress bars |
-| **Suites** | Tree: screen → scenarios; filter by search/status/priority; click → detail modal with steps, expected, error, trace |
-| **Trends** | Pass-rate line chart + stacked status bars across all retained runs (requires ≥2 runs) |
-| **Compare** | Pick base/head run; per-screen Δ table; lists of newly passing/failing/added/removed/changed tests |
-| **Export** | Browser-side CSV / XLSX download. One-button generation, no server. Same column layout as `sungen delivery` |
-
-Trends + Compare are disabled in the sidebar until at least 2 runs exist in history.
-
----
-
-## CLI command reference
-
-```bash
-# All screens + flows
-sungen dashboard
-
-# Specific targets
-sungen dashboard kudos awards flow/checkout
-
-# Skip history persistence (one-off / CI ephemeral)
-sungen dashboard --no-history
-
-# Cap retained history (default: 20)
-sungen dashboard --max-history 50
-
-# Auto-open in default browser
-sungen dashboard --open
-```
-
----
-
-## Skill responsibilities (when invoked from /sungen:dashboard)
-
-1. **Run the CLI** with whatever arguments came from `$ARGUMENTS`.
-2. **Show the CLI output verbatim** — do not summarize, paraphrase, or omit warnings.
-3. **Offer next-step options via `AskUserQuestion`** based on what just happened:
-   - On success → open dashboard, share file, run more tests, build for another screen, done.
-   - On error → diagnose from the error message; common causes are missing `qa/` directories or no targets.
-4. **Do NOT** parse `.feature`, `.spec.ts`, or results files yourself — that is the CLI's job.
-5. **Do NOT** touch files under `qa/dashboard/` directly — only the CLI writes there.
-
----
-
-## Sharing the dashboard
-
-The HTML is self-contained:
-- No CDN or external font — system font stack only.
-- All JS, CSS, charts, and the SheetJS library are inlined.
-- The snapshot payload sits in `<script id="__SUNGEN_DASHBOARD__" type="application/json">…</script>`.
-
-Acceptable sharing: email, Slack upload, S3 bucket, committed in git. The recipient opens it directly, no install required. ~1MB on disk, ~300KB gzipped over the wire.