From eb8e66b4411f79adbb9fcd0ec33f703e48be0c19 Mon Sep 17 00:00:00 2001 From: Robert DeLuca Date: Fri, 15 May 2026 12:29:41 -0500 Subject: [PATCH 1/2] =?UTF-8?q?=F0=9F=94=A7=20Add=20Codex=20Playwright=20M?= =?UTF-8?q?CP=20config?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .codex/config.toml | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .codex/config.toml diff --git a/.codex/config.toml b/.codex/config.toml new file mode 100644 index 0000000..bfa3aa4 --- /dev/null +++ b/.codex/config.toml @@ -0,0 +1,3 @@ +[mcp_servers.playwright] +args = ["@playwright/mcp@latest"] +command = "npx" From 8eb7b9602ea22d080bf5ef250a523d927e3db103 Mon Sep 17 00:00:00 2001 From: Robert DeLuca Date: Fri, 15 May 2026 12:31:57 -0500 Subject: [PATCH 2/2] =?UTF-8?q?=E2=99=BB=EF=B8=8F=20Remove=20Claude=20inte?= =?UTF-8?q?gration=20leftovers?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .claude-plugin/marketplace.json | 19 -- .github/workflows/claude-code-review.yml | 57 ---- .github/workflows/claude.yml | 50 ---- .github/workflows/release-ember-client.yml | 27 +- .github/workflows/release-ruby-client.yml | 27 +- .../workflows/release-static-site-client.yml | 27 +- .../workflows/release-storybook-client.yml | 27 +- .github/workflows/release-swift-client.yml | 27 +- .github/workflows/release-vitest-client.yml | 27 +- .github/workflows/release.yml | 34 +-- .gitignore | 1 - CLAUDE.md | 263 ------------------ package.json | 1 - vizzly-plugin/README.md | 64 ----- .../plugins/vizzly/.claude-plugin/plugin.json | 19 -- vizzly-plugin/plugins/vizzly/README.md | 137 --------- .../plugins/vizzly/commands/setup.md | 151 ---------- .../vizzly/commands/suggest-screenshots.md | 207 -------------- .../vizzly/skills/check-visual-tests/SKILL.md | 182 ------------ .../skills/debug-visual-regression/SKILL.md | 157 ----------- .../skills/visual-testing-philosophy/SKILL.md | 206 -------------- .../vizzly/skills/vizzly-knowledge/SKILL.md | 206 -------------- 22 files changed, 99 insertions(+), 1817 deletions(-) delete mode 100644 .claude-plugin/marketplace.json delete mode 100644 .github/workflows/claude-code-review.yml delete mode 100644 .github/workflows/claude.yml delete mode 100644 CLAUDE.md delete mode 100644 vizzly-plugin/README.md delete mode 100644 vizzly-plugin/plugins/vizzly/.claude-plugin/plugin.json delete mode 100644 vizzly-plugin/plugins/vizzly/README.md delete mode 100644 vizzly-plugin/plugins/vizzly/commands/setup.md delete mode 100644 vizzly-plugin/plugins/vizzly/commands/suggest-screenshots.md delete mode 100644 vizzly-plugin/plugins/vizzly/skills/check-visual-tests/SKILL.md delete mode 100644 vizzly-plugin/plugins/vizzly/skills/debug-visual-regression/SKILL.md delete mode 100644 vizzly-plugin/plugins/vizzly/skills/visual-testing-philosophy/SKILL.md delete mode 100644 vizzly-plugin/plugins/vizzly/skills/vizzly-knowledge/SKILL.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json deleted file mode 100644 index 45bd99d..0000000 --- a/.claude-plugin/marketplace.json +++ /dev/null @@ -1,19 +0,0 @@ -{ - "$schema": "https://anthropic.com/claude-code/marketplace.schema.json", - "name": "vizzly-marketplace", - "version": "1.0.0", - "description": "Vizzly visual regression testing plugin for Claude Code", - "owner": { - "name": "Vizzly Team", - "email": "support@vizzly.dev" - }, - "plugins": [ - { - "name": "vizzly", - "version": "0.3.0", - "description": "Visual regression testing with Vizzly - debug failures, check test status, review changes, and learn visual testing best practices", - "source": "./vizzly-plugin/plugins/vizzly", - "category": "testing" - } - ] -} diff --git a/.github/workflows/claude-code-review.yml b/.github/workflows/claude-code-review.yml deleted file mode 100644 index fa2b0a7..0000000 --- a/.github/workflows/claude-code-review.yml +++ /dev/null @@ -1,57 +0,0 @@ -name: Claude Code Review - -on: - pull_request: - types: [opened] - # Optional: Only run on specific file changes - # paths: - # - "src/**/*.ts" - # - "src/**/*.tsx" - # - "src/**/*.js" - # - "src/**/*.jsx" - -jobs: - claude-review: - # Optional: Filter by PR author - # if: | - # github.event.pull_request.user.login == 'external-contributor' || - # github.event.pull_request.user.login == 'new-developer' || - # github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR' - - runs-on: ubuntu-latest - permissions: - contents: read - pull-requests: read - issues: read - id-token: write - - steps: - - name: Checkout repository - uses: actions/checkout@v4 - with: - fetch-depth: 1 - - - name: Run Claude Code Review - id: claude-review - uses: anthropics/claude-code-action@v1 - with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} - prompt: | - REPO: ${{ github.repository }} - PR NUMBER: ${{ github.event.pull_request.number }} - - Please review this pull request and provide feedback on: - - Code quality and best practices - - Potential bugs or issues - - Performance considerations - - Security concerns - - Test coverage - - Use the repository's CLAUDE.md for guidance on style and conventions. Be constructive and helpful in your feedback. - - Use `gh pr comment` with your Bash tool to leave your review as a comment on the PR. - - # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md - # or https://docs.claude.com/en/docs/claude-code/sdk#command-line for available options - claude_args: '--allowed-tools "Bash(gh issue view:*),Bash(gh search:*),Bash(gh issue list:*),Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr list:*)"' - diff --git a/.github/workflows/claude.yml b/.github/workflows/claude.yml deleted file mode 100644 index b1a3201..0000000 --- a/.github/workflows/claude.yml +++ /dev/null @@ -1,50 +0,0 @@ -name: Claude Code - -on: - issue_comment: - types: [created] - pull_request_review_comment: - types: [created] - issues: - types: [opened, assigned] - pull_request_review: - types: [submitted] - -jobs: - claude: - if: | - (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) || - (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) || - (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) || - (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude'))) - runs-on: ubuntu-latest - permissions: - contents: read - pull-requests: read - issues: read - id-token: write - actions: read # Required for Claude to read CI results on PRs - steps: - - name: Checkout repository - uses: actions/checkout@v4 - with: - fetch-depth: 1 - - - name: Run Claude Code - id: claude - uses: anthropics/claude-code-action@v1 - with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} - - # This is an optional setting that allows Claude to read CI results on PRs - additional_permissions: | - actions: read - - # Optional: Give a custom prompt to Claude. If this is not specified, Claude will perform the instructions specified in the comment that tagged it. - # prompt: 'Update the pull request description to include a summary of changes.' - - # Optional: Add claude_args to customize behavior and configuration - # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md - # or https://docs.claude.com/en/docs/claude-code/sdk#command-line for available options - # claude_args: '--model claude-opus-4-1-20250805 --allowed-tools Bash(gh pr:*)' - diff --git a/.github/workflows/release-ember-client.yml b/.github/workflows/release-ember-client.yml index 1ae2470..a9f66c9 100644 --- a/.github/workflows/release-ember-client.yml +++ b/.github/workflows/release-ember-client.yml @@ -70,11 +70,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=ember/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Ember SDK v${{ steps.version.outputs.version }}. @@ -82,17 +83,18 @@ jobs: - Client location: `clients/ember/` - Previous tag: `ember/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last ember/* tag - 2. Analyze which commits are relevant to `clients/ember/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Ember SDK in this release" + 1. Use git commands to inspect commits and changed files since the previous Ember tag. + 2. Analyze which changes are relevant to `clients/ember/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Ember SDK in this release". + 7. Save the changelog to `clients/ember/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/ember/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -106,7 +108,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/cli/compare/ember/v${{ steps.current_version.outputs.version }}...ember/v${{ steps.version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*),Write"' - name: Install dependencies working-directory: ./clients/ember diff --git a/.github/workflows/release-ruby-client.yml b/.github/workflows/release-ruby-client.yml index 969fbdd..b679230 100644 --- a/.github/workflows/release-ruby-client.yml +++ b/.github/workflows/release-ruby-client.yml @@ -72,11 +72,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=ruby/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Ruby Client SDK v${{ steps.new_version.outputs.version }}. @@ -84,17 +85,18 @@ jobs: - Client location: `clients/ruby/` - Previous tag: `ruby/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.new_version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last ruby/* tag - 2. Analyze which commits are relevant to `clients/ruby/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Ruby client in this release" + 1. Use git commands to inspect commits and changed files since the previous Ruby tag. + 2. Analyze which changes are relevant to `clients/ruby/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Ruby client in this release". + 7. Save the changelog to `clients/ruby/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/ruby/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -108,7 +110,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/vizzly-cli/compare/ruby/v${{ steps.current_version.outputs.version }}...ruby/v${{ steps.new_version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*)"' - name: Update version in gemspec working-directory: ./clients/ruby diff --git a/.github/workflows/release-static-site-client.yml b/.github/workflows/release-static-site-client.yml index e815fb8..d323742 100644 --- a/.github/workflows/release-static-site-client.yml +++ b/.github/workflows/release-static-site-client.yml @@ -61,11 +61,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=static-site/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Static Site Plugin v${{ steps.version.outputs.version }}. @@ -73,17 +74,18 @@ jobs: - Client location: `clients/static-site/` - Previous tag: `static-site/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last static-site/* tag - 2. Analyze which commits are relevant to `clients/static-site/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Static Site plugin in this release" + 1. Use git commands to inspect commits and changed files since the previous Static Site tag. + 2. Analyze which changes are relevant to `clients/static-site/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Static Site plugin in this release". + 7. Save the changelog to `clients/static-site/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/static-site/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -97,7 +99,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/cli/compare/static-site/v${{ steps.current_version.outputs.version }}...static-site/v${{ steps.version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*),Write"' - name: Install dependencies working-directory: ./clients/static-site diff --git a/.github/workflows/release-storybook-client.yml b/.github/workflows/release-storybook-client.yml index f9e3085..4283cc2 100644 --- a/.github/workflows/release-storybook-client.yml +++ b/.github/workflows/release-storybook-client.yml @@ -62,11 +62,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=storybook/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Storybook Plugin v${{ steps.version.outputs.version }}. @@ -74,17 +75,18 @@ jobs: - Client location: `clients/storybook/` - Previous tag: `storybook/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last storybook/* tag - 2. Analyze which commits are relevant to `clients/storybook/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Storybook plugin in this release" + 1. Use git commands to inspect commits and changed files since the previous Storybook tag. + 2. Analyze which changes are relevant to `clients/storybook/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Storybook plugin in this release". + 7. Save the changelog to `clients/storybook/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/storybook/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -98,7 +100,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/cli/compare/storybook/v${{ steps.current_version.outputs.version }}...storybook/v${{ steps.version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*),Write"' - name: Install dependencies working-directory: ./clients/storybook diff --git a/.github/workflows/release-swift-client.yml b/.github/workflows/release-swift-client.yml index b6a1810..6f40004 100644 --- a/.github/workflows/release-swift-client.yml +++ b/.github/workflows/release-swift-client.yml @@ -74,11 +74,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=swift/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Swift SDK v${{ steps.new_version.outputs.version }}. @@ -86,17 +87,18 @@ jobs: - Client location: `clients/swift/` - Previous tag: `swift/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.new_version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last swift/* tag - 2. Analyze which commits are relevant to `clients/swift/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Swift client in this release" + 1. Use git commands to inspect commits and changed files since the previous Swift tag. + 2. Analyze which changes are relevant to `clients/swift/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Swift client in this release". + 7. Save the changelog to `clients/swift/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/swift/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -110,7 +112,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/cli/compare/swift/v${{ steps.current_version.outputs.version }}...swift/v${{ steps.new_version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*)"' - name: Update CHANGELOG.md working-directory: ./clients/swift diff --git a/.github/workflows/release-vitest-client.yml b/.github/workflows/release-vitest-client.yml index d1683ef..56d308b 100644 --- a/.github/workflows/release-vitest-client.yml +++ b/.github/workflows/release-vitest-client.yml @@ -61,11 +61,12 @@ jobs: echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT echo "tag=vitest/v$NEW_VERSION" >> $GITHUB_OUTPUT - - name: Generate changelog with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate changelog + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for the Vizzly Vitest Integration v${{ steps.version.outputs.version }}. @@ -73,17 +74,18 @@ jobs: - Client location: `clients/vitest/` - Previous tag: `vitest/v${{ steps.current_version.outputs.version }}` - New version: `${{ steps.version.outputs.version }}` - - This is a monorepo with multiple clients and a CLI + - This is a monorepo with multiple clients and a CLI. Instructions: - 1. Use git commands (via Bash tool) to get commits since last vitest/* tag - 2. Analyze which commits are relevant to `clients/vitest/` - 3. Read the code changes if needed to understand impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed - 5. Focus on user-facing changes only - 6. If no relevant changes, output: "No changes to Vitest integration in this release" + 1. Use git commands to inspect commits and changed files since the previous Vitest tag. + 2. Analyze which changes are relevant to `clients/vitest/`. + 3. Read relevant code changes when commit messages are not enough. + 4. Generate user-friendly release notes with categories: Added, Changed, Fixed. + 5. Focus on user-facing changes only. + 6. If there are no relevant changes, output: "No changes to Vitest integration in this release". + 7. Save the changelog to `clients/vitest/CHANGELOG-RELEASE.md`. - Save the changelog to `clients/vitest/CHANGELOG-RELEASE.md` with this format: + Use this format: ## What's Changed @@ -97,7 +99,6 @@ jobs: - Bug fixes **Full Changelog**: https://github.com/vizzly-testing/cli/compare/vitest/v${{ steps.current_version.outputs.version }}...vitest/v${{ steps.version.outputs.version }} - claude_args: '--allowed-tools "Bash(git:*),Write"' - name: Install dependencies working-directory: ./clients/vitest diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 728ffbf..4825f9b 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -65,29 +65,30 @@ jobs: PREV_TAG=$(git describe --tags --abbrev=0 HEAD~1 2>/dev/null || echo "") echo "tag=$PREV_TAG" >> $GITHUB_OUTPUT - - name: Generate release notes with Claude - id: changelog - uses: anthropics/claude-code-action@v1 + - name: Generate release notes + uses: openai/codex-action@v1 with: - claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} + openai-api-key: ${{ secrets.OPENAI_API_KEY }} + sandbox: workspace-write + safety-strategy: drop-sudo prompt: | Generate release notes for Vizzly CLI ${{ steps.version.outputs.new_version }}. Context: - Previous tag: `${{ steps.prev_version.outputs.tag }}` - New version: `${{ steps.version.outputs.new_version }}` - - This is the main CLI package for Vizzly visual testing + - This is the main CLI package for Vizzly visual testing. Instructions: - 1. Use git commands to get commits since the previous tag - 2. Analyze the commits and understand what changed - 3. Read relevant code changes if needed to understand the impact - 4. Generate user-friendly release notes with categories: Added, Changed, Fixed, Removed - 5. Focus on user-facing changes - skip internal refactors unless significant - 6. Write clear, concise descriptions (not just commit messages) - 7. Group related changes together + 1. Use git commands to inspect commits and changed files since the previous tag. If there is no previous tag, inspect the recent release commits. + 2. Read relevant code changes when commit messages are not enough. + 3. Generate user-friendly release notes with categories: Added, Changed, Fixed, Removed. + 4. Focus on user-facing changes. Skip internal refactors unless they affect behavior. + 5. Omit empty sections. + 6. If there are no meaningful user-facing changes, write a brief summary. + 7. Save the release notes to `RELEASE-NOTES.md`. - Save the release notes to `RELEASE-NOTES.md` with this format: + Use this format: ## What's Changed @@ -101,15 +102,10 @@ jobs: - Bug fixes ### Removed - - Deprecated features removed (if any) + - Deprecated features removed **Full Changelog**: https://github.com/vizzly-testing/cli/compare/${{ steps.prev_version.outputs.tag }}...${{ steps.version.outputs.new_version }} - Notes: - - Omit empty sections - - If there are no meaningful user-facing changes, just write a brief summary - claude_args: '--allowed-tools "Bash(git:*),Read,Write" --model haiku' - - name: Read release notes id: release_notes run: | diff --git a/.gitignore b/.gitignore index 992af08..a524f86 100644 --- a/.gitignore +++ b/.gitignore @@ -34,5 +34,4 @@ Thumbs.db tests/client/ playwright-report/ test-results/ -.claude .envrc diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index 45093e8..0000000 --- a/CLAUDE.md +++ /dev/null @@ -1,263 +0,0 @@ -# CLAUDE.md - -This file provides guidance to Claude Code (claude.ai/code) when working with code in this -repository. - -## Critical: Repository Information - -**NEVER use `vizzly-co` as the GitHub organization. It is ALWAYS `vizzly-testing`.** -**The product URL is `vizzly.dev` (NOT vizzly.com or any other domain).** - -## What is Vizzly? - -Vizzly is a visual review platform for UI developers and designers. Unlike tools that render -components in isolation, Vizzly captures screenshots directly from your functional tests—the *real -thing*. It enables teams to collaborate on visual changes through an intuitive web dashboard. - -**This CLI is the core of Vizzly.** It provides: -1. **Client SDK** - Lightweight API for test runners to send screenshots -2. **TDD Mode** - Local visual testing with interactive dashboard, settings, and project tools -3. **Cloud Integration** - Upload screenshots to Vizzly's web platform for team review -4. **CI/CD Support** - Run tests in parallel, wait for results, handle visual regressions -5. **Plugin System** - Extensible architecture for adding custom commands and integrations - -## Two Modes of Operation - -**TDD Mode (Local Development):** -- Visual test-driven development workflow -- No API token required for visual testing -- Screenshots compared locally using `honeydiff` (high-performance Rust-based diffing) -- Interactive dashboard at `http://localhost:47392` - - View and accept/reject baselines - - Settings tab for editing configuration without touching files - - Projects tab for authentication and project mappings -- Fast iteration cycle -- Command: `vizzly tdd start` or `vizzly tdd run "npm test"` - -**Run Mode (CI/CD & Cloud):** -- Requires API token -- Screenshots uploaded to Vizzly cloud -- Team reviews changes via web dashboard -- Supports parallel test execution across shards -- Returns exit codes for CI integration -- Command: `vizzly run "npm test" --wait` - -## Development Commands - -### Build and Test -```bash -npm run build # Full build: clean, compile, copy assets, reporter, types -npm run clean # Remove dist directory -npm run compile # Babel compile src to dist -npm run types # Generate TypeScript declarations - -npm test # Run all tests once (node --test) -npm test:watch # Run tests in watch mode -npm run test:reporter # Run Playwright visual regression tests for reporter UI -npm run test:reporter:visual # Self-test: run reporter tests with Vizzly - -npm run lint # ESLint check -npm run lint:fix # ESLint auto-fix -npm run format # Prettier format -npm run format:check # Prettier check -``` - -### Testing Specific Files/Patterns -```bash -node --test tests/commands/builds.test.js # Single test file -node --test $(find tests/services -name '*.test.js') # Directory -``` - -### Reporter Development -```bash -npm run dev:reporter # Start Vite dev server for reporter UI (port 5173) -npm run build:reporter # Build reporter production bundle -``` - -## Architecture Overview - -**Service-Oriented Design:** -The CLI uses a dependency injection container (`src/container/`) to wire up services with proper -lifecycle management. Services are singletons registered with dependencies, making it easy to test -and compose functionality. - -**Client SDK Philosophy:** -The client SDK (`@vizzly-testing/cli/client`) is intentionally thin—it just POSTs screenshot data to -a local HTTP server. This keeps test runner integration simple and language-agnostic. The heavy -lifting happens server-side. - -**Reporter UI:** -The interactive dashboard is a React SPA (`src/reporter/`) built with Vite. It serves two purposes: -1. Live TDD dashboard fetching data from HTTP endpoints -2. Static HTML reports with embedded JSON data - -Same codebase, different data sources. - -**Plugin Architecture:** -The CLI supports a plugin system (`src/plugin-loader.js`) that enables extensibility while keeping the -core lean. Plugins are ESM modules that register Commander.js commands and receive access to the -service container, config, and output utilities. - -- **Auto-discovery**: Plugins under `@vizzly-testing/*` scope are automatically discovered from node_modules -- **Config-based**: Plugins can be explicitly loaded via `vizzly.config.js` -- **Security**: Path validation prevents directory traversal, scope restriction limits auto-discovery -- **Graceful errors**: Plugin failures don't crash the CLI -- **Timeout protection**: 5-second timeout prevents infinite loops during registration -- **Deduplication**: Same plugin won't load twice (warns on version conflicts) - -## Key Workflows - -**TDD Workflow (Local Development):** -1. Developer runs `vizzly tdd start` → Background TDD server starts -2. Developer runs tests in watch mode → `vizzlyScreenshot()` sends images to server -3. Server compares using `honeydiff` → Saves results to `.vizzly/` -4. Dashboard at `http://localhost:47392` shows: - - Live comparisons → Accept/reject baselines - - Settings tab → Edit config (threshold, ports, etc.) without touching files - - Projects tab → Login, manage project mappings as convenient -5. Baselines updated → Tests pass on next run - -**One-off TDD Run:** -1. Developer runs `vizzly tdd run "npm test"` → Ephemeral server starts -2. Tests execute once → Screenshots captured and compared -3. Static HTML report generated → Opens in browser -4. Server automatically stops - -**CI/CD Workflow:** -1. CI runs `vizzly run "npm test" --wait` → Starts screenshot server -2. Tests run → Client SDK sends screenshots to server -3. Server queues screenshots → Batch uploads to cloud after tests -4. `--wait` polls build status → Returns exit code based on visual differences -5. Team reviews on web dashboard → Approves/requests changes - -**Parallel Builds:** -- Multiple CI shards run with same `--parallel-id` -- Each shard uploads its screenshots independently -- After all shards complete, run `vizzly finalize ` -- Cloud processes complete build and shows unified results - -## Configuration - -**Priority (highest to lowest):** -1. CLI flags (`--port`, `--threshold`, etc.) -2. Environment variables (`VIZZLY_TOKEN`, `VIZZLY_API_URL`) -3. Config file (`vizzly.config.js` found via cosmiconfig) -4. Built-in defaults - -Config files use `defineConfig()` helper for better IDE support. - -## Key Concepts - -**Screenshot Identity:** -Screenshots are matched by signature: `name|viewport_width|browser`. This ensures the same logical -screenshot across different runs can be compared, even if viewport or browser differs. - -**Baseline Management:** -- TDD mode: Baselines stored in `.vizzly/baselines/` as PNG files -- Cloud mode: Baselines are previous build's screenshots on same branch -- Both use SHA-based deduplication to avoid redundant uploads/storage - -**Auto-Discovery:** -The client SDK automatically discovers a running TDD server by searching for `.vizzly/server.json` -in parent directories. This allows tests to work without explicit configuration. - -**Dogfooding:** -The reporter UI's visual tests (`tests/reporter/`) use Vizzly itself for visual regression testing. - -**Static vs Live Reports:** -The React-based reporter works in two modes: -- **Live mode**: TDD server serves dashboard that polls for updates (live comparisons, settings, projects) -- **Static mode**: Self-contained HTML report with embedded data (comparisons only, generated by `vizzly tdd run`) - -## Environment Variables - -- `VIZZLY_HOME` - Override config directory (default: ~/.vizzly). Useful for development/testing -- `VIZZLY_TOKEN` - API authentication token -- `VIZZLY_API_URL` - API base URL (default: https://app.vizzly.dev) -- `VIZZLY_LOG_LEVEL` - Logging level (debug|info|warn|error) -- `VIZZLY_BUILD_NAME` - Custom build name (useful in CI for dynamic naming) -- `VIZZLY_PARALLEL_ID` - Parallel build identifier -- `VIZZLY_ENABLED` - Enable/disable SDK (default: auto-detect) -- `VIZZLY_SERVER_URL` - Screenshot server URL for client -- `VIZZLY_BUILD_ID` - Build identifier for grouping screenshots - -Git information overrides (for CI): -- `VIZZLY_COMMIT_SHA` -- `VIZZLY_COMMIT_MESSAGE` -- `VIZZLY_BRANCH` -- `VIZZLY_PR_NUMBER` - -## Package Exports - -The package provides multiple entry points for different use cases: - -- `@vizzly-testing/cli` - Main exports (SDK, client, utilities) -- `@vizzly-testing/cli/client` - Lightweight test runner integration (`vizzlyScreenshot`) -- `@vizzly-testing/cli/sdk` - Full SDK with programmatic upload control -- `@vizzly-testing/cli/config` - Config helpers (`defineConfig`) - -## Testing - -- **Node test runner** for unit/integration tests (`npm test`) -- **Playwright** for reporter UI visual tests (`npm run test:reporter`) -- Coverage thresholds: 75% lines/functions, 70% branches -- Tests mirror `src/` structure in `tests/` - -## Common Development Patterns - -**Adding a new command:** -1. Create command file in `src/commands/` -2. Register in `src/cli.js` with Commander -3. Use `loadConfig()` to merge CLI options with config file -4. Add tests in `tests/commands/` - -**Adding a new service:** -1. Create a plain class in `src/services/` -2. Add it to `createServices()` in `src/services/index.js` with its dependencies -3. Access via `services.myService` in commands - -**Modifying screenshot comparison:** -Remember to update both local (TDD) and cloud comparison logic to keep behavior consistent. - -**Creating a plugin:** -1. Create ESM module that exports `{ name, version?, register(program, context) }` -2. Plugin receives `program` (Commander instance), `config`, `output`, and `services` object -3. For official plugins: Publish under `@vizzly-testing/*` scope with `vizzly.plugin` field in package.json -4. For community/local plugins: Add path to `plugins` array in `vizzly.config.js` -5. Add tests in plugin's own package or in `tests/integration/` -6. See `docs/plugins.md` and `examples/custom-plugin/` for complete guide - -## Local Development Setup - -When developing the CLI, use `VIZZLY_HOME` to isolate dev state from production: - -```bash -# Set up isolated dev environment -export VIZZLY_HOME="$HOME/.vizzly.dev" -export VIZZLY_API_URL="http://localhost:3000" - -# Now login, link projects, etc. - all stored in ~/.vizzly.dev -vizzly login -vizzly project link -``` - -This keeps your production auth/projects in `~/.vizzly` untouched while you work on the CLI. - -Recommended: Add a `.envrc` file (with direnv) to auto-set these when entering the repo. - -## Git Commits & Pull Requests - -**NEVER add AI attribution to commits, PRs, or any writing:** -- ❌ "🤖 Generated with [Claude Code](https://claude.com/claude-code)" -- ❌ "Co-Authored-By: Claude " - -**Commits:** -- Use gitmoji prefix (✨ feat, 🐛 fix, 📝 docs, ♻️ refactor, 🧪 test, etc.) -- Keep messages clear and concise - -**Pull Requests:** -- Title must include gitmoji prefix matching the primary change type -- Description must explain the *why* (motivation/problem being solved) -- Description must cover all changes in the diff, not just highlights -- Use a "Summary" section with bullet points for each change -- Include a "Test plan" section with verification steps diff --git a/package.json b/package.json index da845c1..a94ea56 100644 --- a/package.json +++ b/package.json @@ -51,7 +51,6 @@ "files": [ "bin", "dist", - "claude-plugin", "README.md", "LICENSE" ], diff --git a/vizzly-plugin/README.md b/vizzly-plugin/README.md deleted file mode 100644 index 1762108..0000000 --- a/vizzly-plugin/README.md +++ /dev/null @@ -1,64 +0,0 @@ -# Vizzly Plugin for Claude Code - -Visual regression testing with Vizzly - debug failures, check test status, and learn visual testing best practices. - -## Installation - -```bash -# Add the marketplace -/plugin marketplace add vizzly-testing/cli - -# Install the plugin -/plugin install vizzly@vizzly-marketplace -``` - -Or via CLI: - -```bash -claude plugin marketplace add vizzly-testing/cli -claude plugin install vizzly@vizzly-marketplace -``` - -Then restart Claude Code. - -## What's Included - -### Skills (auto-activated) - -- **vizzly-knowledge** - Core knowledge about Vizzly file structure, CLI commands, and how it works -- **debug-visual-regression** - Analyze visual test failures and screenshot differences -- **check-visual-tests** - Check test status and get summaries -- **visual-testing-philosophy** - Best practices for visual testing - -### Commands (manual) - -- `/vizzly:setup` - Initialize Vizzly in a project -- `/vizzly:suggest-screenshots` - Analyze tests and suggest where to add visual screenshots - -### CLI Integration - -The plugin teaches Claude how to use the full Vizzly CLI: -- TDD commands: `vizzly tdd start`, `vizzly tdd run`, `vizzly baselines` -- Cloud commands: `vizzly run`, `vizzly status`, `vizzly builds` -- Review commands: `vizzly approve`, `vizzly reject`, `vizzly comment` -- Setup commands: `vizzly init`, `vizzly login`, `vizzly project:select` - -## Structure - -``` -vizzly-plugin/ -└── plugins/ - └── vizzly/ - ├── .claude-plugin/ - │ └── plugin.json - ├── skills/ - └── commands/ -``` - -## Development - -Test the plugin locally: - -```bash -claude --plugin-dir ./vizzly-plugin/plugins/vizzly -``` diff --git a/vizzly-plugin/plugins/vizzly/.claude-plugin/plugin.json b/vizzly-plugin/plugins/vizzly/.claude-plugin/plugin.json deleted file mode 100644 index 1afcf1b..0000000 --- a/vizzly-plugin/plugins/vizzly/.claude-plugin/plugin.json +++ /dev/null @@ -1,19 +0,0 @@ -{ - "name": "vizzly", - "description": "Visual regression testing with Vizzly - debug failures, check test status, review changes, and learn visual testing best practices", - "version": "0.3.0", - "author": { - "name": "Vizzly Team", - "url": "https://vizzly.dev" - }, - "homepage": "https://vizzly.dev", - "repository": "https://github.com/vizzly-testing/cli", - "license": "MIT", - "keywords": [ - "visual-testing", - "regression-testing", - "screenshot-testing", - "tdd", - "vizzly" - ] -} diff --git a/vizzly-plugin/plugins/vizzly/README.md b/vizzly-plugin/plugins/vizzly/README.md deleted file mode 100644 index dce8956..0000000 --- a/vizzly-plugin/plugins/vizzly/README.md +++ /dev/null @@ -1,137 +0,0 @@ -# Vizzly Plugin for Claude Code - -> Visual regression testing skills for Claude Code - -This plugin teaches Claude how to work with Vizzly. Debug failures, check test status, and learn visual testing best practices - all through natural conversation. - -## Installation - -### Step 1: Add the marketplace - -In Claude Code, run: - -``` -/plugin marketplace add vizzly-testing/cli -``` - -This registers the Vizzly plugin marketplace with Claude Code. - -### Step 2: Install the plugin - -``` -/plugin install vizzly@vizzly-marketplace -``` - -Or use the interactive installer: -1. Run `/plugin` -2. Go to the **Discover** tab -3. Search for "vizzly" -4. Select it and choose your install scope - -### Step 3: Restart Claude Code - -Skills load on startup. Quit and reopen Claude Code to activate the plugin. - -### Verify Installation - -After restarting, run `/plugin` and check the **Installed** tab. You should see `vizzly@vizzly-marketplace`. - ---- - -## What's Included - -### Skills (Auto-Activated) - -Claude automatically uses these when relevant to your conversation: - -| Skill | Triggers When You Say... | -|-------|---------------------------| -| **check-visual-tests** | "How are my visual tests?", "What's failing?" | -| **debug-visual-regression** | "Debug the homepage screenshot", "Why is this failing?" | -| **visual-testing-philosophy** | "Where should I add screenshots?", "Best practices?" | -| **vizzly-knowledge** | Background context (always available) | - -### Commands (Manual) - -| Command | Purpose | -|---------|---------| -| `/vizzly:setup` | Initialize Vizzly in a new project | -| `/vizzly:suggest-screenshots` | Analyze test files for screenshot opportunities | - ---- - -## Usage Examples - -**Check test status:** -``` -How are my visual tests? -``` - -**Debug a failure:** -``` -The homepage screenshot is failing, can you help debug it? -``` - -**Get screenshot suggestions:** -``` -/vizzly:suggest-screenshots -``` - -**Set up a new project:** -``` -/vizzly:setup -``` - ---- - -## How It Works - -This plugin is **skills-first, not tools-first**. - -The plugin teaches Claude how to work with Vizzly: -- Read `.vizzly/report-data.json` for test results -- View screenshot images with the Read tool -- Run CLI commands like `vizzly tdd start` -- Review and approve visual changes via the CLI -- Understand visual testing best practices - -Claude uses its built-in capabilities (Read, Bash, etc.) combined with the Vizzly CLI - the plugin provides the knowledge to use them effectively. - ---- - -## Requirements - -- Claude Code v1.0.33 or later -- Vizzly CLI in your project: `npm install --save-dev @vizzly-testing/cli` - ---- - -## Troubleshooting - -**Plugin not showing in Discover tab?** -- Make sure the marketplace was added: `/plugin` → Marketplaces tab -- If missing, run `/plugin marketplace add vizzly-testing/cli` again - -**Skills not activating?** -- Restart Claude Code after installing -- Try invoking directly: `/vizzly:check-visual-tests` - -**"Server not running" message?** -- Start the TDD server: `vizzly tdd start` -- Run your tests to generate screenshots - ---- - -## For Plugin Developers - -To test the plugin locally without installing: - -```bash -claude --plugin-dir ./vizzly-plugin/plugins/vizzly -``` - ---- - -## License - -MIT diff --git a/vizzly-plugin/plugins/vizzly/commands/setup.md b/vizzly-plugin/plugins/vizzly/commands/setup.md deleted file mode 100644 index c5cd08b..0000000 --- a/vizzly-plugin/plugins/vizzly/commands/setup.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -description: Initialize Vizzly visual testing in a project ---- - -# Setup Vizzly - -Help the user set up Vizzly visual regression testing in their project. - -## Step 1: Check If Already Configured - -First, check if Vizzly is already set up: - -1. Look for `vizzly.config.js` or `vizzly.config.ts` in the project root -2. Check if `@vizzly-testing/cli` is in `package.json` dependencies - -If already configured, let the user know and offer to help with next steps instead. - -## Step 2: Install Vizzly CLI - -Install the CLI as a dev dependency: - -```bash -npm install --save-dev @vizzly-testing/cli -``` - -Or with other package managers: -```bash -yarn add --dev @vizzly-testing/cli -pnpm add --save-dev @vizzly-testing/cli -``` - -## Step 3: Initialize Configuration - -Run the init command to create the config file: - -```bash -npx vizzly init -``` - -This creates `vizzly.config.js` with sensible defaults. - -## Step 4: Update .gitignore - -Add `.vizzly/` to `.gitignore` to avoid committing local TDD artifacts: - -``` -# Vizzly -.vizzly/ -``` - -The baselines can optionally be committed (they're in `.vizzly/baselines/`) but typically you'll use cloud mode for team collaboration. - -## Step 5: Detect Project Type and Recommend SDK - -Check the project to determine which SDK to recommend: - -**Check in this order:** - -1. **Ruby project** (has `Gemfile`): - ``` - For Ruby projects, install the Ruby SDK: - gem install vizzly - - Documentation: https://docs.vizzly.dev/integration/sdk/ruby/overview - ``` - -2. **Storybook** (has `@storybook/*` in package.json or `.storybook/` directory): - ``` - For Storybook, install the Storybook SDK: - npm install --save-dev @vizzly-testing/storybook - - The Storybook SDK auto-discovers all your stories. - Documentation: https://docs.vizzly.dev/integration/sdk/storybook/overview - ``` - -3. **Static Site** (has static generators like `astro`, `next`, `gatsby`, `vitepress`, `eleventy` in package.json, or build directories like `dist/`, `build/`): - ``` - For static sites, install the Static Site SDK: - npm install --save-dev @vizzly-testing/static-site - - The Static Site SDK auto-discovers all pages in your build output. - Documentation: https://docs.vizzly.dev/integration/sdk/static-site/overview - ``` - -4. **JavaScript/Node.js** (has `package.json`): - ``` - The JavaScript SDK is included with the CLI you just installed. - - Import in your tests: - import { vizzlyScreenshot } from '@vizzly-testing/cli/client'; - - Documentation: https://docs.vizzly.dev/integration/sdk/javascript/overview - ``` - -## Step 6: Provide Environment Setup Instructions - -**For local development:** - -``` -For local TDD mode, no token is needed! -Just run: vizzly tdd start - -For cloud features, authenticate with your account: -vizzly login - -Then select a project for your directory: -vizzly project:select -``` - -**For CI/CD:** - -``` -Add VIZZLY_TOKEN as a secret in your CI provider. -Get your project token with: vizzly project:token - -Example GitHub Actions: -env: - VIZZLY_TOKEN: ${{ secrets.VIZZLY_TOKEN }} -``` - -## Step 7: Summary - -End with a summary of what was accomplished: - -``` -Setup Complete! - -What was done: -✅ Vizzly CLI installed -✅ Configuration file created (vizzly.config.js) -✅ .vizzly/ added to .gitignore - -Next steps: -1. Install the recommended SDK (see above) -2. Add screenshot calls to your tests -3. Run `vizzly tdd start` to begin local development -4. Open http://localhost:47392 to view the dashboard - -Try it now: - vizzly tdd start - npm test -``` - -## What NOT to Do - -- Do NOT modify their test files -- Do NOT generate example test code -- Do NOT create new test files -- Do NOT make assumptions about their test framework - -Let the user integrate Vizzly into their existing tests themselves. Just provide installation and setup. diff --git a/vizzly-plugin/plugins/vizzly/commands/suggest-screenshots.md b/vizzly-plugin/plugins/vizzly/commands/suggest-screenshots.md deleted file mode 100644 index 5aae0b3..0000000 --- a/vizzly-plugin/plugins/vizzly/commands/suggest-screenshots.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -description: Analyze test files and suggest where visual screenshots would be valuable ---- - -# Suggest Screenshot Opportunities - -Analyze the user's test files to identify good opportunities for visual regression testing. - -## Step 1: Check for Auto-Discovery SDKs - -Before analyzing test files, check if the project uses an SDK that auto-discovers screenshots: - -**Storybook detected** (`@storybook/*` in package.json or `.storybook/` directory): -``` -Your project uses Storybook! - -The Storybook SDK auto-discovers all stories - no manual screenshot calls needed. - -Install: npm install --save-dev @vizzly-testing/storybook -Run: npx vizzly-storybook - -Each story becomes a visual test automatically. -``` -Exit early - no test analysis needed. - -**Static Site detected** (build directories like `dist/`, `build/`, `.next/out/`, or generators in package.json): -``` -Your project appears to be a static site! - -The Static Site SDK auto-discovers all pages - no manual screenshot calls needed. - -Install: npm install --save-dev @vizzly-testing/static-site -Run: npx vizzly-static-site ./dist - -Each page in your build output becomes a visual test automatically. -``` -Exit early - no test analysis needed. - -## Step 2: Find Test Files - -Search for test files using these patterns: - -``` -**/*.test.{js,ts,jsx,tsx} -**/*.spec.{js,ts,jsx,tsx} -**/e2e/**/*.{js,ts} -**/__tests__/**/*.{js,ts,jsx,tsx} -``` - -**Exclude these directories:** -- `node_modules/` -- `dist/`, `build/`, `out/` -- `.next/`, `.nuxt/`, `.vite/` -- `coverage/` -- Hidden directories (`.*`) - -## Step 3: Analyze Test Files - -Read the test files and look for screenshot opportunities: - -**High-value opportunities:** - -1. **Page navigations:** - - `.goto()`, `.visit()`, `navigate()`, `push()` - - After routing changes complete - -2. **User interactions before assertions:** - - `.click()`, `.type()`, `.fill()`, `.check()` - - State changes from user actions - -3. **Visual assertions:** - - `toHaveScreenshot()`, `matchImageSnapshot()` - - Where visual testing is already attempted - -4. **Wait conditions:** - - `waitForSelector()`, `waitForLoadState()` - - Indicates a stable state worth capturing - -5. **Component renders:** - - React Testing Library `render()` - - Vue Test Utils `mount()` - - After component is fully rendered - -## Step 4: Suggest Screenshot Locations - -For each opportunity found, suggest: - -- **Line number** in the test file -- **What state** is being captured -- **Suggested screenshot name** following naming conventions -- **Why** this is a good screenshot opportunity - -**Output format:** - -``` -Found 6 screenshot opportunities: - -tests/e2e/auth.spec.ts: - Line 12: After login page navigation - → Screenshot: 'login-page-empty' - Why: Full page render after navigation - - Line 28: After successful login - → Screenshot: 'dashboard-authenticated' - Why: Key state change - user now logged in - - Line 35: After logout - → Screenshot: 'homepage-logged-out' - Why: Returns to unauthenticated state - -tests/e2e/checkout.spec.ts: - Line 15: Cart page with items - → Screenshot: 'checkout-cart-with-items' - Why: Critical e-commerce flow state - - Line 42: Payment form - → Screenshot: 'checkout-payment-form' - Why: Important form state before submission - - Line 58: Order confirmation - → Screenshot: 'checkout-confirmation' - Why: Final state of checkout flow -``` - -## Step 5: Provide Integration Example - -Based on the test framework detected, show a code example: - -**Playwright:** -```javascript -import { vizzlyScreenshot } from '@vizzly-testing/cli/client'; - -test('user login flow', async ({ page }) => { - await page.goto('/login'); - await vizzlyScreenshot('login-page-empty', await page.screenshot()); - - await page.fill('#email', 'user@example.com'); - await page.fill('#password', 'password'); - await page.click('button[type="submit"]'); - - await page.waitForURL('/dashboard'); - await vizzlyScreenshot('dashboard-authenticated', await page.screenshot()); -}); -``` - -**Cypress:** -```javascript -import { vizzlyScreenshot } from '@vizzly-testing/cli/client'; - -describe('Login', () => { - it('allows user to log in', () => { - cy.visit('/login'); - cy.screenshot().then((img) => { - vizzlyScreenshot('login-page-empty', img); - }); - - cy.get('#email').type('user@example.com'); - cy.get('#password').type('password'); - cy.get('button[type="submit"]').click(); - - cy.url().should('include', '/dashboard'); - cy.screenshot().then((img) => { - vizzlyScreenshot('dashboard-authenticated', img); - }); - }); -}); -``` - -**Jest + Testing Library:** -```javascript -import { render, screen } from '@testing-library/react'; -import { vizzlyScreenshot } from '@vizzly-testing/cli/client'; -import html2canvas from 'html2canvas'; - -test('renders login form', async () => { - const { container } = render(); - - const canvas = await html2canvas(container); - await vizzlyScreenshot('login-form', canvas.toDataURL()); - - expect(screen.getByRole('button', { name: /submit/i })).toBeInTheDocument(); -}); -``` - -## What NOT to Do - -- Do NOT modify test files automatically -- Do NOT create new test files -- Do NOT add screenshot code without user approval - -Only provide suggestions. Let the user decide which opportunities to pursue and implement themselves. - -## If No Test Files Found - -``` -No test files found in common locations. - -Looking for files matching: -- **/*.test.{js,ts,jsx,tsx} -- **/*.spec.{js,ts,jsx,tsx} -- **/e2e/**/*.{js,ts} - -If your tests are in a different location, let me know the path and I'll analyze them. - -Alternatively, if you're using Storybook or building a static site, -consider the auto-discovery SDKs that don't require test modifications. -``` diff --git a/vizzly-plugin/plugins/vizzly/skills/check-visual-tests/SKILL.md b/vizzly-plugin/plugins/vizzly/skills/check-visual-tests/SKILL.md deleted file mode 100644 index 2518ed7..0000000 --- a/vizzly-plugin/plugins/vizzly/skills/check-visual-tests/SKILL.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -name: check-visual-tests -description: Check the status of Vizzly visual regression tests. Use when the user asks about test status, test results, what's failing, how tests are doing, or wants a summary of visual tests. ---- - -# Check Visual Test Status - -When the user asks about their visual test status, read the test results and provide a clear summary. - -## Step 1: Read the Test Results - -Use the Read tool to get `.vizzly/report-data.json`: - -``` -Read .vizzly/report-data.json -``` - -**If the file is too large** (over 256KB), use Bash to parse it: -```bash -cat .vizzly/report-data.json | node -e " - const data = require('fs').readFileSync('/dev/stdin', 'utf8'); - const json = JSON.parse(data); - const comps = json.comparisons || []; - console.log(JSON.stringify({ - total: comps.length, - passed: comps.filter(c => c.status === 'passed').length, - failed: comps.filter(c => c.status === 'failed').length, - new: comps.filter(c => c.status === 'new').length, - failures: comps.filter(c => c.status === 'failed').slice(0, 10) - }, null, 2)); -" -``` - -**If the file doesn't exist**, check for `.vizzly/server.json` to see if the TDD server was running. - -**If the JSON is malformed**, suggest running `vizzly tdd status` as a fallback. - -## Step 2: Summarize the Results - -Count the comparisons by status and present a clear summary: - -``` -Vizzly Visual Test Status: - -Total: 15 screenshots - ✅ Passed: 12 - ❌ Failed: 2 (exceeded threshold) - 🆕 New: 1 (no baseline) -``` - -## Step 3: List Issues - -**If there are failures:** -List each failing screenshot with its diff percentage and threshold: - -``` -Failed Comparisons: -• homepage (2.3% diff, threshold: 0.1%) -• login-form (1.8% diff, threshold: 0.1%) -``` - -**If there are new screenshots:** -Explain they need baseline approval: - -``` -New Screenshots: -• dashboard-widget (no baseline yet) - -New screenshots need to be reviewed and accepted as baselines. -``` - -## Step 4: Provide Dashboard Link - -If the TDD server is running, read `.vizzly/server.json` to get the port: - -```json -// .vizzly/server.json contains: -{ "port": 47392, "pid": 12345 } -``` - -Then provide the dashboard URL using the actual port: - -``` -Dashboard: http://localhost:{port} - -Open the dashboard to: -- View visual diffs side-by-side -- Accept or reject baseline changes -- Review all screenshots at a glance -``` - -**Default port is 47392** if server.json doesn't specify. - -## Step 5: Suggest Next Steps - -**If all passed:** -``` -All visual tests are passing. No action needed. -``` - -**If there are failures:** -``` -Next steps: -1. Review the failed comparisons in the dashboard -2. If changes are intentional, accept them as new baselines -3. If changes are bugs, investigate and fix the visual regression -4. Ask me to "debug the homepage screenshot" for detailed analysis -``` - -**If there are new screenshots:** -``` -Next steps: -1. Review new screenshots in the dashboard -2. If they look correct, accept them as baselines -3. Run tests again to confirm they pass -``` - -## When TDD Server Isn't Running - -If `.vizzly/` directory or `report-data.json` doesn't exist: - -``` -Vizzly TDD Status: Not Running - -The TDD server doesn't appear to be running. To start visual testing: - -1. Start the TDD server: - vizzly tdd start - -2. Run your tests: - npm test - -3. Check status again or open the dashboard: - http://localhost:47392 -``` - -## Alternative: CLI Status Commands - -You can also run CLI commands to get status: - -**For local TDD:** (use when running `vizzly tdd start`) -```bash -vizzly tdd status # Show current test status -vizzly baselines # List and query baselines -``` - -**For cloud builds:** (use when running `vizzly run` in CI) -```bash -vizzly status # Check specific build status (build ID from CI output) -vizzly builds # List recent builds to find build IDs -vizzly comparisons # Query and search comparisons -``` - -These commands show the same information in the terminal. - -## Example Full Response - -``` -Vizzly Visual Test Status: - -Total: 8 screenshots - ✅ Passed: 5 - ❌ Failed: 2 - 🆕 New: 1 - -Failed Comparisons: -• homepage (2.3% diff, threshold: 0.1%) - The diff is larger than your 0.1% threshold -• checkout-cart (0.8% diff, threshold: 0.1%) - Small difference but still above threshold - -New Screenshots: -• user-profile (needs baseline) - -Dashboard: http://localhost:47392 - -Next steps: -- Open the dashboard to review the visual diffs -- For the failures, decide if changes are intentional -- For the new screenshot, review and accept as baseline -- Ask me to debug specific failures for detailed analysis -``` diff --git a/vizzly-plugin/plugins/vizzly/skills/debug-visual-regression/SKILL.md b/vizzly-plugin/plugins/vizzly/skills/debug-visual-regression/SKILL.md deleted file mode 100644 index 5075ba4..0000000 --- a/vizzly-plugin/plugins/vizzly/skills/debug-visual-regression/SKILL.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -name: debug-visual-regression -description: Analyze visual regression test failures in Vizzly. Use when the user mentions failing visual tests, screenshot differences, visual bugs, diffs, or asks to debug/investigate/analyze visual changes. ---- - -# Debug Visual Regression - -When a user mentions failing visual tests or screenshot differences, follow these steps to investigate and help them understand what changed. - -## Step 1: Read the Comparison Data - -Use the Read tool to get `.vizzly/report-data.json`: - -``` -Read .vizzly/report-data.json -``` - -**If the file is too large**, use Bash to extract just the failing comparisons: -```bash -cat .vizzly/report-data.json | node -e " - const data = JSON.parse(require('fs').readFileSync('/dev/stdin', 'utf8')); - console.log(JSON.stringify(data.comparisons?.filter(c => c.status === 'failed'), null, 2)); -" -``` - -Find the failing comparison in the `comparisons` array. Each comparison has: -- `name` - Screenshot identifier -- `status` - "failed", "passed", or "new" -- `diffPercentage` - How much the screenshot differs (percentage) -- `threshold` - The allowed difference threshold -- `current` - Path to current screenshot (relative, like `/images/current/name.png`) -- `baseline` - Path to baseline screenshot -- `diff` - Path to diff image - -## Step 2: View the Screenshots - -Convert the paths from report-data.json to filesystem paths: -- `/images/current/name.png` → `.vizzly/current/name.png` -- `/images/baselines/name.png` → `.vizzly/baselines/name.png` - -**Note:** If paths don't match this format, use the screenshot `name` field directly: -- Baseline: `.vizzly/baselines/{name}.png` -- Current: `.vizzly/current/{name}.png` - -Use the Read tool to view both images: -1. Read the baseline image: `.vizzly/baselines/.png` -2. Read the current image: `.vizzly/current/.png` - -**Skip the diff image** (`.vizzly/diffs/`): The diff images are algorithmically generated overlays that highlight pixel differences. They're useful for humans in the dashboard but not helpful for AI analysis - comparing the actual baseline and current images directly gives you better context about what changed. - -## Step 3: Analyze the Visual Differences - -Compare the two images and describe what you observe: - -**Look for:** -- Layout shifts (elements moved, spacing changed) -- Color changes (backgrounds, text, borders) -- Content changes (text, images, icons) -- Missing or added elements -- Typography changes (font size, weight, family) -- State differences (hover, focus, loading states) - -**Categorize by diff percentage:** -- **< 1%:** Anti-aliasing, font rendering, subpixel differences - often acceptable -- **1-5%:** Layout shifts, padding/margin changes, color variations - investigate -- **> 5%:** Significant changes - likely needs attention - -## Step 4: Identify Possible Causes - -Based on what you observe, suggest likely causes: - -**CSS changes:** -- Margin/padding adjustments -- Positioning changes -- Color or background modifications -- Font changes - -**Content changes:** -- Dynamic text or data -- Date/time displays -- User-generated content - -**State issues:** -- Screenshot captured during loading -- Hover state captured unintentionally -- Animation frame captured - -**Environment differences:** -- Browser version changed -- Font availability -- Screen resolution - -## Step 5: Suggest Next Steps - -**If the change is intentional:** -Explain that they can accept the new baseline: -- Via the TDD dashboard at `http://localhost:47392` -- Via CLI (cloud): `vizzly comparisons -b ` to find ID, then `vizzly approve ` -- Via file copy (local TDD): `cp .vizzly/current/.png .vizzly/baselines/.png` - -**If the change is unintentional:** -Help them investigate: -- Suggest specific files to check based on what changed -- Recommend git commands to find recent changes: `git diff --name-only HEAD~5` -- Point to likely CSS or component files - -**If it's unclear:** -Ask clarifying questions: -- "Was this change expected as part of recent work?" -- "Should the button text have changed from X to Y?" - -## Example Analysis - -``` -Based on the comparison data and viewing both screenshots: - -**Screenshot:** homepage -**Diff:** 2.3% (threshold: 0.1%) - -**What I observed:** -The navigation header has shifted down by approximately 15 pixels. The logo -is now positioned lower, and the nav items are overlapping slightly with -the hero section below. - -**Likely cause:** -This appears to be a margin or padding change on the header element. The -layout shift suggests CSS was modified. - -**Suggested investigation:** -Check recent changes to header styles: -- `src/components/Header.css` or similar -- Any global layout styles - -Run: `git diff HEAD~3 -- "*.css" | grep -A5 -B5 "header\|nav"` - -**If intentional:** -Accept the new baseline: -- TDD dashboard at `http://localhost:47392` -- Cloud: `vizzly comparisons -b ` → `vizzly approve ` -- Local TDD: `cp .vizzly/current/homepage.png .vizzly/baselines/homepage.png` -``` - -## When TDD Server Isn't Running - -If `.vizzly/report-data.json` doesn't exist or is empty, the TDD server may not be running: - -1. Check if server is running: Look for `.vizzly/server.json` -2. If not running, suggest: `vizzly tdd start` -3. Then run tests to generate screenshots - -## Tips for Better Analysis - -- Always view BOTH baseline and current images before analyzing -- Be specific about what changed (not just "it looks different") -- Quantify changes when possible ("shifted ~15px", "color changed from #fff to #f0f0f0") -- Consider the context of recent code changes -- Ask if you need more information about what the user was working on diff --git a/vizzly-plugin/plugins/vizzly/skills/visual-testing-philosophy/SKILL.md b/vizzly-plugin/plugins/vizzly/skills/visual-testing-philosophy/SKILL.md deleted file mode 100644 index 214a4fe..0000000 --- a/vizzly-plugin/plugins/vizzly/skills/visual-testing-philosophy/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: visual-testing-philosophy -description: Visual testing best practices and philosophy. Use when the user is adding visual tests, writing test code, deciding where to add screenshots, or asking about screenshot best practices. ---- - -# Visual Testing Philosophy - -When helping users add or improve visual tests, follow these principles and best practices. - -## Core Philosophy - -**Visual tests capture the REAL thing.** - -Unlike component libraries that render in isolation, Vizzly captures screenshots from your actual functional tests - the same tests that verify your app works. This means: - -- You're testing what users actually see -- Integration issues are caught (not just isolated components) -- Visual tests are a byproduct of existing tests, not extra work - -## When to Add Visual Tests - -**High-value screenshot opportunities:** - -1. **After page navigations** - Full page renders after `goto()` or routing changes -2. **After user interactions** - State changes from clicks, form submissions, etc. -3. **Critical user flows** - Checkout, login, onboarding, settings -4. **Different viewport sizes** - Desktop, tablet, mobile breakpoints -5. **Different user states** - Logged in/out, empty/full data, error states - -**Lower value (consider skipping):** - -- Loading spinners (inherently unstable) -- Animations mid-transition -- Highly dynamic content (dates, random data) -- Third-party content you don't control - -## Screenshot Naming Conventions - -Good names are descriptive, consistent, and sortable. - -**Pattern:** `--` - -**Good examples:** -``` -homepage-desktop -homepage-mobile -login-form-empty -login-form-filled -login-form-error -checkout-cart-with-items -checkout-cart-empty -user-profile-settings-tab -``` - -**Avoid:** -``` -test1 # Not descriptive -page # Too generic -myComponent # CamelCase inconsistent -home_page_after_login # Underscores (use hyphens) -``` - -**Include viewport when testing responsive:** -``` -homepage-1920x1080 -homepage-768x1024 -homepage-375x667 -``` - -## Best Practices for Stable Screenshots - -### 1. Wait for Stability - -Capture screenshots after the page is fully loaded: - -```javascript -// Wait for network idle -await page.waitForLoadState('networkidle'); - -// Or wait for specific element -await page.waitForSelector('.main-content'); - -// Then screenshot -await vizzlyScreenshot('homepage', await page.screenshot()); -``` - -### 2. Handle Dynamic Content - -Mock or stabilize dynamic data: - -```javascript -// Mock dates -await page.evaluate(() => { - Date.now = () => new Date('2024-01-01').getTime(); -}); - -// Hide dynamic elements -await page.evaluate(() => { - document.querySelector('.timestamp')?.remove(); -}); -``` - -### 3. Disable Animations - -Prevent animation-related flakiness: - -```javascript -await page.addStyleTag({ - content: ` - *, *::before, *::after { - animation-duration: 0s !important; - transition-duration: 0s !important; - } - ` -}); -``` - -### 4. Use Meaningful Thresholds - -Configure thresholds based on your needs: - -```javascript -// In vizzly.config.js -export default defineConfig({ - threshold: 0.1, // 0.1% - strict, catches minor changes - // threshold: 1.0, // 1% - lenient, ignores anti-aliasing - // threshold: 0, // 0% - pixel-perfect (may be flaky) -}); -``` - -**Threshold guidelines:** -- `0.05% - 0.1%` - Most projects, catches real changes, ignores rendering noise -- `0.5% - 1%` - If you have font rendering issues across environments -- `2%+` - Only for very dynamic UIs or when stability is a problem - -## What Makes a Good Visual Test - -**A good visual test:** -- Captures a stable, representative state -- Has a descriptive name that explains what's being tested -- Runs consistently across environments -- Catches real visual regressions -- Doesn't flake on unimportant changes - -**A bad visual test:** -- Captures loading states or animations -- Has vague naming ("test1", "page") -- Includes timestamps or random data -- Breaks on every run due to dynamic content -- Tests third-party widgets you don't control - -## Adding Screenshots to Existing Tests - -When adding visual tests to an existing test suite: - -1. **Identify key states** - What are the important visual states in this test? -2. **Add screenshots after assertions** - The test already waits for the right state -3. **Use descriptive names** - Match the test description -4. **Run and review** - Check the first screenshots look correct -5. **Accept baselines** - These become your reference - -**Example integration:** - -```javascript -test('user can log in', async ({ page }) => { - await page.goto('/login'); - await vizzlyScreenshot('login-form-empty', await page.screenshot()); - - await page.fill('#email', 'user@example.com'); - await page.fill('#password', 'password'); - await vizzlyScreenshot('login-form-filled', await page.screenshot()); - - await page.click('button[type="submit"]'); - await page.waitForURL('/dashboard'); - await vizzlyScreenshot('dashboard-after-login', await page.screenshot()); -}); -``` - -## TDD Workflow - -The visual TDD workflow: - -1. **Start TDD server:** `vizzly tdd start` -2. **Run tests in watch mode:** Your test runner with `--watch` -3. **Make changes** - Code updates trigger test reruns -4. **Review in dashboard** - See visual changes at `http://localhost:47392` -5. **Accept or fix** - Accept intentional changes, fix regressions -6. **Repeat** - Iterate until visual tests pass - -## Common Pitfalls - -**Flaky tests:** -- Usually caused by animations, loading states, or dynamic content -- Solution: Wait for stability, mock data, disable animations - -**Too many screenshots:** -- Don't screenshot everything - focus on critical states -- Quality over quantity - -**Brittle baselines:** -- If baselines break constantly, your thresholds may be too strict -- Or you're capturing unstable states - -**Ignoring failures:** -- Don't blindly accept all changes -- Each failure is either a regression to fix or a change to consciously accept diff --git a/vizzly-plugin/plugins/vizzly/skills/vizzly-knowledge/SKILL.md b/vizzly-plugin/plugins/vizzly/skills/vizzly-knowledge/SKILL.md deleted file mode 100644 index 527347b..0000000 --- a/vizzly-plugin/plugins/vizzly/skills/vizzly-knowledge/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: vizzly-knowledge -description: Core knowledge about Vizzly visual testing - file structure, CLI commands, and how it works. Use when working with Vizzly, running visual tests, or helping with screenshot-related tasks. -user-invocable: false ---- - -# Vizzly Visual Testing Knowledge Base - -You have deep knowledge of Vizzly, a visual regression testing platform. This context helps you work effectively with Vizzly projects. - -## What is Vizzly? - -Vizzly captures screenshots from real functional tests (not isolated component renders) and compares them against baselines. It works in two modes: - -**TDD Mode (Local Development):** -- Run `vizzly tdd start` to start the local server -- Screenshots are compared locally using `honeydiff` (fast Rust-based diffing) -- Interactive dashboard at `http://localhost:47392` -- Baselines stored in `.vizzly/baselines/` -- No API token required - -**Cloud Mode (CI/CD):** -- Run `vizzly run "npm test" --wait` -- Screenshots uploaded to Vizzly cloud -- Team reviews changes via web dashboard -- Requires `VIZZLY_TOKEN` - -## The .vizzly Directory - -When Vizzly runs, it creates a `.vizzly/` directory with this structure: - -``` -.vizzly/ -├── baselines/ # Baseline screenshots (PNG files) -│ ├── homepage.png -│ └── login-form.png -├── current/ # Current test screenshots -│ ├── homepage.png -│ └── login-form.png -├── diffs/ # Visual diff images (red highlights) -│ └── homepage.png -├── report-data.json # Comparison results (JSON) -├── server.json # TDD server info (port, etc.) -└── baseline-metadata.json # Source of baselines (optional) -``` - -## Understanding report-data.json - -This is the primary source of truth for test results. Read it to understand test status: - -```json -{ - "comparisons": [ - { - "name": "homepage", - "status": "failed", // "passed", "failed", or "new" - "diffPercentage": 2.3, // Percentage of pixels different - "threshold": 0.1, // Allowed diff percentage - "current": "/images/current/homepage.png", - "baseline": "/images/baselines/homepage.png", - "diff": "/images/diffs/homepage.png" - } - ] -} -``` - -**Status meanings:** -- `passed` - Screenshot matches baseline within threshold -- `failed` - Screenshot differs more than threshold allows -- `new` - No baseline exists yet (first time this screenshot was captured) - -## CLI Commands - -**TDD Mode (Local Development):** -```bash -vizzly tdd start # Start TDD server (background) -vizzly tdd run "npm test" # Run tests with ephemeral server -vizzly tdd status # Show current test status -vizzly tdd stop # Stop the TDD server -vizzly baselines # List and query local baselines -``` - -**Cloud Mode (CI/CD):** -```bash -vizzly run "npm test" # Run tests and upload to cloud -vizzly run "npm test" --wait # Wait for cloud processing -vizzly status # Check build status -vizzly builds # List and query builds -vizzly finalize # Finalize parallel builds -vizzly comparisons # Query and search comparisons -``` - -**Review Commands (approve/reject visual changes):** -```bash -vizzly comparisons -b # List comparisons for a build -vizzly comparisons --name "Button*" --status changed # Search by name/status -vizzly approve # Approve a comparison -vizzly approve -m "LGTM" # Approve with comment -vizzly reject -r "reason" # Reject (reason required) -vizzly comment "message" # Add comment to a build -``` - -**Project Setup:** -```bash -vizzly init # Create vizzly.config.js -vizzly config # Display current configuration -vizzly doctor # Run diagnostics to check environment -``` - -**Account & Authentication:** -```bash -vizzly login # Authenticate with Vizzly cloud -vizzly logout # Clear stored authentication tokens -vizzly whoami # Show current auth status -vizzly orgs # List organizations you have access to -vizzly projects # List projects you have access to -``` - -**Project Configuration:** -```bash -vizzly project:select # Configure project for current directory -vizzly project:list # Show all configured projects -vizzly project:token # Show project token for current directory -vizzly project:remove # Remove project configuration -``` - -**Advanced:** -```bash -vizzly api # Make raw API requests -vizzly upload # Upload screenshots directly -vizzly preview # Upload static files as preview -``` - -## Taking Screenshots in Tests - -The client SDK provides `vizzlyScreenshot()`: - -```javascript -import { vizzlyScreenshot } from '@vizzly-testing/cli/client'; - -// In your test -await vizzlyScreenshot('homepage', await page.screenshot(), { - browser: 'chrome', - viewport: '1920x1080' -}); -``` - -**Screenshot Identity:** Screenshots are matched by signature: `name|viewport_width|browser`. The same logical screenshot across runs can be compared even with different parameters. - -## Accepting Baselines - -When a screenshot changes intentionally, you need to accept it as the new baseline: - -**Via TDD Dashboard (Local):** -1. Open `http://localhost:47392` -2. Review the visual diff -3. Click "Accept" on screenshots you want to update - -**Via CLI (Cloud builds):** -```bash -vizzly comparisons -b # List comparisons for a build -vizzly approve # Approve a comparison -vizzly reject -r "reason" # Reject (reason required) -``` - -**Via File Operations (Local TDD):** -Copy the current screenshot to baselines: -```bash -cp .vizzly/current/homepage.png .vizzly/baselines/homepage.png -``` - -## Configuration - -Vizzly uses `vizzly.config.js` for configuration: - -```javascript -import { defineConfig } from '@vizzly-testing/cli/config'; - -export default defineConfig({ - threshold: 0.1, // Default diff threshold (0.1 = 0.1%) - port: 47392, // TDD server port - basePath: '.vizzly', // Where to store screenshots -}); -``` - -## Environment Variables - -- `VIZZLY_TOKEN` - API authentication token -- `VIZZLY_API_URL` - API base URL (default: https://app.vizzly.dev) -- `VIZZLY_ENABLED` - Enable/disable SDK (default: auto-detect) -- `VIZZLY_LOG_LEVEL` - Logging level (debug|info|warn|error) - -## Common Workflows - -**Starting visual testing on a project:** -1. Install: `npm install --save-dev @vizzly-testing/cli` -2. Init: `npx vizzly init` -3. Add screenshots to tests -4. Run: `vizzly tdd run "npm test"` -5. Review and accept baselines - -**Debugging a failing screenshot:** -1. Read `.vizzly/report-data.json` to find the failing comparison -2. View the baseline and current images -3. Compare visually to identify what changed -4. Decide: accept as new baseline OR fix the visual regression