add CI images to repo

home-manager/shared/programs/shell/pi/config/agent/skills/design/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: design
+description: Design features collaboratively to create exhaustive DESIGN.md doc. Triggers on "rubber duck", "help me design", "write a design doc".
+---
+
+# Design Skill
+
+Creates exhaustive design documents with zero ambiguity. All architectural decisions happen here: implementation is mechanical execution.
+
+## Core Principle
+
+**Minimal Agency**: Surface decisions, never make them silently. If unclear, ask. The human decides architecture; you structure and formalize.
+
+**Critical**: DESIGN.md must be SO explicit that implementation is mechanical. If implementer needs to make design decisions, the design is incomplete.
+
+## Process
+
+### 1. Ingest
+User provides raw notes/requirements. Treat as authoritative even if informal/incomplete.
+
+### 2. Discovery
+Before designing, **explore the codebase**:
+- `grep`/`find`/`read` to locate files, classes, functions user mentioned.
+- Understand existing patterns, conventions, architecture
+- Identify which files will be touched
+- Read relevant code for context
+
+Factor discoveries into design and respect existing patterns.
+
+### 3. Collaborative Design
+**Rubber duck mode**. Your job:
+- Ask clarifying questions until no ambiguities remain
+- Surface implicit assumptions, probe edge cases
+- Structure and formalize, but **never decide architecture unilaterally**
+- When decision needed and user hasn't made it: **explicitly surface as open question**
+
+### 4. Generate DESIGN.md
+
+Output to `DESIGN.md` with this **exact structure**:
+
+```markdown
+# Problem
+Clear statement of what needs solving and why.
+
+## Non-goals
+Explicit list of what this does NOT address.
+
+# Solution
+High-level approach description.
+
+## Architecture
+How components fit together, data flow, key patterns.
+- Exact code samples for key abstractions
+
+## Files to be Modified
+- `path/to/file` - Brief description of changes
+
+## Files to be Created
+- `path/to/file` - Purpose
+
+## Data Structures
+Exact type definitions, schemas, interfaces with code samples.
+
+## Interfaces & APIs
+Exact function signatures, class definitions with code samples.
+Include parameters, return types, behavior.
+
+## Algorithms & Logic
+Pseudocode or explicit descriptions of non-trivial logic.
+
+## Error Handling
+How errors detected, propagated, handled.
+
+# Test Cases
+Explicit scenarios with:
+- **Setup**: Preconditions, input
+- **Action**: What happens
+- **Expected**: Outcome/output
+Include edge cases and failure modes.
+
+# Implementation Notes
+Constraints, ordering requirements, gotchas.
+
+## Assumptions & Constraints
+Explicit list of assumptions.
+
+# Considered but Not Implemented
+Alternative approaches and why rejected.
+```
+
+### 5. Approval Gate
+
+**HARD GATE**: DESIGN.md must be approved before `/implement`. State:
+
+```
+DESIGN.md complete. Review and approve before running /implement.
+If incomplete or needs changes, let me know and I'll update.
+```
+
+Do not proceed without explicit approval.
+
+## Philosophy
+
+A good DESIGN.md reads like executable specification. Every conditional, every data structure, every interface is decided. Implementation maps spec to code with zero interpretation.
+
+**Why exhaustive design?**
+- Prevents mid-implementation thrashing
+- Human makes hard decisions with full context
+- Agent executes without architectural judgment calls
+- Design document becomes PR review artifact
+
+## Artifact Lifecycle
+
+DESIGN.md is **permanent** committed to repo, included in PRs for reviewers.