denchclaw 2.3.21 → 2.4.0

package/skills/gstack/design-consultation/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: design-consultation
+description: |
+  Build a complete design system from scratch. Research the landscape, propose
+  safe choices AND creative risks, generate DESIGN.md. Use when creating a new
+  design system or establishing design foundations for a project.
+---
+
+# Design Consultation — Build Your Design System
+
+You are a design partner helping establish the visual and interaction foundations for this project.
+
+**Related skills:** [plan-design-review](../plan-design-review/SKILL.md) | [design-review](../design-review/SKILL.md)
+
+---
+
+## Phase 1: Research
+
+1. **Understand the product** — What is it? Who uses it? What feeling should it evoke?
+2. **Landscape analysis** — Search for comparable products. Note what works and what doesn't.
+3. **Existing constraints** — Is there an existing design system? Brand guidelines? Framework limitations?
+
+---
+
+## Phase 2: Foundation Decisions
+
+For each decision, present 2-3 options with tradeoffs. One safe choice, one creative risk.
+
+### Typography
+- **Font stack** — System fonts vs. custom fonts. Weight and size scale.
+- **Type scale** — Modular scale ratio (1.25, 1.333, 1.5)
+- **Line height** — Body text (1.5-1.7), headings (1.1-1.3)
+
+### Color
+- **Primary palette** — Brand color + semantic colors (success, warning, error, info)
+- **Neutral scale** — Gray scale from background to foreground
+- **Dark mode** — Inverted palette or separate design tokens?
+- **Contrast ratios** — WCAG AA minimum (4.5:1 for text, 3:1 for large text)
+
+### Spacing
+- **Base unit** — 4px or 8px grid
+- **Scale** — 4, 8, 12, 16, 24, 32, 48, 64, 96
+- **Component spacing** — Padding and margin patterns
+
+### Layout
+- **Grid system** — 12-column? Flexible? Max width?
+- **Breakpoints** — Mobile-first? Which breakpoints?
+- **Container widths** — Narrow (prose), medium (content), wide (dashboard)
+
+### Components
+- **Buttons** — Primary, secondary, ghost, destructive. Sizes: sm, md, lg
+- **Forms** — Input styles, validation states, label placement
+- **Cards** — When to use cards vs. flat layout
+- **Navigation** — Top nav, sidebar, tabs, breadcrumbs
+- **Feedback** — Toasts, alerts, modals, loading states
+
+### Motion
+- **Duration scale** — 100ms (micro), 200ms (small), 300ms (medium), 500ms (large)
+- **Easing** — ease-out for enter, ease-in for exit
+- **Principles** — Purposeful, not decorative. Guide attention, not distract.
+
+---
+
+## Phase 3: Output
+
+Write `DESIGN.md` at the project root:
+
+```markdown
+# Design System
+
+## Principles
+[3-5 design principles specific to this product]
+
+## Typography
+[Font stack, scale, usage guidelines]
+
+## Color
+[Palettes with hex values, usage rules]
+
+## Spacing
+[Scale and usage patterns]
+
+## Components
+[Component patterns and when to use each]
+
+## Patterns
+[Common layout patterns, empty states, loading states, error states]
+```
+
+This document is referenced by [design-review](../design-review/SKILL.md) and [plan-design-review](../plan-design-review/SKILL.md) — patterns blessed in DESIGN.md are not flagged during review.

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

@@ -0,0 +1,72 @@
+---
+name: design-review
+description: |
+  Design audit of existing code. Same methodology as plan-design-review,
+  but applies fixes directly with atomic commits and before/after evidence.
+  Use when asked to audit the visual design of implemented code.
+---
+
+# Design Review — Audit and Fix
+
+Same design audit methodology as [plan-design-review](../plan-design-review/SKILL.md), but applied to existing code. You find issues AND fix them.
+
+**Related skills:** [plan-design-review](../plan-design-review/SKILL.md) | [design-consultation](../design-consultation/SKILL.md) | [review](../review/SKILL.md)
+
+---
+
+## Step 1: Context
+
+1. Check for DESIGN.md — patterns blessed here are not flagged
+2. Read changed frontend files (full files, not just diff hunks)
+3. Identify the design system in use (Tailwind, CSS modules, styled-components, etc.)
+
+---
+
+## Step 2: Audit
+
+Apply the same 8 dimensions from [plan-design-review](../plan-design-review/SKILL.md):
+
+1. Information Architecture
+2. Interaction Design
+3. Visual Hierarchy
+4. Consistency
+5. Accessibility
+6. Responsiveness
+7. Performance
+8. Delight
+
+Plus **AI Slop Detection** — check for gratuitous gradients, card soup, icon overload.
+
+---
+
+## Step 3: Fix
+
+For each finding:
+
+### Mechanical CSS fixes → AUTO-FIX
+- `outline: none` without alternative focus indicator → add `focus-visible` styles
+- `!important` that can be removed → increase specificity instead
+- `font-size < 16px` on mobile inputs → set to 16px to prevent iOS zoom
+- Missing `alt` on images → add descriptive alt text
+- Color contrast below WCAG AA → adjust colors
+
+### Design judgment needed → ASK
+Present each with before/after description and let the user decide.
+
+---
+
+## Step 4: Commit
+
+Each fix gets its own atomic commit:
+
+```
+fix(design): add focus-visible indicators to interactive elements
+fix(design): increase contrast ratio on secondary text
+fix(a11y): add alt text to profile images
+```
+
+---
+
+## Step 5: Scorecard
+
+Output the same scorecard as [plan-design-review](../plan-design-review/SKILL.md) showing before and after scores.

package/skills/gstack/document-release/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: document-release
+description: |
+  Update all project documentation to match what was just shipped. Catches stale
+  READMEs, outdated architecture docs, missing changelog entries.
+  Use after shipping features or when docs drift from code.
+---
+
+# Document Release — Keep Docs Current
+
+You are a technical writer. Read every doc file, cross-reference the diff, and update everything that drifted.
+
+**Related skills:** [ship](../ship/SKILL.md) | [review](../review/SKILL.md) | [retro](../retro/SKILL.md)
+
+---
+
+## Step 1: Inventory
+
+Find all documentation files:
+
+```bash
+find . -name "*.md" -not -path "*/node_modules/*" -not -path "*/.git/*" | head -50
+```
+
+Key files to check:
+- `README.md`
+- `ARCHITECTURE.md`
+- `CONTRIBUTING.md`
+- `CHANGELOG.md`
+- `CLAUDE.md` / `AGENTS.md`
+- `TODOS.md`
+- Any `docs/` directory
+
+---
+
+## Step 2: Diff Analysis
+
+```bash
+git log origin/main..HEAD --oneline
+git diff origin/main --stat
+```
+
+For each changed file, determine:
+- What feature/behavior changed?
+- Does any documentation describe this feature?
+- Is the documentation still accurate?
+
+---
+
+## Step 3: Update Each Doc
+
+### README.md
+- Are setup instructions still accurate?
+- Are feature descriptions current?
+- Are examples still working?
+- Are badges/links current?
+
+### ARCHITECTURE.md
+- Do data flow descriptions match current code?
+- Are component diagrams current?
+- Are technology choices documented?
+
+### CHANGELOG.md
+Add an entry for the release:
+
+```markdown
+## [Version] - YYYY-MM-DD
+
+### Added
+- [New features]
+
+### Changed
+- [Modified behavior]
+
+### Fixed
+- [Bug fixes]
+```
+
+### TODOS.md
+- Mark completed items as done
+- Add new items discovered during implementation
+- Remove items that are no longer relevant
+
+### API Documentation
+- Are endpoint descriptions current?
+- Are request/response examples accurate?
+- Are authentication requirements documented?
+
+---
+
+## Step 4: Commit
+
+```bash
+git add -A
+git commit -m "docs: update documentation for [feature/release]"
+```
+
+---
+
+## Output
+
+```
+DOCUMENTATION UPDATE
+═══════════════════════════════════════
+Files checked:     N
+Files updated:     N
+  - README.md (updated setup instructions)
+  - CHANGELOG.md (added v1.2.0 entry)
+  - TODOS.md (marked 3 items complete)
+Files current:     N (no changes needed)
+═══════════════════════════════════════
+```

package/skills/gstack/freeze/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: freeze
+description: |
+  Restrict file edits to one directory. Prevents accidental changes outside
+  scope while debugging or working on a focused task.
+  Use when you want to scope edits to a specific module or directory.
+---
+
+# Freeze — Scope Lock
+
+Restrict all file edits to a single directory. Prevents accidental changes to unrelated code while debugging or making focused changes.
+
+**Related skills:** [unfreeze](../unfreeze/SKILL.md) | [guard](../guard/SKILL.md) | [careful](../careful/SKILL.md) | [investigate](../investigate/SKILL.md)
+
+---
+
+## Activation
+
+When the user says "freeze to [directory]" or when [investigate](../investigate/SKILL.md) auto-locks scope:
+
+1. Record the allowed directory
+2. Before every file edit, check if the target file is within the allowed directory
+3. If outside: **block the edit** and explain why
+
+---
+
+## Behavior
+
+```
+🔒 FREEZE ACTIVE: edits restricted to src/auth/
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Allowed
+- Any file under the frozen directory
+- Reading files anywhere (read-only is always allowed)
+
+### Blocked
+- Editing files outside the frozen directory
+- Creating new files outside the frozen directory
+
+### When Blocked
+
+```
+⛔ EDIT BLOCKED: src/api/handler.ts is outside the freeze boundary (src/auth/)
+   Run /unfreeze to remove the restriction, or explain why this file needs to change.
+```
+
+---
+
+## Use Cases
+
+- **Debugging**: Lock to the buggy module to prevent scope creep
+- **Focused refactoring**: Only touch the files you're refactoring
+- **Code review fixes**: Only modify files in the PR
+
+Use [unfreeze](../unfreeze/SKILL.md) to remove the restriction.

package/skills/gstack/guard/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: guard
+description: |
+  Maximum safety mode — combines careful (destructive command warnings) with
+  freeze (edit scope restriction). Use when working with production systems
+  or making sensitive changes.
+---
+
+# Guard — Maximum Safety Mode
+
+Activates both [careful](../careful/SKILL.md) and [freeze](../freeze/SKILL.md) simultaneously. Maximum safety for production work.
+
+**Related skills:** [careful](../careful/SKILL.md) | [freeze](../freeze/SKILL.md) | [unfreeze](../unfreeze/SKILL.md)
+
+---
+
+## Activation
+
+When the user says "guard mode" or "be very careful":
+
+1. Activate [careful](../careful/SKILL.md) — warn before destructive commands
+2. Activate [freeze](../freeze/SKILL.md) — restrict edits to specified directory
+3. Display status:
+
+```
+🛡️  GUARD MODE ACTIVE
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Destructive command warnings: ON
+Edit scope: [directory] (or "ask user to specify")
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+## Deactivation
+
+Use [unfreeze](../unfreeze/SKILL.md) to remove both restrictions.

package/skills/gstack/investigate/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: investigate
+description: |
+  Systematic root-cause debugging. Four phases: investigate, analyze, hypothesize,
+  implement. Iron Law: no fixes without root cause investigation first.
+  Use when debugging errors, unexpected behavior, or troubleshooting.
+---
+
+# Systematic Debugging — Find the Root Cause
+
+**Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.**
+
+Fixing symptoms creates whack-a-mole debugging. Every fix that doesn't address root cause makes the next bug harder to find.
+
+**Related skills:** [review](../review/SKILL.md) | [qa](../qa/SKILL.md) | [careful](../careful/SKILL.md)
+
+---
+
+## Phase 1: Root Cause Investigation
+
+Gather context before forming any hypothesis.
+
+1. **Collect symptoms:** Read error messages, stack traces, reproduction steps. If not enough context, ask ONE question at a time.
+
+2. **Read the code:** Trace the code path from symptom to potential cause.
+
+3. **Check recent changes:**
+   ```bash
+   git log --oneline -20 -- <affected-files>
+   ```
+   Was this working before? What changed? A regression means the root cause is in the diff.
+
+4. **Reproduce:** Can you trigger the bug deterministically? If not, gather more evidence.
+
+Output: **"Root cause hypothesis: ..."** — a specific, testable claim about what is wrong and why.
+
+---
+
+## Phase 2: Pattern Analysis
+
+Check if this bug matches a known pattern:
+
+| Pattern | Signature | Where to look |
+|---------|-----------|---------------|
+| Race condition | Intermittent, timing-dependent | Concurrent access to shared state |
+| Nil/null propagation | TypeError, undefined is not a function | Missing guards on optional values |
+| State corruption | Inconsistent data, partial updates | Transactions, callbacks, hooks |
+| Integration failure | Timeout, unexpected response | External API calls, service boundaries |
+| Configuration drift | Works locally, fails in staging | Env vars, feature flags, DB state |
+| Stale cache | Shows old data, fixes on cache clear | Redis, CDN, browser cache |
+
+Also check TODOS.md for related known issues and `git log` for prior fixes in the same area — **recurring bugs in the same files are an architectural smell**.
+
+---
+
+## Phase 3: Hypothesis Testing
+
+Before writing ANY fix, verify your hypothesis.
+
+1. **Confirm:** Add a temporary log or assertion at the suspected root cause. Reproduce. Does evidence match?
+
+2. **If wrong:** Return to Phase 1. Gather more evidence. Do not guess.
+
+3. **3-strike rule:** If 3 hypotheses fail, **STOP.** Ask the user:
+   - A) Continue investigating with a new hypothesis
+   - B) Escalate for human review
+   - C) Add logging and catch it next time
+
+**Red flags — slow down:**
+- "Quick fix for now" — there is no "for now." Fix it right or escalate.
+- Proposing a fix before tracing data flow — you're guessing.
+- Each fix reveals a new problem elsewhere — wrong layer, not wrong code.
+
+---
+
+## Phase 4: Implementation
+
+Once root cause is confirmed:
+
+1. **Fix the root cause, not the symptom.** Smallest change that eliminates the actual problem.
+2. **Minimal diff.** Fewest files, fewest lines. Resist refactoring adjacent code.
+3. **Write a regression test** that fails without the fix and passes with it.
+4. **Run the full test suite.** No regressions.
+5. **If fix touches >5 files:** Flag the blast radius and ask before proceeding.
+
+---
+
+## Phase 5: Verification & Report
+
+**Reproduce the original bug and confirm it's fixed. This is not optional.**
+
+```
+DEBUG REPORT
+════════════════════════════════════════
+Symptom:         [what the user observed]
+Root cause:      [what was actually wrong]
+Fix:             [what was changed, file:line]
+Evidence:        [test output showing fix works]
+Regression test: [file:line of the new test]
+Status:          DONE | DONE_WITH_CONCERNS | BLOCKED
+════════════════════════════════════════
+```
+
+---
+
+## Important Rules
+
+- **3+ failed fix attempts → STOP and question the architecture.**
+- **Never apply a fix you cannot verify.**
+- **Never say "this should fix it."** Verify and prove it.
+- **If fix touches >5 files → ask first.**

package/skills/gstack/land-and-deploy/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: land-and-deploy
+description: |
+  Merge the PR, wait for CI and deploy, verify production health.
+  Takes over after ship. One command from "approved" to "verified in production."
+---
+
+# Land and Deploy — From Approved to Verified
+
+Takes over where [ship](../ship/SKILL.md) left off. Merge, deploy, verify.
+
+**Related skills:** [ship](../ship/SKILL.md) | [canary](../canary/SKILL.md) | [qa](../qa/SKILL.md)
+
+---
+
+## Step 1: Pre-Merge Checks
+
+```bash
+gh pr checks
+gh pr view --json reviewDecision -q .reviewDecision
+```
+
+- All CI checks must pass
+- PR must be approved (or the user explicitly overrides)
+
+---
+
+## Step 2: Merge
+
+```bash
+gh pr merge --squash --delete-branch
+```
+
+Use squash merge by default (clean history). If the user prefers merge commits, honor that.
+
+---
+
+## Step 3: Wait for Deploy
+
+Monitor the deployment:
+
+1. Check CI/CD status after merge
+2. Wait for deploy to complete (poll deployment status)
+3. If deploy fails, alert the user immediately
+
+---
+
+## Step 4: Production Verification
+
+After deploy completes:
+
+1. Navigate to the production URL
+2. Verify the shipped feature works
+3. Check for console errors
+4. Check for network errors
+5. Screenshot key pages
+
+---
+
+## Step 5: Post-Deploy
+
+```
+DEPLOY REPORT
+═══════════════════════════════════════
+PR:               #123 (merged)
+Deploy status:    SUCCESS
+Production URL:   https://app.example.com
+Verification:     PASS
+═══════════════════════════════════════
+```
+
+If something breaks, offer to revert:
+```bash
+gh pr create --title "Revert: ..." --body "Reverting PR #123 due to ..."
+```
+
+For extended monitoring, use [canary](../canary/SKILL.md).

package/skills/gstack/office-hours/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: office-hours
+description: |
+  YC Office Hours — forcing questions that reframe the product before code.
+  Two modes: Startup mode (demand reality, status quo, narrowest wedge) and
+  Builder mode (design thinking for side projects and hackathons).
+  Saves a design doc that feeds into plan-ceo-review and plan-eng-review.
+  Use when asked to brainstorm, explore an idea, or before any planning skill.
+---
+
+# Office Hours — Reframe Before You Build
+
+You are running a YC-style office hours session. Your job is to understand the REAL problem — not the feature request — and reframe it before a single line of code is written.
+
+**Related skills:** [plan-ceo-review](../plan-ceo-review/SKILL.md) | [plan-eng-review](../plan-eng-review/SKILL.md) | [plan-design-review](../plan-design-review/SKILL.md)
+
+---
+
+## Mode Detection
+
+Detect mode from context:
+
+- **Startup mode** — The user is building something they want others to use. Revenue, users, or growth matters.
+- **Builder mode** — Side project, hackathon, learning exercise, open source. Joy of building matters.
+
+If unclear, ask: "Are you building this for users/customers, or is this a personal/learning project?"
+
+---
+
+## Startup Mode: Six Forcing Questions
+
+Ask these ONE AT A TIME. Wait for answers. Push back on vague answers.
+
+### 1. Demand Reality
+"Who desperately needs this RIGHT NOW — not 'would be nice,' but their hair is on fire? Can you name a specific person or company? What are they doing today instead?"
+
+### 2. Status Quo Challenge
+"What's the current workaround? How painful is it, really? If it's not painful enough that people are already hacking together solutions, the demand signal is weak."
+
+### 3. Desperate Specificity
+"Describe the most specific, narrow version of this problem. Not 'companies need better analytics' — more like 'Series A SaaS founders can't tell which free trial users will convert because their Mixpanel funnels show vanity metrics.'"
+
+### 4. Narrowest Wedge
+"What is the absolute smallest thing you could build that would make ONE person's life dramatically better? Not a platform. Not a suite. One workflow, one pain point, one user."
+
+### 5. Observation
+"What have you personally observed that others haven't? What do you know about this problem that isn't obvious? The best startups come from non-obvious observations."
+
+### 6. Future-Fit
+"If this works, where does it go in 5 years? Is this a feature, a product, or a company? And what does that tell you about where to start?"
+
+After all six questions, synthesize:
+
+```
+REFRAME
+═══════════════════════════════════════
+You said: [their original idea]
+What you're actually building: [reframed version]
+Why: [key insight from the six questions]
+Narrowest wedge: [smallest shippable version]
+═══════════════════════════════════════
+```
+
+Challenge at least 2 premises. Generate 2-3 implementation approaches with effort estimates.
+
+---
+
+## Builder Mode: Design Thinking
+
+For side projects, hackathons, and learning:
+
+1. **What excites you about this?** — Energy and curiosity, not market analysis.
+2. **What's the core interaction?** — The one thing the user DOES with this.
+3. **What's the fastest path to something you can show someone?** — Demo-driven development.
+4. **What would make YOU want to use this every day?** — Build for yourself first.
+
+---
+
+## Output: Design Doc
+
+After the session, write a design document:
+
+```markdown
+# Design Doc: [Feature/Product Name]
+
+## Problem Statement
+[Reframed problem from the session]
+
+## Key Insights
+[Non-obvious observations that emerged]
+
+## Approach
+[Chosen implementation approach]
+
+## Narrowest Wedge
+[Smallest shippable version]
+
+## Open Questions
+[Things to figure out during implementation]
+
+## Rejected Alternatives
+[Other approaches considered and why they were rejected]
+```
+
+Save the design doc to the workspace. This feeds directly into [plan-ceo-review](../plan-ceo-review/SKILL.md) and [plan-eng-review](../plan-eng-review/SKILL.md).