evizi-kit 1.0.0

package/kits/shared/skills/web-auto-extract-lessons-learned/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: web-auto-extract-lessons-learned
+description: Extract lessons learned from a completed ticket implementation. Reads issues.md (review report) and issues-resolution-report.md (fix-and-run results) for a given ticket, analyzes what worked well, challenges encountered, and how issues were resolved, then generates a structured lessons-learned.md document with actionable recommendations. ALWAYS use this skill when asked to extract lessons learned, document what was learned, do a postmortem, analyze implementation outcomes, summarize what went wrong with a ticket, review what happened during a ticket, or reflect on a completed implementation. Triggers on requests like "extract lessons learned for TKT-001", "document lessons from ticket ABC-123", "what did we learn from fe-2026", "postmortem for ticket X", "what went wrong with ticket Y", "analyze ticket Z results".
+---
+
+# Web Automation Extract Lessons Learned
+
+This skill turns the raw outputs of the review → fix → run pipeline into a concise analysis that feeds back into the project's instruction documents. Without this feedback loop, the same mistakes recur across tickets — a wrong selector strategy gets re-used, an unclear instruction stays unclear, a missing best practice stays missing. The goal is to close that loop with the smallest set of high-impact recommendations.
+
+## Input
+
+| 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 before proceeding.
+
+## Workflow
+
+### Step 1: Gather Reports
+
+Both reports live in `.tickets/{TICKET_ID}/`. Read them in order — the review report establishes what the reviewer found; the resolution report shows how those findings were addressed and whether the tests ultimately passed.
+
+#### 1a — Review Report (`issues.md`)
+
+This is the primary input. Extract:
+- **Verdict** — APPROVED / APPROVED WITH WARNINGS / NEEDS CHANGES
+- **Issues by severity** — critical (count + descriptions), warnings (count + descriptions), suggestions (count + descriptions)
+- **Files reviewed** — list of files and their statuses
+
+If missing, inform the user and stop — without the review report there is nothing to analyze:
+```
+issues.md not found for ticket {TICKET_ID}. Run the review step first.
+```
+
+#### 1b — Resolution Report (`issues-resolution-report.md`)
+
+This report shows what happened after the review. It may contain one or two sections:
+
+**Section 1 — Autonomous Fix-and-Run** (always present):
+- Run status (SUCCESS or FAILED)
+- Issues fixed — severity, file, line, description, fix applied
+- If SUCCESS: final run output
+- If FAILED: runtime error diagnosis — error type, file, line, message, likely cause
+
+**Section 2 — User-Assisted Fix** (present only when the autonomous attempt failed):
+- Run status (SUCCESS with user help, or FAILED after all attempts)
+- User-assisted attempts — attempt number, hint given, fix applied, result
+- If all attempts exhausted: final unresolved error + recommended next steps
+
+If missing, proceed with a partial analysis based on the review report alone — document that runtime outcomes are unknown, and note this limitation in the output. A review-only analysis is still valuable because it captures the review issues and their categories.
+
+### Step 2: Read Context Files
+
+Read these files to understand intent and to check for recommendation duplicates later. This step is essential for producing useful recommendations — without knowledge of what's already documented, you risk repeating existing guidance.
+
+**Ticket artifacts** (same ticket directory):
+1. **Ticket Design** (`ticket-design.md`) — design decisions and selector choices
+2. **Ticket Playbook** (`ticket-playbook.md`) — what was planned vs. what happened
+
+**Project-level standards** (read each if it exists):
+
+| Document | Path | Purpose |
+|----------|------|---------|
+| Project Blueprint | `.documents-design/web-auto-project-blueprint.md` | Architecture, patterns, naming conventions |
+| Coding Instructions | `.documents-design/web-auto-instructions.md` | Project-level coding guide with copy-paste-ready patterns |
+| Best Practices | `.documents-design/web-auto-best-practices.md` | Reusable patterns and anti-patterns |
+
+If any of these are missing, note the gap and proceed with what's available.
+
+### Step 3: Analyze and Extract Lessons
+
+Work through these four dimensions. The goal is to be specific — generic observations like "be more careful" or "improve test quality" have no value.
+
+#### 3.1 — What Worked Well
+
+Look for patterns that succeeded without requiring fixes:
+- **Page Object design** — reusable methods, clean encapsulation, effective use of existing base classes
+- **Selector strategy** — selectors that were stable and didn't cause runtime errors (e.g., data-testid attributes, aria roles)
+- **Test structure** — clear arrange/act/assert, good use of fixtures or hooks
+- **Reuse** — effective use of existing utilities, helpers, or shared components that avoided reinventing the wheel
+
+If the review was clean (APPROVED with zero issues), note that briefly — no need to fabricate praise.
+
+#### 3.2 — Challenges Encountered
+
+Categorize problems from both the review and runtime phases. Web automation tickets tend to hit a few recurring categories:
+
+**Review-phase issues:**
+- Missing or weak assertions (e.g., checking only visibility, not content)
+- Selector problems (fragile selectors, hardcoded values, missing data-testid)
+- Code structure (Page Object violations, duplicated logic, missing abstraction)
+- Convention violations (naming, file organization, import patterns)
+
+**Runtime-phase issues** (from the resolution report):
+- `TimeoutError` — usually means a selector didn't match or a page didn't load in time. Look at whether the selector strategy was sound or the wait condition was wrong.
+- `LocatorError` / element not found — wrong selector, element not yet rendered, or stale reference. Check if the design document had the right selector.
+- `AssertionError` — test expectation didn't match reality. Check whether the expected value was correct or the test was checking the wrong thing.
+- Network/API errors — test environment issues, missing test data setup, or race conditions.
+
+Note how many attempts were needed (autonomous only, or user-assisted too) — this signals the severity and whether instructions need to be clearer.
+
+#### 3.3 — How Issues Were Resolved
+
+For each significant issue or runtime error, trace the chain:
+1. **Problem** — what was wrong
+2. **Root cause** — why it happened (e.g., instructions were ambiguous, pattern was missing from best practices, selector was a placeholder that never got updated)
+3. **Fix applied** — what change was made
+4. **Effectiveness** — did it work on first attempt, or require iteration?
+
+This chain is the raw material for recommendations. An issue where the root cause is "instructions didn't cover this scenario" points to a documentation gap. An issue where the cause is "one-off typo" doesn't.
+
+#### 3.4 — Recommendations
+
+This is the most important section — it's what actually improves the pipeline for future tickets.
+
+Categorize each recommendation by target document:
+- **Project Blueprint** — structural or architectural gaps (missing patterns, naming conventions)
+- **Coding Instructions** — project-level coding patterns or templates that were unclear or missing
+- **Best Practices** — reusable patterns, anti-patterns, or common pitfalls
+
+Prioritize by impact:
+- **High Priority** — caused failure or required multiple fix attempts
+- **Medium Priority** — easily fixed but should be prevented upfront
+- **Examples Needed** — specific code examples that would clarify an existing rule
+
+**Before adding any recommendation, check whether it's already covered.** Read the target document and verify the information isn't already there — even in different wording. This is the single most important quality check. The reason: source instruction files grow with every ticket. If recommendations aren't deduplicated, these files become bloated and contradictory, which actually makes future implementations worse.
+
+Apply these filters:
+- A recommendation must address a gap that directly caused a failure, document something completely absent from the target file, or clarify a demonstrably ambiguous instruction (cite the ambiguity).
+- Skip anything that's general good practice, already implied by existing rules, or unlikely to recur.
+- If a recommendation is closely related to an existing entry, suggest a clarification to that entry rather than adding a new one.
+- Aim for the smallest set that would have prevented the actual issues. Two or three precise recommendations beat ten vague ones.
+
+### Step 4: Generate Lessons Learned Document
+
+Write the document following the template at [templates/lessons-learned.template.md](templates/lessons-learned.template.md).
+
+Save to:
+```
+.tickets/{TICKET_ID}/lessons-learned.md
+```
+
+Generate the document even when the implementation failed — failures often provide the most valuable lessons.
+
+### Step 5: Summary
+
+Display:
+
+```
+Lessons learned extracted for ticket {TICKET_ID}.
+
+Created:
+- .tickets/{TICKET_ID}/lessons-learned.md
+
+Summary:
+- Status: [SUCCESS / FAILED / PARTIAL (review only)]
+- Critical Issues: X | Warnings: X
+- Runtime Error: [None / Fixed autonomously / Fixed with user help (X attempts) / Unresolved]
+- Recommendations: X high priority, X medium priority
+```
+
+## Key Principles
+
+- **Specificity over completeness** — a short document with precise root causes and targeted recommendations is more useful than a comprehensive report full of generic observations. Every issue traced should have a concrete root cause, not just a restatement of the symptom.
+- **Recommendations are the deliverable** — the analysis sections exist to support the recommendations. If the analysis doesn't point to a documentation gap worth fixing, it's fine to keep those sections brief.
+- **Never fabricate** — if data is missing (resolution report absent, context files not found), state it explicitly and work with what's available.
+- **Failures are high-signal** — when implementation failed or needed user-assisted fixes, that's where the most actionable lessons come from. Give those cases more analytical depth.

package/kits/shared/skills/web-auto-extract-lessons-learned/templates/lessons-learned.template.md

@@ -0,0 +1,115 @@
+# Lessons Learned Template
+
+Use this template as the output structure for `lessons-learned.md`.
+
+```markdown
+# Lessons Learned: {TICKET_ID}
+
+**Date:** {YYYY-MM-DD} | **Status:** {✅ SUCCESS / ❌ FAILED / ⚠️ PARTIAL (review only)}
+
+## 1. Summary
+
+| Field | Value |
+|-------|-------|
+| What was implemented | {1-2 sentence description} |
+| Coding instructions used | {path/to/instructions.md or "Not found"} |
+| Outcome | {Brief explanation of success/failure} |
+| Review verdict | {APPROVED / APPROVED WITH WARNINGS / NEEDS CHANGES} |
+| Critical issues fixed | {count} |
+| Warnings fixed | {count} |
+| Runtime error | {None / Fixed autonomously / Fixed with user support (X attempts) / Unresolved} |
+
+## 2. What Worked Well
+
+| # | Pattern / Approach | Why It Was Effective |
+|---|-------------------|---------------------|
+| 1 | {pattern} | {explanation} |
+| 2 | {pattern} | {explanation} |
+
+> If nothing notable, replace the table with: _No standout patterns identified — standard implementation._
+
+## 3. Issues & Resolutions
+
+### Critical Issues Fixed
+
+| # | File | Line | Category | Problem | Root Cause | Fix Applied | Lesson |
+|---|------|------|----------|---------|------------|-------------|--------|
+| 1 | {file} | {line} | {category} | {what was wrong} | {why it happened} | {how it was resolved} | {what this teaches} |
+
+> If no critical issues, replace the table with: _No critical issues found during review._
+
+### Warnings Fixed
+
+| # | File | Line | Category | Problem | Fix Applied |
+|---|------|------|----------|---------|-------------|
+| 1 | {file} | {line} | {category} | {what was wrong} | {how it was resolved} |
+
+> If no warnings, replace the table with: _No warnings found during review._
+
+### Runtime Error (if encountered)
+
+> If no runtime error occurred, replace this entire section with: _No runtime errors encountered._
+
+| Field | Value |
+|-------|-------|
+| Error Type | {error type} |
+| File | {file path} |
+| Line | {line number} |
+| Message | {error message} |
+| Likely Cause | {diagnosis} |
+| Resolution | {Fixed autonomously / Fixed with user support / Unresolved} |
+
+#### User-Assisted Fix Attempts (if applicable)
+
+| Attempt | User Hint | Fix Applied | Result |
+|---------|-----------|-------------|--------|
+| 1 | {summary of hint} | {fix applied} | {outcome} |
+| 2 | {summary of hint} | {fix applied} | {outcome} |
+
+> Omit this table if no user-assisted attempts were made.
+
+### Unresolved Issues (if failed after all attempts)
+
+| Field | Value |
+|-------|-------|
+| Error Type | {error type} |
+| File | {file path} |
+| Line | {line number} |
+| Message | {error message} |
+| User-Assisted Attempts | {summary of both attempts} |
+| Recommended Next Steps | {specific actions for manual intervention} |
+
+> If implementation succeeded, remove this entire subsection.
+
+## 4. Recommendations
+
+### High Priority
+
+Issues that caused failure or required multiple fix attempts.
+
+| # | Target Document | Instruction Gap / Issue | Problem | Impact | Recommended Action |
+|---|----------------|------------------------|---------|--------|--------------------|
+| 1 | {Project Blueprint / Coding Instructions / Best Practices} | {gap} | {what was missing or unclear} | {how it affected implementation} | {specific update needed} |
+
+> If none, replace the table with: _No high-priority recommendations._
+
+### Medium Priority
+
+Issues that were easily fixed but should be prevented.
+
+| # | Target Document | Recommendation |
+|---|----------------|---------------|
+| 1 | {Project Blueprint / Coding Instructions / Best Practices} | {specific recommendation} |
+
+> If none, replace the table with: _No medium-priority recommendations._
+
+### Examples Needed
+
+Specific examples that would help prevent similar issues in future implementations.
+
+| # | Target Document | Topic | What Example Would Help |
+|---|----------------|-------|----------------------|
+| 1 | {Project Blueprint / Coding Instructions / Best Practices} | {topic} | {description of helpful example} |
+
+> If none, replace the table with: _No additional examples needed._
+```

package/kits/shared/skills/web-auto-fe-extract-selectors/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: web-auto-fe-extract-selectors
+description: Update placeholder selectors in a ticket-design.md file by searching the front-end (FE) source code for actual selectors. Reads ticket-design.md, finds all steps with "Update selector for this element" placeholders, searches the FE codebase for matching elements, and replaces each placeholder with the real selector. Use this skill whenever someone asks to update selectors from FE source, fill in missing selectors using front-end code, resolve placeholder selectors via FE, or search the FE repo for element locators — even if phrased casually like "find the selectors in the frontend" or "look up test IDs from the source". Triggers on requests like "update selectors from FE for TKT-001", "fill in selectors using front-end code for ABC-123", "resolve missing selectors via FE for ticket fe-2026", "search the react code for selectors", "extract data-testid from source for ticket X", "look up selectors in the angular/vue/svelte code".
+---
+
+# Web Automation Update Selectors (FE)
+
+Read a `ticket-design.md` file for a given ticket ID, find all steps that contain the `<-- Update selector for this element -->` placeholder, search the front-end source code for the actual selectors, and update the ticket design in place.
+
+This skill works by static analysis of the FE source code — it does not require a running application. This makes it the right choice when the app is unavailable, when you want fast results without launching a browser, or when the live DOM differs from the source (e.g., server-rendered content). Because it reads source files, it can also discover selectors in code paths that the current UI state wouldn't reveal (hidden features, feature-flagged elements, conditionally rendered components).
+
+## 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: 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 file and extract every step that contains:
+
+```
+- Selector: <-- Update selector for this element -->
+```
+
+For each placeholder step, collect:
+- **Step number and test case ID** — to locate the step later for replacement
+- **Element name** — from the `- Element:` line
+- **Natural language description** — from the step description line
+- **Action context** — from the `- Action:` line (what interaction is expected)
+- **Page / feature context** — which page or feature area this step belongs to (from the test case title, background steps, or preceding navigation steps)
+
+Group placeholders by page/feature context — this drives the directory-scoped search in Step 4 and avoids redundant searches when multiple placeholders share the same feature area.
+
+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 searching for 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 (these are the exact formats to use in output — Playwright `getByTestId(...)`, CSS `[data-testid="..."]`, etc.)
+- Any project-specific conventions or exceptions
+
+Use this strategy for all selector resolution in subsequent steps.
+
+**If not found:** Fall back to this default priority: `data-testid` > `role` + name > `aria-label` > CSS selectors.
+
+### Step 3: Identify Front-End Source Root and Search Targets
+
+**3.1 — Locate the FE source root**
+
+The FE source code might live in the same workspace or in a separate directory. Determine the FE source root:
+
+1. Check `.documents-design/web-auto-project-blueprint.md` for a **Frontend Source Path** or similar configuration
+2. If not specified, look for common FE project markers in the workspace: `package.json` with a framework dependency (`react`, `vue`, `angular`, `svelte`, `next`, `nuxt`), or `src/` directories containing component files
+3. For monorepos, identify the relevant package (e.g., `packages/web-app/`, `apps/frontend/`) — look for workspace configurations in `package.json` (`workspaces` field), `pnpm-workspace.yaml`, or `nx.json`
+
+If the FE source root cannot be determined, ask the user:
+
+```
+Could not auto-detect the front-end source root.
+Please provide the path to the FE source directory.
+```
+
+**3.2 — Derive search targets from placeholders**
+
+From Step 1, for each placeholder element, derive:
+
+| Source | Derive |
+|--------|--------|
+| Element name | Component name, field label, button text |
+| Action context | Input type, button role, link text |
+| Natural language description | Feature area, section, modal/dialog name |
+| Page context | Route path, page component name |
+
+**3.3 — Map feature areas to directories**
+
+Identify likely feature directories by matching the feature area or page name to folder names in the FE source tree (e.g., "Create Group modal" → look for `groups/`, `create-group/`, `group/`, `GroupModal` directories). List the top-level directory structure under the FE source root to orient yourself before diving into searches.
+
+**File types to search (by framework):**
+
+| Framework | Extensions |
+|-----------|-----------|
+| React / Next.js | `.tsx`, `.jsx`, `.ts`, `.js` |
+| Vue / Nuxt | `.vue`, `.ts`, `.js` |
+| Angular | `.component.ts`, `.component.html`, `.ts` |
+| Svelte / SvelteKit | `.svelte`, `.ts`, `.js` |
+| Generic | `.html`, `.ts`, `.js` |
+
+Focus on the relevant framework's extensions to avoid noise.
+
+### Step 4: Search Front-End Source Code
+
+Complete all analysis internally — do not output intermediate results to the user.
+
+The search follows a funnel strategy: start narrow (feature-scoped), then widen progressively. This matters because the same selector name (e.g., `data-testid="submit-button"`) may appear in multiple features — the narrow search establishes the correct context first.
+
+**4.1 — Narrow search (feature-scoped)**
+
+For each placeholder, search first within the likely feature directories identified in Step 3:
+
+| Search Target | Patterns |
+|---------------|----------|
+| Test IDs | `data-testid="..."`, `data-test="..."`, `data-cy="..."`, `data-test-id="..."` |
+| Roles | `role="button"`, `role="dialog"`, `role="textbox"`, etc. |
+| Aria labels | `aria-label="..."`, `aria-labelledby="..."` |
+| Playwright helpers | `getByTestId`, `getByRole`, `getByLabel`, `getByText`, `getByPlaceholder` |
+| CSS class/id | `className="..."`, `id="..."` |
+| Component names | Component definitions matching the element name |
+
+**Framework-specific patterns to also search:**
+
+| Framework | Additional Patterns |
+|-----------|-------------------|
+| React | `styled.button`, `styled(Component)`, `forwardRef` wrapping, spread props (`{...props}`) passing `data-testid` |
+| Vue | `v-bind:data-testid`, `:data-testid`, template `ref="..."` |
+| Angular | `[attr.data-testid]`, `#templateRef`, `[data-testid]` in template |
+| Svelte | `data-testid={value}`, `bind:this` |
+
+**4.2 — Confirm match by reading the file**
+
+When a candidate is found, read the surrounding code (at least 30-50 lines around the match) to confirm:
+- The element is in the correct page/feature context (not a similarly named element on a different page)
+- The selector uniquely identifies this element (not shared across multiple elements)
+- The component is actually rendered in the feature path (check imports and route definitions if ambiguous)
+
+If multiple candidates remain after reading, disambiguate using:
+1. **Route/page context** — which page component renders this element?
+2. **Import chain** — trace the component imports back to the page that matches the test case
+3. **Prop drilling** — does a parent pass a unique `testId` prop that distinguishes this instance?
+
+Keep only the candidate in the correct page/component context.
+
+**4.3 — Handle dynamic and constructed test IDs**
+
+If no literal string match is found, search for partial or template literal patterns:
+
+| Pattern Type | Search Strategy |
+|-------------|----------------|
+| Template literals | `` data-testid={` ``, `` `${prefix}-submit` ``, `` `row-${id}` `` |
+| Concatenation | `"prefix-" + varName`, `testIdBase + "-submit"` |
+| Partial matches | Search for the significant substring (e.g., `submit-btn`, `create-group`) |
+| Prop-based | `data-testid={props.testId}`, `data-testid={testId}` — then trace the prop value from the parent |
+| Constant/enum | `TEST_IDS.SUBMIT_BUTTON`, `TestIds.loginForm` — search for the constant definition |
+
+When found: read the file to understand how the runtime value is constructed and derive the actual runtime value.
+
+**4.4 — Broad fallback**
+
+If the narrow search (4.1–4.3) finds no candidate, repeat the same search across the full FE source tree (all FE source files of the target extensions). To keep this tractable in large codebases, prioritize:
+1. Component files (files containing JSX, template syntax, or component decorators)
+2. Page/route files
+3. Shared/common component files
+4. Utility/helper files (least likely to have selectors)
+
+**4.5 — Component hierarchy fallback**
+
+When a JSX/template element is found at the call site but has no selector attribute, the `data-testid` may be defined inside the component's implementation. Trace the component hierarchy:
+
+1. Find the component's import statement at the call site to get its source file
+2. Read the component definition file and search for selector attributes inside it
+3. If the component wraps another component (e.g., a design system `<Button>` wrapping a native `<button>`), continue one more level down
+4. Stop after 2 levels of component nesting — deeper nesting rarely has locator attributes and risks false positives
+
+**4.6 — Evaluate match quality**
+
+For each candidate, classify:
+1. **Exact match** — selector clearly maps to the described element (e.g., `data-testid="login-button"` for "Login button") and is in the correct feature context
+2. **Contextual match** — selector is in the correct component/page and matches the element type, but the naming isn't an obvious direct match
+3. **Ambiguous match** — selector was found but context couldn't be fully verified (e.g., shared component used in multiple places with no distinguishing prop)
+4. **No match** — no suitable selector found in the FE source after all fallbacks
+
+Only use Exact or Contextual matches for replacement. Ambiguous matches should be reported as unresolved with a note explaining why.
+
+### Step 5: Build Selector Values
+
+For each placeholder, determine the final selector value:
+
+| Match Result | Selector Value |
+|--------------|----------------|
+| Exact or contextual match found | The actual selector using the project's locator strategy from Step 2 |
+| Multiple candidates found | Choose the selector that ranks highest in the project's locator strategy priority order |
+| Found via component hierarchy (4.5) | The selector from inside the component definition |
+| Ambiguous match | Keep `<-- Update selector for this element -->` unchanged — report in summary |
+| No match after all fallbacks | Keep `<-- Update selector for this element -->` unchanged |
+
+**Selector format:** Use the locator format from the project's Selector Strategy (Step 2). If the project blueprint includes code examples, follow those formats exactly.
+
+If no project blueprint exists, use this default format:
+
+| Attribute Found | Default Format |
+|----------------|----------------|
+| `data-testid` | `[data-testid="value"]` |
+| `role` + accessible name | `role=button[name="Submit"]` |
+| `aria-label` | `[aria-label="value"]` |
+| `name` on input | `input[name="email"]` |
+
+### 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]
+```
+
+Only modify `- Selector:` lines. Do not touch `- Element:`, `- Action:`, `- Expected Result:`, or `- Note:` lines. The `- Note: New element/action - needs to be implemented` line must remain — this skill only resolves selectors, it does 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]
+
+Possible reasons:
+- Not found: no matching element in the FE source tree
+- Ambiguous: multiple candidates across features — could not determine the correct one
+- Dynamic: selector is constructed at runtime from variable data
+
+Next steps: update manually, provide the FE component paths, or try the Chrome DevTools / Playwright MCP approach to extract selectors from the live application.
+```
+
+## 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
+- **Narrow before broad** — search feature-scoped directories first; fall back to the full codebase only when narrow search finds nothing. This is important because the same selector string can appear in unrelated features — context narrows the right match
+- **Confirm before committing** — always read the matched file to verify context (30-50 lines of surrounding code); do not use a selector based solely on a grep search hit
+- **Match precisely** — only replace a placeholder when confident the selector maps to the correct element on the correct page. When in doubt, leave the placeholder and report it as unresolved rather than risk a wrong selector that will cause flaky tests
+- **Never invent selectors** — only use selectors found in the actual front-end source code; never fabricate or guess selector values
+- **Only modify `- Selector:` lines** — do not alter step numbers, descriptions, actions, expected results, or notes
+- **Keep analysis internal** — do not output search results, candidate lists, or file contents to the user
+- **File update failure** — report the error and ask how to proceed

package/kits/shared/skills/web-auto-fe-extract-selectors/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "web-auto-fe-extract-selectors",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Update selectors from FE for ticket LOGIN-042. The ticket design has 5 placeholder selectors for a login page: email input, password input, submit button, 'forgot password' link, and 'remember me' checkbox. The React FE source uses data-testid attributes consistently. The project blueprint specifies data-testid as the primary locator strategy.",
+      "expected_output": "All 5 placeholders should be resolved to data-testid selectors found in the FE login component. The ticket-design.md should be updated in place with resolved selectors on the - Selector: lines. No other lines should be modified. Summary should show 5 resolved, 0 pending.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Fill in selectors using front-end code for ticket GROUPS-108. The ticket design has 8 placeholders across 2 test cases — a 'Create Group' modal flow and a 'Group List' table view. Some elements use dynamic data-testid values (e.g., row-${groupId}), one element is inside a shared design system <Button> component that wraps the native button with data-testid, and 2 elements have no test IDs at all in the FE source. The project is a Vue/Nuxt monorepo with packages/web-app/src/ as the FE root.",
+      "expected_output": "Should resolve 5-6 selectors (static test IDs + the one found via component hierarchy tracing inside the Button wrapper). Dynamic test IDs should be reported as unresolved with reason 'Dynamic'. Elements with no test IDs should be reported as unresolved with reason 'Not found'. Summary should show resolved and pending counts. Monorepo structure should be navigated correctly to find the right package.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Resolve missing selectors via FE for ticket DASH-055. The ticket design has 3 placeholders for a dashboard analytics page. The Angular FE codebase uses [attr.data-testid] in templates and some elements only have aria-label attributes. No project blueprint file exists. Two of the selectors are on elements that share the same component name (MetricCard) but appear in different page sections with different aria-labels.",
+      "expected_output": "Should fall back to default priority (data-testid > role+name > aria-label > CSS). Should correctly disambiguate the two MetricCard instances by reading surrounding template context and matching to the correct page section. Should resolve selectors using aria-label format when data-testid is absent. Summary should show all resolved or explain any that couldn't be disambiguated.",
+      "files": []
+    }
+  ]
+}