codeply-cli 0.3.0 → 0.4.0

package/skills/browser-qa/SKILL.md

@@ -1,105 +1,105 @@
----
-name: browser-qa
-description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
-metadata:
-  origin: ECC
----
-
-# Browser QA — Automated Visual Testing & Interaction
-
-## When to Use
-
-- After deploying a feature to staging/preview
-- When you need to verify UI behavior across pages
-- Before shipping — confirm layouts, forms, interactions actually work
-- When reviewing PRs that touch frontend code
-- Accessibility audits and responsive testing
-
-## How It Works
-
-Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
-
-### Safety first — blast radius (run read-only by default)
-
-Browser QA drives real auth and real user journeys, so treat the blast radius explicitly.
-Default to **read-only**: never run a **mutating** journey (checkout, payment, delete,
-mass-update) against a production URL — require an explicit opt-in **and** a staging/preview
-URL. Use seeded **test credentials**, never real production logins, and **redact**
-credentials/tokens/PII before saving any screenshot.
-
-### Phase 1: Smoke Test
-```
-1. Navigate to target URL
-2. Check for console errors (filter noise: analytics, third-party)
-3. Verify no 4xx/5xx in network requests
-4. Screenshot above-the-fold on desktop + mobile viewport
-5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
-   (INP replaced FID in March 2024; thresholds per web.dev)
-```
-
-### Phase 2: Interaction Test
-```
-1. Click every nav link — verify no dead links
-2. Submit forms with valid data — verify success state
-3. Submit forms with invalid data — verify error state
-4. Test auth flow: login → protected page → logout (test creds only, never prod)
-5. Test critical user journeys (checkout, onboarding, search)
-   — read-only by default; only exercise mutating journeys against staging
-     with explicit opt-in (see "Safety first" above)
-```
-
-### Phase 3: Visual Regression
-```
-1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
-2. Compare against committed baseline screenshots
-   — no baseline ⇒ report INCONCLUSIVE, never a silent PASS
-3. Flag layout shifts > 5px, missing elements, overflow
-4. Check dark mode if applicable
-```
-
-### Phase 4: Accessibility
-```
-1. Run axe-core or equivalent on each page
-2. Flag WCAG 2.2 AA violations (contrast, labels, focus order)
-3. Verify keyboard navigation works end-to-end
-4. Check screen reader landmarks
-```
-
-> Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is **necessary,
-> not sufficient** — keyboard nav, focus order, and a screen-reader pass still need a manual
-> check. Don't report "accessible" from an automated pass alone.
-
-## Output Format
-
-```markdown
-## QA Report — [URL] — [timestamp]
-
-### Smoke Test
-- Console errors: 0 critical, 2 warnings (analytics noise)
-- Network: all 200/304, no failures
-- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
-
-### Interactions
-- [✓] Nav links: 12/12 working
-- [✗] Contact form: missing error state for invalid email
-- [✓] Auth flow: login/logout working
-
-### Visual
-- [✗] Hero section overflows on 375px viewport
-- [✓] Dark mode: all pages consistent
-
-### Accessibility
-- 2 AA violations: missing alt text on hero image, low contrast on footer links
-
-### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
-# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline
-```
-
-## Integration
-
-Works with any browser MCP:
-- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
-- Playwright via `mcp__browserbase__*`
-- Direct Puppeteer scripts
-
-Pair with `/canary-watch` for post-deploy monitoring.
+---
+name: browser-qa
+description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
+metadata:
+  origin: ECC
+---
+
+# Browser QA — Automated Visual Testing & Interaction
+
+## When to Use
+
+- After deploying a feature to staging/preview
+- When you need to verify UI behavior across pages
+- Before shipping — confirm layouts, forms, interactions actually work
+- When reviewing PRs that touch frontend code
+- Accessibility audits and responsive testing
+
+## How It Works
+
+Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
+
+### Safety first — blast radius (run read-only by default)
+
+Browser QA drives real auth and real user journeys, so treat the blast radius explicitly.
+Default to **read-only**: never run a **mutating** journey (checkout, payment, delete,
+mass-update) against a production URL — require an explicit opt-in **and** a staging/preview
+URL. Use seeded **test credentials**, never real production logins, and **redact**
+credentials/tokens/PII before saving any screenshot.
+
+### Phase 1: Smoke Test
+```
+1. Navigate to target URL
+2. Check for console errors (filter noise: analytics, third-party)
+3. Verify no 4xx/5xx in network requests
+4. Screenshot above-the-fold on desktop + mobile viewport
+5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
+   (INP replaced FID in March 2024; thresholds per web.dev)
+```
+
+### Phase 2: Interaction Test
+```
+1. Click every nav link — verify no dead links
+2. Submit forms with valid data — verify success state
+3. Submit forms with invalid data — verify error state
+4. Test auth flow: login → protected page → logout (test creds only, never prod)
+5. Test critical user journeys (checkout, onboarding, search)
+   — read-only by default; only exercise mutating journeys against staging
+     with explicit opt-in (see "Safety first" above)
+```
+
+### Phase 3: Visual Regression
+```
+1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
+2. Compare against committed baseline screenshots
+   — no baseline ⇒ report INCONCLUSIVE, never a silent PASS
+3. Flag layout shifts > 5px, missing elements, overflow
+4. Check dark mode if applicable
+```
+
+### Phase 4: Accessibility
+```
+1. Run axe-core or equivalent on each page
+2. Flag WCAG 2.2 AA violations (contrast, labels, focus order)
+3. Verify keyboard navigation works end-to-end
+4. Check screen reader landmarks
+```
+
+> Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is **necessary,
+> not sufficient** — keyboard nav, focus order, and a screen-reader pass still need a manual
+> check. Don't report "accessible" from an automated pass alone.
+
+## Output Format
+
+```markdown
+## QA Report — [URL] — [timestamp]
+
+### Smoke Test
+- Console errors: 0 critical, 2 warnings (analytics noise)
+- Network: all 200/304, no failures
+- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
+
+### Interactions
+- [✓] Nav links: 12/12 working
+- [✗] Contact form: missing error state for invalid email
+- [✓] Auth flow: login/logout working
+
+### Visual
+- [✗] Hero section overflows on 375px viewport
+- [✓] Dark mode: all pages consistent
+
+### Accessibility
+- 2 AA violations: missing alt text on hero image, low contrast on footer links
+
+### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
+# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline
+```
+
+## Integration
+
+Works with any browser MCP:
+- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
+- Playwright via `mcp__browserbase__*`
+- Direct Puppeteer scripts
+
+Pair with `/canary-watch` for post-deploy monitoring.

package/skills/bun-runtime/SKILL.md

@@ -1,85 +1,85 @@
----
-name: bun-runtime
-description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
-metadata:
-  origin: ECC
----
-
-# Bun Runtime
-
-Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
-
-## When to Use
-
-- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
-- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
-
-Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
-
-## How It Works
-
-- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
-- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
-- **Bundler**: Built-in bundler and transpiler for apps and libraries.
-- **Test runner**: Built-in `bun test` with Jest-like API.
-
-**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
-
-**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
-
-## Examples
-
-### Run and install
-
-```bash
-# Install dependencies (creates/updates bun.lock or bun.lockb)
-bun install
-
-# Run a script or file
-bun run dev
-bun run src/index.ts
-bun src/index.ts
-```
-
-### Scripts and env
-
-```bash
-bun run --env-file=.env dev
-FOO=bar bun run script.ts
-```
-
-### Testing
-
-```bash
-bun test
-bun test --watch
-```
-
-```typescript
-// test/example.test.ts
-import { expect, test } from "bun:test";
-
-test("add", () => {
-  expect(1 + 2).toBe(3);
-});
-```
-
-### Runtime API
-
-```typescript
-const file = Bun.file("package.json");
-const json = await file.json();
-
-Bun.serve({
-  port: 3000,
-  fetch(req) {
-    return new Response("Hello");
-  },
-});
-```
-
-## Best Practices
-
-- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
-- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
-- Keep dependencies up to date; Bun and the ecosystem evolve quickly.
+---
+name: bun-runtime
+description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
+metadata:
+  origin: ECC
+---
+
+# Bun Runtime
+
+Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
+
+## When to Use
+
+- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
+- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
+
+Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
+
+## How It Works
+
+- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
+- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
+- **Bundler**: Built-in bundler and transpiler for apps and libraries.
+- **Test runner**: Built-in `bun test` with Jest-like API.
+
+**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
+
+**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
+
+## Examples
+
+### Run and install
+
+```bash
+# Install dependencies (creates/updates bun.lock or bun.lockb)
+bun install
+
+# Run a script or file
+bun run dev
+bun run src/index.ts
+bun src/index.ts
+```
+
+### Scripts and env
+
+```bash
+bun run --env-file=.env dev
+FOO=bar bun run script.ts
+```
+
+### Testing
+
+```bash
+bun test
+bun test --watch
+```
+
+```typescript
+// test/example.test.ts
+import { expect, test } from "bun:test";
+
+test("add", () => {
+  expect(1 + 2).toBe(3);
+});
+```
+
+### Runtime API
+
+```typescript
+const file = Bun.file("package.json");
+const json = await file.json();
+
+Bun.serve({
+  port: 3000,
+  fetch(req) {
+    return new Response("Hello");
+  },
+});
+```
+
+## Best Practices
+
+- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
+- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
+- Keep dependencies up to date; Bun and the ecosystem evolve quickly.

package/skills/canary-watch/SKILL.md

@@ -1,108 +1,108 @@
----
-name: canary-watch
-description: Use this skill to monitor and verify a deployed URL after releases — checks HTTP endpoints, SSE streams, static assets, console errors, and performance regressions after deploys, merges, or dependency upgrades. Smoke / canary / post-deploy verification.
-metadata:
-  origin: ECC
----
-
-# Canary Watch — Post-Deploy Monitoring
-
-## When to Use
-
-- After deploying to production or staging
-- After merging a risky PR
-- When you want to verify a fix actually fixed it
-- Continuous monitoring during a launch window
-- After dependency upgrades
-
-## How It Works
-
-Monitors a deployed URL for regressions. Runs in a loop until stopped or until the watch window expires.
-
-### What It Watches
-
-```
-1. HTTP Status — is the page returning 200?
-2. Console Errors — new errors that weren't there before?
-3. Network Failures — failed API calls, 5xx responses?
-4. Performance — LCP/CLS/INP regression vs baseline?
-5. Content — did key elements disappear? (h1, nav, footer, CTA)
-6. API Health — are critical endpoints responding within SLA?
-7. Static Assets — are JS, CSS, image, and font requests returning 2xx/3xx with expected content types?
-8. SSE Streams — do event-stream endpoints connect and receive an initial event or heartbeat?
-```
-
-### Watch Modes
-
-**Quick check** (default): single pass, report results
-```
-/canary-watch https://myapp.com
-```
-
-**Sustained watch**: check every N minutes for M hours
-```
-/canary-watch https://myapp.com --interval 5m --duration 2h
-```
-
-**Diff mode**: compare staging vs production
-```
-/canary-watch --compare https://staging.myapp.com https://myapp.com
-```
-
-### Alert Thresholds
-
-```yaml
-critical:  # immediate alert
-  - HTTP status != 200
-  - Console error count > 5 (new errors only)
-  - LCP > 4s
-  - API endpoint returns 5xx
-  - Static asset returns 4xx/5xx
-  - SSE endpoint cannot connect or drops before first heartbeat
-
-warning:   # flag in report
-  - LCP increased > 500ms from baseline
-  - CLS > 0.1
-  - New console warnings
-  - Response time > 2x baseline
-  - Static asset content type changed unexpectedly
-  - SSE heartbeat latency > 2x baseline
-
-info:      # log only
-  - Minor performance variance
-  - New network requests (third-party scripts added?)
-```
-
-### Notifications
-
-When a critical threshold is crossed:
-- Desktop notification (macOS/Linux)
-- Optional: Slack/Discord webhook
-- Log to `~/.claude/canary-watch.log`
-
-## Output
-
-```markdown
-## Canary Report — myapp.com — 2026-03-23 03:15 PST
-
-### Status: HEALTHY ✓
-
-| Check | Result | Baseline | Delta |
-|-------|--------|----------|-------|
-| HTTP | 200 ✓ | 200 | — |
-| Console errors | 0 ✓ | 0 | — |
-| LCP | 1.8s ✓ | 1.6s | +200ms |
-| CLS | 0.01 ✓ | 0.01 | — |
-| API /health | 145ms ✓ | 120ms | +25ms |
-| Static assets | 42/42 ✓ | 42/42 | — |
-| SSE /events | connected ✓ | connected | +80ms heartbeat |
-
-### No regressions detected. Deploy is clean.
-```
-
-## Integration
-
-Pair with:
-- `/browser-qa` for pre-deploy verification
-- Hooks: add as a PostToolUse hook on `git push` to auto-check after deploys
-- CI: run in GitHub Actions after deploy step
+---
+name: canary-watch
+description: Use this skill to monitor and verify a deployed URL after releases — checks HTTP endpoints, SSE streams, static assets, console errors, and performance regressions after deploys, merges, or dependency upgrades. Smoke / canary / post-deploy verification.
+metadata:
+  origin: ECC
+---
+
+# Canary Watch — Post-Deploy Monitoring
+
+## When to Use
+
+- After deploying to production or staging
+- After merging a risky PR
+- When you want to verify a fix actually fixed it
+- Continuous monitoring during a launch window
+- After dependency upgrades
+
+## How It Works
+
+Monitors a deployed URL for regressions. Runs in a loop until stopped or until the watch window expires.
+
+### What It Watches
+
+```
+1. HTTP Status — is the page returning 200?
+2. Console Errors — new errors that weren't there before?
+3. Network Failures — failed API calls, 5xx responses?
+4. Performance — LCP/CLS/INP regression vs baseline?
+5. Content — did key elements disappear? (h1, nav, footer, CTA)
+6. API Health — are critical endpoints responding within SLA?
+7. Static Assets — are JS, CSS, image, and font requests returning 2xx/3xx with expected content types?
+8. SSE Streams — do event-stream endpoints connect and receive an initial event or heartbeat?
+```
+
+### Watch Modes
+
+**Quick check** (default): single pass, report results
+```
+/canary-watch https://myapp.com
+```
+
+**Sustained watch**: check every N minutes for M hours
+```
+/canary-watch https://myapp.com --interval 5m --duration 2h
+```
+
+**Diff mode**: compare staging vs production
+```
+/canary-watch --compare https://staging.myapp.com https://myapp.com
+```
+
+### Alert Thresholds
+
+```yaml
+critical:  # immediate alert
+  - HTTP status != 200
+  - Console error count > 5 (new errors only)
+  - LCP > 4s
+  - API endpoint returns 5xx
+  - Static asset returns 4xx/5xx
+  - SSE endpoint cannot connect or drops before first heartbeat
+
+warning:   # flag in report
+  - LCP increased > 500ms from baseline
+  - CLS > 0.1
+  - New console warnings
+  - Response time > 2x baseline
+  - Static asset content type changed unexpectedly
+  - SSE heartbeat latency > 2x baseline
+
+info:      # log only
+  - Minor performance variance
+  - New network requests (third-party scripts added?)
+```
+
+### Notifications
+
+When a critical threshold is crossed:
+- Desktop notification (macOS/Linux)
+- Optional: Slack/Discord webhook
+- Log to `~/.claude/canary-watch.log`
+
+## Output
+
+```markdown
+## Canary Report — myapp.com — 2026-03-23 03:15 PST
+
+### Status: HEALTHY ✓
+
+| Check | Result | Baseline | Delta |
+|-------|--------|----------|-------|
+| HTTP | 200 ✓ | 200 | — |
+| Console errors | 0 ✓ | 0 | — |
+| LCP | 1.8s ✓ | 1.6s | +200ms |
+| CLS | 0.01 ✓ | 0.01 | — |
+| API /health | 145ms ✓ | 120ms | +25ms |
+| Static assets | 42/42 ✓ | 42/42 | — |
+| SSE /events | connected ✓ | connected | +80ms heartbeat |
+
+### No regressions detected. Deploy is clean.
+```
+
+## Integration
+
+Pair with:
+- `/browser-qa` for pre-deploy verification
+- Hooks: add as a PostToolUse hook on `git push` to auto-check after deploys
+- CI: run in GitHub Actions after deploy step