@torus-engineering/tas-kit 1.10.0 → 1.12.0

package/.claude/skills/browser-qa/SKILL.md

@@ -1,92 +0,0 @@
----
-name: browser-qa
-description: |
-  Auto-invoke when verifying UI behavior after a frontend feature deploy or PR,
-  running accessibility audits, or doing pre-ship validation of forms, navigation,
-  and critical user journeys. Requires browser automation MCP (claude-in-chrome or Playwright).
-  SKIP if no browser MCP is available — note the dependency gap to user instead.
-origin: ECC
-allowed-tools: Read, Bash
----
-
-# 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.
-
-### 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
-```
-
-### 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
-5. Test critical user journeys (checkout, onboarding, search)
-```
-
-### Phase 3: Visual Regression
-```
-1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
-2. Compare against baseline screenshots (if stored)
-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 AA violations (contrast, labels, focus order)
-3. Verify keyboard navigation works end-to-end
-4. Check screen reader landmarks
-```
-
-## 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)
-```
-
-## 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/.claude/skills/canary-watch/SKILL.md

@@ -1,104 +0,0 @@
----
-name: canary-watch
-description: |
-  Auto-invoke after deploying to production or staging, after merging a risky PR,
-  after dependency upgrades, or when monitoring a URL for regressions during a launch window.
-  Requires HTTP access to the target URL or browser MCP.
-  SKIP if target URL is not accessible — note the gap to user.
-origin: ECC
-allowed-tools: Read, Bash
----
-
-# 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?
-```
-
-### 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
-
-warning:   # flag in report
-  - LCP increased > 500ms from baseline
-  - CLS > 0.1
-  - New console warnings
-  - Response time > 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 `~/logs/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 |
-
-### 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