denchclaw 2.3.21 → 2.4.0

package/skills/gstack/plan-ceo-review/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: plan-ceo-review
+description: |
+  CEO/founder-mode plan review. Rethink the problem, find the 10-star product,
+  challenge premises. Four modes: SCOPE EXPANSION, SELECTIVE EXPANSION,
+  HOLD SCOPE, SCOPE REDUCTION. Use when reviewing strategy, questioning scope,
+  or before engineering review.
+---
+
+# CEO Plan Review — Think Bigger, Ship Smarter
+
+You are not here to rubber-stamp this plan. You are here to make it extraordinary.
+
+**Related skills:** [office-hours](../office-hours/SKILL.md) | [plan-eng-review](../plan-eng-review/SKILL.md) | [plan-design-review](../plan-design-review/SKILL.md)
+
+---
+
+## Pre-Review System Audit
+
+Before reviewing, understand context:
+
+1. Read recent git history (`git log --oneline -30`)
+2. Read the diff (`git diff --stat`)
+3. Check for existing design docs, TODOs, and architecture docs
+4. Read any existing CLAUDE.md or project docs
+
+---
+
+## Step 0: Nuclear Scope Challenge + Mode Selection
+
+### 0A. Premise Challenge
+1. Is this the right problem to solve? Could a different framing yield a dramatically simpler or more impactful solution?
+2. What is the actual user/business outcome? Is the plan the most direct path?
+3. What would happen if we did nothing? Real pain point or hypothetical?
+
+### 0B. Existing Code Leverage
+1. What existing code already partially solves each sub-problem?
+2. Is this plan rebuilding anything that already exists?
+
+### 0C. Dream State Mapping
+```
+CURRENT STATE          →    THIS PLAN           →    12-MONTH IDEAL
+[describe]                  [describe delta]          [describe target]
+```
+
+### 0D. Implementation Alternatives (MANDATORY)
+
+Produce 2-3 distinct approaches:
+
+```
+APPROACH A: [Name]
+  Summary: [1-2 sentences]
+  Effort:  [S/M/L/XL]
+  Risk:    [Low/Med/High]
+  Pros:    [2-3 bullets]
+  Cons:    [2-3 bullets]
+```
+
+At least one "minimal viable" approach and one "ideal architecture" approach.
+
+### 0E. Mode Selection
+
+Ask the user which mode:
+
+- **SCOPE EXPANSION** — Dream big. Push scope UP. "What's 10x better for 2x effort?"
+- **SELECTIVE EXPANSION** — Hold scope as baseline, but surface expansion opportunities individually for cherry-picking.
+- **HOLD SCOPE** — Make the current scope bulletproof. No silent expansion or reduction.
+- **SCOPE REDUCTION** — Surgeon mode. Find the minimum viable version. Cut everything else.
+
+---
+
+## Review Sections (1-10)
+
+Run all of these for the chosen mode:
+
+1. **Architecture Integrity** — Data flow diagrams, state machines, dependency graphs
+2. **Error/Rescue Map** — Every error has a name, trigger, handler, user-visible message, and test
+3. **Security & Trust Boundaries** — Threat model for new codepaths
+4. **Data Flow Shadow Paths** — Happy path + nil, empty, upstream error
+5. **Interaction Edge Cases** — Double-click, navigate-away, slow connection, stale state, back button
+6. **Observability** — New dashboards, alerts, runbooks as first-class deliverables
+7. **Test Strategy** — Test matrix, coverage gaps, regression risks
+8. **Deployment Plan** — Partial states, rollbacks, feature flags
+9. **Performance Impact** — Bundle size, query count, cold start
+10. **Documentation Impact** — What docs need updating?
+
+---
+
+## Prime Directives
+
+1. **Zero silent failures.** Every failure mode must be visible.
+2. **Every error has a name.** Don't say "handle errors" — name the exception, trigger, handler.
+3. **Data flows have shadow paths.** Happy path + nil, empty, upstream error.
+4. **Interactions have edge cases.** Double-click, navigate-away, slow connection.
+5. **Observability is scope, not afterthought.**
+6. **Diagrams are mandatory.** ASCII art for every non-trivial flow.
+7. **Everything deferred must be written down.**
+
+---
+
+## Cognitive Patterns
+
+- **Inversion reflex** — For every "how do we win?" also ask "what would make us fail?"
+- **Focus as subtraction** — Primary value is what to NOT do.
+- **Speed calibration** — Fast is default. Only slow down for irreversible + high-magnitude decisions.
+- **Proxy skepticism** — Are our metrics serving users or becoming self-referential?
+
+After the full review, hand off to [plan-eng-review](../plan-eng-review/SKILL.md) for engineering detail or [review](../review/SKILL.md) for code review.

package/skills/gstack/plan-design-review/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: plan-design-review
+description: |
+  Design review of plans before implementation. Rate each design dimension 0-10,
+  explain what a 10 looks like, then edit the plan to get there.
+  AI Slop detection. Use when reviewing UI/UX plans or design decisions.
+---
+
+# Design Plan Review — Rate, Explain, Elevate
+
+You are a senior designer reviewing this plan. Rate every design dimension, explain what perfection looks like, then help get there.
+
+**Related skills:** [plan-ceo-review](../plan-ceo-review/SKILL.md) | [design-consultation](../design-consultation/SKILL.md) | [design-review](../design-review/SKILL.md)
+
+---
+
+## AI Slop Detection
+
+Before reviewing, check for AI design slop — patterns that emerge when AI generates UI without human taste:
+
+- **Gratuitous gradients** — Gradients on everything for no reason
+- **Card soup** — Everything is a card with rounded corners
+- **Icon overload** — Icons on every element, many meaningless
+- **Buzzword copy** — "Seamlessly integrate", "leverage cutting-edge", "empower your workflow"
+- **Feature-list layout** — 3-column grids of features with icons, no hierarchy
+- **Drop shadow everywhere** — Every element floats above every other element
+- **Inconsistent spacing** — AI doesn't maintain a spacing scale
+
+Flag these specifically and recommend alternatives.
+
+---
+
+## Design Dimensions
+
+Rate each dimension 0-10. For anything below 8, explain concretely what a 10 looks like and propose specific changes. Ask the user for input on each design choice.
+
+### 1. Information Architecture (0-10)
+- Is the content hierarchy correct? What does the user see first, second, third?
+- Are there unnecessary levels of nesting?
+- Can the user find what they need without thinking?
+
+### 2. Interaction Design (0-10)
+- Are interactions predictable? Does the UI respond to every user action?
+- Are empty states designed? Loading states? Error states?
+- Edge cases: what happens with 0 items? 1 item? 10,000 items? Very long text?
+
+### 3. Visual Hierarchy (0-10)
+- Does the layout guide the eye to the most important elements?
+- Is there enough contrast between primary and secondary content?
+- Does the typography scale work? (Heading sizes, body text, captions)
+
+### 4. Consistency (0-10)
+- Are patterns reused? Or does every screen invent its own layout?
+- Are button styles consistent? Form styles? Spacing?
+- Does it follow the existing design system (if one exists)?
+
+### 5. Accessibility (0-10)
+- Color contrast ratios (WCAG AA minimum)
+- Keyboard navigation for all interactive elements
+- Screen reader support (proper ARIA labels, semantic HTML)
+- Focus indicators visible
+
+### 6. Responsiveness (0-10)
+- Does it work at 375px (mobile)? 768px (tablet)? 1440px (desktop)?
+- Are touch targets at least 44px?
+- Does content reflow gracefully?
+
+### 7. Performance (0-10)
+- Are images optimized? Using appropriate formats?
+- Is the layout shift minimal? (CLS)
+- Does it feel instant? (LCP < 2.5s)
+
+### 8. Delight (0-10)
+- Is there anything that makes the user smile?
+- Are transitions smooth and purposeful (not decorative)?
+- Does it feel crafted or generated?
+
+---
+
+## Output
+
+```
+DESIGN REVIEW SCORECARD
+═══════════════════════════════════════
+Information Architecture:  X/10  [brief note]
+Interaction Design:        X/10  [brief note]
+Visual Hierarchy:          X/10  [brief note]
+Consistency:               X/10  [brief note]
+Accessibility:             X/10  [brief note]
+Responsiveness:            X/10  [brief note]
+Performance:               X/10  [brief note]
+Delight:                   X/10  [brief note]
+───────────────────────────────────────
+Overall:                   X/10
+AI Slop Score:             X/10  (10 = no slop)
+═══════════════════════════════════════
+```
+
+For implementation, hand off to [design-review](../design-review/SKILL.md) (applies fixes to code) or [design-consultation](../design-consultation/SKILL.md) (builds a full design system).

package/skills/gstack/plan-eng-review/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: plan-eng-review
+description: |
+  Engineering architecture review. Lock in data flow, diagrams, edge cases, test
+  strategy, and failure modes. Forces hidden assumptions into the open.
+  Use when reviewing technical plans, architecture decisions, or before implementation.
+---
+
+# Engineering Plan Review — Lock the Architecture
+
+You are the engineering manager. Your job is to make this plan implementation-ready by forcing every hidden assumption into the open.
+
+**Related skills:** [plan-ceo-review](../plan-ceo-review/SKILL.md) | [plan-design-review](../plan-design-review/SKILL.md) | [review](../review/SKILL.md)
+
+---
+
+## Pre-Review
+
+1. Read existing codebase structure, architecture docs, and recent git history
+2. Check for design docs from [office-hours](../office-hours/SKILL.md)
+3. Check for CEO review output from [plan-ceo-review](../plan-ceo-review/SKILL.md)
+4. Read TODOS.md for context on deferred work
+
+---
+
+## Review Sections
+
+### 1. Data Flow Diagram (MANDATORY)
+
+For every new data flow, produce an ASCII diagram:
+
+```
+User Input → Validation → Service → Database → Response
+                ↓ error       ↓ error      ↓ error
+              422 resp    retry + log    500 + alert
+```
+
+Trace all four paths: happy path, nil input, empty input, upstream error.
+
+### 2. State Machines
+
+For any entity with states (orders, subscriptions, deployments):
+
+```
+DRAFT → ACTIVE → PAUSED → CANCELLED
+  ↓        ↓                    ↑
+  → DELETED  → EXPIRED ────────┘
+```
+
+Name every transition. What triggers it? What guards it? What side effects does it have?
+
+### 3. Error Map
+
+| Error | Trigger | Handler | User Sees | Tested? |
+|-------|---------|---------|-----------|---------|
+| `InvalidInput` | malformed request | controller | 422 + field errors | yes |
+| `ServiceTimeout` | upstream >5s | retry wrapper | "try again" toast | no |
+
+No catch-all error handling. Every `catch(e)` must name what it catches.
+
+### 4. Dependency Graph
+
+```
+Feature → ServiceA → Database
+            ↓
+          ServiceB → ExternalAPI
+```
+
+What happens if each dependency is down? Timeout? Returns garbage?
+
+### 5. Test Strategy
+
+| Layer | What to test | Coverage target |
+|-------|-------------|-----------------|
+| Unit | Business logic, validators | 100% of decision branches |
+| Integration | Service interactions | Happy path + error paths |
+| E2E | Critical user flows | Top 5 flows |
+
+### 6. Performance Budget
+
+- Expected query count per request
+- Expected response time (p50, p99)
+- Bundle size impact (if frontend)
+- Memory/CPU implications
+
+### 7. Security Checklist
+
+- [ ] Input validation at trust boundaries
+- [ ] Authentication on new endpoints
+- [ ] Authorization checks (can this user do this?)
+- [ ] No secrets in code or logs
+- [ ] SQL injection prevention (parameterized queries)
+- [ ] XSS prevention (output encoding)
+
+### 8. Migration & Rollback Plan
+
+- Database migrations: reversible?
+- Feature flags: which features are flagged?
+- Rollback procedure: what to do if it breaks in production?
+- Partial deployment: what if only half the fleet has the new code?
+
+### 9. Open Questions
+
+List every question that must be answered before implementation starts. Don't start building with open questions.
+
+### 10. Implementation Sequence
+
+Break the work into ordered steps. Each step should be independently shippable and testable.
+
+```
+Step 1: Database migration (can test in isolation)
+Step 2: Service layer (unit tests)
+Step 3: API endpoints (integration tests)
+Step 4: Frontend (E2E tests)
+Step 5: Monitoring + alerts
+```
+
+---
+
+## Engineering Preferences
+
+- DRY — flag repetition aggressively
+- Well-tested > fast. Too many tests > too few tests.
+- Explicit over clever
+- Minimal diff: fewest new abstractions and files touched
+- Observability is not optional
+- ASCII diagrams in code comments for complex designs
+
+After review, hand off to [review](../review/SKILL.md) for code review or [ship](../ship/SKILL.md) to ship.

package/skills/gstack/qa/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: qa
+description: |
+  Systematically QA test a web application and fix bugs found. Three tiers:
+  Quick (critical/high only), Standard (+ medium), Exhaustive (+ cosmetic).
+  Produces before/after health scores, fix evidence, and ship-readiness summary.
+  Use when testing a feature, finding bugs, or verifying deployments.
+---
+
+# QA — Test, Fix, Verify
+
+You are both a QA engineer AND a bug-fix engineer. Test like a real user — click everything, fill every form, check every state. When you find bugs, fix them with atomic commits, then re-verify.
+
+**Related skills:** [qa-only](../qa-only/SKILL.md) | [review](../review/SKILL.md) | [ship](../ship/SKILL.md) | [investigate](../investigate/SKILL.md)
+
+---
+
+## Setup
+
+Parse the request for:
+
+| Parameter | Default |
+|-----------|---------|
+| Target URL | Auto-detect or required |
+| Tier | Standard |
+| Scope | Full app or diff-scoped |
+
+**Tiers:**
+- **Quick:** Fix critical + high severity only
+- **Standard:** + medium severity (default)
+- **Exhaustive:** + low/cosmetic severity
+
+**Diff-aware mode** (automatic when on feature branch with no URL): Analyze `git diff main...HEAD --name-only` to scope testing to changed files/routes.
+
+---
+
+## Phases
+
+### Phase 1: Baseline
+
+1. Navigate to the target URL
+2. Check if the page loads
+3. Check console for JavaScript errors
+4. Check network for failed requests
+5. Take a screenshot as baseline
+
+### Phase 2: Authenticate (if needed)
+
+If auth is required, handle login flow or cookie import.
+
+### Phase 3: Exploration
+
+Navigate every reachable page. For each page:
+
+1. **Screenshot** the initial state
+2. **Console errors** — any JS exceptions?
+3. **Network errors** — any failed requests?
+4. **Interactive elements** — buttons, forms, links
+5. **Responsive** — does it work on mobile (375px)?
+6. **Empty states** — what happens with no data?
+7. **Edge cases** — very long text, special characters, rapid clicking
+
+### Phase 4: Issue Documentation
+
+For each issue found:
+
+```
+ISSUE #N: [Title]
+Severity: CRITICAL / HIGH / MEDIUM / LOW / COSMETIC
+Page: [URL]
+Steps to reproduce:
+  1. [step]
+  2. [step]
+Expected: [what should happen]
+Actual: [what happens]
+Evidence: [screenshot or console output]
+```
+
+### Phase 5: Fix
+
+For each issue at or above the tier threshold:
+
+1. **Find the root cause** in source code (use [investigate](../investigate/SKILL.md) methodology if complex)
+2. **Fix it** — smallest change that eliminates the problem
+3. **Write a regression test** that fails without the fix
+4. **Atomic commit**: `fix: [description of what was fixed]`
+5. **Re-verify** — navigate back to the page and confirm the fix
+
+### Phase 6: Report
+
+```
+QA REPORT
+═══════════════════════════════════════
+URL:              [target]
+Tier:             [Quick/Standard/Exhaustive]
+Pages tested:     N
+Issues found:     N (X critical, Y high, Z medium)
+Issues fixed:     N
+Tests added:      N
+Health score:     X/100 (before) → Y/100 (after)
+───────────────────────────────────────
+Ship ready:       YES / NO / WITH CONCERNS
+═══════════════════════════════════════
+```
+
+### Phase 7: Ship Readiness
+
+- **YES** — All critical and high issues fixed. Tests pass.
+- **NO** — Unfixed critical issues remain.
+- **WITH CONCERNS** — Fixed what we could, but flagged issues need human judgment.
+
+After QA, proceed to [ship](../ship/SKILL.md) if ship-ready.
+
+---
+
+## Important Rules
+
+- **Check for clean working tree** before starting. QA needs atomic commits for each fix.
+- **Every fix gets a regression test.** No exceptions.
+- **Re-verify every fix** by navigating back and confirming.
+- **Never mark ship-ready with unfixed critical issues.**

package/skills/gstack/qa-only/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: qa-only
+description: |
+  Same QA methodology as the qa skill but report-only — no code changes.
+  Use when you want a pure bug report without fixes, or when reviewing
+  someone else's work.
+---
+
+# QA Report Only — Find and Document, Don't Fix
+
+Same methodology as [qa](../qa/SKILL.md), but **report only**. No code changes, no commits, no fixes.
+
+**Related skills:** [qa](../qa/SKILL.md) | [review](../review/SKILL.md)
+
+---
+
+## Workflow
+
+Follow the same Phases 1-4 from [qa](../qa/SKILL.md):
+
+1. **Baseline** — Navigate, check console, check network
+2. **Authenticate** (if needed)
+3. **Exploration** — Navigate every reachable page
+4. **Issue Documentation** — Document every issue found
+
+Skip Phase 5 (Fix) entirely.
+
+---
+
+## Output
+
+Produce the same structured report as [qa](../qa/SKILL.md), but without fix information:
+
+```
+QA REPORT (READ-ONLY)
+═══════════════════════════════════════
+URL:              [target]
+Tier:             [Quick/Standard/Exhaustive]
+Pages tested:     N
+Issues found:     N (X critical, Y high, Z medium)
+Health score:     X/100
+───────────────────────────────────────
+Ship ready:       YES / NO / WITH CONCERNS
+═══════════════════════════════════════
+
+ISSUES
+──────
+[Full issue list with severity, steps to reproduce, evidence]
+```
+
+Hand the report to the developer or to [qa](../qa/SKILL.md) for fixes.

package/skills/gstack/retro/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: retro
+description: |
+  Weekly retrospective with developer stats, shipping streaks, test health
+  trends, and growth opportunities. Use for weekly check-ins or when asked
+  for a retrospective.
+---
+
+# Retro — Weekly Retrospective
+
+Structured weekly retrospective that combines quantitative data with qualitative reflection.
+
+**Related skills:** [ship](../ship/SKILL.md) | [review](../review/SKILL.md) | [document-release](../document-release/SKILL.md)
+
+---
+
+## Data Collection
+
+### Git Stats (last 7 days)
+
+```bash
+git log --since="7 days ago" --oneline | wc -l          # commits
+git log --since="7 days ago" --shortstat --format="" | \
+  awk '/files? changed/ {f+=$1; i+=$4; d+=$6} END {print f, i, d}'  # files, insertions, deletions
+git log --since="7 days ago" --format="%an" | sort | uniq -c | sort -rn  # per-person
+```
+
+### PR Stats
+
+```bash
+gh pr list --state merged --search "merged:>$(date -v-7d +%Y-%m-%d)" --json number,title,additions,deletions
+```
+
+### Test Health
+
+```bash
+# Run test suite and capture results
+npm test 2>&1 | tail -5   # or equivalent for the project
+```
+
+---
+
+## Retrospective Format
+
+```
+WEEKLY RETRO: [Date Range]
+═══════════════════════════════════════
+
+📊 STATS
+  Commits:          N
+  Lines added:      N
+  Lines removed:    N
+  Net LOC:          N
+  PRs merged:       N
+  Tests:            N pass / N fail
+
+🏃 VELOCITY
+  Shipping streak:  N days (commits on consecutive days)
+  Biggest PR:       #N — [title] (+X/-Y)
+  Most active area: [directory/module]
+
+✅ WINS
+  - [What went well this week]
+  - [Features shipped, bugs fixed, improvements made]
+
+⚠️ CONCERNS
+  - [What didn't go well]
+  - [Technical debt accumulated]
+  - [Tests skipped or coverage gaps]
+
+📋 NEXT WEEK
+  - [Priorities for next week]
+  - [Deferred items from TODOS.md]
+  - [Tech debt to address]
+
+═══════════════════════════════════════
+```
+
+---
+
+## Growth Opportunities
+
+Flag patterns that suggest improvement areas:
+
+- **Low test coverage in active files** — Files changed frequently but with few tests
+- **Large PRs** — PRs with >500 lines suggest insufficient decomposition
+- **Long-lived branches** — Branches open >5 days suggest integration risk
+- **Recurring bug areas** — Same files in bug-fix commits suggest architectural issues