evizi-kit 1.0.0

package/kits/shared/skills/web-auto-assisted-fix-and-run/references/resolve-api-error.md

@@ -0,0 +1,108 @@
+# Resolve API Errors
+
+Use this guide when a test fails due to an **incorrect API endpoint**, **wrong payload**, **unexpected HTTP status code**, or **auth failure** in an API call. Do not guess the correct value. Use the following cascade in order and fall through if unresolved.
+
+---
+
+## Diagnose the API Error First
+
+Before resolving, classify the error:
+
+| Error Type | Symptoms | Resolution Focus |
+|------------|----------|-----------------|
+| Wrong endpoint URL | 404 Not Found | Correct the path |
+| Wrong HTTP method | 405 Method Not Allowed | Correct GET/POST/PUT/DELETE |
+| Wrong payload | 400 Bad Request, schema validation error | Fix request body structure or field names |
+| Auth failure | 401 Unauthorized, 403 Forbidden | Fix token setup in test fixture or API helper |
+| Wrong base URL | Connection refused, ECONNREFUSED | Fix environment config or base URL constant |
+| Server error | 500 Internal Server Error | Usually a data/state issue — check test preconditions |
+
+---
+
+## Path A — FE Source Code (first choice)
+
+Search the workspace for FE source files (`.tsx`, `.jsx`, `.vue`, `.ts`, `.js`):
+
+1. Identify the failing API call from the test error — endpoint path, method, or service name
+2. Search FE files for the API call using patterns:
+   - `fetch(`, `axios.`, `api.`, `client.`, `request(`
+   - GraphQL: `gql`, `useQuery`, `useMutation`, `graphql(`
+   - Match on endpoint path fragments (e.g., `"/users"`, `"/login"`)
+3. Extract the correct values:
+   - Endpoint path and HTTP method
+   - Required headers (especially `Content-Type`, `Authorization` format)
+   - Payload structure — field names, types, and nesting
+   - GraphQL operation name, variables, and query/mutation body
+4. Open the failing test file or API helper, locate the incorrect values, apply fixes
+5. Verify no syntax errors after patching
+
+If no FE source files exist → fall through to Path B.
+
+---
+
+## Path B — Chrome DevTools MCP (second choice)
+
+Check if `chrome-devtools/*` MCP tools are available:
+
+1. Verify connection via `list_pages`
+2. Navigate to the relevant page and perform the action that triggers the API call
+3. Use `evaluate_script` to intercept and capture the network request:
+   ```js
+   // Example: capture the last fetch call's details
+   window.__lastRequest
+   ```
+   Or use the accessibility tree to trigger the action and observe network activity
+4. Extract from the captured request:
+   - Full URL (base + path)
+   - HTTP method
+   - Request headers
+   - Request body / payload structure
+5. Open the failing test file or API helper, replace incorrect values with the captured ones
+6. Verify no syntax errors after patching
+
+If Chrome DevTools MCP is not available → fall through to Path C.
+
+---
+
+## Path C — Playwright MCP (third choice)
+
+1. Navigate to the relevant page via `browser_navigate`
+2. Use `browser_run_javascript` to set up a request interceptor before triggering the action:
+   ```js
+   window.__requests = [];
+   const orig = window.fetch;
+   window.fetch = function(...args) {
+     window.__requests.push({ url: args[0], options: args[1] });
+     return orig.apply(this, args);
+   };
+   ```
+3. Trigger the action that causes the API call via MCP interaction tools
+4. Use `browser_run_javascript` to retrieve the captured request:
+   ```js
+   window.__requests[window.__requests.length - 1]
+   ```
+5. Extract the correct endpoint, method, headers, and payload from the captured data
+6. Open the failing test file or API helper, replace incorrect values
+7. Verify no syntax errors after patching
+
+---
+
+## Auth Failure Resolution (all paths)
+
+When the error is **401 Unauthorized** or **403 Forbidden**:
+
+1. Search the test fixture or API helper for how the auth token is set up
+2. Check that the token is being passed in the correct header (e.g., `Authorization: Bearer {token}`)
+3. Verify the token is not expired or hardcoded to a stale value
+4. Check if the test precondition includes a login step that generates the token
+5. If the token setup is missing, add it following the pattern used in other tests in the codebase
+
+---
+
+## Important Rules
+
+- **Never hardcode production credentials** — use test environment values or fixture-generated tokens
+- **Match the exact field names** — API payloads are case-sensitive; extract exact names from source
+- **Check base URL separately** — a ECONNREFUSED error means the base URL or port is wrong, not the endpoint path
+- **GraphQL errors** — a 200 status with `errors` in the response body is still an API error; check the operation name and variables
+- **Update all occurrences** — if the incorrect endpoint or payload appears in multiple places in the test file or helper, fix all of them

package/kits/shared/skills/web-auto-assisted-fix-and-run/references/resolve-selector.md

@@ -0,0 +1,60 @@
+# Resolve Selector Errors
+
+Use this guide when a test fails with a **LocatorError**, **TimeoutError on an element**, or a **selector-related assertion failure**. Do not guess the correct selector. Use the following cascade in order and fall through if unresolved.
+
+---
+
+## Path A — FE Source Code (first choice)
+
+Search the workspace for FE source files (`.tsx`, `.jsx`, `.vue`):
+
+1. Identify the element from the failing test line — its description, label text, or role
+2. Search FE files for matching attributes: `data-testid`, `id`, component name, button/label text
+3. Extract the exact attribute value
+4. Open the failing test file, locate the bad selector, replace it with the found value
+5. If the same element appears elsewhere in the test file, update all occurrences
+6. Verify no syntax errors after patching
+
+If no FE source files exist → fall through to Path B.
+
+---
+
+## Path B — Chrome DevTools MCP (second choice)
+
+Check if `chrome-devtools/*` MCP tools are available:
+
+1. Verify connection via `list_pages`
+2. Navigate to the relevant page and execute preceding test steps to reach the correct application state
+3. Take `take_snapshot` immediately before any interaction to get a fresh accessibility tree
+4. Locate the element in the snapshot by its role, name, or description
+5. Use `evaluate_script` with `args: [{ uid }]` to extract `data-testid`, `id`, or other stable attributes from the live DOM
+6. Open the failing test file, replace the bad selector with the extracted value
+7. If the same selector appears elsewhere in the file, update all occurrences
+
+**Important:** UIDs become stale after any DOM change — always take a fresh `take_snapshot` before using a UID for interaction or extraction.
+
+If Chrome DevTools MCP is not available → fall through to Path C.
+
+---
+
+## Path C — Playwright MCP (third choice)
+
+1. Navigate to the relevant page via `browser_navigate`
+2. Execute preceding test steps via MCP tools to reach the correct application state
+3. Take `browser_snapshot` immediately before any interaction
+4. Find the element by its text content, ARIA role, or description in the snapshot
+5. Use `browser_run_javascript` to extract `data-testid`, `id`, or other stable attributes
+6. Open the failing test file, replace the bad selector with the extracted value
+7. If the same selector appears elsewhere in the file, update all occurrences
+
+**Important:** `ref` values become stale after navigation or DOM changes — always take a fresh `browser_snapshot` before using a `ref`.
+
+---
+
+## Selector Priority (all paths)
+
+1. `data-testid` — always preferred
+2. `id` — if `data-testid` is absent
+3. ARIA role + accessible name — if no `id`
+4. Stable, unique CSS class — last resort only
+5. **Never use:** position-based selectors (`:nth-child`, `:first-of-type`), dynamic/generated classes, or XPath

package/kits/shared/skills/web-auto-assisted-fix-and-run/templates/issues-resolution-report-append.template.md

@@ -0,0 +1,54 @@
+# Issues Resolution Report — User-Assisted Append Template
+
+Use one of the sections below to **append** to the existing `issues-resolution-report.md` after a user-assisted fix attempt. Do NOT replace the file — add these sections after the existing content. Each invocation of the skill appends one section.
+
+---
+
+## User-Assisted Attempt — Success
+
+```markdown
+---
+
+## User-Assisted Fix
+
+| Field | Value |
+|-------|-------|
+| Run Status | SUCCESS (User-Assisted) |
+| User Hint | {summary of user hint} |
+| Fix Applied | {what was changed} |
+
+### Run Output
+
+\`\`\`
+{paste the successful run output here}
+\`\`\`
+```
+
+---
+
+## User-Assisted Attempt — Failure
+
+```markdown
+---
+
+## User-Assisted Fix
+
+| Field | Value |
+|-------|-------|
+| Run Status | FAILED (User-Assisted) |
+| User Hint | {summary of user hint} |
+| Fix Applied | {what was changed} |
+
+### Error Details
+
+| Field | Value |
+|-------|-------|
+| Error Type | {error type} |
+| File | {file path} |
+| Line | {line number} |
+| Message | {error message} |
+
+### Analysis and Recommended Next Steps
+
+{Brief analysis of why the hint did not resolve the issue, and specific recommendations for the next attempt.}
+```

package/kits/shared/skills/web-auto-chrome-devtools-mcp-extract-selectors/SKILL.md

@@ -0,0 +1,284 @@
+---
+name: web-auto-chrome-devtools-mcp-extract-selectors
+description: Update placeholder selectors in a ticket-design.md file by using a Chrome DevTools MCP server to navigate the running application and extract actual selectors from the live DOM. Reads ticket-design.md, finds all steps with "Update selector for this element" placeholders, operates the test case steps via the Chrome DevTools MCP browser, takes accessibility-tree snapshots to identify elements, and replaces each placeholder with the real selector. Use this skill whenever someone asks to update selectors using Chrome DevTools MCP, fill in missing selectors via Chrome DevTools, resolve placeholder selectors by browsing the app, extract real selectors from a running app via Chrome, or browse the live page to find element locators — even if phrased casually like "open the app and grab the selectors" or "use the browser to find the test IDs". Triggers on requests like "update selectors via Chrome DevTools for TKT-001", "fill in selectors using Chrome DevTools MCP for ABC-123", "resolve missing selectors by browsing for ticket fe-2026", "use devtools to extract selectors", "browse the app and find selectors for ticket X".
+---
+
+# Web Automation Update Selectors (Chrome DevTools MCP)
+
+Read a `ticket-design.md` file for a given ticket ID, find all steps that contain the `<-- Update selector for this element -->` placeholder, use a Chrome DevTools MCP server to navigate through the application following the test case steps, extract actual selectors from the live DOM, and update the ticket design in place.
+
+## Input Parameters
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `TICKET_ID` | string | Yes | The ticket identifier (e.g., TKT-001, ABC-123) |
+
+**If `TICKET_ID` is not provided:** Ask the user for the ticket ID before proceeding.
+
+## Prerequisites
+
+- A Chrome DevTools MCP server must be available and configured in the agent profile
+- The application under test must be running and accessible in a Chrome browser
+
+## Chrome DevTools MCP Tool Reference
+
+This skill uses the Chrome DevTools MCP server. The key tools and their signatures are:
+
+| Tool | Purpose | Key Parameters |
+|------|---------|----------------|
+| `navigate_page` | Navigate to a URL or go back/forward/reload | `type` (`"url"`, `"back"`, `"forward"`, `"reload"`), `url` (for type=url) |
+| `take_snapshot` | Capture the page's accessibility tree with element `uid`s | `verbose` (boolean, optional) |
+| `take_screenshot` | Capture a visual screenshot of the page or an element | `uid` (optional), `fullPage` (optional) |
+| `click` | Click on an element identified by its `uid` | `uid` (required), `dblClick` (optional) |
+| `fill` | Type text into an input, textarea, or select an option | `uid` (required), `value` (required) |
+| `fill_form` | Fill multiple form elements at once | `elements` (array of `{uid, value}`) |
+| `hover` | Hover over an element | `uid` (required) |
+| `press_key` | Press a key or key combination | `key` (e.g., `"Enter"`, `"Control+A"`) |
+| `evaluate_script` | Execute a JavaScript function in the page context | `function` (JS function declaration), `args` (optional, array of `{uid}`) |
+| `wait_for` | Wait for specified text to appear on the page | `text` (required), `timeout` (optional) |
+| `handle_dialog` | Accept or dismiss a browser dialog | `action` (`"accept"` or `"dismiss"`), `promptText` (optional) |
+| `list_pages` | List all open pages | — |
+| `select_page` | Select a page for subsequent operations | `pageIdx` (required) |
+
+**Critical concept:** Chrome DevTools MCP operates through an **accessibility-tree snapshot** model. Every `take_snapshot` call returns a tree of elements, each with a unique `uid`. All interaction tools (`click`, `fill`, `hover`, etc.) require the `uid` from the **most recent snapshot**. Always take a fresh snapshot before interacting with elements.
+
+## Workflow
+
+### Step 1: Locate and Read Ticket Design
+
+Search for the ticket design file using this glob pattern:
+
+```
+.tickets/{TICKET_ID}/ticket-design.md
+```
+
+**If not found:** Inform the user and stop:
+
+```
+Error: ticket-design.md not found for ticket {TICKET_ID}.
+Run the web-auto-ticket-design skill first to create it.
+```
+
+**If found:** Read the full file. For each test case, collect:
+- **All steps in order** — to replay them in the browser
+- **Steps with placeholders** — steps containing `- Selector: <-- Update selector for this element -->` and their element names, descriptions, and action context
+
+If no placeholder selectors are found, inform the user and stop:
+
+```
+No placeholder selectors found in ticket-design.md for ticket {TICKET_ID}.
+All selectors are already populated.
+```
+
+### Step 2: Read Project Locator Strategy
+
+Before extracting selectors, read the project's selector strategy from the source instructions.
+
+**Locate the instructions file:**
+
+`.documents-design/web-auto-project-blueprint.md`
+
+**If found:** Read the **Selector Strategy** section. Extract:
+- The priority order of locator types (e.g., `data-testid` first, then ARIA roles, etc.)
+- The locator format examples from the codebase
+- Any project-specific conventions or exceptions
+
+Use this strategy for all selector extraction in subsequent steps.
+
+**If not found:** Fall back to this default priority: `data-testid` > `role` + name > `aria-label` > CSS selectors.
+
+### Step 3: Verify Chrome DevTools MCP Connection
+
+Before starting the test run, verify the Chrome DevTools MCP server is available:
+
+1. Call `list_pages` to check that the browser is connected and pages are accessible
+2. If the call fails → report error and **stop**:
+   ```
+   Error: Chrome DevTools MCP server is not available.
+   Ensure the Chrome DevTools MCP extension is running and the browser is open.
+   ```
+3. If successful, note the available pages and select the appropriate one with `select_page` if needed
+
+### Step 4: Navigate and Extract Selectors
+
+Process **one test case at a time** — complete all steps of one test case before moving to the next. Browser state is cumulative (logged-in sessions, navigation history, form data), so jumping between test cases would corrupt the application state.
+
+**4.1 — Navigate to the starting point**
+
+Use `navigate_page` with `type: "url"` to open the application URL and navigate to the page where the test case begins (using the first step's action context — typically a navigation action).
+
+After navigation, call `wait_for` with expected page text to confirm the page has loaded. If the page content is uncertain, take a snapshot to verify the page state. When the page doesn't load as expected, take a `take_screenshot` to visually confirm what's on screen before proceeding.
+
+**4.2 — Walk through each step**
+
+Process each step in the test case sequentially. Before interacting with any element, **always take a fresh snapshot** using `take_snapshot` to get current element `uid`s.
+
+- **Steps with existing selectors or actions** — execute the action in the browser to advance the application state:
+  - **Click** → identify the element in the snapshot by matching its description, then call `click` with the element's `uid`
+  - **Type/Fill** → identify the input element, then call `fill` with the element's `uid` and the value
+  - **Fill form** → when multiple inputs need filling, use `fill_form` with an array of `{uid, value}` pairs
+  - **Navigate** → call `navigate_page` with the target URL
+  - **Key press** → call `press_key` with the key combination
+  - **Hover** → call `hover` with the element's `uid` (useful for revealing tooltips, dropdowns)
+
+  This ensures the page is in the correct state for subsequent steps.
+
+- **Steps with placeholder selectors** — before executing, pause and extract the selector:
+
+  1. **Take a snapshot** — call `take_snapshot` (with `verbose: true` for richer attribute data) to capture the current page accessibility tree
+  2. **Identify the target element** — match the element from the ticket design to a node in the accessibility tree using these heuristics (in order):
+     - **Role + name match** — the ticket says "Login button" → look for a node with `role: button` and name containing "Login"
+     - **Label match** — the ticket says "Email input" → look for a node with label/placeholder "Email"
+     - **Text match** — the ticket says "Submit link" → look for a link node with text "Submit"
+     - **Structural match** — the ticket says "First name in the form" → find the form section in the tree, then locate the input that corresponds structurally
+     - When multiple nodes match, use the page context from the test case (which section, which modal, which form) to disambiguate
+  3. **Extract selector attributes** — once the element is identified by `uid` in the snapshot, use `evaluate_script` to extract all attributes that could be used to build a selector:
+     ```javascript
+     (el) => {
+       return {
+         tag: el.tagName.toLowerCase(),
+         id: el.id,
+         testId: el.getAttribute('data-testid'),
+         dataCy: el.getAttribute('data-cy'),
+         dataTest: el.getAttribute('data-test'),
+         role: el.getAttribute('role'),
+         name: el.getAttribute('name'),
+         type: el.getAttribute('type'),
+         ariaLabel: el.getAttribute('aria-label'),
+         ariaLabelledBy: el.getAttribute('aria-labelledby'),
+         placeholder: el.getAttribute('placeholder'),
+         href: el.getAttribute('href'),
+         classes: el.className,
+         text: el.textContent?.trim().substring(0, 100)
+       };
+     }
+     ```
+     Pass the element's `uid` via the `args` parameter: `args: [{ uid: "<element-uid>" }]`
+  4. **Choose the best selector** — select the highest-priority attribute per the project's locator strategy from Step 2
+  5. **Record the resolved selector** — store it for updating the ticket design later
+  6. **Execute the step** — after extracting the selector, execute the action (click, fill, etc.) to advance the app state for subsequent steps
+
+**4.3 — Handle multi-state elements**
+
+Some elements only appear after certain interactions (dropdowns, modals, tooltips). When a placeholder element is not visible in the current snapshot:
+
+1. Check if a preceding action would reveal it (e.g., clicking a dropdown trigger)
+2. Execute that action (e.g., `click` on the trigger, or `hover` over a menu item), then call `take_snapshot` again to get updated `uid`s
+3. Use `wait_for` with expected text to confirm the dynamic content has appeared
+4. If the element still cannot be found after revealing interactions, take a `take_screenshot` to visually inspect the page state and confirm the element truly isn't present
+5. If still not found, mark it as unresolved with a reason
+
+**4.4 — Handle page transitions and loading**
+
+After actions that cause page navigation or significant DOM changes:
+
+1. Use `wait_for` with expected text from the target page to confirm loading is complete
+2. If the page shows a loading spinner or skeleton, wait for the actual content text to appear
+3. Always take a **new snapshot** after any navigation — previous `uid`s become stale
+
+**4.5 — Retry on interaction failures**
+
+Browser interactions can fail due to loading delays, animations, or elements not yet interactive. When a `click`, `fill`, or other interaction fails:
+
+1. Wait briefly (use `wait_for` with expected text, or pause for the element to settle)
+2. Take a fresh snapshot — the element's `uid` may have changed due to DOM re-render
+3. Re-identify the element and retry the interaction once
+4. If it fails again, take a `take_screenshot` to diagnose the situation and mark the step as problematic in the summary
+
+**4.6 — Detect design gaps**
+
+While walking through steps, watch for situations where the ticket design doesn't match reality:
+- A navigation step is missing (the app shows a different page than expected)
+- A prerequisite action isn't described (e.g., need to dismiss a cookie banner or accept terms first)
+- An element described in the design doesn't exist on the actual page
+- The step order doesn't match the actual user flow
+
+Record these gaps — they'll be reported in Step 7 so the ticket designer can fix them. Do not modify `ticket-design.md` to fix gaps; only replace placeholder selectors.
+
+### Step 5: Build Selector Values
+
+For each placeholder, apply the project's locator priority in strict order — use the first attribute that is present and stable:
+
+| Priority | Condition | Selector format |
+|----------|-----------|-----------------|
+| 1 | `testId` is present | `[data-testid="<value>"]` |
+| 2 | `name` is present on an input/select/textarea | `<tag>[name="<value>"]` (e.g. `input[name="email"]`) |
+| 3 | `role` + `ariaLabel` are both present | `[role="<value>"][aria-label="<value>"]` |
+| 4 | None of the above — use relative XPath | `//tag[contains(@class,"...") and text()="..."]` |
+| — | Element not found | Keep `<-- Update selector for this element -->` unchanged |
+
+**Avoid these anti-patterns** because they produce brittle, flaky selectors that break on routine code changes:
+- **`id`** — often auto-generated by frameworks (e.g., `#radix-12`, `#mui-input-3`) and changes across renders
+- **CSS class names** — typically generated by CSS-in-JS or build tools (e.g., `.styles_button__a1b2c`) and change on every build
+- **Absolute XPath** — encodes the full DOM path (e.g., `/html/body/div[2]/main/form/button`), breaks when any ancestor element changes
+- **Index-based selectors** — depend on element ordering (e.g., `button:nth-child(3)`) which changes when elements are added or reordered
+- **Text-only selectors** — break when copy is updated, translated, or A/B tested
+
+### Step 6: Update Ticket Design
+
+For each placeholder that has a resolved selector, update the `ticket-design.md` file in place:
+
+**Replace:**
+```
+  - Selector: <-- Update selector for this element -->
+```
+
+**With:**
+```
+  - Selector: [resolved-selector]
+```
+
+Do not modify any other lines in the step (`- Element:`, `- Action:`, `- Expected Result:`, `- Note:`). The `- Note: New element/action - needs to be implemented` line must remain — this skill only resolves selectors, not implement the automation code.
+
+Save the updated file at its original location.
+
+### Step 7: Summary
+
+Display the result to the user:
+
+```
+Selectors updated for ticket {TICKET_ID}.
+
+Updated:
+- .tickets/{TICKET_ID}/ticket-design.md
+
+Summary:
+- Selectors resolved: {resolved_count}
+- Selectors still pending: {pending_count}
+```
+
+If any selectors remain unresolved, add:
+
+```
+Unresolved elements:
+- [Test Case ID] Step [N]: [Element name] — [reason: not found in snapshot / element not visible / page state unclear]
+
+Note: These elements could not be identified in the live application.
+You can update them manually or try the FE source code approach.
+```
+
+If any design gaps were detected during navigation (Step 4.6), add:
+
+```
+⚠️ Design gaps detected — ticket-design.md was NOT modified for these:
+- [Test Case ID] Step [N]: [description of the gap]
+  Suggested fix: [what step or action is missing]
+
+Re-run the web-auto-ticket-designer agent to address these gaps before proceeding.
+```
+
+## Important Rules
+
+- **Follow project locator strategy** — always read and follow the Selector Strategy from the project blueprint; only use the default fallback when no blueprint is found
+- **Execute steps in order** — follow the test case step sequence to ensure the application is in the correct state before extracting each selector; skipping or reordering steps corrupts browser state
+- **One test case at a time** — complete all steps of one test case before moving to the next to maintain correct application state
+- **Extract from live DOM only** — selectors must come from actual page snapshots and `evaluate_script` calls; never fabricate or guess selector values
+- **Always use fresh snapshots** — before interacting with any element, take a new `take_snapshot`; previous `uid`s become invalid after DOM changes or navigation
+- **Use `uid` for all interactions** — Chrome DevTools MCP requires the `uid` from the latest snapshot for `click`, `fill`, `hover`, and other interaction tools; CSS selectors cannot be passed to these tools
+- **Use `evaluate_script` for attribute extraction** — execute JavaScript in the browser context to extract DOM attributes from identified elements, passing the element `uid` via `args: [{ uid }]`
+- **Use screenshots for debugging** — when an element can't be found or page state is unexpected, take a `take_screenshot` to visually inspect before marking as unresolved
+- **Preserve file structure** — only modify `- Selector:` lines; do not alter step numbers, descriptions, actions, expected results, or notes
+- **Report design gaps, never fix them** — if a missing navigation step, prerequisite action, or undescribed interaction is detected, report it in the summary under "Design gaps detected"; do not add, remove, or reorder steps in `ticket-design.md`
+- **Keep analysis internal** — do not output snapshot data or candidate lists to the user
+- **Handle failures gracefully** — if the MCP server is unavailable or the app is not running, inform the user and stop before making any changes
+- **File update failure** — report the error and ask how to proceed

package/kits/shared/skills/web-auto-coding/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: web-auto-coding
+description: Implement web automation test code based on a ticket playbook. Reads ticket-playbook.md, follows the implementation checklist to create or modify Page Objects, test data, API helpers, and test scripts while adhering to project coding standards. Use this skill whenever someone asks to implement a ticket, code test automation, write test code from a playbook, build out test scripts, implement Page Objects, or turn a playbook into working code — even casual requests like "code up ticket X" or "build the tests for ABC-123". Triggers on requests like "implement ticket TKT-001", "code the playbook for ABC-123", "write the test code for ticket fe-2026", "implement the tasks in the playbook", "start coding ticket X".
+---
+
+# Web Automation Coding
+
+Read a `ticket-playbook.md` file for a given ticket ID and systematically implement every task — creating or modifying Page Objects, test data, API helpers, and test scripts. The playbook is the single source of truth: it contains pre-computed file paths, dependency order, reference patterns, and coding conventions. Your job is execution, not architecture.
+
+## Input Parameters
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `TICKET_ID` | string | Yes | The ticket identifier (e.g., TKT-001, ABC-123) |
+
+**If `TICKET_ID` is not provided:** Ask the user for the ticket ID before proceeding.
+
+## Workflow
+
+### Step 1: Read the Ticket Playbook
+
+Search for the playbook file:
+
+```
+.tickets/{TICKET_ID}/ticket-playbook.md
+```
+
+**If not found:** Inform the user and stop:
+
+```
+Error: ticket-playbook.md not found for ticket {TICKET_ID}.
+Run the web-auto-ticket-playbook skill first to create it.
+```
+
+**If found:** Extract:
+- **Pre-Implementation Analysis** — component mapping (existing and new components)
+- **Implementation Checklist** — all tasks organized by subsections
+- **Total task count**
+
+The playbook already incorporates all coding standards from the project and feature instructions. Each task's Guidance and Reference Pattern embed the relevant conventions — there's no need to re-read the upstream instruction files.
+
+### Step 2: Plan and Track
+
+Build an internal execution plan before writing any code. This plan drives your task-by-task tracking:
+
+1. List all tasks from the playbook with their dependency numbers
+2. Sort by dependencies — prerequisite tasks first
+3. Group tasks that modify the same file so edits happen together (reduces context switching and avoids stale-read conflicts)
+4. Build a file inventory:
+   - **Files to create** — note the planned path for each
+   - **Files to modify** — note which tasks touch each file and in what order
+5. Create a progress tracker (todo list or internal checklist) with every task. Mark each task as you complete it — this prevents skipping tasks in large playbooks.
+
+### Step 3: Execute Tasks
+
+Work through each task in dependency order. For every task:
+
+#### 3.1 — Prepare context
+
+**Read existing files before modifying them.** When reading a file you're about to change, pay attention to:
+- Import statements (you'll need to add yours without duplicating existing ones)
+- Code structure and ordering (methods, exports, class members)
+- Naming conventions used in that specific file (they may have minor variations from the reference pattern)
+
+**Read the reference pattern file** specified in the task. Extract from it:
+- The structural pattern (class hierarchy, method signatures, return types)
+- How it handles setup/teardown or state
+- The assertion or action style used
+- Import paths and how they reference other components
+
+The reference pattern is a model, not a copy-paste source. Adapt it to match the current task's requirements — different selectors, different data, different assertions — while preserving the structural pattern.
+
+#### 3.2 — Write code
+
+- Follow the task's **Guidance** — this is the most specific instruction for what to build and how
+- Use the **Key Selector(s)** exactly as specified (resolved selectors are final; placeholders need resolution — see Error Recovery below)
+- Apply the structural pattern from the **Reference Pattern** but adapted to the current task
+- When adding to an existing file, place new code in the logical position: methods next to related methods, imports grouped with similar imports, exports at the bottom following the file's convention
+
+#### 3.3 — Save
+
+- Create or modify the file at the specified path
+- Include proper imports — check for duplication against existing imports
+- When multiple tasks modify the same file, each subsequent edit builds on the previous one (you already modified this file earlier in the session)
+- Maintain consistent code style: indentation, quotes, semicolons, trailing commas — match what the file already uses
+
+#### 3.4 — Verify
+
+- Check for syntax errors and linting issues in the modified file
+- If errors exist, fix them immediately. Common pitfalls:
+  - Missing or duplicate imports after adding new ones
+  - Mismatched brackets/braces from inserting code mid-file
+  - Wrong import path when the reference pattern lived in a different directory
+- Do not proceed to the next task until the current file is error-free. Uncaught errors cascade — a broken import in a Page Object makes every test script that imports it fail.
+
+#### 3.5 — Track progress
+
+Mark the task as complete in your progress tracker. If the playbook has many tasks, briefly note what was done (e.g., "Task 3: added `fillEmail()` to RegistrationPage") to maintain orientation.
+
+### Step 4: Final Verification
+
+After all tasks are complete:
+
+1. **Syntax check** — verify every created and modified file has no errors
+2. **Import resolution** — confirm every import points to an existing file/export. Pay special attention to:
+   - New files created in this session (verify the path matches what other files import)
+   - Barrel exports (index files) — if the project uses them, add the new export
+3. **Cross-file consistency** — check that method signatures used across files match (e.g., a Page Object method called from a test script has the same name and parameters)
+4. **Pattern adherence** — spot-check that the code follows the reference patterns from the playbook (correct base class, correct assertion style, correct hook usage)
+
+### Step 5: Summary
+
+Display the result:
+
+```
+Code implementation completed for ticket {TICKET_ID}.
+
+Files Created:
+- [path/to/new/file.ts]
+
+Files Modified:
+- [path/to/modified/file.ts]
+
+Summary:
+- Total tasks completed: {count}
+- Test data files: {count}
+- Page Object methods: {count}
+- Test scripts: {count}
+```
+
+## Error Recovery
+
+These situations come up regularly — handle them without stopping:
+
+| Situation | Action |
+|-----------|--------|
+| **Reference pattern file not found** | Search for files with similar names or in adjacent directories. If found, use it. If not, search the codebase for the same pattern type (e.g., another Page Object using the same base class) and use the closest match. Note the substitution in your progress tracker. |
+| **Selector placeholder** (`<-- Update selector -->`) | Check if a `ticket-design.md` exists in the same ticket directory with resolved selectors. If still unresolved, add a `TODO` comment in code with the placeholder text so the downstream reviewer catches it. |
+| **File path conflict** | If a file you need to create already exists, read it first. If it's a stub or empty scaffold, overwrite it. If it has real implementation, treat it as a modification task instead. |
+| **Circular dependency in playbook** | If two tasks depend on each other, break the cycle: implement the one with fewer external dependencies first, using forward-declared types or placeholder imports if needed, then complete the second task and update the first. |
+| **Playbook task is ambiguous** | Use the reference pattern as the tiebreaker. When guidance is unclear, the reference pattern shows the intended approach. If both are unclear, implement the simpler interpretation and note the ambiguity in the summary. |
+
+## Important Rules
+
+- **Read playbook first** — the playbook is the single source of truth; do not implement anything without reading and understanding it first
+- **Read before modifying** — always read existing files before editing them; this prevents accidentally overwriting recent changes and ensures your additions fit the file's structure
+- **Follow dependency order** — completing prerequisites first prevents broken imports and missing dependencies that waste time to debug
+- **Adapt reference patterns** — use the structural pattern from the reference but adjust for the current task's specifics; blind copy-paste of a reference pattern produces code that doesn't match the task
+- **Fix errors immediately** — a syntax error in one file cascades to every file that imports it; catching errors early prevents compounding failures
+- **Complete all tasks** — the downstream review and test-run steps expect all playbook tasks to be implemented; skipping tasks causes test failures
+- **Do not create files outside specified paths** — only create or modify files listed in the playbook; unexpected files confuse the project structure
+- **Track progress** — for playbooks with many tasks, use a progress tracker to avoid skipping or repeating tasks