evizi-kit 1.0.0

package/kits/shared/skills/web-auto-generate-instructions/references/analysis-guide.md

@@ -0,0 +1,145 @@
+# Codebase Analysis Guide
+
+Reference for Steps 2–3 of the workflow. Each section maps directly to a section in the output template.
+
+> **Before starting**: Read `.documents-design/web-auto-project-blueprint.md` and `.documents-design/web-auto-best-practices.md` first (Step 1 of the workflow). Build a mental note of what is already documented there so you do not repeat it.
+
+---
+
+## Pre-analysis: Understand the Project Context
+
+These steps are for orientation only — their findings do NOT go into the instructions file.
+
+**Detect the framework** using dependency files and config file signals:
+
+| Framework | Detection Signals |
+|-----------|------------------|
+| Playwright | `playwright.config.*`, `@playwright/test` import |
+| Cypress | `cypress.config.*`, `cypress/` directory |
+| WebdriverIO | `wdio.conf.*`, `@wdio/` imports |
+| Selenium | `selenium-webdriver` / `selenium` package, `WebDriver` class |
+| Robot Framework | `.robot` / `.resource` files, `Library  SeleniumLibrary` |
+| Nightwatch | `nightwatch.conf.*` |
+| Puppeteer | `puppeteer` package, `browser.newPage()` |
+| TestCafe | `testcafe` package, `.testcafe` config |
+
+Secondary signals by language: `package.json` (JS/TS) · `requirements.txt` / `pyproject.toml` (Python) · `pom.xml` / `build.gradle` (Java) · `Gemfile` (Ruby) · `*.csproj` (C#)
+
+**Find all relevant files** before reading any of them:
+
+```
+Test specs:    **/*.spec.*, **/*.test.*, **/*_test.*, **/*Test.*, **/test_*.*, **/*.cy.*
+Page objects:  **/*.page.*, **/*Page.*, **/*_page.*, **/*PO.*
+Helpers:       **/helpers/**/*,  **/utils/**/*,  **/support/**/*
+Data/fixtures: **/fixtures/**/*,  **/data/**/*,  **/factories/**/*
+Config:        *.config.*, wdio.conf.*, conftest.*, jest.config.*
+```
+
+Adjust patterns to match the project's actual file extensions and naming style. Read samples from **at least 5 different feature areas** — not just one.
+
+---
+
+## → Template Section 1: Page Object Patterns
+
+Read **3–5 representative Page Object files**. Extract:
+
+| Aspect | What to Look For |
+|--------|-----------------|
+| **Class structure** | Class declaration, inheritance, export/instantiation pattern |
+| **Selector definitions** | How selectors are stored — properties, getters, factory methods; static vs parameterized |
+| **Selector declaration rules** | Any framework-specific constraints on how selectors must be written (e.g., sync vs async) |
+| **Action methods** | How user interactions are encapsulated; naming convention |
+| **Verification methods** | Whether assertions live in Page Objects or in test files |
+| **Step wrappers** | Whether a step/substep reporting wrapper is used (allure.step, custom wrappers) |
+| **Component reuse** | Whether smaller components (modals, tables, forms) are composed into page objects |
+
+> If you find selector strategy rules (priority order: test IDs, ARIA, CSS, XPath) or anti-patterns during this analysis, add them to `.documents-design/web-auto-best-practices.md`.
+
+---
+
+## → Template Section 2: Test Structure & Patterns
+
+Read **5–8 test files** across different features. Extract:
+
+| Aspect | What to Look For |
+|--------|-----------------|
+| **Test file template** | Import order, describe/suite structure, one complete test case |
+| **Hook patterns** | What belongs in `before` / `beforeAll` vs `beforeEach`; cleanup placement |
+| **Assertion style** | Which library is used; assertion style (BDD, TDD, custom matchers) |
+| **Step organization** | How actions and verifications are grouped; step ownership rules per page object |
+| **Tags / annotations** | How tests are categorized for selective execution |
+
+---
+
+## → Template Section 3: Test Data Management
+
+Look for dedicated data files, fixture files, or factory modules. Extract:
+
+| Aspect | What to Look For |
+|--------|-----------------|
+| **Data file structure** | Location, naming, what a typical data file contains |
+| **Type definitions** | How test data shape is expressed (interfaces, dataclasses, POJOs, type hints) |
+| **Dynamic value generation** | What utility generates unique/random values |
+| **Shared constants** | Enums, lookup tables, or constant sets reused across tests |
+| **Cleanup pattern** | How data created by tests is removed; whether cleanup is in a hook or inline |
+
+> Omit Section 3 from the output if the project has no dedicated data files — inline or ad-hoc data is sufficient to note in the test file template.
+
+---
+
+## → Template Section 4: API & Backend Helpers
+
+Look for programmatic test data setup/teardown. Common locations: `helpers/`, `utils/`, `support/`, `api/`, `factories/`, `seeds/`, or files named after entities.
+
+| Aspect | What to Look For |
+|--------|-----------------|
+| **Auth pattern** | How a token, session, or credential is obtained for API calls |
+| **Data setup** | How test data is created programmatically before tests |
+| **Data teardown** | How test data is removed after tests |
+| **Find / search** | How existing records are located (needed to get IDs for cleanup) |
+| **Available modules** | Which helper modules exist and what entities they cover |
+| **Conventions** | Project-wide rules: default role, retry/sleep patterns, query style, error handling |
+
+> Omit Section 4 from the output if the project has no programmatic API helpers.
+
+---
+
+## → Template Section 5: Common Workflow Patterns
+
+Look for patterns that appear repeatedly across multiple test files. Extract real code for:
+
+- Login and navigation flows
+- Search and selection from a list
+- Form fill and submission
+- Modal / dialog confirmation
+- Async UI feedback (spinners, loading states, toast notifications)
+
+> Omit Section 5 from the output if no recurring multi-step patterns were found.
+
+---
+
+## → Template Section 6: Implementation Checklist
+
+Fill in the actual values directly into the checklist items — this section must be self-contained and immediately usable without opening any other document.
+
+**Planning steps:** List the project-specific steps required before writing a test (e.g., assign a test ID, register a feature abbreviation in the test registry). Check the README, CONTRIBUTING.md, or blueprint for any required setup steps. If there are none, omit the Planning sub-section.
+
+**Files to Create — replace example paths with real patterns:**
+
+| Item | Where to Find the Pattern |
+|------|-----------------------------|
+| Page Object path | From the page object directory structure |
+| API helper path | From the helper module locations |
+| Type definition path | From the interfaces / models file locations |
+| Test data / fixture path | From the fixture or data file locations |
+| Test spec path | From the test spec directory |
+
+**Before Committing — replace placeholder commands with real commands:**
+
+| Command | Where to Find It |
+|---------|-----------------|
+| Run tests locally | `package.json` scripts, `Makefile`, README, or CI config |
+| Lint command | Same sources |
+| Type-check command | Same sources |
+
+If any of these commands don't apply to the project (e.g., no type-checking), omit that checklist item.

package/kits/shared/skills/web-auto-generate-instructions/templates/web-auto-instructions.template.md

@@ -0,0 +1,184 @@
+# Web Automation Test Instructions
+
+> **Purpose**: Copy-paste-ready code patterns and templates extracted from the actual codebase. Use this file when writing new tests.
+>
+> **Related documents** — read these alongside this file:
+> - `.documents-design/web-auto-project-blueprint.md` — project architecture, tech stack, directory structure, file naming conventions, and selector strategy
+> - `.documents-design/web-auto-best-practices.md` — coding standards, rules, and anti-patterns
+>
+> This file does not repeat information from the two files above, except in **Section 6** where path patterns and commands are reproduced inline for quick reference. Cross-references are added elsewhere where relevant.
+
+## 1. Page Object Patterns
+
+### Page Object Template
+
+```
+[Full, copy-paste-ready Page Object skeleton following the exact conventions observed:
+  - import statements
+  - class declaration and inheritance
+  - selector definitions (static and parameterized)
+  - action methods
+  - verification / assertion methods
+  - export statement]
+```
+
+### Selector Definition Conventions
+
+```
+[Real examples of how selectors are declared in this project:
+  static selectors, parameterized/dynamic selectors, and any rules that must be followed]
+```
+
+### Action Methods
+
+```
+[Real example of an action method, including any required wrappers (e.g., step, allure.step)]
+```
+
+### Verification Methods
+
+```
+[Real example of a verification method, including any required wrappers]
+```
+
+## 2. Test Structure & Patterns
+
+### Test File Template
+
+```
+[Full, copy-paste-ready test file skeleton:
+  - import statements
+  - describe / suite block
+  - setup and teardown hooks
+  - one complete test case showing the full flow]
+```
+
+### Hook Patterns
+
+```
+[What belongs in each hook — before, beforeEach, afterEach, after — with real examples]
+```
+
+### Assertion Patterns
+
+```
+[Primary assertion style used in this project, with real examples]
+[Secondary assertion style, if a second library is used]
+```
+
+### Step Organization
+
+```
+[How actions and verifications are structured inside a test.
+  Include rules about step ownership — which page object drives which steps.]
+```
+
+### Tag / Annotation Conventions
+
+```
+[How tests are categorized or tagged in this project, with real examples]
+```
+
+## 3. Test Data Management
+
+[Omit this section if the project has no dedicated data files or fixtures.]
+
+### Strategy
+
+[Describe the approach used: inline data, fixture files, API-seeded data, factory pattern, or a combination.]
+
+### Data File Template
+
+```
+[Full data file skeleton following the exact conventions in this project,
+  including imports, shared constants, and dynamic field generation]
+```
+
+### Type Definitions / Data Models
+
+```
+[How test data shapes are typed or modelled in this project, e.g., interfaces, dataclasses, POJOs]
+```
+
+### Dynamic Data Generation
+
+```
+[How unique or random values are generated in this project, with real examples]
+```
+
+### Cleanup Pattern
+
+```
+[How test data is removed after tests, with a real example]
+```
+
+> **Rule**: [Any mandatory cleanup rule observed in the project — e.g., cleanup must run in a setup hook, not inline in the test body]
+
+## 4. API & Backend Helpers
+
+[Omit this section entirely if the project has no programmatic API helpers for test data setup.]
+
+### Overview
+
+| Helper Type | Location | When to Use |
+|-------------|----------|-------------|
+| [REST / GraphQL / DB / other] | [path] | [condition] |
+
+### Auth Helper
+
+```
+[How a token or session is obtained for programmatic API calls, with real code]
+```
+
+### Data Setup Pattern
+
+```
+[How test data is created via API before tests, with real code]
+```
+
+### Data Teardown Pattern
+
+```
+[How test data is destroyed via API, with real code]
+```
+
+### Available Helper Modules
+
+| Module | Path | Key Operations |
+|--------|------|----------------|
+| [module name] | [path] | [create, find, delete, …] |
+
+### Rules & Gotchas
+
+[Any mandatory conventions or known pitfalls for this project's API helpers. Omit if none.]
+
+## 5. Common Workflow Patterns
+
+[Omit this section if no recurring multi-step patterns were found.]
+
+```
+[Patterns that appear frequently across tests, with real code from the project.
+  Cover what is applicable: login and navigation, search and selection,
+  form fill and submission, modal confirmation, async UI feedback (spinners, notifications).]
+```
+
+## 6. Implementation Checklist
+
+### Planning
+- [ ] [Project-specific step 1 — e.g., assign a test ID]
+- [ ] [Project-specific step 2 — e.g., register feature abbreviation in the test registry]
+
+### Files to Create
+
+- [ ] Page Object: `[e.g., e2e/pages/{feature}.page.ts]` _(if the page has no Page Object yet)_
+- [ ] API / backend helper: `[e.g., e2e/helpers/{entity}.helper.ts]` _(if not yet created)_
+- [ ] Type definition / data model: `[e.g., e2e/types/{entity}.types.ts]` _(if not yet defined)_
+- [ ] Test data / fixture file: `[e.g., e2e/data/{feature}.data.ts]`
+- [ ] Test spec: `[e.g., e2e/specs/{feature}/{scenario}.spec.ts]`
+
+### Before Committing
+
+- [ ] Run tests locally: `[actual run command]`
+- [ ] Report shows correct steps and assertions
+- [ ] Test data is cleaned up after the run
+- [ ] Code quality checks pass: `[lint command]` / `[type-check command]`

package/kits/shared/skills/web-auto-generate-project-blueprint/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: web-auto-generate-project-blueprint
+description: "Analyze a web automation test codebase and generate a project blueprint saved to `.documents-design/web-auto-project-blueprint.md`. The blueprint documents what the project IS — framework, language, directory structure, file naming conventions, selector strategy, key configuration, CI/CD pipeline, global setup/fixtures, and third-party integrations. Works with any language (TypeScript, JavaScript, Python, Java, Ruby, C#) and any framework (Playwright, Cypress, WebdriverIO, Selenium, Robot Framework, Puppeteer, TestCafe, Nightwatch). Use this skill whenever someone asks to create a web automation project blueprint, document the test project structure, generate a project overview for automation, scaffold the documentation foundation, or initialize the web-auto-project-blueprint file. Also use when someone wants to onboard to an existing automation project, understand how an automation repo is organized, or needs the structural foundation before generating instructions or best practices. Triggers on requests like 'create project blueprint', 'generate web-auto-project-blueprint', 'document the test project structure', 'analyze this automation project', 'what framework does this project use', or 'create documentation foundation for automation'."
+---
+
+# Web Auto Generate Project Blueprint
+
+Analyze the web automation test codebase and generate a project blueprint that captures what the project is — its framework, language, directory structure, file naming conventions, selector strategy, key configuration, CI/CD pipeline, global setup/fixtures, and third-party integrations. This blueprint is the foundational reference document that other skills (like `web-auto-generate-instructions` and `web-auto-generate-best-practices`) rely on — it should be generated first before running those skills.
+
+## Output
+
+Save the generated blueprint to:
+
+```
+.documents-design/web-auto-project-blueprint.md
+```
+
+If the file already exists, update it — preserving accurate sections and replacing outdated ones.
+
+## Relationship to Other `.documents-design` Files
+
+| File | Role |
+|------|------|
+| `web-auto-project-blueprint.md` (this output) | *What* the project is — structure, tech choices, conventions, infrastructure |
+| `web-auto-best-practices.md` | *How* to write good code — rules, standards, anti-patterns |
+| `web-auto-instructions.md` | *Concrete patterns* — copy-paste templates from the actual codebase |
+
+The blueprint is the foundation. The other two files reference it and build on it. When updating the blueprint, avoid duplicating content that belongs in its siblings — structural facts go here, coding rules go in best-practices, concrete code templates go in instructions.
+
+## Workflow
+
+### Step 1: Read Existing Documentation
+
+Before analyzing the codebase, check whether sibling documentation already exists. This prevents duplication and ensures the blueprint stays in its lane.
+
+Read if present:
+- `.documents-design/web-auto-best-practices.md` — so you know what's already documented as rules (don't repeat it)
+- `.documents-design/web-auto-instructions.md` — so you know what's already documented as patterns (don't repeat it)
+- `README.md` or project-level docs — may contain setup instructions, architecture notes, or CI info worth cross-referencing
+
+If none exist, that's fine — you're creating the first document in the set.
+
+### Step 2: Detect Framework and Language
+
+Identify the test framework and language by looking for these signals:
+
+| Framework | Detection Signals |
+|-----------|------------------|
+| Playwright | `playwright.config.*`, `@playwright/test` import |
+| Cypress | `cypress.config.*`, `cypress/` directory |
+| WebdriverIO | `wdio.conf.*`, `@wdio/` imports |
+| Selenium | `selenium-webdriver` / `selenium` package, `WebDriver` class |
+| Robot Framework | `.robot` / `.resource` files, `Library  SeleniumLibrary` |
+| Nightwatch | `nightwatch.conf.*` |
+| Puppeteer | `puppeteer` package, `browser.newPage()` |
+| TestCafe | `testcafe` package, `.testcafe` config |
+
+Secondary signals by language: `package.json` (JS/TS) · `requirements.txt` / `pyproject.toml` (Python) · `pom.xml` / `build.gradle` (Java) · `Gemfile` (Ruby) · `*.csproj` (C#)
+
+**Multi-framework projects**: Some repos use more than one framework (e.g., Cypress for component tests + Playwright for E2E). If you detect multiple frameworks, document each one with its scope and config file. The template has a "Multiple Frameworks" subsection for this.
+
+### Step 3: Extract Configuration
+
+Read the framework configuration file(s). Extract:
+- Base URL and environment-specific URL handling
+- Timeouts (global, per-action, per-navigation)
+- Retries on failure
+- Parallel execution settings (workers, sharding)
+- Browser / device targets and headless flag
+- Test directory paths and spec include/exclude patterns
+- Reporter configuration
+- Screenshot, video, trace capture settings
+- Registered services, plugins, or support files
+
+### Step 4: Detect Global Setup, Fixtures, and Auth
+
+Look for project-wide setup mechanisms — these are structural decisions that affect every test:
+
+- **Global setup/teardown files** — e.g., Playwright's `globalSetup`, Cypress `support/e2e.js`, WebdriverIO `before`/`after` hooks
+- **Fixtures / test data strategy** — shared fixture files, factory functions, data builder patterns
+- **Authentication state** — how the project handles login: stored auth state files, API-based auth setup, environment-based credentials
+- **Custom test abstractions** — base page classes, custom test wrappers, shared hooks
+
+Search for patterns like: `globalSetup`, `global-setup`, `storageState`, `auth.setup`, `support/`, `fixtures/`, `beforeAll`, `BaseTest`, `BasePage`
+
+### Step 5: Map Directory Structure and Naming Conventions
+
+Explore the repository to document the test-specific directory tree and all file naming conventions.
+
+For each file type, identify:
+- Directory location relative to the project root
+- File naming style (kebab-case, PascalCase, snake_case, suffix pattern)
+- Class or module naming style
+- Whether a test ID or abbreviation scheme exists (e.g., `COM-1`, `TC-001`)
+
+**How to explore systematically**: Start from the project root. List the top-level directories, then drill into test-related directories. Use file search patterns like `**/*.spec.*`, `**/*.test.*`, `**/*Page.*`, `**/*page.*` to find test and page object files. Look at 5–8 representative files to confirm patterns, not just 1–2.
+
+### Step 6: Identify Selector Strategy
+
+Read 3–5 Page Object files (pick them from different feature areas to get a representative sample). Determine the selector priority order used consistently across the project. Document:
+- Priority order (e.g., `data-testid` → ARIA role → CSS → XPath)
+- Real examples of each selector type used in the project
+- Any framework-specific constraints on how selectors must be declared
+
+If the project has no Page Object files (e.g., selectors are inline in tests), document that pattern instead and pull selector examples from test files.
+
+### Step 7: Detect Third-Party Integrations and Dependencies
+
+Scan the dependency file (`package.json`, `requirements.txt`, `pom.xml`, etc.) and config files for test-relevant libraries. These are structural facts about the project:
+
+| Category | Examples |
+|----------|----------|
+| API mocking | MSW, Nock, WireMock, Polly.js |
+| Visual testing | Percy, Applitools, Playwright visual comparisons |
+| Accessibility | axe-core, pa11y, Lighthouse |
+| Test data | Faker, Chance, factory libraries |
+| Reporting | Allure, ReportPortal, custom reporters |
+| BDD | Cucumber, SpecFlow, behave |
+| Other | Mailosaur, Docker test containers, database seeders |
+
+Only document libraries actually present in the project.
+
+### Step 8: Detect CI/CD Pipeline
+
+Look for CI/CD configuration files:
+- `.github/workflows/*.yml` (GitHub Actions)
+- `.gitlab-ci.yml` (GitLab CI)
+- `Jenkinsfile` (Jenkins)
+- `.circleci/config.yml` (CircleCI)
+- `azure-pipelines.yml` (Azure DevOps)
+- `bitbucket-pipelines.yml` (Bitbucket)
+
+If found, document:
+- Which CI platform is used
+- Which events trigger test runs (push, PR, schedule)
+- Test-related pipeline steps (install, run tests, upload reports)
+- Environment variables or secrets referenced
+- Any Docker images or service containers used
+
+If no CI/CD files exist, note that — it's a useful structural fact.
+
+### Step 9: Generate the Blueprint
+
+Create `.documents-design/web-auto-project-blueprint.md` using the template at [templates/web-auto-project-blueprint.template.md](templates/web-auto-project-blueprint.template.md).
+
+**Rules:**
+1. **Facts only** — every statement must be backed by evidence from the codebase or config files
+2. **No code patterns** — copy-paste templates, action method examples, and test data patterns belong in `web-auto-instructions.md`, not here
+3. **No rules or anti-patterns** — coding standards and best practices belong in `web-auto-best-practices.md`, not here
+4. **Real values** — use actual paths, actual command names, and actual configuration values — no placeholders left unfilled
+5. **Omit empty sections** — if the project doesn't have CI/CD, or no third-party integrations, remove those sections rather than leaving placeholder text
+
+### Step 10: Verify and Present
+
+1. Confirm the file was saved to `.documents-design/web-auto-project-blueprint.md`
+2. Present a summary:
+   - Framework(s) and language detected
+   - Number of config files and Page Objects read
+   - Directory structure sections documented
+   - CI/CD pipeline detected (or not)
+   - Third-party integrations found
+3. Ask: "Does this blueprint accurately describe the project structure and tech choices?"
+
+## Edge Cases
+
+- **Greenfield project (no test files yet)**: If the repo has a config file but no tests, generate a blueprint with what exists — tech stack, config, directory structure — and note which sections are empty because no tests exist yet.
+- **Monorepo with multiple test projects**: Look for multiple config files or distinct test directories. Generate one blueprint that documents each sub-project under a clearly labeled subsection, or generate separate blueprints if the user specifies which project.
+- **Mixed frameworks**: Some projects use different frameworks for different purposes (e.g., Cypress component + Playwright E2E, or Jest unit + Playwright E2E). Document each framework's scope clearly.
+- **No Page Object pattern**: If tests use inline selectors or a different abstraction (screen objects, component helpers), adapt the Selector Strategy section to document what actually exists.
+- **Non-standard project structure**: If the project doesn't follow common conventions (e.g., tests scattered across feature directories instead of a central `tests/` folder), document the actual structure and note the pattern.
+
+## Important Rules
+
+- **Read before writing** — always analyze real files before generating the blueprint
+- **Structure over patterns** — this file describes the project's anatomy, not how to use it
+- **Keep it current** — if re-running on an existing project, check each section for outdated values (e.g., changed directory names, updated framework versions)
+- **Stay in your lane** — resist the urge to add coding rules or code templates; those belong in sibling files
+
+## Additional Resources
+
+- Output template: [templates/web-auto-project-blueprint.template.md](templates/web-auto-project-blueprint.template.md)

package/kits/shared/skills/web-auto-generate-project-blueprint/evals/evals.json

@@ -0,0 +1,57 @@
+{
+  "skill_name": "web-auto-generate-project-blueprint",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I have a mature Playwright TypeScript project with about 25 test files, page objects, API helpers, a global setup for auth, Allure reporting, and a GitHub Actions CI pipeline. The project also has .documents-design/web-auto-best-practices.md and web-auto-instructions.md already. Can you generate the project blueprint?",
+      "expected_output": "A .documents-design/web-auto-project-blueprint.md file that: (1) correctly identifies Playwright + TypeScript as the framework/language, (2) extracts real config values from playwright.config.ts, (3) documents the global setup and auth strategy (storageState or similar), (4) documents the full directory structure and naming conventions based on real files, (5) documents selector strategy from multiple page objects across different feature areas, (6) detects and documents third-party integrations (Allure, etc.), (7) detects and documents the GitHub Actions CI pipeline with trigger events and test steps, (8) does NOT duplicate content from existing best-practices or instructions files, (9) has no unfilled placeholder text — all values are real, (10) omits no applicable section that has evidence in the codebase",
+      "files": [],
+      "expectations": [
+        "Output file exists at .documents-design/web-auto-project-blueprint.md",
+        "Tech Stack section identifies Playwright and TypeScript with versions",
+        "Key Configuration section has real values extracted from playwright.config.ts",
+        "Global Setup section documents auth strategy and global setup file",
+        "Directory Structure section shows the real directory tree",
+        "Selector Strategy section has real selector examples from multiple page objects",
+        "Third-Party Integrations section lists Allure and any other detected libraries",
+        "CI/CD Pipeline section documents GitHub Actions with trigger events",
+        "No placeholder brackets remain in the output (no [value] or [path] text)",
+        "Does not contain coding rules or code templates (those belong in sibling files)",
+        "Existing best-practices and instructions files were read first"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We just initialized a new Cypress project — there's a cypress.config.ts and the default support files, but no test files or page objects have been written yet. No .documents-design files exist. Can you create a project blueprint for it?",
+      "expected_output": "A .documents-design/web-auto-project-blueprint.md file that: (1) correctly identifies Cypress + the language from config, (2) extracts configuration from cypress.config.ts, (3) documents the directory structure as it currently exists, (4) gracefully handles missing tests/page objects — notes that sections are empty because no tests exist yet rather than leaving placeholders, (5) omits Selector Strategy or notes it can't be determined yet, (6) still documents what IS available (tech stack, config, directory structure, commands)",
+      "files": [],
+      "expectations": [
+        "Output file exists at .documents-design/web-auto-project-blueprint.md",
+        "Tech Stack section identifies Cypress",
+        "Key Configuration section has values from cypress.config.ts",
+        "Directory Structure reflects the actual (sparse) project structure",
+        "Selector Strategy section is either omitted or notes no tests exist to analyze",
+        "File naming conventions section acknowledges no test files exist yet",
+        "Summary notes this is a greenfield project with limited content",
+        "No placeholder brackets remain in the output"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Our project uses both Cypress for component testing and Playwright for E2E tests. Each has its own config file and test directory. There's also a shared fixtures directory and a Jenkins pipeline. The existing blueprint is outdated — we recently added the Playwright E2E layer. Can you update it?",
+      "expected_output": "An updated .documents-design/web-auto-project-blueprint.md that: (1) documents both frameworks with their distinct scopes (component vs E2E), (2) has separate configuration sections or subsections for each framework, (3) documents the shared fixtures directory, (4) detects the Jenkins pipeline from Jenkinsfile, (5) updates outdated sections while preserving accurate ones, (6) uses the Multiple Frameworks subsection in Tech Stack, (7) presents a summary noting what changed from the previous version",
+      "files": [],
+      "expectations": [
+        "Output file exists at .documents-design/web-auto-project-blueprint.md",
+        "Tech Stack section lists both Cypress and Playwright with their scopes",
+        "Multiple Frameworks subsection is present and populated",
+        "Configuration documented for both cypress.config and playwright.config",
+        "Shared fixtures directory is documented in Global Setup section",
+        "CI/CD section documents Jenkins pipeline from Jenkinsfile",
+        "Directory Structure reflects both test directories",
+        "Summary notes what was updated vs preserved from previous blueprint",
+        "No placeholder brackets remain in the output"
+      ]
+    }
+  ]
+}