add CI images to repo

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

@@ -0,0 +1,66 @@
+---
+name: commit
+description: Generate commit messages and PR descriptions from implementation.
+---
+
+# Commit Skill
+
+Generates commit messages from completed implementation.
+
+## Inputs
+
+Read these files:
+- **DESIGN.md** (design contract)
+- **IMPLEMENTATION.md** (if exists; provides decisions log, deviations)
+- **run `jj diff`** (actual changes)
+
+## Process
+
+### 1. Review Changes
+
+Examine diff to understand what changed. Cross-reference with DESIGN.md to understand why.
+
+### 2. Generate Commit Message
+
+**Format: Conventional Commits**
+
+```
+brief description
+
+Detailed body explaining:
+- What changed
+- Why (reference DESIGN.md problem/solution)
+```
+
+**Types**: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`
+
+**Example**:
+```
+feat: add support for nested JSON
+
+Changes:
+- Added parseNestedJSON() to handle nested patterns
+- Updated JSONParser.java to consume new patterns.
+```
+
+**Guidelines**:
+- One commit for the entire feature (per DESIGN.md)
+- Accurate, complete: human will edit further
+
+**Note**: IMPLEMENTATION.md should be deleted
+
+## Output
+
+Present to user:
+
+```
+=== COMMIT MESSAGE ===
+[Generated message]
+```
+
+Prompt user if they would like to commit using the message. If so, use `jj desc -m '<commit message>'`
+
+## Philosophy
+
+Your output is a **draft** for human editing. Optimize for accuracy and completeness, not polish. Provide context reviewers need:
+Good commit/PR messages make review faster and preserve project history.

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.

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

@@ -0,0 +1,129 @@
+---
+name: implement
+description: Mechanically execute approved design. Creates tasks, writes tests first, implements feature.
+---
+
+# Implement Skill
+
+Mechanical execution of DESIGN.md. No architectural decisions, only code that maps directly to specs.
+
+## Core Principle
+
+**Implementation is execution, not planning**. If you need to make a design decision, the design is incomplete. STOP and surface it.
+
+## Startup
+
+**MUST run on startup**:
+1. Read `DESIGN.md` from current directory
+2. If missing: STOP, instruct user to run `/design` first
+
+## Process
+
+### 1. Task Decomposition
+
+Create `IMPLEMENTATION.md` with ordered task list.
+
+**Task list structure**:
+
+```markdown
+# Task List
+
+## Status: [In Progress / Complete]
+
+- [ ] Task 1: Write tests for [feature area]
+  - Files: `tests/feature.test.c`
+  - Creates test cases from DESIGN.md § Test Cases
+- [ ] Task 2: Implement [interfaces]
+  - Files: `src/interfaces.c`
+  - Functions: `funcName()`
+  - Implements DESIGN.md § Interfaces & APIs
+- [ ] Task 3: Integrate [parts]
+  - Files: `src/main.c`, `src/util.c`
+  - Connects components per DESIGN.md § Architecture
+- [ ] Task 4: End-to-end validation
+  - Run all tests, verify feature works
+
+# Decisions Log
+
+Description of any deviation from DESIGN.md, with rationale. Remember that any deviation should be surfaced to the user.
+
+# Notes
+Any implementation context, gotchas encountered, etc.
+```
+
+**Task requirements**:
+- **First tasks write tests** from DESIGN.md test cases, provides feedback loops
+- Each task = one logical unit of diff
+- Specify: what changes, which files, which functions
+- Order to minimize conflicts/dependencies
+- Include end-to-end validation
+
+**Purpose**: State tracking across sessions. Prevents losing track when resuming. NOT for planning, all planning in DESIGN.md.
+
+### 2. Implementation
+
+Execute tasks in order. Update checkboxes as completed.
+
+**Rules**:
+- Map DESIGN.md specs directly to code
+- **Tests first**: run tests, fix failures, proceed
+- Do not introduce scope beyond DESIGN.md
+- **Minimal comments**: Only when drastically improving clarity. Prefer self-documenting code (clear names, small functions, obvious structure)
+- Mark tasks complete: `- [x] Task 1: ...`
+
+**Failure mode handling**:
+
+If task requires decision not in DESIGN.md:
+1. **STOP immediately**
+2. Surface ambiguity to user: "DESIGN.md doesn't specify [X]. Options: [A], [B]. Which should I use?"
+3. Recommend updating DESIGN.md
+4. User updates DESIGN.md → restart `/implement` from fresh session
+
+**Never make architectural decisions silently.**
+
+### 3. Test Feedback Loops
+
+- Run tests after implementing all functionality
+
+### 4. Decisions Log
+
+If any deviations from DESIGN.md occur (even minor), log in IMPLEMENTATION.md
+
+Examples:
+- Changed file structure slightly for [reason]
+- Added helper function not in DESIGN.md for [reason]
+- Adjusted error handling approach because [reason]
+
+## Code Style
+
+- **Self-documenting code**: Clear variable/function names, small focused functions
+- **Comments**: Rare. Only for non-obvious "why" (never "what")
+- Follow existing codebase patterns discovered during `/design`
+
+## Context Management
+
+For very large implementations: break into sub-sessions or delegate to subagents. Maintain coherence via shared DESIGN.md and IMPLEMENTATION.md.
+
+## Commit Scope
+
+**One feature = one commit**. Complete all tasks before invoking `/commit`.
+
+## Completion
+
+When all tasks complete:
+```
+Implementation complete. Ready for /commit to generate commit message and PR description.
+```
+
+## Artifact Lifecycle
+
+**IMPLEMENTATION.md is ephemeral** and deleted before commit. Only DESIGN.md is committed.
+
+## Philosophy
+
+You are a compiler: DESIGN.md → working code. The better the design, the more mechanical your work. If you're making judgment calls, something's wrong upstream - STOP.
+
+**Why mechanical execution?**
+- Prevents scope creep and ensures design intent preserved
+- Human made hard decisions with full context
+- Agent executes reliably without interpretation