cp-toolkit 2.2.2 → 2.2.4

package/templates/skills/optional/web-design-guidelines/SKILL.md

@@ -1,57 +1,60 @@
----
-name: web-design-guidelines
-description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
-metadata:
-  author: vercel
-  version: "1.0.0"
-  argument-hint: <file-or-pattern>
----
-
-# Web Interface Guidelines
-
-Review files for compliance with Web Interface Guidelines.
-
-## How It Works
-
-1. Fetch the latest guidelines from the source URL below
-2. Read the specified files (or prompt user for files/pattern)
-3. Check against all rules in the fetched guidelines
-4. Output findings in the terse `file:line` format
-
-## Guidelines Source
-
-Fetch fresh guidelines before each review:
-
-```
-https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
-```
-
-Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
-
-## Usage
-
-When a user provides a file or pattern argument:
-1. Fetch guidelines from the source URL above
-2. Read the specified files
-3. Apply all rules from the fetched guidelines
-4. Output findings using the format specified in the guidelines
-
-If no files specified, ask the user which files to review.
-
----
-
-## Related Skills
-
-| Skill | When to Use |
-|-------|-------------|
-| **[frontend-design](../frontend-design/SKILL.md)** | Before coding - Learn design principles (color, typography, UX psychology) |
-| **web-design-guidelines** (this) | After coding - Audit for accessibility, performance, and best practices |
-
-## Design Workflow
-
-```
-1. DESIGN   → Read frontend-design principles
-2. CODE     → Implement the design
-3. AUDIT    → Run web-design-guidelines review ← YOU ARE HERE
-4. FIX      → Address findings from audit
-```
+---
+name: web-design-guidelines
+description: Review UI code for Web Interface Guidelines compliance. Use when asked
+  to "review my UI", "check accessibility", "audit design", "review UX", or "check
+  my site against best practices".
+metadata:
+  author: vercel
+  version: 1.0.0
+  argument-hint: <file-or-pattern>
+version: '1.0'
+---
+
+# Web Interface Guidelines
+
+Review files for compliance with Web Interface Guidelines.
+
+## How It Works
+
+1. Fetch the latest guidelines from the source URL below
+2. Read the specified files (or prompt user for files/pattern)
+3. Check against all rules in the fetched guidelines
+4. Output findings in the terse `file:line` format
+
+## Guidelines Source
+
+Fetch fresh guidelines before each review:
+
+```
+https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
+```
+
+Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
+
+## Usage
+
+When a user provides a file or pattern argument:
+1. Fetch guidelines from the source URL above
+2. Read the specified files
+3. Apply all rules from the fetched guidelines
+4. Output findings using the format specified in the guidelines
+
+If no files specified, ask the user which files to review.
+
+---
+
+## Related Skills
+
+| Skill | When to Use |
+|-------|-------------|
+| **[frontend-design](../frontend-design/SKILL.md)** | Before coding - Learn design principles (color, typography, UX psychology) |
+| **web-design-guidelines** (this) | After coding - Audit for accessibility, performance, and best practices |
+
+## Design Workflow
+
+```
+1. DESIGN   → Read frontend-design principles
+2. CODE     → Implement the design
+3. AUDIT    → Run web-design-guidelines review ← YOU ARE HERE
+4. FIX      → Address findings from audit
+```

package/templates/skills/optional/webapp-testing/SKILL.md

@@ -1,187 +1,188 @@
----
-name: webapp-testing
-description: Web application testing principles. E2E, Playwright, deep audit strategies.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# Web App Testing
-
-> Discover and test everything. Leave no route untested.
-
-## 🔧 Runtime Scripts
-
-**Execute these for automated browser testing:**
-
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/playwright_runner.py` | Basic browser test | `python scripts/playwright_runner.py https://example.com` |
-| | With screenshot | `python scripts/playwright_runner.py <url> --screenshot` |
-| | Accessibility check | `python scripts/playwright_runner.py <url> --a11y` |
-
-**Requires:** `pip install playwright && playwright install chromium`
-
----
-
-## 1. Deep Audit Approach
-
-### Discovery First
-
-| Target | How to Find |
-|--------|-------------|
-| Routes | Scan app/, pages/, router files |
-| API endpoints | Grep for HTTP methods |
-| Components | Find component directories |
-| Features | Read documentation |
-
-### Systematic Testing
-
-1. **Map** - List all routes/APIs
-2. **Scan** - Verify they respond
-3. **Test** - Cover critical paths
-
----
-
-## 2. Testing Pyramid for Web
-
-```
-        /\          E2E (Few)
-       /  \         Critical user flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, data flow
-   /          \
-  /------------\    Component (Many)
-                    Individual UI pieces
-```
-
----
-
-## 3. E2E Test Principles
-
-### What to Test
-
-| Priority | Tests |
-|----------|-------|
-| 1 | Happy path user flows |
-| 2 | Authentication flows |
-| 3 | Critical business actions |
-| 4 | Error handling |
-
-### E2E Best Practices
-
-| Practice | Why |
-|----------|-----|
-| Use data-testid | Stable selectors |
-| Wait for elements | Avoid flaky tests |
-| Clean state | Independent tests |
-| Avoid implementation details | Test user behavior |
-
----
-
-## 4. Playwright Principles
-
-### Core Concepts
-
-| Concept | Use |
-|---------|-----|
-| Page Object Model | Encapsulate page logic |
-| Fixtures | Reusable test setup |
-| Assertions | Built-in auto-wait |
-| Trace Viewer | Debug failures |
-
-### Configuration
-
-| Setting | Recommendation |
-|---------|----------------|
-| Retries | 2 on CI |
-| Trace | on-first-retry |
-| Screenshots | on-failure |
-| Video | retain-on-failure |
-
----
-
-## 5. Visual Testing
-
-### When to Use
-
-| Scenario | Value |
-|----------|-------|
-| Design system | High |
-| Marketing pages | High |
-| Component library | Medium |
-| Dynamic content | Lower |
-
-### Strategy
-
-- Baseline screenshots
-- Compare on changes
-- Review visual diffs
-- Update intentional changes
-
----
-
-## 6. API Testing Principles
-
-### Coverage Areas
-
-| Area | Tests |
-|------|-------|
-| Status codes | 200, 400, 404, 500 |
-| Response shape | Matches schema |
-| Error messages | User-friendly |
-| Edge cases | Empty, large, special chars |
-
----
-
-## 7. Test Organization
-
-### File Structure
-
-```
-tests/
-├── e2e/           # Full user flows
-├── integration/   # API, data
-├── component/     # UI units
-└── fixtures/      # Shared data
-```
-
-### Naming Convention
-
-| Pattern | Example |
-|---------|---------|
-| Feature-based | `login.spec.ts` |
-| Descriptive | `user-can-checkout.spec.ts` |
-
----
-
-## 8. CI Integration
-
-### Pipeline Steps
-
-1. Install dependencies
-2. Install browsers
-3. Run tests
-4. Upload artifacts (traces, screenshots)
-
-### Parallelization
-
-| Strategy | Use |
-|----------|-----|
-| Per file | Playwright default |
-| Sharding | Large suites |
-| Workers | Multiple browsers |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Hardcode waits | Use auto-wait |
-| Skip cleanup | Isolate tests |
-| Ignore flaky tests | Fix root cause |
-
----
-
-> **Remember:** E2E tests are expensive. Use them for critical paths only.
+---
+name: webapp-testing
+description: Web application testing principles. E2E, Playwright, deep audit strategies.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+version: '1.0'
+---
+
+# Web App Testing
+
+> Discover and test everything. Leave no route untested.
+
+## 🔧 Runtime Scripts
+
+**Execute these for automated browser testing:**
+
+| Script | Purpose | Usage |
+|--------|---------|-------|
+| `scripts/playwright_runner.py` | Basic browser test | `python scripts/playwright_runner.py https://example.com` |
+| | With screenshot | `python scripts/playwright_runner.py <url> --screenshot` |
+| | Accessibility check | `python scripts/playwright_runner.py <url> --a11y` |
+
+**Requires:** `pip install playwright && playwright install chromium`
+
+---
+
+## 1. Deep Audit Approach
+
+### Discovery First
+
+| Target | How to Find |
+|--------|-------------|
+| Routes | Scan app/, pages/, router files |
+| API endpoints | Grep for HTTP methods |
+| Components | Find component directories |
+| Features | Read documentation |
+
+### Systematic Testing
+
+1. **Map** - List all routes/APIs
+2. **Scan** - Verify they respond
+3. **Test** - Cover critical paths
+
+---
+
+## 2. Testing Pyramid for Web
+
+```
+        /\          E2E (Few)
+       /  \         Critical user flows
+      /----\
+     /      \       Integration (Some)
+    /--------\      API, data flow
+   /          \
+  /------------\    Component (Many)
+                    Individual UI pieces
+```
+
+---
+
+## 3. E2E Test Principles
+
+### What to Test
+
+| Priority | Tests |
+|----------|-------|
+| 1 | Happy path user flows |
+| 2 | Authentication flows |
+| 3 | Critical business actions |
+| 4 | Error handling |
+
+### E2E Best Practices
+
+| Practice | Why |
+|----------|-----|
+| Use data-testid | Stable selectors |
+| Wait for elements | Avoid flaky tests |
+| Clean state | Independent tests |
+| Avoid implementation details | Test user behavior |
+
+---
+
+## 4. Playwright Principles
+
+### Core Concepts
+
+| Concept | Use |
+|---------|-----|
+| Page Object Model | Encapsulate page logic |
+| Fixtures | Reusable test setup |
+| Assertions | Built-in auto-wait |
+| Trace Viewer | Debug failures |
+
+### Configuration
+
+| Setting | Recommendation |
+|---------|----------------|
+| Retries | 2 on CI |
+| Trace | on-first-retry |
+| Screenshots | on-failure |
+| Video | retain-on-failure |
+
+---
+
+## 5. Visual Testing
+
+### When to Use
+
+| Scenario | Value |
+|----------|-------|
+| Design system | High |
+| Marketing pages | High |
+| Component library | Medium |
+| Dynamic content | Lower |
+
+### Strategy
+
+- Baseline screenshots
+- Compare on changes
+- Review visual diffs
+- Update intentional changes
+
+---
+
+## 6. API Testing Principles
+
+### Coverage Areas
+
+| Area | Tests |
+|------|-------|
+| Status codes | 200, 400, 404, 500 |
+| Response shape | Matches schema |
+| Error messages | User-friendly |
+| Edge cases | Empty, large, special chars |
+
+---
+
+## 7. Test Organization
+
+### File Structure
+
+```
+tests/
+├── e2e/           # Full user flows
+├── integration/   # API, data
+├── component/     # UI units
+└── fixtures/      # Shared data
+```
+
+### Naming Convention
+
+| Pattern | Example |
+|---------|---------|
+| Feature-based | `login.spec.ts` |
+| Descriptive | `user-can-checkout.spec.ts` |
+
+---
+
+## 8. CI Integration
+
+### Pipeline Steps
+
+1. Install dependencies
+2. Install browsers
+3. Run tests
+4. Upload artifacts (traces, screenshots)
+
+### Parallelization
+
+| Strategy | Use |
+|----------|-----|
+| Per file | Playwright default |
+| Sharding | Large suites |
+| Workers | Multiple browsers |
+
+---
+
+## 9. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Test implementation | Test behavior |
+| Hardcode waits | Use auto-wait |
+| Skip cleanup | Isolate tests |
+| Ignore flaky tests | Fix root cause |
+
+---
+
+> **Remember:** E2E tests are expensive. Use them for critical paths only.