chore: move documentation files to old2 folder

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Makefile

@@ -4,7 +4,7 @@ CLAUDE_DIR := $(HOME)/.claude
 REPO_DIR := $(shell pwd)
 
 # Items to symlink
-ITEMS := commands scripts skills agents settings.json
+ITEMS := scripts skills agents settings.json
 
 install:
 	@echo "Installing Claude Code config symlinks..."

agents/code-reviewer/AGENT.md

@@ -1,76 +0,0 @@
----
-name: code-reviewer
-description: Automated code review of pull requests. Reviews PRs for quality, bugs, security, style, and test coverage. Spawn after PR creation or for on-demand review.
-# Model: sonnet provides good code understanding for review tasks.
-# The structured output format doesn't require opus-level reasoning.
-model: sonnet
-skills: gitea, code-review
-disallowedTools:
-  - Edit
-  - Write
----
-
-You are a code review specialist that provides immediate, structured feedback on pull request changes.
-
-## When Invoked
-
-You will receive a PR number to review. Follow this process:
-
-1. Fetch PR diff: checkout with `tea pulls checkout <number>`, then `git diff main...HEAD`
-2. Analyze the diff for issues in these categories:
-   - **Code Quality**: Readability, maintainability, complexity
-   - **Bugs**: Logic errors, edge cases, null checks
-   - **Security**: Injection vulnerabilities, auth issues, data exposure
-   - **Style**: Naming conventions, formatting, consistency
-   - **Test Coverage**: Missing tests, untested edge cases
-3. Generate a structured review comment
-4. Post the review using `tea comment <number> "<review body>"`
-5. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`
-6. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
-
-## Review Comment Format
-
-Post reviews in this structured format:
-
-```markdown
-## AI Code Review
-
-> This is an automated review generated by the code-reviewer agent.
-
-### Summary
-[Brief overall assessment]
-
-### Findings
-
-#### Code Quality
-- [Finding 1]
-- [Finding 2]
-
-#### Potential Bugs
-- [Finding or "No issues found"]
-
-#### Security Concerns
-- [Finding or "No issues found"]
-
-#### Style Notes
-- [Finding or "Consistent with codebase"]
-
-#### Test Coverage
-- [Finding or "Adequate coverage"]
-
-### Verdict
-[LGTM / Needs Changes / Blocking Issues]
-```
-
-## Verdict Criteria
-
-- **LGTM**: No blocking issues, code meets quality standards, ready to merge
-- **Needs Changes**: Minor issues worth addressing before merge
-- **Blocking Issues**: Security vulnerabilities, logic errors, or missing critical functionality
-
-## Guidelines
-
-- Be specific: Reference exact lines and explain *why* something is an issue
-- Be constructive: Suggest alternatives when pointing out problems
-- Be kind: Distinguish between blocking issues and suggestions
-- Acknowledge good solutions when you see them

commands/dashboard.md

@@ -1,13 +0,0 @@
----
-description: Show dashboard of open issues, PRs awaiting review, and CI status.
----
-
-# Repository Dashboard
-
-@~/.claude/skills/gitea/SKILL.md
-
-Fetch and display:
-1. All open issues
-2. All open PRs
-
-Format as tables showing number, title, and author.

commands/review-pr.md

@@ -1,38 +0,0 @@
----
-description: Review a Gitea pull request. Fetches PR details, diff, and comments.
-argument-hint: <pr-number>
----
-
-# Review PR #$1
-
-@~/.claude/skills/gitea/SKILL.md
-
-1. **View PR details** with `--comments` flag to see description, metadata, and discussion
-2. **Get the diff** to review the changes
-
-Review the changes and provide feedback on:
-- Code quality
-- Potential bugs
-- Test coverage
-- Documentation
-
-Ask the user what action to take:
-- **Merge**: Post review summary as comment, then merge with rebase style
-- **Request changes**: Leave feedback without merging
-- **Comment only**: Add a comment for discussion
-
-## Merging
-
-Always use tea CLI for merges to preserve user attribution:
-
-```bash
-tea pulls merge <number> --style rebase
-```
-
-For review comments, use `tea comment` since `tea pulls review` is interactive-only:
-
-```bash
-tea comment <number> "<review summary>"
-```
-
-> **Warning**: Never use the Gitea API with admin credentials for user-facing operations like merging. This causes the merge to be attributed to the admin account instead of the user.

commands/work-issue.md

@@ -1,17 +0,0 @@
----
-description: Work on a Gitea issue. Fetches issue details and sets up branch for implementation.
-argument-hint: <issue-number>
----
-
-# Work on Issue #$1
-
-@~/.claude/skills/gitea/SKILL.md
-
-1. **View the issue** with `--comments` flag to understand requirements and context
-2. **Create a branch**: `git checkout -b issue-$1-<short-kebab-title>`
-3. **Plan**: Use TodoWrite to break down the work based on acceptance criteria
-4. **Implement** the changes
-5. **Commit** with message referencing the issue
-6. **Push** the branch to origin
-7. **Create PR** with title "[Issue #$1] <title>" and body "Closes #$1"
-8. **Auto-review**: Inform the user that auto-review is starting, then spawn the `code-reviewer` agent in background (using `run_in_background: true`) with the PR number

docs/writing-agents.md

@@ -1,709 +0,0 @@
-# Writing Agents
-
-A guide to creating specialized subagents that combine multiple skills for complex, context-isolated tasks.
-
-## What is an Agent?
-
-Agents are **specialized subprocesses** that combine multiple skills into focused personas. Unlike commands (which define workflows) or skills (which encode knowledge), agents are autonomous workers that can handle complex tasks independently.
-
-Think of agents as specialists you can delegate work to. They have their own context, their own expertise (via skills), and they report back when finished.
-
-## File Structure
-
-Agents live in the `agents/` directory, each in its own folder:
-
-```
-agents/
-└── product-manager/
-    └── AGENT.md
-```
-
-### Why AGENT.md?
-
-The uppercase `AGENT.md` filename:
-- Makes the agent file immediately visible in directory listings
-- Follows a consistent convention across all agents
-- Clearly identifies the primary file in an agent folder
-
-### Supporting Files (Optional)
-
-An agent folder can contain additional files if needed:
-
-```
-agents/
-└── code-reviewer/
-    ├── AGENT.md           # Main agent document (required)
-    └── checklists/        # Supporting materials
-        └── security.md
-```
-
-However, prefer keeping everything in `AGENT.md` when possible—agent definitions should be concise.
-
-## Agent Document Structure
-
-A well-structured `AGENT.md` follows this pattern:
-
-```markdown
-# Agent Name
-
-Brief description of what this agent does.
-
-## Skills
-List of skills this agent has access to.
-
-## Capabilities
-What the agent can do—its areas of competence.
-
-## When to Use
-Guidance on when to spawn this agent.
-
-## Behavior
-How the agent should operate—rules and constraints.
-```
-
-All sections are important:
-- **Skills**: Defines what knowledge the agent has
-- **Capabilities**: Tells spawners what to expect
-- **When to Use**: Prevents misuse and guides selection
-- **Behavior**: Sets expectations for operation
-
-## YAML Frontmatter
-
-Agent files support YAML frontmatter for configuration. While the body content defines the agent's personality and instructions, frontmatter controls its technical behavior.
-
-### Required Fields
-
-| Field | Description |
-|-------|-------------|
-| `name` | Agent identifier (lowercase, hyphens). Should match directory name. |
-| `description` | What the agent does. Used for matching when spawning agents. |
-
-### Optional Fields
-
-| Field | Description |
-|-------|-------------|
-| `model` | Model to use: `haiku`, `sonnet`, `opus`, or `inherit` (default). |
-| `skills` | Comma-separated list of skills the agent can access. |
-| `disallowedTools` | Explicitly block specific tools from this agent. |
-| `permissionMode` | Permission behavior: `default`, `bypassPermissions`, or custom. |
-| `hooks` | Define PreToolUse, PostToolUse, or Stop hooks scoped to this agent. |
-
-### Example Frontmatter
-
-**Basic agent:**
-```yaml
----
-name: code-reviewer
-description: Review code for quality, bugs, and style issues.
-model: sonnet
-skills: gitea, code-review
----
-```
-
-**Agent with tool restrictions:**
-```yaml
----
-name: read-only-analyst
-description: Analyze code without making changes.
-model: haiku
-skills: code-review
-disallowedTools:
-  - Edit
-  - Write
-  - Bash
----
-```
-
-**Agent with hooks:**
-```yaml
----
-name: database-admin
-description: Manage database operations safely.
-model: opus
-hooks:
-  - type: PreToolUse
-    matcher: Bash
-    command: echo "Validating database command..."
-  - type: Stop
-    command: echo "Database operation completed"
----
-```
-
-### Permission Modes
-
-The `permissionMode` field controls how the agent handles tool permissions:
-
-| Mode | Behavior |
-|------|----------|
-| `default` | Inherits parent's permission settings (standard behavior) |
-| `bypassPermissions` | Skip permission prompts (use for trusted, well-tested agents) |
-
-Use `bypassPermissions` sparingly—only for agents that are thoroughly tested and operate within safe boundaries.
-
-## Built-in Agents
-
-Claude Code provides built-in agents that you can leverage instead of creating custom ones:
-
-| Agent | Purpose | When to Use |
-|-------|---------|-------------|
-| **Explore** | Codebase exploration and search | Finding files, understanding structure, searching code. Powered by Haiku for efficiency. |
-| **Plan** | Implementation planning | Designing approaches, breaking down tasks, architectural decisions. |
-
-Consider using built-in agents before creating custom ones—they're optimized for common tasks.
-
-## How Agents Combine Skills
-
-Agents gain their expertise by combining multiple skills. Each skill contributes domain knowledge to the agent's overall capability.
-
-### Skill Composition
-
-```
-┌────────────────────────────────────────────────┐
-│           Product Manager Agent                │
-│                                                │
-│  ┌──────────┐  ┌──────────────┐                │
-│  │ gitea  │  │issue-writing │                │
-│  │          │  │              │                │
-│  │ CLI      │  │ Structure    │                │
-│  │ commands │  │ patterns     │                │
-│  └──────────┘  └──────────────┘                │
-│                                                │
-│  ┌──────────────────┐  ┌─────────────────┐     │
-│  │backlog-grooming  │  │roadmap-planning │     │
-│  │                  │  │                 │     │
-│  │ Review           │  │ Feature         │     │
-│  │ checklists       │  │ breakdown       │     │
-│  └──────────────────┘  └─────────────────┘     │
-│                                                │
-└────────────────────────────────────────────────┘
-```
-
-The agent can:
-- Use **gitea** to interact with issues and PRs
-- Apply **issue-writing** patterns when creating content
-- Follow **backlog-grooming** checklists when reviewing
-- Use **roadmap-planning** strategies when breaking down features
-
-### Emergent Capabilities
-
-When skills combine, new capabilities emerge:
-
-| Skills Combined | Emergent Capability |
-|-----------------|---------------------|
-| gitea + issue-writing | Create well-structured issues programmatically |
-| backlog-grooming + issue-writing | Improve existing issues systematically |
-| roadmap-planning + gitea | Plan and create linked issue hierarchies |
-| All four skills | Full backlog management lifecycle |
-
-## Use Cases for Agents
-
-### 1. Parallel Processing
-
-Agents work independently with their own context. Spawn multiple agents to work on separate tasks simultaneously.
-
-```
-Command: /groom (batch mode)
-         │
-         ├─── Spawn Agent: Review issues #1-5
-         │
-         ├─── Spawn Agent: Review issues #6-10
-         │
-         └─── Spawn Agent: Review issues #11-15
-
-         ↓ (agents work in parallel)
-
-Results aggregated by command
-```
-
-**Use when:**
-- Tasks are independent and don't need to share state
-- Workload can be divided into discrete chunks
-- Speed matters more than sequential consistency
-
-### 2. Context Isolation
-
-Each agent maintains separate conversation state. This prevents context pollution when handling complex, unrelated subtasks.
-
-```
-Main Context                    Agent Context
-┌─────────────────┐            ┌─────────────────┐
-│ User working on │            │ Isolated work   │
-│ feature X       │   spawn    │ on backlog      │
-│                 │ ─────────► │ review          │
-│ (preserves      │            │                 │
-│  feature X      │   return   │ (doesn't know   │
-│  context)       │ ◄───────── │  about X)       │
-└─────────────────┘            └─────────────────┘
-```
-
-**Use when:**
-- Subtask requires deep exploration that would pollute main context
-- Work involves many files or concepts unrelated to main task
-- You want clean separation between different concerns
-
-### 3. Complex Workflows
-
-Some workflows are better handled by a specialized agent than by inline execution. Agents can make decisions, iterate, and adapt.
-
-```
-Command: /plan-issues "add user authentication"
-         │
-         └─── Spawn product-manager agent
-                   │
-                   ├── Explore codebase to understand structure
-                   ├── Research authentication patterns
-                   ├── Design issue breakdown
-                   ├── Create issues in dependency order
-                   └── Return summary to command
-```
-
-**Use when:**
-- Task requires iterative decision-making
-- Workflow has many steps that depend on intermediate results
-- Specialist expertise (via combined skills) adds value
-
-### 4. Autonomous Exploration
-
-Agents can explore codebases independently, building understanding without polluting the main conversation.
-
-**Use when:**
-- You need to understand a new part of the codebase
-- Exploration might involve many file reads and searches
-- Results should be summarized, not shown in full
-
-### 5. Background Execution
-
-Agents can run in the background while you continue working. Background agents execute asynchronously and notify the main thread when complete.
-
-```
-User working                    Background Agent
-┌─────────────────┐            ┌─────────────────┐
-│ Continue coding │            │ Running tests   │
-│ on feature      │            │ in background   │
-│                 │            │                 │
-│ (not blocked)   │   notify   │ (async work)    │
-│                 │ ◄───────── │                 │
-└─────────────────┘            └─────────────────┘
-```
-
-**Use when:**
-- Task is long-running (test suites, large codebase analysis)
-- You want to continue working while the agent operates
-- Results are needed later, not immediately
-
-Background agents can send messages to wake up the main agent when they have results or need attention.
-
-## When to Use an Agent vs Direct Skill Invocation
-
-### Use Direct Skill Invocation When:
-
-- **Simple, single-skill task**: Writing one issue doesn't need an agent
-- **Main context is relevant**: The current conversation context helps
-- **Quick reference needed**: Just need to check a pattern or command
-- **Sequential workflow**: Command can orchestrate step-by-step
-
-Example: Creating a single issue with `/create-issue`
-```
-Command reads issue-writing skill directly
-         │
-         └── Creates one issue following patterns
-```
-
-### Use an Agent When:
-
-- **Multiple skills needed together**: Complex tasks benefit from composition
-- **Context isolation required**: Don't want to pollute main conversation
-- **Parallel execution possible**: Can divide and conquer
-- **Autonomous exploration needed**: Agent can figure things out independently
-- **Specialist persona helps**: "Product manager" framing improves outputs
-
-Example: Grooming entire backlog with `/groom`
-```
-Command spawns product-manager agent
-         │
-         └── Agent iterates through all issues
-             using multiple skills
-```
-
-### Decision Matrix
-
-| Scenario | Agent? | Reason |
-|----------|--------|--------|
-| Create one issue | No | Single skill, simple task |
-| Review 20 issues | Yes | Batch processing, isolation |
-| Quick CLI lookup | No | Just need gitea reference |
-| Plan new feature | Yes | Multiple skills, exploration |
-| Fix issue title | No | Trivial edit |
-| Reorganize backlog | Yes | Complex, multi-skill workflow |
-
-## Annotated Example: Product Manager Agent
-
-Let's examine the `product-manager` agent in detail:
-
-```markdown
-# Product Manager Agent
-
-Specialized agent for backlog management and roadmap planning.
-```
-
-**The opening** identifies the agent's role clearly. "Product Manager" is a recognizable persona that sets expectations.
-
-```markdown
-## Skills
-
-- gitea
-- issue-writing
-- backlog-grooming
-- roadmap-planning
-```
-
-**Skills section** lists all knowledge the agent has access to. These skills are loaded into the agent's context when spawned. The combination enables:
-- Reading/writing issues (gitea)
-- Creating quality content (issue-writing)
-- Evaluating existing issues (backlog-grooming)
-- Planning work strategically (roadmap-planning)
-
-```markdown
-## Capabilities
-
-This agent can:
-- Review and improve existing issues
-- Create new well-structured issues
-- Analyze the backlog for gaps and priorities
-- Plan feature breakdowns
-- Maintain roadmap clarity
-```
-
-**Capabilities section** tells spawners what to expect. Each capability maps to skill combinations:
-- "Review and improve" = backlog-grooming + issue-writing
-- "Create new issues" = gitea + issue-writing
-- "Analyze backlog" = backlog-grooming + roadmap-planning
-- "Plan breakdowns" = roadmap-planning + issue-writing
-
-```markdown
-## When to Use
-
-Spawn this agent for:
-- Batch operations on multiple issues
-- Comprehensive backlog reviews
-- Feature planning that requires codebase exploration
-- Complex issue creation with dependencies
-```
-
-**When to Use section** guides appropriate usage. Note the criteria:
-- "Batch operations" → Parallel/isolation benefit
-- "Comprehensive reviews" → Complex workflow benefit
-- "Requires exploration" → Context isolation benefit
-- "Complex with dependencies" → Multi-skill benefit
-
-```markdown
-## Behavior
-
-- Always fetches current issue state before making changes
-- Asks for approval before creating or modifying issues
-- Provides clear summaries of actions taken
-- Uses the tea CLI for all Forgejo operations
-```
-
-**Behavior section** sets operational rules. These ensure:
-- Accuracy: Fetches current state, doesn't assume
-- Safety: Asks before acting
-- Transparency: Summarizes what happened
-- Consistency: Uses standard tooling
-
-## Naming Conventions
-
-### Agent Folder Names
-
-- Use **kebab-case**: `product-manager`, `code-reviewer`
-- Name by **role or persona**: what the agent "is"
-- Keep **recognizable**: familiar roles are easier to understand
-
-Good names:
-- `product-manager` - Recognizable role
-- `code-reviewer` - Clear function
-- `security-auditor` - Specific expertise
-- `documentation-writer` - Focused purpose
-
-Avoid:
-- `helper` - Too vague
-- `do-stuff` - Not a role
-- `issue-thing` - Not recognizable
-
-### Agent Titles
-
-The H1 title in `AGENT.md` should be the role name in Title Case:
-
-| Folder | Title |
-|--------|-------|
-| `product-manager` | Product Manager Agent |
-| `code-reviewer` | Code Reviewer Agent |
-| `security-auditor` | Security Auditor Agent |
-
-## Model Selection
-
-Agents can specify which Claude model to use via the `model` field in YAML frontmatter. Choosing the right model balances capability, speed, and cost.
-
-### Available Models
-
-| Model | Characteristics | Best For |
-|-------|-----------------|----------|
-| `haiku` | Fastest, most cost-effective | Simple structured tasks, formatting, basic transformations |
-| `sonnet` | Balanced speed and capability | Most agent tasks, code review, issue management |
-| `opus` | Most capable, best reasoning | Complex analysis, architectural decisions, nuanced judgment |
-| `inherit` | Uses parent context's model | When agent should match caller's capability level |
-
-### Decision Matrix
-
-| Agent Task Type | Recommended Model | Reasoning |
-|-----------------|-------------------|-----------|
-| Structured output formatting | `haiku` | Pattern-following, no complex reasoning |
-| Code review (style/conventions) | `sonnet` | Needs code understanding, not deep analysis |
-| Security vulnerability analysis | `opus` | Requires nuanced judgment, high stakes |
-| Issue triage and labeling | `haiku` or `sonnet` | Mostly classification tasks |
-| Feature planning and breakdown | `sonnet` or `opus` | Needs strategic thinking |
-| Batch processing (many items) | `haiku` or `sonnet` | Speed and cost matter at scale |
-| Architectural exploration | `opus` | Complex reasoning about tradeoffs |
-
-### Examples
-
-These examples show recommended model configurations for different agent types:
-
-**Code Reviewer Agent** - Use `sonnet`:
-```yaml
----
-name: code-reviewer
-model: sonnet
-skills: gitea, code-review
----
-```
-Code review requires understanding code patterns and conventions but rarely needs the deepest reasoning. Sonnet provides good balance.
-
-**Security Auditor Agent** (hypothetical) - Use `opus`:
-```yaml
----
-name: security-auditor
-model: opus
-skills: code-review  # would add security-specific skills
----
-```
-Security analysis requires careful, nuanced judgment where missing issues have real consequences. Worth the extra capability.
-
-**Formatting Agent** (hypothetical) - Use `haiku`:
-```yaml
----
-name: markdown-formatter
-model: haiku
-skills: documentation
----
-```
-Pure formatting tasks follow patterns and don't require complex reasoning. Haiku is fast and sufficient.
-
-### Best Practices for Model Selection
-
-1. **Start with `sonnet`** - It handles most agent tasks well
-2. **Use `haiku` for volume** - When processing many items, speed and cost add up
-3. **Reserve `opus` for judgment** - Use when errors are costly or reasoning is complex
-4. **Avoid `inherit` by default** - Make a deliberate choice; `inherit` obscures the decision
-5. **Consider the stakes** - Higher consequence tasks warrant more capable models
-6. **Test with real tasks** - Verify the chosen model performs adequately
-
-### When to Use `inherit`
-
-The `inherit` option has legitimate uses:
-
-- **Utility agents**: Small helpers that should match their caller's capability
-- **Delegation chains**: When an agent spawns sub-agents that should stay consistent
-- **Testing/development**: When you want to control model from the top level
-
-However, most production agents should specify an explicit model.
-
-## Best Practices
-
-### 1. Choose Skills Deliberately
-
-Include only skills the agent needs. More skills = more context = potential confusion.
-
-**Too many skills:**
-```markdown
-## Skills
-- gitea
-- issue-writing
-- backlog-grooming
-- roadmap-planning
-- code-review
-- testing
-- documentation
-- deployment
-```
-
-**Right-sized:**
-```markdown
-## Skills
-- gitea
-- issue-writing
-- backlog-grooming
-- roadmap-planning
-```
-
-### 2. Define Clear Boundaries
-
-Agents should know what they can and cannot do.
-
-**Vague:**
-```markdown
-## Capabilities
-This agent can help with project management.
-```
-
-**Clear:**
-```markdown
-## Capabilities
-This agent can:
-- Review and improve existing issues
-- Create new well-structured issues
-- Analyze the backlog for gaps
-
-This agent cannot:
-- Merge pull requests
-- Deploy code
-- Make architectural decisions
-```
-
-### 3. Set Behavioral Guardrails
-
-Prevent agents from causing problems by setting explicit rules.
-
-**Important behaviors to specify:**
-- When to ask for approval
-- What to do before making changes
-- How to report results
-- Error handling expectations
-
-### 4. Match Persona to Purpose
-
-The agent's name and description should align with its skills and capabilities.
-
-**Mismatched:**
-```markdown
-# Security Agent
-
-## Skills
-- issue-writing
-- documentation
-```
-
-**Aligned:**
-```markdown
-# Security Auditor Agent
-
-## Skills
-- security-scanning
-- vulnerability-assessment
-- code-review
-```
-
-### 5. Keep Agents Focused
-
-One agent = one role. If an agent does too many unrelated things, split it.
-
-**Too broad:**
-```markdown
-# Everything Agent
-Handles issues, code review, deployment, and customer support.
-```
-
-**Focused:**
-```markdown
-# Product Manager Agent
-Specialized for backlog management and roadmap planning.
-```
-
-## When to Create a New Agent
-
-Create an agent when you need:
-
-1. **Role-based expertise**: A recognizable persona improves outputs
-2. **Skill composition**: Multiple skills work better together
-3. **Context isolation**: Work shouldn't pollute main conversation
-4. **Parallel capability**: Tasks can run independently
-5. **Autonomous operation**: Agent should figure things out on its own
-
-### Signs You Need a New Agent
-
-- Commands repeatedly spawn similar skill combinations
-- Tasks require deep exploration that pollutes context
-- Work benefits from a specialist "persona"
-- Batch processing would help
-
-### Signs You Don't Need a New Agent
-
-- Single skill is sufficient
-- Task is simple and sequential
-- Main context is helpful, not harmful
-- No clear persona or role emerges
-
-## Agent Lifecycle
-
-### 1. Design
-
-Define the agent's role:
-- What persona makes sense?
-- Which skills does it need?
-- What can it do (and not do)?
-- When should it be spawned?
-
-### 2. Implement
-
-Create the agent file:
-- Clear name and description
-- Appropriate skill list
-- Specific capabilities
-- Usage guidance
-- Behavioral rules
-
-### 3. Integrate
-
-Connect the agent to workflows:
-- Update commands that should spawn it
-- Document in ARCHITECTURE.md
-- Test with real tasks
-
-### 4. Refine
-
-Improve based on usage:
-- Add/remove skills as needed
-- Clarify capabilities
-- Strengthen behavioral rules
-- Update documentation
-
-## Checklist: Before Submitting a New Agent
-
-### Structure
-- [ ] File is at `agents/<name>/AGENT.md`
-- [ ] Name follows kebab-case convention
-- [ ] Agent has a clear, recognizable role
-
-### Frontmatter
-- [ ] `name` and `description` fields are set
-- [ ] `model` selection is deliberate (not just `inherit` by default)
-- [ ] `skills` list is deliberate (not too many, not too few)
-- [ ] Consider `disallowedTools` if agent should be restricted
-- [ ] Consider `permissionMode` for trusted agents
-- [ ] Consider `hooks` for validation or logging
-
-### Content
-- [ ] Capabilities are specific and achievable
-- [ ] "When to Use" guidance is clear
-- [ ] Behavioral rules prevent problems
-
-### Integration
-- [ ] Consider if built-in agents (Explore, Plan) could be used instead
-- [ ] Agent is referenced by at least one command
-- [ ] ARCHITECTURE.md is updated
-
-## See Also
-
-- [ARCHITECTURE.md](../ARCHITECTURE.md): How agents fit into the overall system
-- [writing-skills.md](writing-skills.md): Creating the skills that agents use
-- [VISION.md](../VISION.md): The philosophy behind composable components

docs/writing-capabilities.md

@@ -0,0 +1,508 @@
+# Writing Capabilities
+
+A comprehensive guide to creating capabilities for the Claude Code AI workflow system.
+
+> **Official Documentation**: For the most up-to-date Claude Code documentation, see https://code.claude.com/docs
+
+## Component Types
+
+The architecture repository uses two component types:
+
+| Component | Location | Purpose | Invocation |
+|-----------|----------|---------|------------|
+| **Skill** | `skills/<name>/SKILL.md` | Knowledge modules and workflows | Auto-triggered or `/skill-name` |
+| **Agent** | `agents/<name>/AGENT.md` | Isolated subtask handlers | Spawned via Task tool |
+
+### Skills: Two Types
+
+Skills come in two flavors based on the `user-invocable` frontmatter field:
+
+| Type | `user-invocable` | Purpose | Example |
+|------|------------------|---------|---------|
+| **User-invocable** | `true` | Workflows users trigger with `/skill-name` | `/work-issue`, `/dashboard` |
+| **Background** | `false` | Reference knowledge auto-loaded when needed | `gitea`, `issue-writing` |
+
+User-invocable skills replaced the former "commands" - they define workflows that users trigger directly.
+
+### Agents: Isolated Workers
+
+Agents are specialized subprocesses that:
+- Combine multiple skills into focused personas
+- Run with isolated context (don't pollute main conversation)
+- Handle complex subtasks autonomously
+- Can run in parallel or background
+
+---
+
+## Writing Skills
+
+Skills are markdown files in the `skills/` directory, each in its own folder.
+
+### File Structure
+
+```
+skills/
+├── gitea/                    # Background skill
+│   └── SKILL.md
+├── work-issue/               # User-invocable skill
+│   └── SKILL.md
+└── issue-writing/            # Background skill
+    └── SKILL.md
+```
+
+### YAML Frontmatter
+
+Every skill requires YAML frontmatter starting on line 1:
+
+```yaml
+---
+name: skill-name
+description: >
+  What this skill does and when to use it.
+  Include trigger terms for auto-detection.
+model: haiku
+user-invocable: true
+argument-hint: <required-arg> [optional-arg]
+---
+```
+
+#### Required Fields
+
+| Field | Description |
+|-------|-------------|
+| `name` | Lowercase, hyphens only (max 64 chars). Must match directory name. |
+| `description` | What the skill does + when to use (max 1024 chars). Critical for triggering. |
+
+#### Optional Fields
+
+| Field | Description |
+|-------|-------------|
+| `user-invocable` | Whether skill appears in `/` menu. Default: `true` |
+| `model` | Model to use: `haiku`, `sonnet`, `opus` |
+| `argument-hint` | For user-invocable: `<required>`, `[optional]` |
+| `context` | Use `fork` for isolated context |
+| `allowed-tools` | Restrict available tools (YAML list) |
+| `hooks` | Define PreToolUse, PostToolUse, or Stop hooks |
+
+### User-Invocable Skills (Workflows)
+
+These replace the former "commands" - workflows users invoke with `/skill-name`.
+
+**Example: `/work-issue`**
+
+```yaml
+---
+name: work-issue
+description: >
+  Work on a Gitea issue. Fetches issue details and sets up branch.
+  Use when working on issues, implementing features, or when user says /work-issue.
+model: haiku
+argument-hint: <issue-number>
+user-invocable: true
+---
+
+# Work on Issue #$1
+
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/software-architecture/SKILL.md
+
+1. **View the issue** with `--comments` flag
+2. **Create a branch**: `git checkout -b issue-$1-<short-title>`
+3. **Plan**: Use TodoWrite to break down work
+4. **Implement** following architectural patterns
+5. **Commit** with message referencing the issue
+6. **Push** and **Create PR**
+```
+
+**Key patterns for user-invocable skills:**
+
+1. **Argument handling**: Use `$1`, `$2` for positional arguments
+2. **Skill references**: Use `@~/.claude/skills/name/SKILL.md` to include background skills
+3. **Approval workflows**: Ask before significant actions
+4. **Clear steps**: Numbered, actionable workflow steps
+
+### Background Skills (Reference)
+
+Knowledge modules that Claude applies automatically when context matches.
+
+**Example: `gitea`**
+
+```yaml
+---
+name: gitea
+description: >
+  View, create, and manage Gitea issues and pull requests using tea CLI.
+  Use when working with issues, PRs, or when user mentions tea, gitea.
+model: haiku
+user-invocable: false
+---
+
+# Gitea CLI (tea)
+
+## Common Commands
+
+### Issues
+```bash
+tea issues                    # List open issues
+tea issues <number>           # View issue details
+tea issues create --title "..." --description "..."
+```
+...
+```
+
+**Key patterns for background skills:**
+
+1. **Rich descriptions**: Include trigger terms like tool names, actions
+2. **Reference material**: Commands, templates, patterns, checklists
+3. **No workflow steps**: Just knowledge, not actions
+
+### Writing Effective Descriptions
+
+The `description` field determines when Claude applies the skill. Include:
+
+1. **What the skill does**: Specific capabilities
+2. **When to use it**: Trigger terms users would mention
+
+**Bad:**
+```yaml
+description: Helps with documents
+```
+
+**Good:**
+```yaml
+description: >
+  View, create, and manage Gitea issues and pull requests using tea CLI.
+  Use when working with issues, PRs, viewing issue details, creating pull
+  requests, or when the user mentions tea, gitea, or issue numbers.
+```
+
+### Argument Handling (User-Invocable Skills)
+
+User-invocable skills can accept arguments via `$1`, `$2`, etc.
+
+**Argument hints:**
+- `<arg>` - Required argument
+- `[arg]` - Optional argument
+- `<arg1> [arg2]` - Mix of both
+
+**Example with optional argument:**
+```yaml
+---
+name: groom
+argument-hint: [issue-number]
+---
+
+# Groom Issues
+
+## If issue number provided ($1):
+1. Fetch that specific issue
+2. Evaluate against checklist
+...
+
+## If no argument:
+1. List all open issues
+2. Review each against checklist
+...
+```
+
+### Skill References
+
+User-invocable skills include background skills using file references:
+
+```markdown
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/issue-writing/SKILL.md
+```
+
+**Important**: Do NOT use phrases like "Use the gitea skill" - skills have ~20% auto-activation rate. File references guarantee the content is loaded.
+
+### Approval Workflows
+
+User-invocable skills should ask for approval before significant actions:
+
+```markdown
+4. **Present plan** for approval
+5. **If approved**, create the issues
+6. **Present summary** with links
+```
+
+---
+
+## Writing Agents
+
+Agents are specialized subprocesses that combine skills for complex, isolated tasks.
+
+### File Structure
+
+```
+agents/
+└── code-reviewer/
+    └── AGENT.md
+```
+
+### YAML Frontmatter
+
+```yaml
+---
+name: code-reviewer
+description: Review code for quality, bugs, and style issues
+model: sonnet
+skills: gitea, code-review
+disallowedTools:
+  - Edit
+  - Write
+---
+```
+
+#### Required Fields
+
+| Field | Description |
+|-------|-------------|
+| `name` | Agent identifier (lowercase, hyphens). Match directory name. |
+| `description` | What the agent does. Used for matching when spawning. |
+
+#### Optional Fields
+
+| Field | Description |
+|-------|-------------|
+| `model` | `haiku`, `sonnet`, `opus`, or `inherit` |
+| `skills` | Comma-separated skill names the agent can access |
+| `disallowedTools` | Block specific tools (e.g., Edit, Write for read-only) |
+| `permissionMode` | `default` or `bypassPermissions` |
+| `hooks` | Define PreToolUse, PostToolUse, or Stop hooks |
+
+### Agent Document Structure
+
+```markdown
+# Agent Name
+
+Brief description of the agent's role.
+
+## Skills
+- skill1
+- skill2
+
+## Capabilities
+What the agent can do.
+
+## When to Use
+Guidance on when to spawn this agent.
+
+## Behavior
+Operational rules and constraints.
+```
+
+### Built-in Agents
+
+Claude Code provides built-in agents - prefer these before creating custom ones:
+
+| Agent | Purpose |
+|-------|---------|
+| **Explore** | Codebase exploration, finding files, searching code |
+| **Plan** | Implementation planning, architectural decisions |
+
+### Skill Composition
+
+Agents gain expertise by combining skills:
+
+```
+┌─────────────────────────────────────────┐
+│         Code Reviewer Agent             │
+│                                         │
+│  ┌─────────┐  ┌─────────────┐           │
+│  │ gitea   │  │ code-review │           │
+│  │ CLI     │  │ patterns    │           │
+│  └─────────┘  └─────────────┘           │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+### Use Cases for Agents
+
+1. **Parallel processing**: Spawn multiple agents for independent tasks
+2. **Context isolation**: Deep exploration without polluting main context
+3. **Complex workflows**: Iterative decision-making with multiple skills
+4. **Background execution**: Long-running tasks while user continues working
+
+### Model Selection
+
+| Model | Best For |
+|-------|----------|
+| `haiku` | Simple tasks, formatting, batch processing |
+| `sonnet` | Most agent tasks, code review (default choice) |
+| `opus` | Complex analysis, security audits, architectural decisions |
+
+---
+
+## Decision Guide
+
+### When to Create a User-Invocable Skill
+
+Create when you have:
+- Repeatable workflow used multiple times
+- User explicitly triggers the action
+- Clear start and end points
+- Approval checkpoints needed
+
+### When to Create a Background Skill
+
+Create when:
+- You explain the same concepts repeatedly
+- Multiple user-invocable skills need the same knowledge
+- Quality is inconsistent without explicit guidance
+- There's a clear domain that doesn't fit existing skills
+
+### When to Create an Agent
+
+Create when:
+- Multiple skills needed together for complex tasks
+- Context isolation required
+- Parallel execution possible
+- Autonomous exploration needed
+- Specialist persona improves outputs
+
+### Decision Matrix
+
+| Scenario | Component | Reason |
+|----------|-----------|--------|
+| User types `/work-issue 42` | User-invocable skill | Explicit user trigger |
+| Need tea CLI reference | Background skill | Auto-loaded knowledge |
+| Review 20 issues in parallel | Agent | Batch processing, isolation |
+| Create one issue | User-invocable skill | Single workflow |
+| Deep architectural analysis | Agent | Complex, isolated work |
+
+---
+
+## Templates
+
+### User-Invocable Skill Template
+
+```yaml
+---
+name: skill-name
+description: >
+  What this skill does and when to use it.
+  Use when [trigger conditions] or when user says /skill-name.
+model: haiku
+argument-hint: <required> [optional]
+user-invocable: true
+---
+
+# Skill Title
+
+@~/.claude/skills/relevant-skill/SKILL.md
+
+Brief intro if needed.
+
+1. **First step**: What to do
+2. **Second step**: What to do next
+3. **Ask for approval** before significant actions
+4. **Execute** the approved actions
+5. **Present results** with links and summary
+```
+
+### Background Skill Template
+
+```yaml
+---
+name: skill-name
+description: >
+  What this skill teaches and when to use it.
+  Include trigger conditions in description.
+user-invocable: false
+---
+
+# Skill Name
+
+Brief description of what this skill covers.
+
+## Core Concepts
+
+Explain fundamental ideas.
+
+## Patterns and Templates
+
+Provide reusable structures.
+
+## Guidelines
+
+List rules and best practices.
+
+## Examples
+
+Show concrete illustrations.
+
+## Common Mistakes
+
+Document pitfalls to avoid.
+```
+
+### Agent Template
+
+```yaml
+---
+name: agent-name
+description: What this agent does and when to spawn it
+model: sonnet
+skills: skill1, skill2
+---
+
+You are a [role] specialist that [primary function].
+
+## When Invoked
+
+1. **Gather context**: What to collect
+2. **Analyze**: What to evaluate
+3. **Act**: What actions to take
+4. **Report**: How to communicate results
+
+## Output Format
+
+Describe expected output structure.
+
+## Guidelines
+
+- Behavioral rules
+- Constraints
+- Quality standards
+```
+
+---
+
+## Checklists
+
+### Before Creating a User-Invocable Skill
+
+- [ ] Workflow is repeatable (used multiple times)
+- [ ] User explicitly triggers it
+- [ ] File at `skills/<name>/SKILL.md`
+- [ ] `user-invocable: true` in frontmatter
+- [ ] `description` includes "Use when... or when user says /skill-name"
+- [ ] Background skills referenced via `@~/.claude/skills/<name>/SKILL.md`
+- [ ] Approval checkpoints before significant actions
+- [ ] Clear numbered workflow steps
+
+### Before Creating a Background Skill
+
+- [ ] Knowledge used in multiple places
+- [ ] Doesn't fit existing skills
+- [ ] File at `skills/<name>/SKILL.md`
+- [ ] `user-invocable: false` in frontmatter
+- [ ] `description` includes trigger terms
+- [ ] Content is specific and actionable
+
+### Before Creating an Agent
+
+- [ ] Built-in agents (Explore, Plan) aren't sufficient
+- [ ] Context isolation or skill composition needed
+- [ ] File at `agents/<name>/AGENT.md`
+- [ ] `model` selection is deliberate
+- [ ] `skills` list is right-sized
+- [ ] Clear role/persona emerges
+
+---
+
+## See Also
+
+- [ARCHITECTURE.md](../ARCHITECTURE.md): How components fit together
+- [skills/capability-writing/SKILL.md](../skills/capability-writing/SKILL.md): Quick reference

docs/writing-commands.md

@@ -1,731 +0,0 @@
-# Writing Commands
-
-A guide to creating user-facing entry points that trigger workflows.
-
-## What is a Command?
-
-Commands are **user-facing entry points** that trigger workflows. Unlike skills (which encode knowledge) or agents (which execute tasks autonomously), commands define *what* to do—they orchestrate the workflow that users invoke directly.
-
-Think of commands as the interface between users and the system. Users type `/work-issue 42` and the command defines the entire workflow: fetch issue, create branch, implement, commit, push, create PR.
-
-## File Structure
-
-Commands live directly in the `commands/` directory as markdown files:
-
-```
-commands/
-├── work-issue.md
-├── dashboard.md
-├── review-pr.md
-├── create-issue.md
-├── groom.md
-├── roadmap.md
-└── plan-issues.md
-```
-
-### Why Flat Files?
-
-Unlike skills and agents (which use folders), commands are single files because:
-- Commands are self-contained workflow definitions
-- No supporting files needed
-- Simple naming: `/work-issue` maps to `work-issue.md`
-
-## Command Document Structure
-
-A well-structured command file has two parts:
-
-### 1. Frontmatter (YAML Header)
-
-```yaml
----
-description: Brief description shown in command listings
-argument-hint: <required-arg> [optional-arg]
----
-```
-
-#### Required Fields
-
-| Field | Purpose |
-|-------|---------|
-| `description` | One-line summary for help/listings |
-
-#### Optional Fields
-
-| Field | Purpose |
-|-------|---------|
-| `argument-hint` | Shows expected arguments (e.g., `<issue-number>`, `[title]`) |
-| `model` | Model to use: `haiku`, `sonnet`, `opus`. Overrides session default. |
-| `context` | Execution context. Use `fork` to run in isolated sub-agent context. |
-| `hooks` | Define PreToolUse, PostToolUse, or Stop hooks scoped to this command. |
-| `allowed-tools` | Restrict which tools the command can use. |
-
-### 2. Body (Markdown Instructions)
-
-```markdown
-# Command Title
-
-Brief intro if needed.
-
-1. **Step one**: What to do
-2. **Step two**: What to do next
-...
-```
-
-The body contains the workflow steps that Claude follows when the command is invoked.
-
-## Complete Command Example
-
-```markdown
----
-description: Work on a Gitea issue. Fetches issue details and sets up branch.
-argument-hint: <issue-number>
----
-
-# Work on Issue #$1
-
-@~/.claude/skills/gitea/SKILL.md
-
-1. **View the issue** to understand requirements
-2. **Create a branch**: `git checkout -b issue-$1-<short-kebab-title>`
-3. **Plan**: Use TodoWrite to break down the work
-4. **Implement** the changes
-5. **Commit** with message referencing the issue
-6. **Push** the branch to origin
-7. **Create PR** with title "[Issue #$1] <title>" and body "Closes #$1"
-```
-
-## Advanced Frontmatter Examples
-
-**Command with specific model:**
-```yaml
----
-description: Plan complex feature implementation.
-argument-hint: <feature-description>
-model: opus
----
-```
-
-**Command with isolated context (prevents context pollution):**
-```yaml
----
-description: Analyze codebase architecture deeply.
-context: fork
-model: haiku
----
-```
-
-**Command with hooks:**
-```yaml
----
-description: Deploy to production environment.
-hooks:
-  - type: PreToolUse
-    matcher: Bash
-    command: echo "Validating deployment command..."
-  - type: Stop
-    command: ./scripts/notify-deployment.sh
----
-```
-
-**Read-only command with tool restrictions:**
-```yaml
----
-description: Generate codebase report without modifications.
-allowed-tools:
-  - Read
-  - Glob
-  - Grep
----
-```
-
-## Argument Handling
-
-Commands can accept arguments from the user. Arguments are passed via positional variables: `$1`, `$2`, etc.
-
-### The ARGUMENTS Pattern
-
-When users invoke a command with arguments:
-```
-/work-issue 42
-```
-
-The system provides the arguments via the `$1`, `$2`, etc. placeholders in the command body:
-```markdown
-# Work on Issue #$1
-1. **View the issue** to understand requirements
-```
-
-Becomes:
-```markdown
-# Work on Issue #42
-1. **View the issue** to understand requirements
-```
-
-### Argument Hints
-
-Use `argument-hint` in frontmatter to document expected arguments:
-
-| Pattern | Meaning |
-|---------|---------|
-| `<arg>` | Required argument |
-| `[arg]` | Optional argument |
-| `<arg1> <arg2>` | Multiple required |
-| `[arg1] [arg2]` | Multiple optional |
-| `<required> [optional]` | Mix of both |
-
-Examples:
-```yaml
-argument-hint: <issue-number>           # One required
-argument-hint: [issue-number]           # One optional
-argument-hint: <title> [description]    # Required + optional
-argument-hint: [title] or "batch"       # Choice of modes
-```
-
-### Handling Optional Arguments
-
-Commands often have different behavior based on whether arguments are provided:
-
-```markdown
----
-description: Groom issues. Without argument, reviews all. With argument, grooms specific issue.
-argument-hint: [issue-number]
----
-
-# Groom Issues
-
-@~/.claude/skills/gitea/SKILL.md
-
-## If issue number provided ($1):
-1. **Fetch the issue** details
-2. **Evaluate** against checklist
-...
-
-## If no argument (groom all):
-1. **List open issues**
-2. **Review each** against checklist
-...
-```
-
-### Multiple Modes
-
-Some commands support distinct modes based on the first argument:
-
-```markdown
----
-description: Create issues. Single or batch mode.
-argument-hint: [title] or "batch"
----
-
-# Create Issue(s)
-
-@~/.claude/skills/gitea/SKILL.md
-
-## Single Issue (default)
-If title provided, create an issue with that title.
-
-## Batch Mode
-If $1 is "batch":
-1. Ask user for the plan
-2. Generate list of issues
-3. Show for approval
-4. Create each issue
-```
-
-## Including Skills
-
-Commands include skills using the `@` file reference syntax. This automatically injects the skill content into the command context when the command is invoked.
-
-### File Reference Syntax
-
-Use the `@` prefix followed by the path to the skill file:
-
-```markdown
-# Groom Issues
-
-@~/.claude/skills/gitea/SKILL.md
-@~/.claude/skills/backlog-grooming/SKILL.md
-@~/.claude/skills/issue-writing/SKILL.md
-
-1. **Fetch the issue** details
-2. **Evaluate** against grooming checklist
-...
-```
-
-When the command runs, the content of each referenced skill file is automatically loaded into context.
-
-### Why File References?
-
-**DO NOT** use phrases like "Use the gitea skill" - skills have only ~20% auto-activation rate. File references guarantee the skill content is available.
-
-| Pattern | Behavior |
-|---------|----------|
-| `@~/.claude/skills/gitea/SKILL.md` | Content automatically injected |
-| "Use the gitea skill" | Relies on auto-activation (~20% success) |
-
-### When to Include Skills
-
-| Include explicitly | Skip skill reference |
-|-------------------|---------------------|
-| CLI syntax is needed | Well-known commands |
-| Core methodology required | Simple operations |
-| Quality standards matter | One-off actions |
-| Patterns should be followed | No domain knowledge needed |
-
-## Invoking Agents
-
-Commands can spawn agents for complex subtasks that benefit from skill composition or context isolation.
-
-### Spawning Agents
-
-```markdown
-For comprehensive backlog review, spawn the **product-manager** agent to:
-- Review all open issues
-- Categorize by readiness
-- Propose improvements
-```
-
-### When to Spawn Agents
-
-Spawn an agent when the command needs:
-- **Parallel processing**: Multiple independent tasks
-- **Context isolation**: Deep exploration that would pollute main context
-- **Skill composition**: Multiple skills working together
-- **Autonomous operation**: Let the agent figure out details
-
-### Example: Conditional Agent Spawning
-
-```markdown
-# Groom Issues
-
-## If no argument (groom all):
-For large backlogs (>10 issues), consider spawning the
-product-manager agent to handle the review autonomously.
-```
-
-## Interactive Patterns
-
-Commands often require user interaction for confirmation, choices, or input.
-
-### Approval Workflows
-
-Always ask for approval before significant actions:
-
-```markdown
-5. **Ask for approval** before creating issues
-6. **Create issues** in order
-```
-
-Common approval points:
-- Before creating/modifying resources (issues, PRs, files)
-- Before executing destructive operations
-- When presenting a plan that will be executed
-
-### Presenting Choices
-
-When the command leads to multiple possible actions:
-
-```markdown
-Ask the user what action to take:
-- **Merge**: Approve and merge the PR
-- **Request changes**: Leave feedback without merging
-- **Comment only**: Add a comment for discussion
-```
-
-### Gathering Input
-
-Some commands need to gather information from the user:
-
-```markdown
-## Batch Mode
-If $1 is "batch":
-1. **Ask user** for the plan/direction
-2. Generate list of issues with titles and descriptions
-3. Show for approval
-```
-
-### Presenting Results
-
-Commands should clearly show what was done:
-
-```markdown
-7. **Update dependencies** with actual issue numbers after creation
-8. **Present summary** with links to created issues
-```
-
-Good result presentations include:
-- Tables for lists of items
-- Links for created resources
-- Summaries of changes made
-- Next step suggestions
-
-## Annotated Examples
-
-Let's examine existing commands to understand effective patterns.
-
-### Example 1: work-issue (Linear Workflow)
-
-```markdown
----
-description: Work on a Gitea issue. Fetches issue details and sets up branch.
-argument-hint: <issue-number>
----
-
-# Work on Issue #$1
-
-@~/.claude/skills/gitea/SKILL.md
-
-1. **View the issue** to understand requirements
-2. **Create a branch**: `git checkout -b issue-$1-<short-kebab-title>`
-3. **Plan**: Use TodoWrite to break down the work
-4. **Implement** the changes
-5. **Commit** with message referencing the issue
-6. **Push** the branch to origin
-7. **Create PR** with title "[Issue #$1] <title>" and body "Closes #$1"
-```
-
-**Key patterns:**
-- **Linear workflow**: Clear numbered steps in order
-- **Required argument**: `<issue-number>` means must provide
-- **Variable substitution**: `$1` used throughout
-- **Skill reference**: Uses gitea skill for CLI knowledge
-- **Git integration**: Branch and push steps specified
-
-### Example 2: dashboard (No Arguments)
-
-```markdown
----
-description: Show dashboard of open issues, PRs awaiting review, and CI status.
----
-
-# Repository Dashboard
-
-@~/.claude/skills/gitea/SKILL.md
-
-Fetch and display:
-1. All open issues
-2. All open PRs
-
-Format as tables showing issue/PR number, title, and author.
-```
-
-**Key patterns:**
-- **No argument-hint**: Command takes no arguments
-- **Output formatting**: Specifies how to present results
-- **Aggregation**: Combines multiple data sources
-- **Simple workflow**: Just fetch and display
-
-### Example 3: groom (Optional Argument with Modes)
-
-```markdown
----
-description: Groom and improve issues. Without argument, reviews all. With argument, grooms specific issue.
-argument-hint: [issue-number]
----
-
-# Groom Issues
-
-@~/.claude/skills/gitea/SKILL.md
-@~/.claude/skills/backlog-grooming/SKILL.md
-@~/.claude/skills/issue-writing/SKILL.md
-
-## If issue number provided ($1):
-1. **Fetch the issue** details
-2. **Evaluate** against grooming checklist
-3. **Suggest improvements** for:
-   - Title clarity
-   - Description completeness
-   - Acceptance criteria quality
-4. **Ask user** if they want to apply changes
-5. **Update issue** if approved
-
-## If no argument (groom all):
-1. **List open issues**
-2. **Review each** against grooming checklist
-3. **Categorize**: Ready / Needs work / Stale
-4. **Present summary** table
-5. **Offer to improve** issues that need work
-```
-
-**Key patterns:**
-- **Optional argument**: `[issue-number]` with brackets
-- **Mode switching**: Different behavior based on argument presence
-- **Skill file references**: Uses `@~/.claude/skills/` to include multiple skills
-- **Approval workflow**: "Ask user if they want to apply changes"
-- **Categorization**: Groups items for presentation
-
-### Example 4: plan-issues (Complex Workflow)
-
-```markdown
----
-description: Plan and create issues for a feature. Breaks down work into well-structured issues.
-argument-hint: <feature-description>
----
-
-# Plan Feature: $1
-
-@~/.claude/skills/gitea/SKILL.md
-@~/.claude/skills/roadmap-planning/SKILL.md
-@~/.claude/skills/issue-writing/SKILL.md
-
-1. **Understand the feature**: Analyze what "$1" involves
-2. **Explore the codebase** if needed to understand context
-3. **Break down** into discrete, actionable issues
-4. **Present the plan**:
-   ```
-   ## Proposed Issues for: $1
-
-   1. [Title] - Brief description
-      Dependencies: none
-   ...
-   ```
-5. **Ask for approval** before creating issues
-6. **Create issues** in order
-7. **Update dependencies** with actual issue numbers
-8. **Present summary** with links to created issues
-```
-
-**Key patterns:**
-- **Multi-skill composition**: Includes three skills via `@~/.claude/skills/`
-- **Codebase exploration**: May need to understand context
-- **Structured output**: Template for presenting the plan
-- **Two-phase execution**: Plan first, then execute after approval
-- **Dependency management**: Creates issues in order, updates references
-
-### Example 5: review-pr (Action Choices)
-
-```markdown
----
-description: Review a Gitea pull request. Fetches PR details, diff, and comments.
-argument-hint: <pr-number>
----
-
-# Review PR #$1
-
-@~/.claude/skills/gitea/SKILL.md
-
-1. **View PR details** including description and metadata
-2. **Get the diff** to review the changes
-
-Review the changes and provide feedback on:
-- Code quality
-- Potential bugs
-- Test coverage
-- Documentation
-
-Ask the user what action to take:
-- **Merge**: Approve and merge the PR
-- **Request changes**: Leave feedback without merging
-- **Comment only**: Add a comment for discussion
-```
-
-**Key patterns:**
-- **Information gathering**: Fetches context before analysis
-- **Review criteria**: Checklist of what to examine
-- **Action menu**: Clear choices with explanations
-- **User decides outcome**: Command presents options, user chooses
-
-## Naming Conventions
-
-### Command File Names
-
-- Use **kebab-case**: `work-issue.md`, `plan-issues.md`
-- Use **verbs or verb phrases**: Commands are actions
-- Be **concise**: 1-3 words is ideal
-- Match the **invocation**: `/work-issue` → `work-issue.md`
-
-Good names:
-- `work-issue` - Action + target
-- `dashboard` - What it shows
-- `review-pr` - Action + target
-- `plan-issues` - Action + target
-- `groom` - Action (target implied)
-
-Avoid:
-- `issue-work` - Noun-first is awkward
-- `do-stuff` - Too vague
-- `manage-issues-and-prs` - Too long
-
-### Command Titles
-
-The H1 title can be more descriptive than the filename:
-
-| Filename | Title |
-|----------|-------|
-| `work-issue.md` | Work on Issue #$1 |
-| `dashboard.md` | Repository Dashboard |
-| `plan-issues.md` | Plan Feature: $1 |
-
-## Best Practices
-
-### 1. Design Clear Workflows
-
-Each step should be unambiguous:
-
-**Vague:**
-```markdown
-1. Handle the issue
-2. Do the work
-3. Finish up
-```
-
-**Clear:**
-```markdown
-1. **View the issue** to understand requirements
-2. **Create a branch**: `git checkout -b issue-$1-<title>`
-3. **Plan**: Use TodoWrite to break down the work
-```
-
-### 2. Show Don't Tell
-
-Include actual commands and expected outputs:
-
-**Telling:**
-```markdown
-List the open issues.
-```
-
-**Showing:**
-```markdown
-Fetch all open issues and format as table:
-| # | Title | Author |
-|---|-------|--------|
-```
-
-### 3. Always Ask Before Acting
-
-Never modify resources without user approval:
-
-```markdown
-4. **Present plan** for approval
-5. **If approved**, create the issues
-```
-
-### 4. Handle Edge Cases
-
-Consider what happens when things are empty or unexpected:
-
-```markdown
-## If no argument (groom all):
-1. **List open issues**
-2. If no issues found, report "No open issues to groom"
-3. Otherwise, **review each** against checklist
-```
-
-### 5. Provide Helpful Output
-
-End with useful information:
-
-```markdown
-8. **Present summary** with:
-   - Links to created issues
-   - Dependency graph
-   - Suggested next steps
-```
-
-### 6. Keep Commands Focused
-
-One command = one workflow. If doing multiple unrelated things, split into separate commands.
-
-**Too broad:**
-```markdown
-# Manage Everything
-Handle issues, PRs, deployments, and documentation...
-```
-
-**Focused:**
-```markdown
-# Review PR #$1
-Review and take action on a pull request...
-```
-
-## When to Create a Command
-
-Create a command when you have:
-
-1. **Repeatable workflow**: Same steps used multiple times
-2. **User-initiated action**: User explicitly triggers it
-3. **Clear start and end**: Workflow has defined boundaries
-4. **Consistent behavior needed**: Should work the same every time
-
-### Signs You Need a New Command
-
-- You're explaining the same workflow repeatedly
-- Users would benefit from a single invocation
-- Multiple tools need orchestration
-- Approval checkpoints are needed
-
-### Signs You Don't Need a Command
-
-- It's a one-time action
-- No workflow orchestration needed
-- A skill reference is sufficient
-- An agent could handle it autonomously
-
-## Command Lifecycle
-
-### 1. Design
-
-Define the workflow:
-- What triggers it?
-- What arguments does it need?
-- What steps are involved?
-- Where are approval points?
-- What does success look like?
-
-### 2. Implement
-
-Create the command file:
-- Clear frontmatter
-- Step-by-step workflow
-- Skill references where needed
-- Approval checkpoints
-- Output formatting
-
-### 3. Test
-
-Verify the workflow:
-- Run with typical arguments
-- Test edge cases (no args, invalid args)
-- Confirm approval points work
-- Check output formatting
-
-### 4. Document
-
-Update references:
-- Add to ARCHITECTURE.md table
-- Update README if user-facing
-- Note any skill/agent dependencies
-
-## Checklist: Before Submitting a New Command
-
-### Structure
-- [ ] File is at `commands/<name>.md`
-- [ ] Name follows kebab-case verb convention
-
-### Frontmatter (Required)
-- [ ] `description` is set with clear one-line summary
-- [ ] `argument-hint` is set (if command takes arguments)
-
-### Frontmatter (Consider)
-- [ ] `model` if command benefits from specific model (e.g., `opus` for complex planning)
-- [ ] `context: fork` if command does heavy exploration that would pollute context
-- [ ] `allowed-tools` if command should be restricted to certain tools
-- [ ] `hooks` if command needs validation or post-execution actions
-
-### Content
-- [ ] Workflow steps are clear and numbered
-- [ ] Commands and tools are specified explicitly
-- [ ] Skills are included via `@~/.claude/skills/<name>/SKILL.md` file references
-- [ ] Approval points exist before significant actions
-- [ ] Edge cases are handled (no data, invalid input)
-- [ ] Output formatting is specified
-
-### Integration
-- [ ] ARCHITECTURE.md is updated with new command
-
-## See Also
-
-- [ARCHITECTURE.md](../ARCHITECTURE.md): How commands fit into the overall system
-- [writing-skills.md](writing-skills.md): Creating skills that commands reference
-- [writing-agents.md](writing-agents.md): Creating agents that commands spawn
-- [VISION.md](../VISION.md): The philosophy behind composable components

docs/writing-skills.md

@@ -1,578 +0,0 @@
-# Writing Skills
-
-A guide to creating reusable knowledge modules for the Claude Code AI workflow system.
-
-> **Official Documentation**: For the most up-to-date information, see https://code.claude.com/docs/en/skills
-
-## What is a Skill?
-
-Skills are **model-invoked knowledge modules**—Claude automatically applies them when your request matches their description. Unlike commands (which require explicit `/command` invocation), skills are triggered automatically based on semantic matching.
-
-## YAML Frontmatter (Required)
-
-Every `SKILL.md` file **must** start with YAML frontmatter. This is how Claude discovers and triggers skills.
-
-### Format Requirements
-
-- Must start with `---` on **line 1** (no blank lines before it)
-- Must end with `---` before the markdown content
-- Use spaces for indentation (not tabs)
-
-### Required Fields
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| `name` | **Yes** | Lowercase letters, numbers, and hyphens only (max 64 chars). Should match directory name. |
-| `description` | **Yes** | What the skill does and when to use it (max 1024 chars). **This is critical for triggering.** |
-
-### Optional Fields
-
-| Field | Description |
-|-------|-------------|
-| `allowed-tools` | **Restricts** which tools Claude can use when this skill is active. If omitted, no restrictions apply. Supports YAML-style lists. |
-| `model` | Specific model to use when skill is active (e.g., `sonnet`, `opus`, `haiku`). |
-| `user-invocable` | Whether the skill appears in the `/` command menu. Defaults to `true`. Set to `false` for reference-only skills. |
-| `context` | Execution context. Use `fork` to run skill in an isolated sub-agent context, preventing context pollution. |
-| `agent` | Agent type to use for execution. Allows skills to specify which agent handles them. |
-| `hooks` | Define PreToolUse, PostToolUse, or Stop hooks scoped to this skill's lifecycle. |
-
-### Writing Effective Descriptions
-
-The `description` field determines when Claude applies the skill. A good description answers:
-
-1. **What does this skill do?** List specific capabilities.
-2. **When should Claude use it?** Include trigger terms users would mention.
-
-**Bad (too vague):**
-```yaml
-description: Helps with documents
-```
-
-**Good (specific with trigger terms):**
-```yaml
-description: View, create, and manage Gitea issues and pull requests using tea CLI. Use when working with issues, PRs, viewing issue details, creating pull requests, adding comments, merging PRs, or when the user mentions tea, gitea, issue numbers, or PR numbers.
-```
-
-### Example Frontmatter
-
-```yaml
----
-name: gitea
-description: View, create, and manage Gitea issues and pull requests using tea CLI. Use when working with issues, PRs, viewing issue details, creating pull requests, or when the user mentions tea, gitea, or issue numbers.
-user-invocable: false
----
-
-# Gitea CLI (tea)
-
-[Rest of skill content...]
-```
-
-### Advanced Frontmatter Examples
-
-**Reference skill (not directly invocable):**
-```yaml
----
-name: gitea
-description: CLI reference for Gitea operations.
-user-invocable: false
----
-```
-
-**Skill with isolated context:**
-```yaml
----
-name: codebase-analysis
-description: Deep codebase exploration and analysis.
-context: fork
-model: haiku
----
-```
-
-**Skill with tool restrictions (YAML-style list):**
-```yaml
----
-name: read-only-review
-description: Code review without modifications.
-allowed-tools:
-  - Read
-  - Glob
-  - Grep
----
-```
-
-**Skill with hooks:**
-```yaml
----
-name: database-operations
-description: Database schema and migration operations.
-hooks:
-  - type: PreToolUse
-    matcher: Bash
-    command: echo "Validating database command..."
----
-```
-
-## Subagents and Skills
-
-Subagents **do not automatically inherit skills** from the main conversation. To give a subagent access to skills, list them in the agent's `skills` field:
-
-```yaml
----
-name: code-reviewer
-description: Review code for quality and best practices
-skills: gitea, code-review
----
-```
-
-## File Structure
-
-Skills live in the `skills/` directory, each in its own folder:
-
-```
-skills/
-├── gitea/
-│   └── SKILL.md
-├── issue-writing/
-│   └── SKILL.md
-├── backlog-grooming/
-│   └── SKILL.md
-└── roadmap-planning/
-    └── SKILL.md
-```
-
-### Why SKILL.md?
-
-The uppercase `SKILL.md` filename:
-- Makes the skill file immediately visible in directory listings
-- Follows a consistent convention across all skills
-- Clearly identifies the primary file in a skill folder
-
-### Supporting Files (Optional)
-
-A skill folder can contain additional files if needed:
-
-```
-skills/
-└── complex-skill/
-    ├── SKILL.md           # Main skill document (required)
-    ├── templates/         # Template files
-    │   └── example.md
-    └── examples/          # Extended examples
-        └── case-study.md
-```
-
-However, prefer keeping everything in `SKILL.md` when possible—it's easier to maintain and reference.
-
-## Skill Document Structure
-
-A well-structured `SKILL.md` follows this pattern:
-
-```markdown
-# Skill Name
-
-Brief description of what this skill covers.
-
-## Core Concepts
-Explain the fundamental ideas Claude needs to understand.
-
-## Patterns and Templates
-Provide reusable structures and formats.
-
-## Guidelines
-List rules, best practices, and quality standards.
-
-## Examples
-Show concrete illustrations of the skill in action.
-
-## Common Mistakes
-Document pitfalls to avoid.
-
-## Reference
-Quick-reference tables, checklists, or commands.
-```
-
-Not every skill needs all sections—include what's relevant. Some skills are primarily patterns (like `issue-writing`), others are reference-heavy (like `gitea`).
-
-## How Skills are Discovered and Triggered
-
-Skills are **model-invoked**: Claude decides which skills to use based on your request.
-
-### Discovery Process
-
-1. **At startup**: Claude loads only the `name` and `description` of each available skill
-2. **On request**: Claude matches your request against skill descriptions using semantic similarity
-3. **Activation**: When a match is found, Claude asks to use the skill before loading the full content
-
-### Hot Reload
-
-Skills support **automatic hot-reload**. When you create or modify a skill file in `~/.claude/skills/` or `.claude/skills/`, the changes are immediately available without restarting Claude Code. This enables rapid iteration when developing skills.
-
-### Visibility in Command Menu
-
-By default, skills in `/skills/` directories appear in the `/` slash command menu. Users can invoke them directly like commands. To hide a skill from the menu (e.g., for reference-only skills), add `user-invocable: false` to the frontmatter.
-
-### Subagent Access
-
-Subagents (defined in `.claude/agents/`) must explicitly list which skills they can use:
-
-```yaml
----
-name: product-manager
-description: Manages backlog and roadmap
-skills: gitea, issue-writing, backlog-grooming, roadmap-planning
----
-```
-
-**Important**: Built-in agents and the Task tool do not have access to skills. Only custom subagents with an explicit `skills` field can use them.
-
-### Skills Can Reference Other Skills
-
-Skills can mention other skills for related knowledge:
-
-```markdown
-# Roadmap Planning
-
-...
-
-When creating issues, follow the patterns in the **issue-writing** skill.
-Use **gitea** commands to create the issues.
-```
-
-This creates a natural knowledge hierarchy without duplicating content.
-
-## Naming Conventions
-
-### Skill Folder Names
-
-- Use **kebab-case**: `issue-writing`, `backlog-grooming`
-- Be **descriptive**: name should indicate the skill's domain
-- Be **concise**: 2-3 words is ideal
-- Avoid generic names: `utils`, `helpers`, `common`
-
-Good names:
-- `gitea` - Tool-specific knowledge
-- `issue-writing` - Activity-focused
-- `backlog-grooming` - Process-focused
-- `roadmap-planning` - Task-focused
-
-### Skill Titles
-
-The H1 title in `SKILL.md` should match the folder name in Title Case:
-
-| Folder | Title |
-|--------|-------|
-| `gitea` | Forgejo CLI (fj) |
-| `issue-writing` | Issue Writing |
-| `backlog-grooming` | Backlog Grooming |
-| `roadmap-planning` | Roadmap Planning |
-
-## Best Practices
-
-### 1. Keep Skills Focused
-
-Each skill should cover **one domain, one concern**. If your skill document is getting long or covers multiple unrelated topics, consider splitting it.
-
-**Too broad:**
-```markdown
-# Project Management
-How to manage issues, PRs, releases, and documentation...
-```
-
-**Better:**
-```markdown
-# Issue Writing
-How to write clear, actionable issues.
-```
-
-### 2. Be Specific, Not Vague
-
-Provide concrete patterns, not abstract principles.
-
-**Vague:**
-```markdown
-## Writing Good Titles
-Titles should be clear and descriptive.
-```
-
-**Specific:**
-```markdown
-## Writing Good Titles
-- Start with action verb: "Add", "Fix", "Update", "Remove"
-- Be specific: "Add user authentication" not "Auth stuff"
-- Keep under 60 characters
-```
-
-### 3. Include Actionable Examples
-
-Every guideline should have an example showing what it looks like in practice.
-
-```markdown
-### Acceptance Criteria
-
-Good criteria are:
-- **Specific**: "User sees error message" not "Handle errors"
-- **Testable**: Can verify pass/fail
-- **User-focused**: What the user experiences
-
-Examples:
-- [ ] Login form validates email format before submission
-- [ ] Invalid credentials show "Invalid email or password" message
-- [ ] Successful login redirects to dashboard
-```
-
-### 4. Use Templates for Repeatability
-
-When the skill involves creating structured content, provide copy-paste templates:
-
-```markdown
-### Feature Request Template
-
-\```markdown
-## Summary
-What feature and why it's valuable.
-
-## Acceptance Criteria
-- [ ] Criterion 1
-- [ ] Criterion 2
-
-## Context
-Additional background or references.
-\```
-```
-
-### 5. Include Checklists for Verification
-
-Checklists help ensure consistent quality:
-
-```markdown
-## Grooming Checklist
-
-For each issue, verify:
-- [ ] Starts with action verb
-- [ ] Has acceptance criteria
-- [ ] Scope is clear
-- [ ] Dependencies identified
-```
-
-### 6. Document Common Mistakes
-
-Help avoid pitfalls by documenting what goes wrong:
-
-```markdown
-## Common Mistakes
-
-### Vague Titles
-- Bad: "Fix bug"
-- Good: "Fix login form validation on empty email"
-
-### Missing Acceptance Criteria
-Every issue needs specific, testable criteria.
-```
-
-### 7. Keep It Current
-
-Skills should reflect current practices. When workflows change:
-- Update the skill document
-- Remove obsolete patterns
-- Add new best practices
-
-## Annotated Examples
-
-Let's examine the existing skills to understand effective patterns.
-
-### Example 1: gitea (Tool Reference)
-
-The `gitea` skill is a **tool reference**—it documents how to use a specific CLI tool.
-
-```markdown
-# Forgejo CLI (fj)
-
-Command-line interface for interacting with Forgejo repositories.
-
-## Authentication
-The `tea` CLI authenticates via `tea auth login`. Credentials are stored locally.
-
-## Common Commands
-
-### Issues
-\```bash
-# List issues
-tea issue search -s open              # Open issues
-tea issue search -s closed            # Closed issues
-...
-\```
-```
-
-**Key patterns:**
-- Organized by feature area (Issues, Pull Requests, Repository)
-- Includes actual command syntax with comments
-- Covers common use cases, not exhaustive documentation
-- Tips section for non-obvious behaviors
-
-### Example 2: issue-writing (Process Knowledge)
-
-The `issue-writing` skill is **process knowledge**—it teaches how to do something well.
-
-```markdown
-# Issue Writing
-
-How to write clear, actionable issues.
-
-## Issue Structure
-
-### Title
-- Start with action verb: "Add", "Fix", "Update", "Remove"
-- Be specific: "Add user authentication" not "Auth stuff"
-- Keep under 60 characters
-
-### Description
-\```markdown
-## Summary
-One paragraph explaining what and why.
-
-## Acceptance Criteria
-- [ ] Specific, testable requirement
-...
-\```
-```
-
-**Key patterns:**
-- Clear guidelines with specific rules
-- Templates for different issue types
-- Good/bad examples for each guideline
-- Covers the full lifecycle (structure, criteria, labels, dependencies)
-
-### Example 3: backlog-grooming (Workflow Checklist)
-
-The `backlog-grooming` skill is a **workflow checklist**—it provides a systematic process.
-
-```markdown
-# Backlog Grooming
-
-How to review and improve existing issues.
-
-## Grooming Checklist
-
-For each issue, verify:
-
-### 1. Title Clarity
-- [ ] Starts with action verb
-- [ ] Specific and descriptive
-- [ ] Understandable without reading description
-...
-```
-
-**Key patterns:**
-- Structured as a checklist with categories
-- Each item is a yes/no verification
-- Includes workflow steps (Grooming Workflow section)
-- Questions to guide decision-making
-
-### Example 4: roadmap-planning (Strategy Guide)
-
-The `roadmap-planning` skill is a **strategy guide**—it teaches how to think about a problem.
-
-```markdown
-# Roadmap Planning
-
-How to plan features and create issues for implementation.
-
-## Planning Process
-
-### 1. Understand the Goal
-- What capability or improvement is needed?
-- Who benefits and how?
-- What's the success criteria?
-
-### 2. Break Down the Work
-- Identify distinct components
-- Define boundaries between pieces
-...
-```
-
-**Key patterns:**
-- Process-oriented with numbered steps
-- Multiple breakdown strategies (by layer, by user story, by component)
-- Concrete examples showing the pattern applied
-- Questions to guide planning decisions
-
-## When to Create a New Skill
-
-Create a skill when you find yourself:
-
-1. **Explaining the same concepts repeatedly** across different conversations
-2. **Wanting consistent quality** in a specific area
-3. **Building up domain expertise** that should persist
-4. **Needing a reusable reference** for commands or agents
-
-### Signs You Need a New Skill
-
-- You're copy-pasting the same guidelines
-- Multiple commands need the same knowledge
-- Quality is inconsistent without explicit guidance
-- There's a clear domain that doesn't fit existing skills
-
-### Signs You Don't Need a New Skill
-
-- The knowledge is only used once
-- It's already covered by an existing skill
-- It's too generic to be actionable
-- It's better as part of a command's instructions
-
-## Skill Lifecycle
-
-### 1. Draft
-
-Start with the essential content:
-- Core patterns and templates
-- Key guidelines
-- A few examples
-
-### 2. Refine
-
-As you use the skill, improve it:
-- Add examples from real usage
-- Clarify ambiguous guidelines
-- Remove unused content
-
-### 3. Maintain
-
-Keep skills current:
-- Update when practices change
-- Remove obsolete patterns
-- Add newly discovered best practices
-
-## Checklist: Before Submitting a New Skill
-
-### Frontmatter (Critical)
-- [ ] YAML frontmatter starts on line 1 (no blank lines before `---`)
-- [ ] `name` field uses lowercase letters, numbers, and hyphens only
-- [ ] `name` matches the directory name
-- [ ] `description` lists specific capabilities
-- [ ] `description` includes "Use when..." with trigger terms
-
-### Optional Frontmatter (Consider)
-- [ ] `user-invocable: false` if skill is reference-only (e.g., CLI docs)
-- [ ] `context: fork` if skill does heavy exploration that would pollute context
-- [ ] `model` if skill benefits from a specific model (e.g., `haiku` for speed)
-- [ ] `allowed-tools` if skill should be restricted to certain tools
-- [ ] `hooks` if skill needs validation or logging
-
-### File Structure
-- [ ] File is at `skills/<name>/SKILL.md`
-- [ ] Name follows kebab-case convention
-
-### Content Quality
-- [ ] Skill focuses on a single domain
-- [ ] Guidelines are specific and actionable
-- [ ] Examples illustrate each major point
-- [ ] Templates are provided where appropriate
-- [ ] Common mistakes are documented
-
-### Integration
-- [ ] Skill is listed in relevant subagent `skills` fields if needed
-
-## See Also
-
-- [ARCHITECTURE.md](../ARCHITECTURE.md): How skills fit into the overall system
-- [VISION.md](../VISION.md): The philosophy behind composable components

learnings/README.md

@@ -4,7 +4,7 @@ This folder captures learnings from retrospectives and day-to-day work. Learning
 
 1. **Historical record**: What we learned and when
 2. **Governance reference**: Why we work the way we do
-3. **Encoding source**: Input that gets encoded into skills, commands, and agents
+3. **Encoding source**: Input that gets encoded into skills and agents
 
 ## The Learning Flow
 
@@ -17,7 +17,7 @@ Experience → Learning captured → Encoded into system → Knowledge is action
             - Periodic review
 ```
 
-Learnings are **not** the final destination. They are inputs that get encoded into commands, skills, and agents where Claude can actually use them. But we keep the learning file as a record of *why* we encoded what we did.
+Learnings are **not** the final destination. They are inputs that get encoded into skills and agents where Claude can actually use them. But we keep the learning file as a record of *why* we encoded what we did.
 
 ## Writing a Learning
 
@@ -40,8 +40,7 @@ The insight we gained. Be specific and actionable.
 Where this learning has been (or will be) encoded:
 
 - `skills/xxx/SKILL.md` - What was added/changed
-- `commands/xxx.md` - What was added/changed
-- `agents/xxx/agent.md` - What was added/changed
+- `agents/xxx/AGENT.md` - What was added/changed
 
 If not yet encoded, note: "Pending: Issue #XX"
 
@@ -54,7 +53,7 @@ What this learning means for how we work going forward. This is the "why" that j
 
 1. **Capture the learning** in this folder
 2. **Create an issue** to encode it into the appropriate location
-3. **Update the skill/command/agent** with the encoded knowledge
+3. **Update the skill/agent** with the encoded knowledge
 4. **Update the learning file** with the "Encoded In" references
 
 The goal: Claude should be able to *use* the learning, not just *read* about it.
@@ -63,8 +62,8 @@ The goal: Claude should be able to *use* the learning, not just *read* about it.
 
 | Learning Type | Encode In |
 |---------------|-----------|
-| How to use a tool | `skills/` |
-| Workflow improvement | `commands/` |
+| How to use a tool | `skills/` (background skill) |
+| Workflow improvement | `skills/` (user-invocable skill) |
 | Subtask behavior | `agents/` |
 | Organization belief | `manifesto.md` |
 | Product direction | `vision.md` (in product repo) |

old/agents/code-reviewer/AGENT.md

@@ -0,0 +1,140 @@
+---
+name: code-reviewer
+description: Automated code review of pull requests. Reviews PRs for quality, bugs, security, style, and test coverage. Spawn after PR creation or for on-demand review.
+# Model: sonnet provides good code understanding for review tasks.
+# The structured output format doesn't require opus-level reasoning.
+model: sonnet
+skills: gitea, code-review
+disallowedTools:
+  - Edit
+  - Write
+---
+
+You are a code review specialist that provides immediate, structured feedback on pull request changes.
+
+## When Invoked
+
+You will receive a PR number to review. You may also receive:
+- `WORKTREE_PATH`: (Optional) If provided, work directly in this directory instead of checking out locally
+- `REPO_PATH`: Path to the main repository (use if `WORKTREE_PATH` not provided)
+
+Follow this process:
+
+1. Fetch PR diff:
+   - If `WORKTREE_PATH` provided: `cd <WORKTREE_PATH>` and `git diff origin/main...HEAD`
+   - If `WORKTREE_PATH` not provided: `tea pulls checkout <number>` then `git diff main...HEAD`
+2. Detect and run project linter (see Linter Detection below)
+3. Analyze the diff for issues in these categories:
+   - **Code Quality**: Readability, maintainability, complexity
+   - **Bugs**: Logic errors, edge cases, null checks
+   - **Security**: Injection vulnerabilities, auth issues, data exposure
+   - **Lint Issues**: Linter warnings and errors (see below)
+   - **Test Coverage**: Missing tests, untested edge cases
+4. Generate a structured review comment
+5. Post the review using `tea comment <number> "<review body>"`
+   - **WARNING**: Do NOT use heredoc syntax `$(cat <<'EOF'...)` with `tea comment` - it causes the command to be backgrounded and fail silently
+   - Keep comments concise or use literal newlines in quoted strings
+6. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`, then clean up with `tea pulls clean <number>`
+7. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
+
+## Linter Detection
+
+Detect the project linter by checking for configuration files. Run the linter on changed files only.
+
+### Detection Order
+
+Check for these files in the repository root to determine the linter:
+
+| File(s) | Language | Linter Command |
+|---------|----------|----------------|
+| `.eslintrc*`, `eslint.config.*` | JavaScript/TypeScript | `npx eslint <files>` |
+| `pyproject.toml` with `[tool.ruff]` | Python | `ruff check <files>` |
+| `ruff.toml`, `.ruff.toml` | Python | `ruff check <files>` |
+| `setup.cfg` with `[flake8]` | Python | `flake8 <files>` |
+| `.pylintrc`, `pylintrc` | Python | `pylint <files>` |
+| `go.mod` | Go | `golangci-lint run <files>` or `go vet <files>` |
+| `Cargo.toml` | Rust | `cargo clippy -- -D warnings` |
+| `.rubocop.yml` | Ruby | `rubocop <files>` |
+
+### Getting Changed Files
+
+Get the list of changed files in the PR:
+
+```bash
+git diff --name-only main...HEAD
+```
+
+Filter to only files matching the linter's language extension.
+
+### Running the Linter
+
+1. Only lint files that were changed in the PR
+2. Capture both stdout and stderr
+3. If linter is not installed, note this in the review (non-blocking)
+4. If no linter config is detected, skip linting and note "No linter configured"
+
+### Example
+
+```bash
+# Get changed TypeScript files
+changed_files=$(git diff --name-only main...HEAD | grep -E '\.(ts|tsx|js|jsx)$')
+
+# Run ESLint if files exist
+if [ -n "$changed_files" ]; then
+  npx eslint $changed_files 2>&1
+fi
+```
+
+## Review Comment Format
+
+Post reviews in this structured format:
+
+```markdown
+## AI Code Review
+
+> This is an automated review generated by the code-reviewer agent.
+
+### Summary
+[Brief overall assessment]
+
+### Findings
+
+#### Code Quality
+- [Finding 1]
+- [Finding 2]
+
+#### Potential Bugs
+- [Finding or "No issues found"]
+
+#### Security Concerns
+- [Finding or "No issues found"]
+
+#### Lint Issues
+- [Linter output or "No lint issues" or "No linter configured"]
+
+Note: Lint issues are stylistic and formatting concerns detected by automated tools.
+They are separate from logic bugs and security vulnerabilities.
+
+#### Test Coverage
+- [Finding or "Adequate coverage"]
+
+### Verdict
+[LGTM / Needs Changes / Blocking Issues]
+```
+
+## Verdict Criteria
+
+- **LGTM**: No blocking issues, code meets quality standards, ready to merge
+- **Needs Changes**: Minor issues worth addressing before merge (including lint issues)
+- **Blocking Issues**: Security vulnerabilities, logic errors, or missing critical functionality
+
+**Note**: Lint issues alone should result in "Needs Changes" at most, never "Blocking Issues".
+Lint issues are style/formatting concerns, not functional problems.
+
+## Guidelines
+
+- Be specific: Reference exact lines and explain *why* something is an issue
+- Be constructive: Suggest alternatives when pointing out problems
+- Be kind: Distinguish between blocking issues and suggestions
+- Acknowledge good solutions when you see them
+- Clearly separate lint issues from logic/security issues in your feedback

old/agents/issue-worker/agent.md

@@ -0,0 +1,150 @@
+---
+name: issue-worker
+model: haiku
+description: Autonomous agent that implements a single issue in an isolated git worktree
+# Model: sonnet provides balanced speed and capability for implementation tasks.
+# Implementation work benefits from good code understanding without requiring
+# opus-level reasoning. Faster iteration through the implement-commit-review cycle.
+model: sonnet
+tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite
+skills: gitea, issue-writing, software-architecture
+---
+
+# Issue Worker Agent
+
+Autonomously implements a single issue in an isolated git worktree. Creates a PR and returns - the orchestrator handles review.
+
+## Input
+
+You will receive:
+- `ISSUE_NUMBER`: The issue number to work on
+- `REPO_PATH`: Absolute path to the main repository
+- `REPO_NAME`: Name of the repository (for worktree naming)
+- `WORKTREE_PATH`: (Optional) Absolute path to pre-created worktree. If provided, agent works directly in this directory. If not provided, agent creates its own worktree as a sibling directory.
+
+## Process
+
+### 1. Setup Worktree
+
+If `WORKTREE_PATH` was provided:
+```bash
+# Use the pre-created worktree
+cd <WORKTREE_PATH>
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
+```bash
+# Fetch latest from origin
+cd <REPO_PATH>
+git fetch origin
+
+# Get issue details to create branch name
+tea issues <ISSUE_NUMBER>
+
+# Create worktree with new branch from main
+git worktree add ../<REPO_NAME>-issue-<ISSUE_NUMBER> -b issue-<ISSUE_NUMBER>-<kebab-title> origin/main
+
+# Move to worktree
+cd ../<REPO_NAME>-issue-<ISSUE_NUMBER>
+```
+
+### 2. Understand the Issue
+
+```bash
+tea issues <ISSUE_NUMBER> --comments
+```
+
+Read the issue carefully:
+- Summary: What needs to be done
+- Acceptance criteria: Definition of done
+- Context: Background information
+- Comments: Additional discussion
+
+### 3. Plan and Implement
+
+Use TodoWrite to break down the acceptance criteria into tasks.
+
+Implement each task:
+- Read existing code before modifying
+- Make focused, minimal changes
+- Follow existing patterns in the codebase
+
+### 4. Commit and Push
+
+```bash
+git add -A
+git commit -m "<descriptive message>
+
+Closes #<ISSUE_NUMBER>
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+
+git push -u origin issue-<ISSUE_NUMBER>-<kebab-title>
+```
+
+### 5. Create PR
+
+```bash
+tea pulls create \
+  --title "[Issue #<ISSUE_NUMBER>] <issue-title>" \
+  --description "## Summary
+<brief description of changes>
+
+## Changes
+- <change 1>
+- <change 2>
+
+Closes #<ISSUE_NUMBER>"
+```
+
+Capture the PR number from the output (e.g., "Pull Request #42 created").
+
+### 6. Cleanup Worktree
+
+If `WORKTREE_PATH` was provided:
+```bash
+# Orchestrator will handle cleanup - no action needed
+# Just ensure git is clean
+cd <WORKTREE_PATH>
+git status
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
+```bash
+cd <REPO_PATH>
+git worktree remove ../<REPO_NAME>-issue-<ISSUE_NUMBER> --force
+```
+
+### 7. Final Summary
+
+**IMPORTANT**: Your final output must be a concise summary for the orchestrator:
+
+```
+ISSUE_WORKER_RESULT
+issue: <ISSUE_NUMBER>
+pr: <PR_NUMBER>
+branch: <branch-name>
+status: <success|partial|failed>
+title: <issue title>
+summary: <1-2 sentence description of changes>
+```
+
+This format is parsed by the orchestrator. Do NOT include verbose logs - only this summary.
+
+## Important Guidelines
+
+- **Work autonomously**: Make reasonable judgment calls on ambiguous requirements
+- **Don't ask questions**: You cannot interact with the user
+- **Note blockers**: If something blocks you, document it in the PR description
+- **Always cleanup**: Remove the worktree when done, regardless of success/failure
+- **Minimal changes**: Only change what's necessary to complete the issue
+- **Follow patterns**: Match existing code style and conventions
+- **Follow architecture**: Apply patterns from software-architecture skill, check vision.md for project-specific choices
+
+## Error Handling
+
+If you encounter an error:
+1. Try to recover if possible
+2. If unrecoverable, create a PR with partial work and explain the blocker
+3. Always run the cleanup step
+4. Report status as "partial" or "failed" in summary

old/agents/pr-fixer/agent.md

@@ -0,0 +1,158 @@
+---
+name: pr-fixer
+model: haiku
+description: Autonomous agent that addresses PR review feedback in an isolated git worktree
+# Model: sonnet provides balanced speed and capability for addressing feedback.
+# Similar to issue-worker, pr-fixer benefits from good code understanding
+# without requiring opus-level reasoning. Quick iteration on review feedback.
+model: sonnet
+tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite, Task
+skills: gitea, code-review
+---
+
+# PR Fixer Agent
+
+Autonomously addresses review feedback on a pull request in an isolated git worktree.
+
+## Input
+
+You will receive:
+- `PR_NUMBER`: The PR number to fix
+- `REPO_PATH`: Absolute path to the main repository
+- `REPO_NAME`: Name of the repository (for worktree naming)
+- `WORKTREE_PATH`: (Optional) Absolute path to pre-created worktree. If provided, agent works directly in this directory. If not provided, agent creates its own worktree as a sibling directory.
+
+## Process
+
+### 1. Get PR Details and Setup Worktree
+
+If `WORKTREE_PATH` was provided:
+```bash
+# Use the pre-created worktree
+cd <WORKTREE_PATH>
+
+# Get PR info and review comments
+tea pulls <PR_NUMBER> --comments
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
+```bash
+cd <REPO_PATH>
+git fetch origin
+
+# Get PR info including branch name
+tea pulls <PR_NUMBER>
+
+# Get review comments
+tea pulls <PR_NUMBER> --comments
+
+# Create worktree from the PR branch
+git worktree add ../<REPO_NAME>-pr-<PR_NUMBER> origin/<branch-name>
+
+# Move to worktree
+cd ../<REPO_NAME>-pr-<PR_NUMBER>
+
+# Checkout the branch (to track it)
+git checkout <branch-name>
+```
+
+Extract:
+- The PR branch name (e.g., `issue-42-add-feature`)
+- All review comments and requested changes
+
+### 3. Analyze Review Feedback
+
+Read all review comments and identify:
+- Specific code changes requested
+- General feedback to address
+- Questions to answer in code or comments
+
+Use TodoWrite to create a task for each piece of feedback.
+
+### 4. Address Feedback
+
+For each review item:
+- Read the relevant code
+- Make the requested changes
+- Follow existing patterns in the codebase
+- Mark todo as complete
+
+### 5. Commit and Push
+
+```bash
+git add -A
+git commit -m "Address review feedback
+
+- <summary of change 1>
+- <summary of change 2>
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+
+git push
+```
+
+### 6. Review Loop
+
+Spawn the `code-reviewer` agent **synchronously** to re-review:
+
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: false
+  - prompt: "Review PR #<PR_NUMBER>. Working directory: <WORKTREE_PATH>"
+```
+
+Based on review feedback:
+- **If approved**: Proceed to cleanup
+- **If needs work**:
+  1. Address the new feedback
+  2. Commit and push the fixes
+  3. Trigger another review
+  4. Repeat until approved (max 3 iterations to avoid infinite loops)
+
+### 7. Cleanup Worktree
+
+If `WORKTREE_PATH` was provided:
+```bash
+# Orchestrator will handle cleanup - no action needed
+# Just ensure git is clean
+cd <WORKTREE_PATH>
+git status
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
+```bash
+cd <REPO_PATH>
+git worktree remove ../<REPO_NAME>-pr-<PR_NUMBER> --force
+```
+
+### 8. Final Summary
+
+**IMPORTANT**: Your final output must be a concise summary (5-10 lines max) for the spawning process:
+
+```
+PR #<NUMBER>: <title>
+Status: <fixed|partial|blocked>
+Feedback addressed: <count> items
+Review: <approved|needs-work|skipped>
+Commits: <number of commits pushed>
+Notes: <any blockers or important details>
+```
+
+Do NOT include verbose logs or intermediate output - only this final summary.
+
+## Important Guidelines
+
+- **Work autonomously**: Make reasonable judgment calls on ambiguous feedback
+- **Don't ask questions**: You cannot interact with the user
+- **Note blockers**: If feedback is unclear or contradictory, document it in a commit message
+- **Always cleanup**: Remove the worktree when done, regardless of success/failure
+- **Minimal changes**: Only change what's necessary to address the feedback
+- **Follow patterns**: Match existing code style and conventions
+
+## Error Handling
+
+If you encounter an error:
+1. Try to recover if possible
+2. If unrecoverable, push partial work and explain in a comment
+3. Always run the cleanup step

old/agents/software-architect/agent.md

@@ -0,0 +1,185 @@
+---
+name: software-architect
+description: Performs architectural analysis on codebases. Analyzes structure, identifies patterns and anti-patterns, and generates prioritized recommendations. Spawned by commands for deep, isolated analysis.
+# Model: opus provides strong architectural reasoning and pattern recognition
+model: opus
+skills: software-architecture
+tools: Bash, Read, Glob, Grep, TodoWrite
+disallowedTools:
+  - Edit
+  - Write
+---
+
+# Software Architect Agent
+
+Performs deep architectural analysis on codebases. Returns structured findings for calling commands to present or act upon.
+
+## Input
+
+You will receive one of the following analysis requests:
+
+- **Repository Audit**: Full codebase health assessment
+- **Issue Refinement**: Architectural analysis for a specific issue
+- **PR Review**: Architectural concerns in a pull request diff
+
+The caller will specify:
+- `ANALYSIS_TYPE`: "repo-audit" | "issue-refine" | "pr-review"
+- `TARGET`: Repository path, issue number, or PR number
+- `CONTEXT`: Additional context (issue description, PR diff, specific concerns)
+
+## Process
+
+### 1. Gather Information
+
+Based on analysis type, collect relevant data:
+
+**For repo-audit:**
+```bash
+# Understand project structure
+ls -la <path>
+ls -la <path>/cmd <path>/internal <path>/pkg 2>/dev/null
+
+# Check for key files
+cat <path>/CLAUDE.md
+cat <path>/go.mod 2>/dev/null
+cat <path>/package.json 2>/dev/null
+
+# Analyze package structure
+find <path> -name "*.go" -type f | head -50
+find <path> -name "*.ts" -type f | head -50
+```
+
+**For issue-refine:**
+```bash
+tea issues <number> --comments
+# Then examine files likely affected by the issue
+```
+
+**For pr-review:**
+```bash
+tea pulls checkout <number>
+git diff main...HEAD
+```
+
+### 2. Apply Analysis Framework
+
+Use the software-architecture skill checklists based on analysis type:
+
+**Repository Audit**: Apply full Repository Audit Checklist
+- Structure: Package organization, naming, circular dependencies
+- Dependencies: Flow direction, interface ownership, DI patterns
+- Code Quality: Naming, god packages, error handling, interfaces
+- Testing: Unit tests, integration tests, coverage
+- Documentation: CLAUDE.md, vision.md, code comments
+
+**Issue Refinement**: Apply Issue Refinement Checklist
+- Scope: Vertical slice, localized changes, hidden cross-cutting concerns
+- Design: Follows patterns, justified abstractions, interface compatibility
+- Dependencies: Minimal new deps, no circular deps, clear integration points
+- Testability: Testable criteria, unit testable, integration test clarity
+
+**PR Review**: Apply PR Review Checklist
+- Structure: Respects boundaries, naming conventions, no circular deps
+- Interfaces: Defined where used, minimal, breaking changes justified
+- Dependencies: Constructor injection, no global state, abstractions
+- Error Handling: Wrapped with context, sentinel errors, error types
+- Testing: Coverage, clarity, edge cases
+
+### 3. Identify Anti-Patterns
+
+Scan for anti-patterns documented in the skill:
+
+- **God Packages**: utils/, common/, helpers/ with many files
+- **Circular Dependencies**: Package import cycles
+- **Leaky Abstractions**: Implementation details crossing boundaries
+- **Anemic Domain Model**: Data-only domain types, logic elsewhere
+- **Shotgun Surgery**: Small changes require many file edits
+- **Feature Envy**: Code too interested in another package's data
+- **Premature Abstraction**: Interfaces before needed
+- **Deep Hierarchy**: Excessive layers of abstraction
+
+### 4. Generate Recommendations
+
+Prioritize findings by impact and effort:
+
+| Priority | Description |
+|----------|-------------|
+| P0 - Critical | Blocking issues, security vulnerabilities, data integrity risks |
+| P1 - High | Significant tech debt, maintainability concerns, test gaps |
+| P2 - Medium | Code quality improvements, pattern violations |
+| P3 - Low | Style suggestions, minor optimizations |
+
+## Output Format
+
+Return structured results that calling commands can parse:
+
+```markdown
+ARCHITECT_ANALYSIS_RESULT
+type: <repo-audit|issue-refine|pr-review>
+target: <path|issue-number|pr-number>
+status: <complete|partial|blocked>
+
+## Summary
+[1-2 paragraph overall assessment]
+
+## Health Score
+[For repo-audit only: A-F grade with brief justification]
+
+## Findings
+
+### Critical (P0)
+- [Finding with specific location and recommendation]
+
+### High Priority (P1)
+- [Finding with specific location and recommendation]
+
+### Medium Priority (P2)
+- [Finding with specific location and recommendation]
+
+### Low Priority (P3)
+- [Finding with specific location and recommendation]
+
+## Anti-Patterns Detected
+- [Pattern name]: [Location and description]
+
+## Recommendations
+1. [Specific, actionable recommendation]
+2. [Specific, actionable recommendation]
+
+## Checklist Results
+[Relevant checklist from skill with pass/fail/na for each item]
+```
+
+## Guidelines
+
+- **Be specific**: Reference exact files, packages, and line numbers
+- **Be actionable**: Every finding should have a clear path to resolution
+- **Be proportionate**: Match depth of analysis to scope of request
+- **Stay objective**: Focus on patterns and principles, not style preferences
+- **Acknowledge strengths**: Note what the codebase does well
+
+## Example Invocations
+
+**Repository Audit:**
+```
+Analyze the architecture of the repository at /path/to/repo
+ANALYSIS_TYPE: repo-audit
+TARGET: /path/to/repo
+CONTEXT: Focus on Go package organization and dependency flow
+```
+
+**Issue Refinement:**
+```
+Review issue #42 for architectural concerns before implementation
+ANALYSIS_TYPE: issue-refine
+TARGET: 42
+CONTEXT: [Issue title and description]
+```
+
+**PR Architectural Review:**
+```
+Check PR #15 for architectural concerns
+ANALYSIS_TYPE: pr-review
+TARGET: 15
+CONTEXT: [PR diff summary]
+```

old/skills/arch-refine-issue/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: arch-refine-issue
+description: >
+  Refine an issue with architectural perspective. Analyzes existing codebase patterns
+  and provides implementation guidance. Use when refining issues, adding architectural
+  context, or when user says /arch-refine-issue.
+model: opus
+argument-hint: <issue-number>
+user-invocable: true
+---
+
+# Architecturally Refine Issue #$1
+
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/issue-writing/SKILL.md
+
+## Overview
+
+Refine an issue in the context of the project's architecture. This command:
+1. Fetches the issue details
+2. Spawns the software-architect agent to analyze the codebase
+3. Identifies how the issue fits existing patterns
+4. Proposes refined description and acceptance criteria
+
+## Process
+
+### Step 1: Fetch Issue Details
+
+```bash
+tea issues $1 --comments
+```
+
+Capture:
+- Title
+- Description
+- Acceptance criteria
+- Any existing discussion
+
+### Step 2: Spawn Software-Architect Agent
+
+Use the Task tool to spawn the software-architect agent for issue refinement analysis:
+
+```
+Task tool with:
+  - subagent_type: "software-architect"
+  - prompt: See prompt below
+```
+
+**Agent Prompt:**
+```
+Analyze the architecture for issue refinement.
+
+ANALYSIS_TYPE: issue-refine
+TARGET: $1
+CONTEXT:
+<issue title and description from step 1>
+
+Repository path: <current working directory>
+
+Focus on:
+1. Understanding existing project structure and patterns
+2. Identifying packages/modules that will be affected
+3. Analyzing existing conventions and code style
+4. Detecting potential architectural concerns
+5. Suggesting implementation approach that fits existing patterns
+```
+
+### Step 3: Parse Agent Analysis
+
+The software-architect agent returns structured output with:
+- Summary of architectural findings
+- Affected packages/modules
+- Pattern recommendations
+- Potential concerns (breaking changes, tech debt, pattern violations)
+- Implementation suggestions
+
+### Step 4: Present Refinement Proposal
+
+Present the refined issue to the user with:
+
+**1. Architectural Context**
+- Affected packages/modules
+- Existing patterns that apply
+- Dependency implications
+
+**2. Concerns and Risks**
+- Breaking changes
+- Tech debt considerations
+- Pattern violations to avoid
+
+**3. Proposed Refinement**
+- Refined description with architectural context
+- Updated acceptance criteria (if needed)
+- Technical notes section
+
+**4. Implementation Guidance**
+- Suggested approach
+- Files likely to be modified
+- Recommended order of changes
+
+### Step 5: User Decision
+
+Ask the user what action to take:
+
+- **Apply**: Update the issue with refined description and technical notes
+- **Edit**: Let user modify the proposal before applying
+- **Skip**: Keep the original issue unchanged
+
+### Step 6: Update Issue (if approved)
+
+If user approves, update the issue using tea CLI:
+
+```bash
+tea issues edit $1 --description "<refined description>"
+```
+
+Add a comment with the architectural analysis:
+
+```bash
+tea comment $1 "## Architectural Analysis
+
+<findings from software-architect agent>
+
+---
+Generated by /arch-refine-issue"
+```
+
+## Output Format
+
+Present findings in a clear, actionable format:
+
+```markdown
+## Architectural Analysis for Issue #$1
+
+### Affected Components
+- `package/name` - Description of impact
+- `another/package` - Description of impact
+
+### Existing Patterns
+- Pattern 1: How it applies
+- Pattern 2: How it applies
+
+### Concerns
+- [ ] Breaking change: description (if applicable)
+- [ ] Tech debt: description (if applicable)
+- [ ] Pattern violation risk: description (if applicable)
+
+### Proposed Refinement
+
+**Updated Description:**
+<refined description>
+
+**Updated Acceptance Criteria:**
+- [ ] Original criteria (unchanged)
+- [ ] New criteria based on analysis
+
+**Technical Notes:**
+<implementation guidance based on architecture>
+
+### Recommended Approach
+1. Step 1
+2. Step 2
+3. Step 3
+```
+
+## Error Handling
+
+- If issue does not exist, inform user
+- If software-architect agent fails, report partial analysis
+- If tea CLI fails, show manual instructions

old/skills/arch-review-repo/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: arch-review-repo
+description: >
+  Perform a full architecture review of the current repository. Analyzes structure,
+  patterns, dependencies, and generates prioritized recommendations. Use when reviewing
+  architecture, auditing codebase, or when user says /arch-review-repo.
+model: opus
+argument-hint:
+context: fork
+user-invocable: true
+---
+
+# Architecture Review
+
+@~/.claude/skills/software-architecture/SKILL.md
+
+## Process
+
+1. **Identify the repository**: Use the current working directory as the repository path.
+
+2. **Spawn the software-architect agent** for deep analysis:
+
+   ```
+   ANALYSIS_TYPE: repo-audit
+   TARGET: <repository-path>
+   CONTEXT: Full repository architecture review
+   ```
+
+   The agent will:
+   - Analyze directory structure and package organization
+   - Identify patterns and anti-patterns in the codebase
+   - Assess dependency graph and module boundaries
+   - Review test coverage approach
+   - Generate structured findings with prioritized recommendations
+
+3. **Present the results** to the user in this format:
+
+   ```markdown
+   ## Repository Architecture Review: <repo-name>
+
+   ### Structure: <Good|Needs Work>
+   - [Key observations about package organization]
+   - [Directory structure assessment]
+   - [Naming conventions evaluation]
+
+   ### Patterns Identified
+   - [Positive patterns found in the codebase]
+   - [Architectural styles detected (layered, hexagonal, etc.)]
+
+   ### Anti-Patterns Detected
+   - [Anti-pattern name]: [Location and description]
+   - [Anti-pattern name]: [Location and description]
+
+   ### Concerns
+   - [Specific issues that need attention]
+   - [Technical debt areas]
+
+   ### Recommendations (prioritized)
+   1. **P0 - Critical**: [Most urgent recommendation]
+   2. **P1 - High**: [Important improvement]
+   3. **P2 - Medium**: [Nice-to-have improvement]
+   4. **P3 - Low**: [Minor optimization]
+
+   ### Health Score: <A|B|C|D|F>
+   [Brief justification for the grade]
+   ```
+
+4. **Offer follow-up actions**:
+   - Create issues for critical findings
+   - Generate a detailed report
+   - Review specific components in more depth
+
+## Guidelines
+
+- Be specific: Reference exact files, packages, and locations
+- Be actionable: Every finding should have a clear path to resolution
+- Be balanced: Acknowledge what the codebase does well
+- Be proportionate: Focus on high-impact issues first
+- Stay objective: Focus on patterns and principles, not style preferences

old/skills/backlog-grooming/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: backlog-grooming
+model: haiku
 description: Review and improve existing issues for clarity and actionability. Use when grooming the backlog, reviewing issue quality, cleaning up stale issues, or when the user wants to improve existing issues.
 user-invocable: false
 ---

old/skills/claude-md-writing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: claude-md-writing
+model: haiku
 description: Write effective CLAUDE.md files that give AI assistants the context they need. Use when creating new repos, improving existing CLAUDE.md files, or setting up projects.
 user-invocable: false
 ---

old/skills/code-review/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: code-review
+model: haiku
 description: Review code for quality, bugs, security, and style issues. Use when reviewing pull requests, checking code quality, looking for bugs or security vulnerabilities, or when the user asks for a code review.
 user-invocable: false
 ---

old/skills/commit/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: commit
+description: >
+  Create a commit with an auto-generated conventional commit message. Analyzes staged
+  changes and proposes a message for approval. Use when committing changes, creating
+  commits, or when user says /commit.
+model: haiku
+argument-hint:
+user-invocable: true
+---
+
+# Commit Changes
+
+## Process
+
+1. **Check for staged changes**:
+   ```bash
+   git diff --staged --stat
+   ```
+
+   If no staged changes, inform the user and suggest staging files first:
+   - Show unstaged changes with `git status`
+   - Ask if they want to stage all changes (`git add -A`) or specific files
+
+2. **Analyze staged changes**:
+   ```bash
+   git diff --staged
+   ```
+
+   Examine the diff to understand:
+   - What files were changed, added, or deleted
+   - The nature of the changes (new feature, bug fix, refactor, docs, etc.)
+   - Key details worth mentioning
+
+3. **Generate commit message**:
+
+   Create a conventional commit message following this format:
+   ```
+   <type>(<scope>): <description>
+
+   [optional body with more details]
+
+   Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+   ```
+
+   **Types:**
+   - `feat`: New feature or capability
+   - `fix`: Bug fix
+   - `refactor`: Code restructuring without behavior change
+   - `docs`: Documentation changes
+   - `style`: Formatting, whitespace (no code change)
+   - `test`: Adding or updating tests
+   - `chore`: Maintenance tasks, dependencies, config
+
+   **Scope:** The component or area affected (optional, use when helpful)
+
+   **Description:**
+   - Imperative mood ("add" not "added")
+   - Lowercase first letter
+   - No period at the end
+   - Focus on the "why" when the "what" is obvious
+
+4. **Present message for approval**:
+
+   Show the proposed message and ask the user to:
+   - **Approve**: Use the message as-is
+   - **Edit**: Let them modify the message
+   - **Regenerate**: Create a new message with different focus
+
+5. **Create the commit**:
+
+   Once approved, execute:
+   ```bash
+   git commit -m "$(cat <<'EOF'
+   <approved message>
+   EOF
+   )"
+   ```
+
+6. **Confirm success**:
+
+   Show the commit result and suggest next steps:
+   - Push to remote: `git push`
+   - Continue working and commit more changes
+
+## Guidelines
+
+- Only commits what's staged (respects partial staging)
+- Never auto-commits without user approval
+- Keep descriptions concise (50 chars or less for first line)
+- Include body for non-obvious changes
+- Always include Co-Authored-By attribution

old/skills/create-issue/SKILL.md

@@ -1,6 +1,11 @@
 ---
-description: Create a new Gitea issue. Can create single issues or batch create from a plan.
+name: create-issue
+description: >
+  Create a new Gitea issue. Can create single issues or batch create from a plan.
+  Use when creating issues, adding tickets, or when user says /create-issue.
+model: haiku
 argument-hint: [title] or "batch"
+user-invocable: true
 ---
 
 # Create Issue(s)

old/skills/create-repo/SKILL.md

@@ -1,7 +1,13 @@
 ---
-description: Create a new repository with standard structure. Scaffolds vision.md, CLAUDE.md, and CI configuration.
+name: create-repo
+description: >
+  Create a new repository with standard structure. Scaffolds vision.md, CLAUDE.md,
+  and CI configuration. Use when creating repos, initializing projects, or when user
+  says /create-repo.
+model: haiku
 argument-hint: <repo-name>
 context: fork
+user-invocable: true
 ---
 
 # Create Repository
@@ -154,7 +160,7 @@ Create a new repository with Flowmade's standard structure.
     - CI workflow template
     - Basic Makefile
 
-    🤖 Generated with [Claude Code](https://claude.com/claude-code)
+    Generated with [Claude Code](https://claude.com/claude-code)
 
     Co-Authored-By: Claude <noreply@anthropic.com>"
 

old/skills/dashboard/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: dashboard
+description: >
+  Show dashboard of open issues, PRs awaiting review, and CI status. Use when
+  checking project status, viewing issues/PRs, or when user says /dashboard.
+model: haiku
+user-invocable: true
+---
+
+# Repository Dashboard
+
+@~/.claude/skills/gitea/SKILL.md
+
+Fetch and display the following sections:
+
+## 1. Open Issues
+
+Run `tea issues` to list all open issues.
+
+Format as a table showing:
+- Number
+- Title
+- Author
+
+## 2. Open Pull Requests
+
+Run `tea pulls` to list all open PRs.
+
+Format as a table showing:
+- Number
+- Title
+- Author
+
+## 3. CI Status (Recent Workflow Runs)
+
+Run `tea actions runs` to list recent workflow runs.
+
+**Output formatting:**
+- Show the most recent 10 workflow runs maximum
+- For each run, display:
+  - Status (use indicators: [SUCCESS], [FAILURE], [RUNNING], [PENDING])
+  - Workflow name
+  - Branch or PR reference
+  - Commit (short SHA)
+  - Triggered time
+
+**Highlighting:**
+- **Highlight failed runs** by prefixing with a warning indicator and ensuring they stand out visually
+- Example: "**[FAILURE]** build - PR #42 - abc1234 - 2h ago"
+
+**Handling repos without CI:**
+- If `tea actions runs` returns "No workflow runs found" or similar, display:
+  "No CI workflows configured for this repository."
+- Do not treat this as an error - simply note it and continue
+
+## Output Format
+
+Present each section with a clear header. Example:
+
+```
+## Open Issues (3)
+
+| #  | Title                  | Author |
+|----|------------------------|--------|
+| 15 | Fix login timeout      | alice  |
+| 12 | Add dark mode          | bob    |
+| 8  | Update documentation   | carol  |
+
+## Open Pull Requests (2)
+
+| #  | Title                  | Author |
+|----|------------------------|--------|
+| 16 | Fix login timeout      | alice  |
+| 14 | Refactor auth module   | bob    |
+
+## CI Status
+
+| Status      | Workflow | Branch/PR   | Commit  | Time    |
+|-------------|----------|-------------|---------|---------|
+| **[FAILURE]** | build    | PR #16      | abc1234 | 2h ago  |
+| [SUCCESS]   | build    | main        | def5678 | 5h ago  |
+| [SUCCESS]   | lint     | main        | def5678 | 5h ago  |
+```
+
+If no CI is configured:
+```
+## CI Status
+
+No CI workflows configured for this repository.
+```

old/skills/groom/SKILL.md

@@ -1,6 +1,12 @@
 ---
-description: Groom and improve issues. Without argument, reviews all open issues. With argument, grooms specific issue.
+name: groom
+description: >
+  Groom and improve issues. Without argument, reviews all open issues. With argument,
+  grooms specific issue. Use when grooming backlog, improving issues, or when user
+  says /groom.
+model: sonnet
 argument-hint: [issue-number]
+user-invocable: true
 ---
 
 # Groom Issues

old/skills/improve/SKILL.md

@@ -1,7 +1,12 @@
 ---
-description: Identify improvement opportunities based on product vision. Analyzes gaps between vision goals and current backlog.
-argument-hint:
+name: improve
+description: >
+  Identify improvement opportunities based on product vision. Analyzes gaps between
+  vision goals and current backlog. Use when analyzing alignment, finding gaps, or
+  when user says /improve.
+model: sonnet
 context: fork
+user-invocable: true
 ---
 
 # Improvement Analysis

old/skills/issue-writing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: issue-writing
+model: haiku
 description: Write clear, actionable issues with proper structure and acceptance criteria. Use when creating issues, writing bug reports, feature requests, or when the user needs help structuring an issue.
 user-invocable: false
 ---

old/skills/manifesto/SKILL.md

@@ -1,6 +1,11 @@
 ---
-description: View and manage the organization manifesto. Shows identity, personas, beliefs, and principles.
-argument-hint:
+name: manifesto
+description: >
+  View and manage the organization manifesto. Shows identity, personas, beliefs,
+  and principles. Use when viewing manifesto, checking organization identity, or
+  when user says /manifesto.
+model: haiku
+user-invocable: true
 ---
 
 # Organization Manifesto

old/skills/plan-issues/SKILL.md

@@ -1,7 +1,13 @@
 ---
-description: Plan and create issues for a feature or improvement. Breaks down work into well-structured issues with vision alignment.
+name: plan-issues
+description: >
+  Plan and create issues for a feature or improvement. Breaks down work into
+  well-structured issues with vision alignment. Use when planning a feature,
+  creating a roadmap, breaking down large tasks, or when user says /plan-issues.
+model: sonnet
 argument-hint: <feature-description>
 context: fork
+user-invocable: true
 ---
 
 # Plan Feature: $1
@@ -16,12 +22,24 @@ context: fork
 3. **Identify job**: Which job to be done does this enable?
 4. **Understand the feature**: Analyze what "$1" involves
 5. **Explore the codebase** if needed to understand context
-6. **Break down** into discrete, actionable issues:
+
+6. **Discovery phase**: Before proposing issues, walk through the user workflow:
+   - Who is the specific user?
+   - What is their goal?
+   - What is their step-by-step workflow to reach that goal?
+   - What exists today?
+   - Where does the workflow break or have gaps?
+   - What's the MVP that delivers value?
+
+   Present this as a workflow walkthrough before proposing any issues.
+
+7. **Break down** into discrete, actionable issues:
+   - Derive issues from the workflow gaps identified in discovery
    - Each issue should be independently completable
    - Clear dependencies between issues
    - Appropriate scope (not too big, not too small)
 
-7. **Present the plan** (include vision alignment if vision exists):
+8. **Present the plan** (include vision alignment if vision exists):
    ```
    ## Proposed Issues for: $1
 
@@ -30,12 +48,15 @@ context: fork
    Supports: [Milestone/Goal name]
 
    1. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: none
 
    2. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: #1
 
    3. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: #1, #2
    ```
 
@@ -45,7 +66,7 @@ context: fork
    - This should be added as a non-goal
    - Proceed anyway (with justification)
 
-8. **Ask for approval** before creating issues
-9. **Create issues** in dependency order (blockers first)
-10. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
-11. **Present summary** with links to created issues and dependency graph
+9. **Ask for approval** before creating issues
+10. **Create issues** in dependency order (blockers first)
+11. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
+12. **Present summary** with links to created issues and dependency graph

old/skills/pr/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: pr
+description: >
+  Create a PR from current branch. Auto-generates title and description from branch
+  name and commits. Use when creating pull requests, submitting changes, or when
+  user says /pr.
+model: haiku
+user-invocable: true
+---
+
+# Create Pull Request
+
+@~/.claude/skills/gitea/SKILL.md
+
+Quick PR creation from current branch - lighter than full `/work-issue` flow for when you're already on a branch with commits.
+
+## Prerequisites
+
+- Current branch is NOT main/master
+- Branch has commits ahead of main
+- Changes have been pushed to origin (or will be pushed)
+
+## Process
+
+### 1. Verify Branch State
+
+```bash
+# Check current branch
+git branch --show-current
+
+# Ensure we're not on main
+# If on main, abort with message: "Cannot create PR from main branch"
+
+# Check for commits ahead of main
+git log main..HEAD --oneline
+```
+
+### 2. Push if Needed
+
+```bash
+# Check if branch is tracking remote
+git status -sb
+
+# If not pushed or behind, push with upstream
+git push -u origin <branch-name>
+```
+
+### 3. Generate PR Title
+
+**Option A: Branch contains issue number** (e.g., `issue-42-add-feature`)
+
+Extract issue number and use format: `[Issue #<number>] <issue-title>`
+
+```bash
+tea issues <number>  # Get the actual issue title
+```
+
+**Option B: No issue number**
+
+Generate from branch name or recent commit messages:
+- Convert branch name from kebab-case to title case: `add-user-auth` -> `Add user auth`
+- Or use the most recent commit subject line
+
+### 4. Generate PR Description
+
+Analyze the diff and commits to generate a description:
+
+```bash
+# Get diff against main
+git diff main...HEAD --stat
+
+# Get commit messages
+git log main..HEAD --format="- %s"
+```
+
+Structure the description:
+
+```markdown
+## Summary
+[1-2 sentences describing the overall change]
+
+## Changes
+[Bullet points summarizing commits or key changes]
+
+[If issue linked: "Closes #<number>"]
+```
+
+### 5. Create PR
+
+Use tea CLI to create the PR:
+
+```bash
+tea pulls create --title "<generated-title>" --description "<generated-description>"
+```
+
+Capture the PR number from the output (e.g., "Pull Request #42 created").
+
+### 6. Auto-review
+
+Inform the user that auto-review is starting, then spawn the `code-reviewer` agent in background:
+
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: true
+  - prompt: |
+      Review PR #<PR_NUMBER> in the repository at <REPO_PATH>.
+
+      1. Checkout the PR: tea pulls checkout <PR_NUMBER>
+      2. Get the diff: git diff main...HEAD
+      3. Analyze for code quality, bugs, security, style, test coverage
+      4. Post structured review comment with tea comment
+      5. Merge with rebase if LGTM, otherwise leave for user
+```
+
+### 7. Display Result
+
+Show the user:
+- PR URL/number
+- Generated title and description
+- Status of auto-review (spawned in background)
+
+## Issue Linking
+
+To detect if branch is linked to an issue:
+
+1. Check branch name for patterns:
+   - `issue-<number>-*`
+   - `<number>-*`
+   - `*-#<number>`
+
+2. If issue number found:
+   - Fetch issue title from Gitea
+   - Use `[Issue #N] <issue-title>` format for PR title
+   - Add `Closes #N` to description
+
+## Example Output
+
+```
+Created PR #42: [Issue #15] Add /pr command
+
+## Summary
+Adds /pr command for quick PR creation from current branch.
+
+## Changes
+- Add commands/pr.md with auto-generation logic
+- Support issue linking from branch name
+
+Closes #15
+
+---
+Auto-review started in background. Check status with: tea pulls 42 --comments
+```

old/skills/repo-conventions/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: repo-conventions
+model: haiku
 description: Standard structure and conventions for Flowmade repositories. Use when creating new repos, reviewing repo structure, or setting up projects.
 user-invocable: false
 ---
@@ -16,8 +17,7 @@ All product repos should follow this structure relative to the architecture repo
 org/
 ├── architecture/           # Organizational source of truth
 │   ├── manifesto.md        # Organization identity and beliefs
-│   ├── commands/           # Claude Code workflows
-│   ├── skills/             # Knowledge modules
+│   ├── skills/             # User-invocable and background skills
 │   └── agents/             # Subtask handlers
 ├── product-a/              # Product repository
 │   ├── vision.md           # Product vision (extends manifesto)

old/skills/retro/SKILL.md

@@ -1,11 +1,17 @@
 ---
-description: Run a retrospective on completed work. Captures insights as issues for later encoding into skills/commands/agents.
+name: retro
+description: >
+  Run a retrospective on completed work. Captures insights as issues for later
+  encoding into skills/agents. Use when capturing learnings, running retrospectives,
+  or when user says /retro.
+model: haiku
 argument-hint: [task-description]
+user-invocable: true
 ---
 
 # Retrospective
 
-Capture insights from completed work as issues on the architecture repo. Issues are later encoded into learnings and skills/commands/agents.
+Capture insights from completed work as issues on the architecture repo. Issues are later encoded into learnings and skills/agents.
 
 @~/.claude/skills/vision-management/SKILL.md
 @~/.claude/skills/gitea/SKILL.md
@@ -13,7 +19,7 @@ Capture insights from completed work as issues on the architecture repo. Issues
 ## Flow
 
 ```
-Retro (any repo) → Issue (architecture repo) → Encode: learning file + skill/command/agent
+Retro (any repo) → Issue (architecture repo) → Encode: learning file + skill/agent
 ```
 
 The retro creates the issue. Encoding happens when the issue is worked on.
@@ -29,7 +35,7 @@ The retro creates the issue. Encoding happens when the issue is worked on.
 
 3. **Identify insights**: For each insight, determine:
    - **What was learned**: The specific insight
-   - **Where to encode it**: Which skill, command, or agent should change?
+   - **Where to encode it**: Which skill or agent should change?
    - **Governance impact**: What does this mean for how we work?
 
 4. **Create issue on architecture repo**: Always create issues on `flowmade-one/architecture`:
@@ -45,7 +51,6 @@ The retro creates the issue. Encoding happens when the issue is worked on.
 
    ## Suggested Encoding
    - [ ] \`skills/xxx/SKILL.md\` - [what to add/change]
-   - [ ] \`commands/xxx.md\` - [what to add/change]
    - [ ] \`agents/xxx/agent.md\` - [what to add/change]
 
    ## Governance
@@ -78,14 +83,13 @@ When encoding a learning issue, the implementer should:
    ## Encoded In
 
    - `skills/xxx/SKILL.md` - [what was added/changed]
-   - `commands/xxx.md` - [what was added/changed]
 
    ## Governance
 
    [What this means for how we work]
    ```
 
-2. **Update skill/command/agent** with the encoded knowledge
+2. **Update skill/agent** with the encoded knowledge
 
 3. **Close the issue** with reference to the learning file and changes made
 
@@ -94,7 +98,7 @@ When encoding a learning issue, the implementer should:
 | Insight Type | Encode In |
 |--------------|-----------|
 | How to use a tool | `skills/[tool]/SKILL.md` |
-| Workflow improvement | `commands/[command].md` |
+| Workflow improvement | `skills/[skill]/SKILL.md` (user-invocable) |
 | Subtask behavior | `agents/[agent]/agent.md` |
 | Organization belief | `manifesto.md` |
 | Product direction | `vision.md` (in product repo) |
@@ -103,8 +107,8 @@ When encoding a learning issue, the implementer should:
 
 Add appropriate labels to issues:
 - `learning` - Always add this
-- `prompt-improvement` - For command/skill text changes
-- `new-feature` - For new commands/skills/agents
+- `prompt-improvement` - For skill text changes
+- `new-feature` - For new skills/agents
 - `bug` - For things that are broken
 
 ## Guidelines

old/skills/review-pr/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: review-pr
+description: >
+  Review a Gitea pull request. Fetches PR details, diff, and comments. Includes
+  both code review and software architecture review. Use when reviewing pull requests,
+  checking code quality, or when user says /review-pr.
+model: sonnet
+argument-hint: <pr-number>
+user-invocable: true
+---
+
+# Review PR #$1
+
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/software-architecture/SKILL.md
+
+## 1. Gather Information
+
+1. **View PR details** with `--comments` flag to see description, metadata, and discussion
+2. **Get the diff** to review the changes:
+   ```bash
+   tea pulls checkout <number>
+   git diff main...HEAD
+   ```
+
+## 2. Code Review
+
+Review the changes and provide feedback on:
+- Code quality and style
+- Potential bugs or logic errors
+- Test coverage
+- Documentation updates
+
+## 3. Software Architecture Review
+
+Spawn the software-architect agent for architectural analysis:
+
+```
+Task tool with:
+  - subagent_type: "software-architect"
+  - prompt: |
+      ANALYSIS_TYPE: pr-review
+      TARGET: <pr-number>
+      CONTEXT: [Include the PR diff and description]
+```
+
+The architecture review checks:
+- **Pattern consistency**: Changes follow existing codebase patterns
+- **Dependency direction**: Dependencies flow correctly (toward domain layer)
+- **Breaking changes**: API changes are flagged and justified
+- **Module boundaries**: Changes respect existing package boundaries
+- **Error handling**: Errors wrapped with context, proper error types used
+
+## 4. Present Findings
+
+Structure the review with two sections:
+
+### Code Review
+- Quality, bugs, style issues
+- Test coverage gaps
+- Documentation needs
+
+### Architecture Review
+- Summary of architectural concerns from agent
+- Pattern violations or anti-patterns detected
+- Dependency or boundary issues
+- Breaking change assessment
+
+## 5. User Actions
+
+Ask the user what action to take:
+- **Merge**: Post review summary as comment, then merge with rebase style
+- **Request changes**: Leave feedback without merging
+- **Comment only**: Add a comment for discussion
+
+## Merging
+
+Always use tea CLI for merges to preserve user attribution:
+
+```bash
+tea pulls merge <number> --style rebase
+```
+
+For review comments, use `tea comment` since `tea pulls review` is interactive-only:
+
+```bash
+tea comment <number> "<review summary>"
+```
+
+> **Warning**: Never use the Gitea API with admin credentials for user-facing operations like merging. This causes the merge to be attributed to the admin account instead of the user.

old/skills/roadmap-planning/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: roadmap-planning
+model: haiku
 description: Plan features and break down work into implementable issues. Use when planning a feature, creating a roadmap, breaking down large tasks, or when the user needs help organizing work into issues.
 user-invocable: false
 ---
@@ -15,7 +16,33 @@ How to plan features and create issues for implementation.
 - Who benefits and how?
 - What's the success criteria?
 
-### 2. Break Down the Work
+### 2. Discovery Phase
+
+Before breaking down work into issues, understand the user's workflow:
+
+| Question | Why It Matters |
+|----------|----------------|
+| **Who** is the user? | Specific persona, not "users" |
+| **What's their goal?** | The job they're trying to accomplish |
+| **What's their workflow?** | Step-by-step actions to reach the goal |
+| **What exists today?** | Current state and gaps |
+| **What's the MVP?** | Minimum to deliver value |
+
+**Walk through the workflow step by step:**
+1. User starts at: [starting point]
+2. User does: [action 1]
+3. System responds: [what happens]
+4. User does: [action 2]
+5. ... continue until goal is reached
+
+**Identify the gaps:**
+- Where does the workflow break today?
+- Which steps are missing or painful?
+- What's the smallest change that unblocks value?
+
+**Derive issues from workflow gaps** - not from guessing what might be needed. Each issue should address a specific gap in the user's workflow.
+
+### 3. Break Down the Work
 - Identify distinct components
 - Define boundaries between pieces
 - Aim for issues that are:
@@ -23,12 +50,12 @@ How to plan features and create issues for implementation.
   - Independently testable
   - Clear in scope
 
-### 3. Identify Dependencies
+### 4. Identify Dependencies
 - Which pieces must come first?
 - What can be parallelized?
 - Are there external blockers?
 
-### 4. Create Issues
+### 5. Create Issues
 - Follow issue-writing patterns
 - Reference dependencies explicitly
 - Use consistent labeling

old/skills/roadmap/SKILL.md

@@ -1,6 +1,11 @@
 ---
-description: View current issues as a roadmap. Shows open issues organized by status and dependencies.
-argument-hint:
+name: roadmap
+description: >
+  View current issues as a roadmap. Shows open issues organized by status and
+  dependencies. Use when viewing roadmap, checking issue status, or when user
+  says /roadmap.
+model: haiku
+user-invocable: true
 ---
 
 # Roadmap View

old/skills/software-architecture/SKILL.md

@@ -0,0 +1,633 @@
+---
+name: software-architecture
+model: haiku
+description: >
+  Architectural patterns for building systems: DDD, Event Sourcing, event-driven communication.
+  Use when implementing features, reviewing code, planning issues, refining architecture,
+  or making design decisions. Ensures alignment with organizational beliefs about
+  auditability, domain modeling, and independent evolution.
+user-invocable: false
+---
+
+# Software Architecture
+
+Architectural patterns and best practices. This skill is auto-triggered when implementing, reviewing, or planning work that involves architectural decisions.
+
+## Architecture Beliefs
+
+These outcome-focused beliefs (from our organization manifesto) guide architectural decisions:
+
+| Belief | Why It Matters |
+|--------|----------------|
+| **Auditability by default** | Systems should remember what happened, not just current state |
+| **Business language in code** | Domain experts' words should appear in the codebase |
+| **Independent evolution** | Parts should change without breaking other parts |
+| **Explicit over implicit** | Intent and side effects should be visible and traceable |
+
+## Beliefs → Patterns
+
+| Belief | Primary Pattern | Supporting Patterns |
+|--------|-----------------|---------------------|
+| Auditability by default | Event Sourcing | Immutable events, temporal queries |
+| Business language in code | Domain-Driven Design | Ubiquitous language, aggregates, bounded contexts |
+| Independent evolution | Event-driven communication | Bounded contexts, published language |
+| Explicit over implicit | Commands and Events | Domain events, clear intent |
+
+## Event Sourcing
+
+**Achieves:** Auditability by default
+
+Instead of storing current state, store the sequence of events that led to it.
+
+**Core concepts:**
+- **Events** are immutable facts about what happened, named in past tense: `OrderPlaced`, `PaymentReceived`
+- **State** is derived by replaying events, not stored directly
+- **Event store** is append-only - history is never modified
+
+**Why this matters:**
+- Complete audit trail for free
+- Debug by replaying history
+- Answer "what was the state at time X?"
+- Recover from bugs by fixing logic and replaying
+
+**Trade-offs:**
+- More complex than CRUD for simple cases
+- Requires thinking in events, not state
+- Eventually consistent read models
+
+## Domain-Driven Design
+
+**Achieves:** Business language in code
+
+The domain model reflects how the business thinks and talks.
+
+**Core concepts:**
+- **Ubiquitous language** - same terms in code, conversations, and documentation
+- **Bounded contexts** - explicit boundaries where terms have consistent meaning
+- **Aggregates** - clusters of objects that change together, with one root entity
+- **Domain events** - capture what happened in business terms
+
+**Why this matters:**
+- Domain experts can read and validate the model
+- New team members learn the domain through code
+- Changes in business rules map clearly to code changes
+
+**Trade-offs:**
+- Upfront investment in understanding the domain
+- Boundaries may need to shift as understanding grows
+- Overkill for pure technical/infrastructure code
+
+## Event-Driven Communication
+
+**Achieves:** Independent evolution
+
+Services communicate by publishing events, not calling each other directly.
+
+**Core concepts:**
+- **Publish events** when something important happens
+- **Subscribe to events** you care about
+- **No direct dependencies** between publisher and subscriber
+- **Eventual consistency** - accept that not everything updates instantly
+
+**Why this matters:**
+- Add new services without changing existing ones
+- Services can be deployed independently
+- Natural resilience - if a subscriber is down, events queue
+
+**Trade-offs:**
+- Harder to trace request flow
+- Eventual consistency requires different thinking
+- Need infrastructure for reliable event delivery
+
+## Commands and Events
+
+**Achieves:** Explicit over implicit
+
+Distinguish between requests (commands) and facts (events).
+
+**Core concepts:**
+- **Commands** express intent: `PlaceOrder`, `CancelSubscription`
+- Commands can be rejected (validation, business rules)
+- **Events** express facts: `OrderPlaced`, `SubscriptionCancelled`
+- Events are immutable - what happened, happened
+
+**Why this matters:**
+- Clear separation of "trying to do X" vs "X happened"
+- Commands validate, events just record
+- Enables replay - reprocess events with new logic
+
+## When to Diverge
+
+These patterns are defaults, not mandates. Diverge intentionally when:
+
+- **Simplicity wins** - a simple CRUD endpoint doesn't need event sourcing
+- **Performance requires it** - sometimes synchronous calls are necessary
+- **Team context** - patterns the team doesn't understand cause more harm than good
+- **Prototyping** - validate ideas before investing in full architecture
+
+When diverging, document the decision in the project's `vision.md` Architecture section.
+
+## Project-Level Architecture
+
+Each project documents architectural choices in `vision.md`:
+
+```markdown
+## Architecture
+
+This project follows organization architecture patterns.
+
+### Alignment
+- Event sourcing for [which aggregates/domains]
+- Bounded contexts: [list contexts and their responsibilities]
+- Event-driven communication between [which services]
+
+### Intentional Divergences
+| Area | Standard Pattern | What We Do Instead | Why |
+|------|------------------|-------------------|-----|
+```
+
+## Go-Specific Best Practices
+
+### Package Organization
+
+**Good package structure:**
+```
+project/
+├── cmd/                    # Application entry points
+│   └── server/
+│       └── main.go
+├── internal/               # Private packages
+│   ├── domain/             # Core business logic
+│   │   ├── user/
+│   │   └── order/
+│   ├── service/            # Application services
+│   ├── repository/         # Data access
+│   └── handler/            # HTTP/gRPC handlers
+├── pkg/                    # Public, reusable packages
+└── go.mod
+```
+
+**Package naming:**
+- Short, concise, lowercase: `user`, `order`, `auth`
+- Avoid generic names: `util`, `common`, `helpers`, `misc`
+- Name after what it provides, not what it contains
+- One package per concept, not per file
+
+**Package cohesion:**
+- A package should have a single, focused responsibility
+- Package internal files can use internal types freely
+- Minimize exported types - export interfaces, hide implementations
+
+### Interfaces
+
+**Accept interfaces, return structs:**
+```go
+// Good: Accept interface, return concrete type
+func NewUserService(repo UserRepository) *UserService {
+    return &UserService{repo: repo}
+}
+
+// Bad: Accept and return interface
+func NewUserService(repo UserRepository) UserService {
+    return &userService{repo: repo}
+}
+```
+
+**Define interfaces at point of use:**
+```go
+// Good: Interface defined where it's used (consumer owns the interface)
+package service
+
+type UserRepository interface {
+    FindByID(ctx context.Context, id string) (*User, error)
+}
+
+// Bad: Interface defined with implementation (producer owns the interface)
+package repository
+
+type UserRepository interface {
+    FindByID(ctx context.Context, id string) (*User, error)
+}
+```
+
+**Keep interfaces small:**
+- Prefer single-method interfaces
+- Large interfaces indicate missing abstraction
+- Compose small interfaces when needed
+
+### Error Handling
+
+**Wrap errors with context:**
+```go
+// Good: Wrap with context
+if err != nil {
+    return fmt.Errorf("fetching user %s: %w", id, err)
+}
+
+// Bad: Return bare error
+if err != nil {
+    return err
+}
+```
+
+**Use sentinel errors for expected conditions:**
+```go
+var ErrNotFound = errors.New("not found")
+var ErrConflict = errors.New("conflict")
+
+// Check with errors.Is
+if errors.Is(err, ErrNotFound) {
+    // handle not found
+}
+```
+
+**Error types for rich errors:**
+```go
+type ValidationError struct {
+    Field   string
+    Message string
+}
+
+func (e *ValidationError) Error() string {
+    return fmt.Sprintf("%s: %s", e.Field, e.Message)
+}
+
+// Check with errors.As
+var valErr *ValidationError
+if errors.As(err, &valErr) {
+    // handle validation error
+}
+```
+
+### Dependency Injection
+
+**Constructor injection:**
+```go
+type UserService struct {
+    repo   UserRepository
+    logger Logger
+}
+
+func NewUserService(repo UserRepository, logger Logger) *UserService {
+    return &UserService{
+        repo:   repo,
+        logger: logger,
+    }
+}
+```
+
+**Wire dependencies in main:**
+```go
+func main() {
+    // Create dependencies
+    db := database.Connect()
+    logger := slog.Default()
+
+    // Wire up services
+    userRepo := repository.NewUserRepository(db)
+    userService := service.NewUserService(userRepo, logger)
+    userHandler := handler.NewUserHandler(userService)
+
+    // Start server
+    http.Handle("/users", userHandler)
+    http.ListenAndServe(":8080", nil)
+}
+```
+
+**Avoid global state:**
+- No `init()` for service initialization
+- No package-level variables for dependencies
+- Pass context explicitly, don't store in structs
+
+### Testing
+
+**Table-driven tests:**
+```go
+func TestUserService_Create(t *testing.T) {
+    tests := []struct {
+        name    string
+        input   CreateUserInput
+        want    *User
+        wantErr error
+    }{
+        {
+            name:  "valid user",
+            input: CreateUserInput{Email: "test@example.com"},
+            want:  &User{Email: "test@example.com"},
+        },
+        {
+            name:    "invalid email",
+            input:   CreateUserInput{Email: "invalid"},
+            wantErr: ErrInvalidEmail,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            // arrange, act, assert
+        })
+    }
+}
+```
+
+**Test doubles:**
+- Use interfaces for test doubles
+- Prefer hand-written mocks over generated ones for simple cases
+- Use `testify/mock` or `gomock` for complex mocking needs
+
+**Test package naming:**
+- `package user_test` for black-box testing (preferred)
+- `package user` for white-box testing when needed
+
+## Generic Architecture Patterns
+
+### Layered Architecture
+
+```
+┌─────────────────────────────────┐
+│         Presentation            │  HTTP handlers, CLI, gRPC
+├─────────────────────────────────┤
+│         Application             │  Use cases, orchestration
+├─────────────────────────────────┤
+│           Domain                │  Business logic, entities
+├─────────────────────────────────┤
+│        Infrastructure           │  Database, external services
+└─────────────────────────────────┘
+```
+
+**Rules:**
+- Dependencies point downward only
+- Upper layers depend on interfaces, not implementations
+- Domain layer has no external dependencies
+
+### SOLID Principles
+
+**Single Responsibility (S):**
+- Each module has one reason to change
+- Split code that changes for different reasons
+
+**Open/Closed (O):**
+- Open for extension, closed for modification
+- Add new behavior through new types, not changing existing ones
+
+**Liskov Substitution (L):**
+- Subtypes must be substitutable for their base types
+- Interfaces should be implementable without surprises
+
+**Interface Segregation (I):**
+- Clients shouldn't depend on interfaces they don't use
+- Prefer many small interfaces over few large ones
+
+**Dependency Inversion (D):**
+- High-level modules shouldn't depend on low-level modules
+- Both should depend on abstractions
+
+### Dependency Direction
+
+```
+                    ┌──────────────┐
+                    │    Domain    │
+                    │  (no deps)   │
+                    └──────────────┘
+                           ▲
+              ┌────────────┴────────────┐
+              │                         │
+      ┌───────┴───────┐         ┌───────┴───────┐
+      │  Application  │         │Infrastructure │
+      │ (uses domain) │         │(implements    │
+      └───────────────┘         │ domain intf)  │
+              ▲                 └───────────────┘
+              │
+      ┌───────┴───────┐
+      │ Presentation  │
+      │(calls app)    │
+      └───────────────┘
+```
+
+**Key insight:** Infrastructure implements domain interfaces, doesn't define them. This inverts the "natural" dependency direction.
+
+### Module Boundaries
+
+**Signs of good boundaries:**
+- Modules can be understood in isolation
+- Changes are localized within modules
+- Clear, minimal public API
+- Dependencies flow in one direction
+
+**Signs of bad boundaries:**
+- Circular dependencies between modules
+- "Shotgun surgery" - small changes require many file edits
+- Modules reach into each other's internals
+- Unclear ownership of concepts
+
+## Repository Health Indicators
+
+### Positive Indicators
+
+| Indicator | What to Look For |
+|-----------|------------------|
+| Clear structure | Obvious package organization, consistent naming |
+| Small interfaces | Most interfaces have 1-3 methods |
+| Explicit dependencies | Constructor injection, no globals |
+| Test coverage | Unit tests for business logic, integration tests for boundaries |
+| Error handling | Wrapped errors, typed errors for expected cases |
+| Documentation | CLAUDE.md accurate, code comments explain "why" |
+
+### Warning Signs
+
+| Indicator | What to Look For |
+|-----------|------------------|
+| God packages | `utils/`, `common/`, `helpers/` with 20+ files |
+| Circular deps | Package A imports B, B imports A |
+| Deep nesting | 4+ levels of directory nesting |
+| Huge files | Files with 500+ lines |
+| Interface pollution | Interfaces for everything, even single implementations |
+| Global state | Package-level variables, `init()` for setup |
+
+### Metrics to Track
+
+- **Package fan-out:** How many packages does each package import?
+- **Cyclomatic complexity:** How complex are the functions?
+- **Test coverage:** What percentage of code is tested?
+- **Import depth:** How deep is the import tree?
+
+## Review Checklists
+
+### Repository Audit Checklist
+
+Use this when evaluating overall repository health.
+
+**Structure:**
+- [ ] Clear package organization following Go conventions
+- [ ] No circular dependencies between packages
+- [ ] Appropriate use of `internal/` for private packages
+- [ ] `cmd/` for application entry points
+
+**Dependencies:**
+- [ ] Dependencies flow inward (toward domain)
+- [ ] Interfaces defined at point of use (not with implementation)
+- [ ] No global state or package-level dependencies
+- [ ] Constructor injection throughout
+
+**Code Quality:**
+- [ ] Consistent naming conventions
+- [ ] No "god" packages (utils, common, helpers)
+- [ ] Errors wrapped with context
+- [ ] Small, focused interfaces
+
+**Testing:**
+- [ ] Unit tests for domain logic
+- [ ] Integration tests for boundaries (DB, HTTP)
+- [ ] Tests are readable and maintainable
+- [ ] Test coverage for critical paths
+
+**Documentation:**
+- [ ] CLAUDE.md is accurate and helpful
+- [ ] vision.md explains the product purpose
+- [ ] Code comments explain "why", not "what"
+
+### Issue Refinement Checklist
+
+Use this when reviewing issues for architecture impact.
+
+**Scope:**
+- [ ] Issue is a vertical slice (user-visible value)
+- [ ] Changes are localized to specific packages
+- [ ] No cross-cutting concerns hidden in implementation
+
+**Design:**
+- [ ] Follows existing patterns in the codebase
+- [ ] New abstractions are justified
+- [ ] Interface changes are backward compatible (or breaking change is documented)
+
+**Dependencies:**
+- [ ] New dependencies are minimal and justified
+- [ ] No new circular dependencies introduced
+- [ ] Integration points are clearly defined
+
+**Testability:**
+- [ ] Acceptance criteria are testable
+- [ ] New code can be unit tested in isolation
+- [ ] Integration test requirements are clear
+
+### PR Review Checklist
+
+Use this when reviewing pull requests for architecture concerns.
+
+**Structure:**
+- [ ] Changes respect existing package boundaries
+- [ ] New packages follow naming conventions
+- [ ] No new circular dependencies
+
+**Interfaces:**
+- [ ] Interfaces are defined where used
+- [ ] Interfaces are minimal and focused
+- [ ] Breaking interface changes are justified
+
+**Dependencies:**
+- [ ] Dependencies injected via constructors
+- [ ] No new global state
+- [ ] External dependencies properly abstracted
+
+**Error Handling:**
+- [ ] Errors wrapped with context
+- [ ] Sentinel errors for expected conditions
+- [ ] Error types for rich error information
+
+**Testing:**
+- [ ] New code has appropriate test coverage
+- [ ] Tests are clear and maintainable
+- [ ] Edge cases covered
+
+## Anti-Patterns to Flag
+
+### God Packages
+
+**Problem:** Packages like `utils/`, `common/`, `helpers/` become dumping grounds.
+
+**Symptoms:**
+- 20+ files in one package
+- Unrelated functions grouped together
+- Package imported by everything
+
+**Fix:** Extract cohesive packages based on what they provide: `validation`, `httputil`, `timeutil`.
+
+### Circular Dependencies
+
+**Problem:** Package A imports B, and B imports A (directly or transitively).
+
+**Symptoms:**
+- Import cycle compile errors
+- Difficulty understanding code flow
+- Changes cascade unexpectedly
+
+**Fix:**
+- Extract shared types to a third package
+- Use interfaces to invert dependency
+- Merge packages if truly coupled
+
+### Leaky Abstractions
+
+**Problem:** Implementation details leak through abstraction boundaries.
+
+**Symptoms:**
+- Database types in domain layer
+- HTTP types in service layer
+- Framework types in business logic
+
+**Fix:** Define types at each layer, map between them explicitly.
+
+### Anemic Domain Model
+
+**Problem:** Domain objects are just data containers, logic is elsewhere.
+
+**Symptoms:**
+- Domain types have only getters/setters
+- All logic in "service" classes
+- Domain types can be in invalid states
+
+**Fix:** Put behavior with data. Domain types should enforce their own invariants.
+
+### Shotgun Surgery
+
+**Problem:** Small changes require editing many files across packages.
+
+**Symptoms:**
+- Feature adds touch 10+ files
+- Similar changes in multiple places
+- Copy-paste between packages
+
+**Fix:** Consolidate related code. If things change together, they belong together.
+
+### Feature Envy
+
+**Problem:** Code in one package is more interested in another package's data.
+
+**Symptoms:**
+- Many calls to another package's methods
+- Pulling data just to compute something
+- Logic that belongs elsewhere
+
+**Fix:** Move the code to where the data lives, or extract the behavior to a shared place.
+
+### Premature Abstraction
+
+**Problem:** Creating interfaces and abstractions before they're needed.
+
+**Symptoms:**
+- Interfaces with single implementations
+- "Factory" and "Manager" classes everywhere
+- Configuration for things that never change
+
+**Fix:** Write concrete code first. Extract abstractions when you have multiple implementations or need to break dependencies.
+
+### Deep Hierarchy
+
+**Problem:** Excessive layers of abstraction or inheritance.
+
+**Symptoms:**
+- 5+ levels of embedding/composition
+- Hard to trace code flow
+- Changes require understanding many layers
+
+**Fix:** Prefer composition over inheritance. Flatten hierarchies where possible.

old/skills/spawn-issues/SKILL.md

@@ -0,0 +1,349 @@
+---
+name: spawn-issues
+description: Orchestrate parallel issue implementation with review cycles
+model: haiku
+argument-hint: <issue-number> [<issue-number>...]
+allowed-tools: Bash, Task, Read, TaskOutput
+user-invocable: true
+---
+
+# Spawn Issues (Orchestrator)
+
+Orchestrate parallel issue implementation: spawn workers, review PRs, fix feedback, until all approved.
+
+## Arguments
+
+One or more issue numbers separated by spaces: `$ARGUMENTS`
+
+Example: `/spawn-issues 42 43 44`
+
+## Orchestration Flow
+
+```
+Concurrent Pipeline - each issue flows independently:
+
+  Issue #42 ──► worker ──► PR #55 ──► review ──► fix? ──► ✓
+  Issue #43 ──► worker ──► PR #56 ──► review ──► ✓
+  Issue #44 ──► worker ──► PR #57 ──► review ──► fix ──► ✓
+
+As each step completes, immediately:
+1. Print a status update
+2. Start the next step for that issue
+
+Don't wait for all workers before reviewing - pipeline each issue.
+```
+
+## Status Updates
+
+Print a brief status update whenever any step completes:
+
+```
+[#42] Worker completed → PR #55 created
+[#43] Worker completed → PR #56 created
+[#42] Review: needs work → spawning fixer
+[#43] Review: approved ✓
+[#42] Fix completed → re-reviewing
+[#44] Worker completed → PR #57 created
+[#42] Review: approved ✓
+[#44] Review: approved ✓
+
+All done! Final summary:
+| Issue | PR  | Status   |
+|-------|-----|----------|
+| #42   | #55 | approved |
+| #43   | #56 | approved |
+| #44   | #57 | approved |
+```
+
+## Implementation
+
+### Step 1: Parse and Validate
+
+Parse `$ARGUMENTS` into a list of issue numbers. If empty, inform the user:
+```
+Usage: /spawn-issues <issue-number> [<issue-number>...]
+Example: /spawn-issues 42 43 44
+```
+
+### Step 2: Get Repository Info and Setup Worktrees
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename $REPO_PATH)
+
+# Create parent worktrees directory
+mkdir -p "${REPO_PATH}/../worktrees"
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+```
+
+For each issue, create the worktree upfront:
+```bash
+# Fetch latest from origin
+cd "${REPO_PATH}"
+git fetch origin
+
+# Get issue details for branch naming
+ISSUE_TITLE=$(tea issues <ISSUE_NUMBER> | grep "TITLE" | head -1)
+BRANCH_NAME="issue-<ISSUE_NUMBER>-<kebab-title>"
+
+# Create worktree for this issue
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-issue-<ISSUE_NUMBER>" \
+  -b "${BRANCH_NAME}" origin/main
+```
+
+Track the worktree path for each issue.
+
+### Step 3: Spawn All Issue Workers
+
+For each issue number, spawn a background issue-worker agent and track its task_id:
+
+```
+Task tool with:
+  - subagent_type: "issue-worker"
+  - run_in_background: true
+  - prompt: <issue-worker prompt below>
+```
+
+Track state for each issue:
+```
+issues = {
+  42: { task_id: "xxx", stage: "implementing", pr: null, branch: null, review_iterations: 0 },
+  43: { task_id: "yyy", stage: "implementing", pr: null, branch: null, review_iterations: 0 },
+  44: { task_id: "zzz", stage: "implementing", pr: null, branch: null, review_iterations: 0 },
+}
+```
+
+Print initial status:
+```
+Spawned 3 issue workers:
+  [#42] implementing...
+  [#43] implementing...
+  [#44] implementing...
+```
+
+**Issue Worker Prompt:**
+```
+You are an issue-worker agent. Implement issue #<NUMBER> autonomously.
+
+Context:
+- Repository path: <REPO_PATH>
+- Repository name: <REPO_NAME>
+- Issue number: <NUMBER>
+- Worktree path: <WORKTREE_PATH>
+
+Process:
+1. Setup worktree:
+   cd <WORKTREE_PATH>
+
+2. Get issue: tea issues <NUMBER> --comments
+
+3. Plan with TodoWrite, implement the changes
+
+4. Commit: git add -A && git commit -m "...\n\nCloses #<NUMBER>\n\nCo-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+
+5. Push: git push -u origin <branch-name>
+
+6. Create PR: tea pulls create --title "[Issue #<NUMBER>] <title>" --description "Closes #<NUMBER>\n\n..."
+   Capture the PR number.
+
+7. Cleanup: No cleanup needed - orchestrator handles worktree removal
+
+8. Output EXACTLY this format (orchestrator parses it):
+   ISSUE_WORKER_RESULT
+   issue: <NUMBER>
+   pr: <PR_NUMBER>
+   branch: <branch-name>
+   status: <success|partial|failed>
+   title: <issue title>
+   summary: <1-2 sentence description>
+
+Work autonomously. If blocked, note it in PR description and report status as partial/failed.
+```
+
+### Step 4: Event-Driven Pipeline
+
+**Do NOT poll.** Wait for `<task-notification>` messages that arrive automatically when background tasks complete.
+
+When a notification arrives:
+1. Read the output file to get the result
+2. Parse the result and print status update
+3. Spawn the next stage (reviewer/fixer) in background
+4. Continue waiting for more notifications
+
+```
+On <task-notification> for task_id X:
+  - Find which issue this task belongs to
+  - Read output file, parse result
+  - Print status update
+  - If not terminal state, spawn next agent in background
+  - Update issue state
+  - If all issues terminal, print final summary
+```
+
+**State transitions:**
+
+```
+implementing → (worker done) → reviewing → (approved) → DONE
+                             → (needs-work) → fixing → reviewing...
+                             → (3 iterations) → needs-manual-review
+           → (worker failed) → FAILED
+```
+
+**On each notification, print status:**
+
+```
+[#42] Worker completed → PR #55 created, starting review
+[#43] Worker completed → PR #56 created, starting review
+[#42] Review: needs work → spawning fixer
+[#43] Review: approved ✓
+[#42] Fix completed → re-reviewing
+[#44] Worker completed → PR #57 created, starting review
+[#42] Review: approved ✓
+[#44] Review: approved ✓
+```
+
+### Step 5: Spawn Reviewers and Fixers
+
+When spawning reviewers/fixers, create worktrees for them and pass the path.
+
+For review, create a review worktree from the PR branch:
+```bash
+cd "${REPO_PATH}"
+git fetch origin
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-review-<PR_NUMBER>" \
+  origin/<BRANCH_NAME>
+```
+
+Pass this worktree path to the reviewer/fixer agents.
+
+**Code Reviewer:**
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: true
+  - prompt: <code-reviewer prompt below>
+```
+
+**Code Reviewer Prompt:**
+```
+You are a code-reviewer agent. Review PR #<PR_NUMBER> autonomously.
+
+Context:
+- Repository path: <REPO_PATH>
+- PR number: <PR_NUMBER>
+- Worktree path: <WORKTREE_PATH>
+
+Process:
+1. Move to worktree:
+   cd <WORKTREE_PATH>
+
+2. Get PR details: tea pulls <PR_NUMBER> --comments
+
+3. Review the diff: git diff origin/main...HEAD
+
+4. Analyze changes for:
+   - Code quality and style
+   - Potential bugs or logic errors
+   - Test coverage
+   - Documentation
+
+5. Post review comment: tea comment <PR_NUMBER> "<review summary>"
+
+6. Cleanup: No cleanup needed - orchestrator handles worktree removal
+
+7. Output EXACTLY this format:
+   REVIEW_RESULT
+   pr: <PR_NUMBER>
+   verdict: <approved|needs-work>
+   summary: <1-2 sentences>
+
+Work autonomously. Be constructive but thorough.
+```
+
+**PR Fixer Prompt:** (see below)
+
+### Step 6: Final Report
+
+When all issues reach terminal state, display summary:
+
+```
+All done!
+
+| Issue | PR  | Status              |
+|-------|-----|---------------------|
+| #42   | #55 | approved            |
+| #43   | #56 | approved            |
+| #44   | #57 | approved            |
+
+3 PRs created and approved
+```
+
+## PR Fixer
+
+When spawning pr-fixer for a PR that needs work:
+
+```
+Task tool with:
+  - subagent_type: "pr-fixer"
+  - run_in_background: true
+  - prompt: <pr-fixer prompt below>
+```
+
+**PR Fixer Prompt:**
+```
+You are a pr-fixer agent. Address review feedback on PR #<NUMBER>.
+
+Context:
+- Repository path: <REPO_PATH>
+- PR number: <NUMBER>
+- Worktree path: <WORKTREE_PATH>
+
+Process:
+1. Move to worktree:
+   cd <WORKTREE_PATH>
+
+2. Get feedback: tea pulls <NUMBER> --comments
+
+3. Address each piece of feedback
+
+4. Commit and push:
+   git add -A && git commit -m "Address review feedback\n\nCo-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+   git push
+
+5. Cleanup: No cleanup needed - orchestrator handles worktree removal
+
+6. Output EXACTLY:
+   PR_FIXER_RESULT
+   pr: <NUMBER>
+   status: <fixed|partial|failed>
+   changes: <summary of fixes>
+
+Work autonomously. If feedback is unclear, make reasonable judgment calls.
+```
+
+## Worktree Cleanup
+
+After all issues reach terminal state, clean up all worktrees:
+
+```bash
+# Remove all worktrees created for this run
+for worktree in "${WORKTREES_DIR}"/*; do
+  if [ -d "$worktree" ]; then
+    cd "${REPO_PATH}"
+    git worktree remove "$worktree" --force
+  fi
+done
+
+# Remove worktrees directory if empty
+rmdir "${WORKTREES_DIR}" 2>/dev/null || true
+```
+
+**Important:** Always clean up worktrees, even if the orchestration failed partway through.
+
+## Error Handling
+
+- If an issue-worker fails, continue with others
+- If a review fails, mark as "review-failed" and continue
+- If pr-fixer fails after 3 iterations, mark as "needs-manual-review"
+- Always report final status even if some items failed
+- Always clean up all worktrees before exiting

old/skills/spawn-pr-fixes/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: spawn-pr-fixes
+description: Spawn parallel background agents to address PR review feedback
+model: haiku
+argument-hint: [pr-number...]
+allowed-tools: Bash, Task, Read
+user-invocable: true
+---
+
+# Spawn PR Fixes
+
+Spawn background agents to address review feedback on multiple PRs in parallel. Each agent works in an isolated git worktree.
+
+## Arguments
+
+Optional PR numbers separated by spaces: `$ARGUMENTS`
+
+- With arguments: `/spawn-pr-fixes 12 15 18` - fix specific PRs
+- Without arguments: `/spawn-pr-fixes` - find and fix all PRs with requested changes
+
+## Process
+
+### Step 1: Get Repository Info
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename $REPO_PATH)
+```
+
+### Step 2: Determine PRs to Fix
+
+**If PR numbers provided**: Use those directly
+
+**If no arguments**: Find PRs needing work
+```bash
+# List open PRs
+tea pulls --state open
+
+# For each PR, check if it has review comments requesting changes
+tea pulls <number> --comments
+```
+
+Look for PRs where:
+- Review comments exist that haven't been addressed
+- PR is not approved yet
+- PR is open (not merged/closed)
+
+### Step 3: For Each PR
+
+1. Fetch PR title using `tea pulls <number>`
+
+2. Spawn background agent using Task tool:
+   ```
+   Task tool with:
+     - subagent_type: "pr-fixer"
+     - run_in_background: true
+     - prompt: See agent prompt below
+   ```
+
+### Agent Prompt
+
+For each PR, use this prompt:
+
+```
+You are a pr-fixer agent. Address review feedback on PR #<NUMBER> autonomously.
+
+Context:
+- Repository path: <REPO_PATH>
+- Repository name: <REPO_NAME>
+- PR number: <NUMBER>
+
+Instructions from @agents/pr-fixer/agent.md:
+
+1. Get PR details and review comments:
+   cd <REPO_PATH>
+   git fetch origin
+   tea pulls <NUMBER> --comments
+
+2. Setup worktree from PR branch:
+   git worktree add ../<REPO_NAME>-pr-<NUMBER> origin/<branch-name>
+   cd ../<REPO_NAME>-pr-<NUMBER>
+   git checkout <branch-name>
+
+3. Analyze feedback, create todos with TodoWrite
+
+4. Address each piece of feedback
+
+5. Commit and push:
+   git add -A && git commit with message "Address review feedback\n\n...\n\nCo-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+   git push
+
+6. Spawn code-reviewer synchronously (NOT in background) to re-review
+
+7. If needs more work, fix and re-review (max 3 iterations)
+
+8. Cleanup (ALWAYS do this):
+   cd <REPO_PATH> && git worktree remove ../<REPO_NAME>-pr-<NUMBER> --force
+
+9. Output concise summary (5-10 lines max):
+   PR #<NUMBER>: <title>
+   Status: <fixed|partial|blocked>
+   Feedback addressed: <count> items
+   Review: <approved|needs-work|skipped>
+
+Work autonomously. Make judgment calls on ambiguous feedback. If blocked, note it in a commit message.
+```
+
+### Step 4: Report
+
+After spawning all agents, display:
+
+```
+Spawned <N> pr-fixer agents:
+
+| PR  | Title                    | Status     |
+|-----|--------------------------|------------|
+| #12 | Add /commit command      | spawned    |
+| #15 | Add /pr command          | spawned    |
+| #18 | Add CI status            | spawned    |
+
+Agents working in background. Monitor with:
+- Check PR list: tea pulls
+- Check worktrees: git worktree list
+```

old/skills/update-claude-md/SKILL.md

@@ -1,7 +1,12 @@
 ---
-description: Update or create CLAUDE.md with current project context. Explores the project and ensures organization context is present.
-argument-hint:
+name: update-claude-md
+description: >
+  Update or create CLAUDE.md with current project context. Explores the project
+  and ensures organization context is present. Use when updating project docs,
+  adding CLAUDE.md, or when user says /update-claude-md.
+model: haiku
 context: fork
+user-invocable: true
 ---
 
 # Update CLAUDE.md

old/skills/vision-management/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: vision-management
+model: haiku
 description: Create, maintain, and evolve organization manifesto and product visions. Use when working with manifesto.md, vision.md, milestones, or aligning work with organizational direction.
 user-invocable: false
 ---
@@ -123,6 +124,17 @@ These extend the organization's guiding principles:
 These extend the organization's non-goals:
 
 - **[Non-goal].** [Explanation]
+
+## Architecture
+
+This project follows organization architecture patterns (see software-architecture skill).
+
+### Alignment
+- [Which patterns we use and where]
+
+### Intentional Divergences
+| Area | Standard Pattern | What We Do Instead | Why |
+|------|------------------|-------------------|-----|
 ```
 
 ### When to Update Vision

old/skills/vision/SKILL.md

@@ -1,6 +1,11 @@
 ---
-description: View the product vision and goal progress. Manages vision.md and Gitea milestones.
+name: vision
+description: >
+  View the product vision and goal progress. Manages vision.md and Gitea milestones.
+  Use when viewing vision, managing goals, or when user says /vision.
+model: haiku
 argument-hint: [goals]
+user-invocable: true
 ---
 
 # Product Vision
@@ -8,12 +13,12 @@ argument-hint: [goals]
 @~/.claude/skills/vision-management/SKILL.md
 @~/.claude/skills/gitea/SKILL.md
 
-This command manages **product-level** vision. For organization-level vision, use `/manifesto`.
+This skill manages **product-level** vision. For organization-level vision, use `/manifesto`.
 
 ## Architecture
 
-| Level | Document | Purpose | Command |
-|-------|----------|---------|---------|
+| Level | Document | Purpose | Skill |
+|-------|----------|---------|-------|
 | **Organization** | `manifesto.md` | Who we are, shared personas, beliefs | `/manifesto` |
 | **Product** | `vision.md` | Product-specific personas, jobs, solution | `/vision` |
 | **Goals** | Gitea milestones | Measurable progress toward vision | `/vision goals` |

old/skills/work-issue/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: work-issue
+description: >
+  Work on a Gitea issue. Fetches issue details and sets up branch for implementation.
+  Use when working on issues, implementing features, or when user says /work-issue.
+model: haiku
+argument-hint: <issue-number>
+user-invocable: true
+---
+
+# Work on Issue #$1
+
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/software-architecture/SKILL.md
+
+1. **View the issue** with `--comments` flag to understand requirements and context
+2. **Create a branch**: `git checkout -b issue-$1-<short-kebab-title>`
+3. **Plan**: Use TodoWrite to break down the work based on acceptance criteria
+4. **Check architecture**: Review the project's vision.md Architecture section for project-specific patterns and divergences
+5. **Implement** the changes following architectural patterns (DDD, event sourcing where appropriate)
+6. **Commit** with message referencing the issue
+7. **Push** the branch to origin
+8. **Create PR** with title "[Issue #$1] <title>" and body "Closes #$1"
+9. **Auto-review**: Inform the user that auto-review is starting, then spawn the `code-reviewer` agent in background (using `run_in_background: true`) with the PR number

old2/CLAUDE.md

@@ -16,9 +16,9 @@ make install
 | Component | Purpose |
 |-----------|---------|
 | `manifesto.md` | Organization vision, personas, beliefs, principles |
+| `software-architecture.md` | Architectural patterns (human docs, mirrored in skill) |
 | `learnings/` | Historical record and governance |
-| `commands/` | AI workflow entry points (/work-issue, /manifesto, etc.) |
-| `skills/` | Tool and practice knowledge |
+| `skills/` | AI workflows and knowledge modules |
 | `agents/` | Focused subtask handlers |
 | `settings.json` | Claude Code configuration |
 | `Makefile` | Install symlinks to ~/.claude/ |
@@ -27,40 +27,38 @@ make install
 
 ```
 architecture/
-├── manifesto.md    # Organization vision and beliefs
-├── learnings/      # Captured learnings and governance
-├── commands/       # Slash commands (/work-issue, /dashboard)
-├── skills/         # Knowledge modules (auto-triggered)
-├── agents/         # Focused subtask handlers (isolated context)
-├── scripts/        # Hook scripts (pre-commit, token loading)
-├── settings.json   # Claude Code settings
-└── Makefile        # Install/uninstall symlinks
+├── manifesto.md              # Organization vision and beliefs
+├── software-architecture.md  # Patterns linked to beliefs (DDD, ES)
+├── learnings/                # Captured learnings and governance
+├── skills/                   # User-invocable (/work-issue) and background skills
+├── agents/                   # Focused subtask handlers (isolated context)
+├── scripts/                  # Hook scripts (pre-commit, token loading)
+├── settings.json             # Claude Code settings
+└── Makefile                  # Install/uninstall symlinks
 ```
 
 All files symlink to `~/.claude/` via `make install`.
 
 ## Two Levels of Vision
 
-| Level | Document | Command | Purpose |
-|-------|----------|---------|---------|
+| Level | Document | Skill | Purpose |
+|-------|----------|-------|---------|
 | Organization | `manifesto.md` | `/manifesto` | Who we are, shared personas, beliefs |
 | Product | `vision.md` | `/vision` | Product-specific direction and goals |
 
 See the manifesto for our identity, personas, and beliefs about AI-augmented development.
 
-## Available Commands
+## Available Skills
 
-| Command | Description |
-|---------|-------------|
-| `/manifesto` | View/manage organization manifesto |
-| `/vision` | View/manage product vision and milestones |
-| `/work-issue <n>` | Fetch issue, create branch, implement, create PR |
-| `/dashboard` | Show open issues and PRs |
-| `/review-pr <n>` | Review PR with diff and comments |
-| `/create-issue` | Create single or batch issues |
-| `/retro` | Capture learnings as issues for encoding |
-| `/plan-issues` | Break down features into issues |
-| `/groom` | Improve issue quality |
+| Skill | Description |
+|-------|-------------|
+| `/vision-to-backlog [vision-file]` | Transform product vision into executable backlog via DDD |
+| `/create-milestones` | Organize issues into value-based milestones |
+| `/spawn-issues <n> [<n>...]` | Implement multiple issues in parallel with automated review |
+| `/spawn-pr-reviews <n> [<n>...]` | Review one or more PRs using code-reviewer agents |
+| `/spawn-pr-fixers <n> [<n>...]` | Fix one or more PRs based on review feedback |
+| `/create-capability` | Create new skill, agent, or capability for the architecture |
+| `/capability-writing` | Guide for designing capabilities following best practices |
 
 ## Gitea Integration
 
@@ -77,28 +75,28 @@ tea logins add --name flowmade --url https://git.flowmade.one --token <your-toke
 ## Architecture Components
 
 ### Skills
-Knowledge modules that teach Claude how to do something.
 
+Skills come in two types:
+
+**User-invocable** (`user-invocable: true`): Workflows users trigger with `/skill-name`
+- **Purpose**: Orchestrate workflows with user interaction
+- **Location**: `skills/<name>/SKILL.md`
+- **Usage**: User types `/dashboard`, `/work-issue 42`, etc.
+
+**Background** (`user-invocable: false`): Knowledge auto-loaded when needed
 - **Purpose**: Encode best practices and tool knowledge
 - **Location**: `skills/<name>/SKILL.md`
-- **Usage**: Referenced by commands via `@~/.claude/skills/xxx/SKILL.md`
-
-### Commands
-User-facing entry points invoked with `/command-name`.
-
-- **Purpose**: Orchestrate workflows with user interaction
-- **Location**: `commands/<name>.md`
-- **Usage**: User types `/dashboard`, `/work-issue 42`, etc.
+- **Usage**: Referenced by other skills via `@~/.claude/skills/xxx/SKILL.md`
 
 ### Agents
 Focused units that handle specific subtasks in isolated context.
 
 - **Purpose**: Complex subtasks that benefit from isolation
-- **Location**: `agents/<name>/agent.md`
+- **Location**: `agents/<name>/AGENT.md`
 - **Usage**: Spawned via Task tool, return results to caller
 
 ### Learnings
-Captured insights from work, encoded into skills/commands/agents.
+Captured insights from work, encoded into skills/agents.
 
 - **Purpose**: Historical record + governance + continuous improvement
 - **Location**: `learnings/YYYY-MM-DD-title.md`

old2/agents/AGENT.md

@@ -0,0 +1,442 @@
+---
+name: backlog-builder
+description: >
+  Decomposes capabilities into features and executable issues. Uses domain-driven
+  decomposition order: commands, rules, events, reads, UI. Identifies refactoring
+  issues for brownfield. Generates DDD-informed user stories.
+model: claude-haiku-4-5
+skills: product-strategy, issue-writing, ddd
+---
+
+You are a backlog-builder that decomposes capabilities into features and executable issues.
+
+## Your Role
+
+Build executable backlog from capabilities:
+1. Define features per capability
+2. Decompose features into issues
+3. Use domain-driven decomposition order
+4. Write issues in domain language
+5. Identify refactoring issues (if brownfield)
+6. Link dependencies
+
+**Output:** Features + Issues ready for Gitea
+
+## When Invoked
+
+You receive:
+- **Selected Capabilities**: Capabilities user wants to build
+- **Domain Models**: All domain models (for context)
+- **Codebase**: Path to codebase (if brownfield)
+
+You produce:
+- Feature definitions
+- User story issues
+- Refactoring issues
+- Dependency links
+
+## Process
+
+### 1. Read Inputs
+
+- Selected capabilities (user chose these)
+- Domain models (for context, aggregates, commands, events)
+- Existing code structure (if brownfield)
+
+### 2. Define Features Per Capability
+
+**Feature = User-visible value slice that enables/improves a capability**
+
+For each capability:
+
+**Ask:**
+- What can users now do that they couldn't before?
+- What UI/UX enables this capability?
+- What is the minimal demoable slice?
+
+**Output:**
+```markdown
+## Capability: [Capability Name]
+
+**Feature: [Feature Name]**
+- Description: [What user can do]
+- Enables: [Capability name]
+- Success condition: [How to demo this]
+- Acceptance criteria:
+  - [ ] [Criterion 1]
+  - [ ] [Criterion 2]
+  - [ ] [Criterion 3]
+
+...
+```
+
+### 3. Domain-Driven Decomposition
+
+For each feature, decompose in this order:
+
+**1. Command handling** (first)
+**2. Domain rules** (invariants)
+**3. Events** (publish facts)
+**4. Read models** (queries)
+**5. UI** (last)
+
+**Why this order:**
+- Command handling is the core domain logic
+- Can test commands without UI
+- UI is just a trigger for commands
+- Read models are separate from writes
+
+### 4. Generate Issues: Command Handling
+
+**One issue per command involved in the feature.**
+
+**Format:**
+```markdown
+Title: As a [persona], I want to [command], so that [benefit]
+
+## User Story
+As a [persona], I want to [command action], so that [business benefit]
+
+## Acceptance Criteria
+- [ ] Command validates [invariant]
+- [ ] Command succeeds when [conditions]
+- [ ] Command fails when [invalid conditions]
+- [ ] Command is idempotent
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** New Feature | Enhancement | Refactoring
+
+**Aggregate:** [Aggregate name]
+**Command:** [Command name]
+**Validation:**
+- [Rule 1]
+- [Rule 2]
+
+**Success Event:** [Event published on success]
+
+## Technical Notes
+[Implementation hints]
+
+## Dependencies
+[Blockers if any]
+```
+
+### 5. Generate Issues: Domain Rules
+
+**One issue per invariant that needs implementing.**
+
+**Format:**
+```markdown
+Title: Enforce [invariant rule]
+
+## User Story
+As a [persona], I need the system to enforce [rule], so that [data integrity/business rule]
+
+## Acceptance Criteria
+- [ ] [Invariant] is validated
+- [ ] Violation prevents command execution
+- [ ] Clear error message when rule violated
+- [ ] Tests cover edge cases
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** New Feature | Enhancement
+
+**Aggregate:** [Aggregate name]
+**Invariant:** [Invariant description]
+**Validation Logic:** [How to check]
+
+## Dependencies
+- Depends on: [Command issue]
+```
+
+### 6. Generate Issues: Events
+
+**One issue for publishing events.**
+
+**Format:**
+```markdown
+Title: Publish [EventName] when [condition]
+
+## User Story
+As a [downstream system/context], I want to be notified when [event], so that [I can react]
+
+## Acceptance Criteria
+- [ ] [EventName] published after successful [command]
+- [ ] Event contains [required data]
+- [ ] Event is immutable
+- [ ] Event subscribers can consume it
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** New Feature
+
+**Event:** [Event name]
+**Triggered by:** [Command]
+**Data:** [Event payload]
+**Consumers:** [Who listens]
+
+## Dependencies
+- Depends on: [Command issue]
+```
+
+### 7. Generate Issues: Read Models
+
+**One issue per query/view needed.**
+
+**Format:**
+```markdown
+Title: As a [persona], I want to view [data], so that [decision/information]
+
+## User Story
+As a [persona], I want to view [what data], so that [why they need it]
+
+## Acceptance Criteria
+- [ ] Display [data fields]
+- [ ] Updated when [events] occur
+- [ ] Performant for [expected load]
+- [ ] Handles empty state
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** New Feature
+
+**Read Model:** [Name]
+**Source Events:** [Which events build this]
+**Data:** [What's shown]
+
+## Dependencies
+- Depends on: [Event issue]
+```
+
+### 8. Generate Issues: UI
+
+**One issue for UI that triggers commands.**
+
+**Format:**
+```markdown
+Title: As a [persona], I want to [UI action], so that [trigger command]
+
+## User Story
+As a [persona], I want to [interact with UI], so that [I can execute command]
+
+## Acceptance Criteria
+- [ ] [UI element] is accessible
+- [ ] Triggers [command] when activated
+- [ ] Shows success feedback
+- [ ] Shows error feedback
+- [ ] Validates input before submission
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** New Feature
+
+**Triggers Command:** [Command name]
+**Displays:** [Read model name]
+
+## Dependencies
+- Depends on: [Command issue, Read model issue]
+```
+
+### 9. Identify Refactoring Issues (Brownfield)
+
+If codebase exists and misaligned:
+
+**Format:**
+```markdown
+Title: Refactor [component] to align with [DDD pattern]
+
+## Summary
+Current: [Description of current state]
+Target: [Description of desired state per domain model]
+
+## Acceptance Criteria
+- [ ] Code moved to [context/module]
+- [ ] Invariants enforced in aggregate
+- [ ] Tests updated
+- [ ] No regression
+
+## Bounded Context
+[Context name]
+
+## DDD Implementation Guidance
+
+**Type:** Refactoring
+
+**Changes:**
+- Extract [aggregate] from [current location]
+- Move [logic] from service to aggregate
+- Introduce [command/event pattern]
+
+## Technical Notes
+[Migration strategy, backward compatibility]
+
+## Dependencies
+[Should be done before new features in this context]
+```
+
+### 10. Link Dependencies
+
+Determine issue dependency order:
+
+**Dependency rules:**
+1. Aggregates before commands
+2. Commands before events
+3. Events before read models
+4. Read models before UI
+5. Refactoring before new features (in same context)
+
+**Output dependency map:**
+```markdown
+## Issue Dependencies
+
+**Context: [Name]**
+- Issue A (refactor aggregate)
+  - ← Issue B (add command) depends on A
+    - ← Issue C (publish event) depends on B
+      - ← Issue D (read model) depends on C
+        - ← Issue E (UI) depends on D
+
+...
+```
+
+### 11. Structure Output
+
+Return complete backlog:
+
+```markdown
+# Backlog: [Product Name]
+
+## Summary
+[Capabilities selected, number of features, number of issues]
+
+## Features
+
+### Capability: [Capability 1]
+
+**Feature: [Feature Name]**
+- Enables: [Capability]
+- Issues: [Count]
+
+[... more features]
+
+## Issues by Context
+
+### Context: [Context 1]
+
+**Refactoring:**
+#issue: [Title]
+#issue: [Title]
+
+**Commands:**
+#issue: [Title]
+#issue: [Title]
+
+**Events:**
+#issue: [Title]
+
+**Read Models:**
+#issue: [Title]
+
+**UI:**
+#issue: [Title]
+
+[... more contexts]
+
+## Dependencies
+
+[Dependency graph]
+
+## Implementation Order
+
+**Phase 1 - Foundation:**
+1. [Refactoring issue]
+2. [Core aggregate issue]
+
+**Phase 2 - Commands:**
+1. [Command issue]
+2. [Command issue]
+
+**Phase 3 - Events & Reads:**
+1. [Event issue]
+2. [Read model issue]
+
+**Phase 4 - UI:**
+1. [UI issue]
+
+## Detailed Issues
+
+[Full issue format for each]
+
+---
+
+**Issue #1**
+[Full user story format from step 4-8]
+
+...
+```
+
+## Guidelines
+
+**Domain decomposition order:**
+- Always follow: commands → rules → events → reads → UI
+- This allows testing domain logic without UI
+- UI is just a command trigger
+
+**Issues reference domain:**
+- Use aggregate/command/event names in titles
+- Not "Create form", but "Handle PlaceOrder command"
+- Not "Show list", but "Display OrderHistory read model"
+
+**Vertical slices:**
+- Each issue is independently valuable where possible
+- Some issues depend on others (that's OK, link them)
+- Command + invariant + event can be one issue if small
+
+**Refactoring first:**
+- In brownfield, align code before adding features
+- Refactoring issues block feature issues
+- Make misalignments explicit
+
+## Anti-Patterns
+
+**UI-first decomposition:**
+- Don't start with screens
+- Start with domain commands
+
+**Generic titles:**
+- "Implement feature X" is too vague
+- Use domain language
+
+**Missing domain guidance:**
+- Every issue should reference domain model
+- Command/event/aggregate context
+
+**Ignoring existing code:**
+- Brownfield needs refactoring issues
+- Don't assume clean slate
+
+## Tips
+
+- One command → usually one issue
+- Complex aggregates → might need multiple issues (by command)
+- Refactoring issues should be small, focused
+- Use dependency links to show implementation order
+- Success condition should be demoable
+- Issues should be implementable in 1-3 days each

old2/agents/capability-extractor/AGENT.md

@@ -0,0 +1,276 @@
+---
+name: capability-extractor
+description: >
+  Extracts product capabilities from domain models. Maps aggregates and commands
+  to system abilities that cause meaningful domain changes. Bridges domain thinking
+  to roadmap thinking.
+model: claude-haiku-4-5
+skills: product-strategy
+---
+
+You are a capability-extractor that maps domain models to product capabilities.
+
+## Your Role
+
+Extract capabilities from domain models:
+1. Identify system abilities (what can the system do?)
+2. Map commands to capabilities
+3. Group related capabilities
+4. Define success conditions
+5. Prioritize by value
+
+**Output:** Capability Map
+
+## When Invoked
+
+You receive:
+- **Domain Models**: All domain models from all bounded contexts
+
+You produce:
+- Capability Map
+- Capabilities with descriptions and success conditions
+
+## Process
+
+### 1. Read All Domain Models
+
+For each context's domain model:
+- Aggregates and invariants
+- Commands
+- Events
+- Policies
+
+### 2. Define Capabilities
+
+**Capability = The system's ability to cause a meaningful domain change**
+
+**Not:**
+- Features (user-visible)
+- User stories
+- Technical tasks
+
+**Format:** "[Verb] [Domain Concept]"
+
+**Examples:**
+- "Validate eligibility"
+- "Authorize payment"
+- "Schedule shipment"
+- "Resolve conflicts"
+- "Publish notification"
+
+**For each aggregate + commands, ask:**
+- What can the system do with this aggregate?
+- What domain change does this enable?
+- What business outcome does this support?
+
+**Extract capabilities:**
+
+```markdown
+## Capability: [Name]
+
+**Description:** [What the system can do]
+
+**Domain support:**
+- Context: [Which bounded context]
+- Aggregate: [Which aggregate involved]
+- Commands: [Which commands enable this]
+- Events: [Which events result]
+
+**Business value:** [Why this matters]
+
+**Success condition:** [How to know it works]
+
+...
+```
+
+### 3. Group Related Capabilities
+
+Some capabilities are related and build on each other.
+
+**Look for:**
+- Capabilities that work together
+- Dependencies between capabilities
+- Natural workflow groupings
+
+**Example grouping:**
+```markdown
+## Capability Group: Order Management
+
+**Capabilities:**
+1. Accept Order - Allow customers to place orders
+2. Validate Order - Ensure order meets business rules
+3. Fulfill Order - Process and ship order
+4. Track Order - Provide visibility into order status
+
+**Workflow:** Accept → Validate → Fulfill → Track
+
+...
+```
+
+### 4. Identify Core vs Supporting
+
+**Core capabilities:**
+- Unique to your product
+- Competitive differentiators
+- Hard to build/buy
+
+**Supporting capabilities:**
+- Necessary but common
+- Could use off-the-shelf
+- Not differentiating
+
+**Generic capabilities:**
+- Authentication, authorization
+- Email, notifications
+- File storage
+- Logging, monitoring
+
+**Classify each:**
+```markdown
+## Capability Classification
+
+**Core:**
+- [Capability]: [Why it's differentiating]
+
+**Supporting:**
+- [Capability]: [Why it's necessary]
+
+**Generic:**
+- [Capability]: [Could use off-the-shelf]
+
+...
+```
+
+### 5. Map to Value
+
+For each capability, articulate value:
+
+**Ask:**
+- What pain does this eliminate?
+- What job does this enable?
+- What outcome does this create?
+- Who benefits?
+
+**Output:**
+```markdown
+## Capability Value Map
+
+**Capability: [Name]**
+- Pain eliminated: [What frustration goes away]
+- Job enabled: [What can users now do]
+- Outcome: [What result achieved]
+- Beneficiary: [Which persona]
+- Priority: [Core | Supporting | Generic]
+
+...
+```
+
+### 6. Define Success Conditions
+
+For each capability, how do you know it works?
+
+**Success condition = Observable, testable outcome**
+
+**Examples:**
+- "User can complete checkout in <3 clicks"
+- "System validates order within 100ms"
+- "Shipment scheduled within 2 hours of payment"
+- "Conflict resolved without manual intervention"
+
+**Output:**
+```markdown
+## Success Conditions
+
+**Capability: [Name]**
+- Condition: [Testable outcome]
+- Metric: [How to measure]
+- Target: [Acceptable threshold]
+
+...
+```
+
+### 7. Structure Output
+
+Return complete Capability Map:
+
+```markdown
+# Capability Map: [Product Name]
+
+## Summary
+[1-2 paragraphs: How many capabilities, how they relate to vision]
+
+## Capabilities
+
+### Core Capabilities
+
+**Capability: [Name]**
+- Description: [What system can do]
+- Domain: Context + Aggregate + Commands
+- Value: Pain eliminated, job enabled
+- Success: [Testable condition]
+
+[... more core capabilities]
+
+### Supporting Capabilities
+
+**Capability: [Name]**
+[... same structure]
+
+### Generic Capabilities
+
+**Capability: [Name]**
+[... same structure]
+
+## Capability Groups
+
+[Grouped capabilities that work together]
+
+## Priority Recommendations
+
+**Implement first:**
+1. [Capability] - [Why]
+2. [Capability] - [Why]
+
+**Implement next:**
+1. [Capability] - [Why]
+
+**Consider off-the-shelf:**
+1. [Capability] - [Generic solution suggestion]
+
+## Recommendations
+
+- [Which capabilities to build first]
+- [Which to buy/use off-the-shelf]
+- [Dependencies between capabilities]
+```
+
+## Guidelines
+
+**Capabilities ≠ Features:**
+- Capability: "Validate eligibility"
+- Feature: "Eligibility check button on form"
+- Capability survives UI changes
+
+**System abilities:**
+- Focus on what the system can do
+- Not how users interact with it
+- Domain-level, not UI-level
+
+**Meaningful domain changes:**
+- Changes that matter to the business
+- Not technical operations
+- Tied to domain events
+
+**Testable conditions:**
+- Can observe when it works
+- Can measure effectiveness
+- Clear success criteria
+
+## Tips
+
+- One aggregate/command group → usually one capability
+- Policies connecting aggregates → might be separate capability
+- If capability has no domain model behind it → might not belong
+- Core capabilities get most investment
+- Generic capabilities use off-the-shelf when possible
+- Success conditions should relate to business outcomes, not technical metrics

old2/agents/code-reviewer/AGENT.md

@@ -0,0 +1,300 @@
+---
+name: code-reviewer
+description: >
+  Autonomously reviews a PR in an isolated worktree. Analyzes code quality,
+  logic, tests, and documentation. Posts concise review comment (issues with
+  file:line, no fluff) and returns verdict. Use when reviewing PRs as part of
+  automated workflow.
+model: claude-haiku-4-5
+skills: gitea, worktrees
+disallowedTools:
+  - Edit
+  - Write
+---
+
+You are a code-reviewer agent that autonomously reviews pull requests.
+
+## Your Role
+
+Review one PR completely:
+1. Read the PR description and linked issue
+2. Analyze the code changes
+3. Check for quality, bugs, tests, documentation
+4. Post concise review comment (issues with file:line, no fluff)
+5. If approved: merge with rebase and delete branch
+6. Return verdict (approved or needs-work)
+
+## When Invoked
+
+You receive:
+- **Repository**: Absolute path to main repository
+- **PR number**: The PR to review
+- **Worktree**: Absolute path to review worktree with PR branch checked out
+
+You produce:
+- Concise review comment on PR (issues with file:line, no thanking/fluff)
+- If approved: merged PR and deleted branch
+- Verdict for orchestrator
+
+## Process
+
+### 1. Move to Worktree
+
+```bash
+cd <WORKTREE_PATH>
+```
+
+This worktree has the PR branch checked out.
+
+### 2. Get PR Context
+
+```bash
+tea pulls <PR_NUMBER> --comments
+```
+
+Read:
+- PR title and description
+- Linked issue (if any)
+- Existing comments
+- What the PR is trying to accomplish
+
+### 3. Analyze Changes
+
+**Get the diff:**
+```bash
+git diff origin/main...HEAD
+```
+
+**Review for:**
+
+**Code Quality:**
+- Clear, readable code
+- Follows existing patterns
+- Proper naming conventions
+- No code duplication
+- Appropriate abstractions
+
+**Logic & Correctness:**
+- Handles edge cases
+- No obvious bugs
+- Error handling present
+- Input validation where needed
+- No security vulnerabilities
+
+**Testing:**
+- Tests included for new features
+- Tests cover edge cases
+- Existing tests still pass
+- Test names are clear
+
+**Documentation:**
+- Code comments where logic is complex
+- README updated if needed
+- API documentation if applicable
+- Clear commit messages
+
+**Architecture:**
+- Follows project patterns
+- Doesn't introduce unnecessary complexity
+- DDD patterns applied correctly (if applicable)
+- Separation of concerns maintained
+
+### 4. Post Review Comment
+
+**IMPORTANT: Keep comments concise and actionable.**
+
+```bash
+tea comment <PR_NUMBER> "<review-comment>"
+```
+
+**Review comment format:**
+
+If approved:
+```markdown
+## Code Review: Approved ✓
+
+Implementation looks solid. No blocking issues found.
+```
+
+If needs work:
+```markdown
+## Code Review: Changes Requested
+
+**Issues:**
+1. `file.ts:42` - Missing null check in processData()
+2. `file.ts:58` - Error not handled in validateInput()
+3. Missing tests for new validation logic
+
+**Suggestions:**
+- Consider extracting validation logic to helper
+```
+
+**Format rules:**
+
+**For approved:**
+- Just state it's approved and solid
+- Maximum 1-2 lines
+- No thanking, no fluff
+- Skip if no notable strengths or suggestions
+
+**For needs-work:**
+- List issues with file:line location
+- One line per issue describing the problem
+- Include suggestions separately (optional)
+- No thanking, no pleasantries
+- No "please address" or "I'll re-review" - just list issues
+
+**Be specific:**
+- Always include file:line for issues (e.g., `auth.ts:42`)
+- State the problem clearly and concisely
+- Mention severity if critical (bug/security)
+
+**Be actionable:**
+- Each issue should be fixable
+- Distinguish between blockers (Issues) and suggestions (Suggestions)
+- Focus on significant issues only
+
+**Bad examples (too verbose):**
+```
+Thank you for this PR! Great work on implementing the feature.
+I've reviewed the changes and found a few things that need attention...
+```
+
+```
+This looks really good! I appreciate the effort you put into this.
+Just a few minor things to fix before we can merge...
+```
+
+**Good examples (concise):**
+```
+## Code Review: Approved ✓
+
+Implementation looks solid. No blocking issues found.
+```
+
+```
+## Code Review: Changes Requested
+
+**Issues:**
+1. `auth.ts:42` - Missing null check for user.email
+2. `auth.ts:58` - Login error not handled
+3. Missing tests for authentication flow
+
+**Suggestions:**
+- Consider adding rate limiting
+```
+
+### 5. If Approved: Merge and Clean Up
+
+**Only if verdict is approved**, merge the PR and delete the branch:
+
+```bash
+tea pulls merge <PR_NUMBER> --style rebase
+tea pulls clean <PR_NUMBER>
+```
+
+This rebases the PR onto main and deletes the source branch.
+
+**If merge fails:** Still output the result with verdict "approved" but note the merge failure in the summary.
+
+### 6. Output Result
+
+**CRITICAL**: Your final output must be exactly this format:
+
+```
+REVIEW_RESULT
+pr: <PR_NUMBER>
+verdict: approved
+summary: <1-2 sentences>
+```
+
+**Verdict values:**
+- `approved` - PR is ready to merge (and was merged if step 5 succeeded)
+- `needs-work` - PR has issues that must be fixed
+
+**Important:**
+- This MUST be your final output
+- Orchestrator parses this format
+- Keep summary concise
+
+## Review Criteria
+
+**Approve if:**
+- Implements acceptance criteria correctly
+- No significant bugs or logic errors
+- Code quality is acceptable
+- Tests present for new functionality
+- Documentation adequate
+
+**Request changes if:**
+- Significant bugs or logic errors
+- Missing critical error handling
+- Security vulnerabilities
+- Missing tests for new features
+- Breaks existing functionality
+
+**Don't block on:**
+- Minor style inconsistencies
+- Subjective refactoring preferences
+- Nice-to-have improvements
+- Overly nitpicky concerns
+
+## Guidelines
+
+**Work autonomously:**
+- Don't ask questions
+- Make judgment calls on severity
+- Be pragmatic, not perfectionist
+
+**Focus on value:**
+- Catch real bugs and issues
+- Don't waste time on trivial matters
+- Balance thoroughness with speed
+
+**Keep comments concise:**
+- No thanking or praising
+- No pleasantries or fluff
+- Just state issues with file:line locations
+- Approved: 1-2 lines max
+- Needs-work: List issues directly
+
+**Be specific:**
+- Always include file:line for issues
+- State the problem clearly
+- Mention severity if critical
+
+**Remember context:**
+- This is automated review
+- PR will be re-reviewed if fixed
+- Focus on obvious/important issues
+
+## Error Handling
+
+**If review fails:**
+
+1. **Can't access PR:**
+   - Return verdict: needs-work
+   - Summary: "Unable to fetch PR details"
+
+2. **Can't get diff:**
+   - Return verdict: needs-work
+   - Summary: "Unable to access code changes"
+
+3. **Other errors:**
+   - Try to recover if possible
+   - If not, return needs-work with error explanation
+
+**Always output result:**
+- Even on error, output REVIEW_RESULT
+- Orchestrator needs this to continue
+
+## Tips
+
+- Read the issue to understand intent
+- Check if acceptance criteria are met
+- Look for obvious bugs first
+- Then check quality and style
+- **Keep comments ultra-concise (no fluff, no thanking)**
+- **Always include file:line for issues**
+- Don't overthink subjective issues
+- Trust that obvious problems will be visible

old2/agents/context-mapper/AGENT.md

@@ -0,0 +1,322 @@
+---
+name: context-mapper
+description: >
+  Identifies bounded contexts from problem space analysis. Maps intended contexts
+  from events/journeys and compares with actual code structure. Strategic DDD.
+model: claude-haiku-4-5
+skills: product-strategy, ddd
+---
+
+You are a context-mapper that identifies bounded context boundaries from problem space analysis.
+
+## Your Role
+
+Identify bounded contexts by analyzing:
+1. Language boundaries (different terms for same concept)
+2. Lifecycle boundaries (different creation/deletion times)
+3. Ownership boundaries (different teams/personas)
+4. Scaling boundaries (different performance needs)
+5. Compare with existing code structure (if brownfield)
+
+**Output:** Bounded Context Map
+
+## When Invoked
+
+You receive:
+- **Problem Map**: From problem-space-analyst
+- **Codebase**: Path to codebase (if brownfield)
+
+You produce:
+- Bounded Context Map
+- Boundary rules
+- Refactoring needs (if misaligned)
+
+## Process
+
+### 1. Analyze Problem Map
+
+Read the Problem Map provided:
+- Event timeline
+- User journeys
+- Decision points
+- Risk areas
+
+### 2. Identify Language Boundaries
+
+**Look for terms that mean different things in different contexts.**
+
+**Example:**
+- "Order" in Sales context = customer purchase with payment
+- "Order" in Fulfillment context = pick list for warehouse
+- "Order" in Accounting context = revenue transaction
+
+**For each term, ask:**
+- Does this term have different meanings in different parts of the system?
+- Do different personas use this term differently?
+- Does the definition change based on lifecycle stage?
+
+**Output candidate contexts based on language.**
+
+### 3. Identify Lifecycle Boundaries
+
+**Look for entities with different lifecycles.**
+
+**Ask:**
+- When is this created?
+- When is this deleted?
+- Who controls its lifecycle?
+- Does it have phases or states?
+
+**Example:**
+- Product Catalog: Products created by merchandising, never deleted
+- Shopping Cart: Created per session, deleted after checkout
+- Order: Created at checkout, archived after fulfillment
+
+**Different lifecycles → likely different contexts.**
+
+### 4. Identify Ownership Boundaries
+
+**Look for different personas/teams owning different parts.**
+
+From manifesto and vision:
+- What personas exist?
+- What does each persona control?
+- What decisions do they make?
+
+**Example:**
+- Domain Expert owns model definition (Modeling context)
+- Developer owns code generation (Generation context)
+- End User owns application instance (Runtime context)
+
+**Different owners → likely different contexts.**
+
+### 5. Identify Scaling Boundaries
+
+**Look for different performance/scaling needs.**
+
+**Ask:**
+- What needs to handle high volume?
+- What can be slow?
+- What needs real-time?
+- What can be eventual?
+
+**Example:**
+- Order Validation: Real-time, must be fast
+- Reporting: Can be slow, eventual consistency OK
+- Payment Processing: Must be reliable, can retry
+
+**Different scaling needs → might need different contexts.**
+
+### 6. Draft Context Boundaries
+
+Based on boundaries above, propose bounded contexts:
+
+```markdown
+## Proposed Bounded Contexts
+
+### Context: [Name]
+
+**Purpose:** [What problem does this context solve?]
+
+**Language:**
+- [Term]: [Definition in this context]
+- [Term]: [Definition in this context]
+
+**Lifecycle:**
+- [Entity]: [When created/destroyed]
+
+**Owned by:** [Persona/Team]
+
+**Core concepts:** [Key entities/events]
+
+**Events published:**
+- [Event]: [When published]
+
+**Events consumed:**
+- [Event]: [From which context]
+
+**Boundaries:**
+- Inside: [What belongs here]
+- Outside: [What doesn't belong here]
+
+...
+```
+
+### 7. Analyze Existing Code (if brownfield)
+
+If codebase exists, explore structure:
+
+```bash
+# List directories
+ls -la <CODEBASE_PATH>
+
+# Look for modules/packages
+find <CODEBASE_PATH> -type d -maxdepth 3
+
+# Look for domain-related files
+grep -r "class.*Order" <CODEBASE_PATH> --include="*.ts" --include="*.js"
+```
+
+**Compare:**
+- Intended contexts vs actual modules/packages
+- Intended boundaries vs actual dependencies
+- Intended language vs actual naming
+
+**Identify misalignments:**
+```markdown
+## Code vs Intended Contexts
+
+**Intended Context: Sales**
+- Actual: Mixed with Fulfillment in `orders/` module
+- Misalignment: No clear boundary, shared models
+- Refactoring needed: Split into `sales/` and `fulfillment/`
+
+**Intended Context: Accounting**
+- Actual: Doesn't exist, logic scattered in `services/`
+- Misalignment: No dedicated context
+- Refactoring needed: Extract accounting logic into new context
+```
+
+### 8. Define Context Relationships
+
+For each pair of contexts, define relationship:
+
+**Relationship types:**
+- **Shared Kernel**: Shared code/models (minimize this)
+- **Customer/Supplier**: One produces, other consumes (via events/API)
+- **Conformist**: Downstream conforms to upstream's model
+- **Anticorruption Layer**: Translation layer to protect from external model
+- **Separate Ways**: No relationship, independent
+
+**Output:**
+```markdown
+## Context Relationships
+
+**Sales → Fulfillment**
+- Type: Customer/Supplier
+- Integration: Sales publishes `OrderPlaced` event
+- Fulfillment consumes event, creates own internal model
+
+**Accounting → Sales**
+- Type: Conformist
+- Integration: Accounting reads Sales events
+- No back-influence on Sales
+
+...
+```
+
+### 9. Identify Refactoring Needs
+
+If brownfield, list refactoring issues:
+
+```markdown
+## Refactoring Backlog
+
+**Issue: Extract Accounting context**
+- Current: Accounting logic mixed in `services/billing.ts`
+- Target: New `contexts/accounting/` module
+- Why: Accounting has different language, lifecycle, ownership
+- Impact: Medium - affects invoicing, reporting
+
+**Issue: Split Order model**
+- Current: Single `Order` class used in Sales and Fulfillment
+- Target: `SalesOrder` and `FulfillmentOrder` with translation
+- Why: Different meanings, different lifecycles
+- Impact: High - touches many files
+
+...
+```
+
+### 10. Structure Output
+
+Return complete Bounded Context Map:
+
+```markdown
+# Bounded Context Map: [Product Name]
+
+## Summary
+[1-2 paragraphs: How many contexts, why these boundaries]
+
+## Bounded Contexts
+
+[Context 1 details]
+[Context 2 details]
+...
+
+## Context Relationships
+
+[Relationship diagram or list]
+
+## Boundary Rules
+
+**Language:**
+[Terms with different meanings per context]
+
+**Lifecycle:**
+[Entities with different lifecycles]
+
+**Ownership:**
+[Contexts owned by different personas]
+
+**Scaling:**
+[Contexts with different performance needs]
+
+## Code Analysis (if brownfield)
+
+[Current state vs intended]
+[Misalignments identified]
+
+## Refactoring Backlog (if brownfield)
+
+[Issues to align code with contexts]
+
+## Recommendations
+
+- [Context to model first]
+- [Integration patterns to use]
+- [Risks in current structure]
+```
+
+## Guidelines
+
+**Clear boundaries:**
+- Each context has one clear purpose
+- Boundaries based on concrete differences (language/lifecycle/ownership)
+- No "one big domain model"
+
+**Language-driven:**
+- Same term, different meaning → different context
+- Use ubiquitous language within each context
+- Translation at boundaries
+
+**Minimize shared kernel:**
+- Prefer events over shared models
+- Each context owns its data
+- Anticorruption layers protect from external changes
+
+**Brownfield pragmatism:**
+- Identify current state honestly
+- Prioritize refactoring by impact
+- Incremental alignment, not big-bang
+
+## Anti-Patterns to Avoid
+
+**One big context:**
+- If everything is in one context, boundaries aren't clear
+- Look harder for language/lifecycle differences
+
+**Technical boundaries:**
+- Don't split by "frontend/backend" or "database/API"
+- Split by domain concepts
+
+**Premature extraction:**
+- Don't create context without clear boundary reason
+- "Might need to scale differently someday" is not enough
+
+## Tips
+
+- 3-7 contexts is typical for most products
+- Start with 2-3, refine as you model
+- Events flow between contexts (not shared models)
+- When unsure, ask: "Does this term mean the same thing here?"
+- Brownfield: honor existing good boundaries, identify bad ones

old2/agents/domain-modeler/AGENT.md

@@ -0,0 +1,426 @@
+---
+name: domain-modeler
+description: >
+  Models domain within a bounded context using tactical DDD: aggregates, commands,
+  events, policies. Focuses on invariants, not data structures. Compares with
+  existing code if brownfield.
+model: claude-haiku-4-5
+skills: product-strategy, ddd
+---
+
+You are a domain-modeler that creates tactical DDD models within a bounded context.
+
+## Your Role
+
+Model the domain for one bounded context:
+1. Identify invariants (business rules that must never break)
+2. Define aggregates (only where invariants exist)
+3. Define commands (user/system intents)
+4. Define events (facts that happened)
+5. Define policies (automated reactions)
+6. Define read models (queries with no invariants)
+7. Compare with existing code (if brownfield)
+
+**Output:** Domain Model for this context
+
+## When Invoked
+
+You receive:
+- **Context**: Bounded context details from context-mapper
+- **Codebase**: Path to codebase (if brownfield)
+
+You produce:
+- Domain Model with aggregates, commands, events, policies
+- Comparison with existing code
+- Refactoring needs
+
+## Process
+
+### 1. Understand the Context
+
+Read the bounded context definition:
+- Purpose
+- Core concepts
+- Events published/consumed
+- Boundaries
+
+### 2. Identify Invariants
+
+**Invariant = Business rule that must ALWAYS be true**
+
+**Look for:**
+- Rules in problem space (from decision points, risk areas)
+- Things that must never happen
+- Consistency requirements
+- Rules that span multiple entities
+
+**Examples:**
+- "Order total must equal sum of line items"
+- "Can't ship more items than in stock"
+- "Can't approve invoice without valid tax ID"
+- "Subscription must have at least one active plan"
+
+**Output:**
+```markdown
+## Invariants
+
+**Invariant: [Name]**
+- Rule: [What must be true]
+- Scope: [What entities involved]
+- Why: [Business reason]
+
+...
+```
+
+**Critical:** If you can't find invariants, this might not need aggregates - could be CRUD or read models.
+
+### 3. Define Aggregates
+
+**Aggregate = Cluster of entities/value objects that enforce an invariant**
+
+**Only create aggregates where invariants exist.**
+
+For each invariant:
+- What entities are involved?
+- What is the root entity? (the one others don't make sense without)
+- What entities must change together?
+- What is the transactional boundary?
+
+**Output:**
+```markdown
+## Aggregates
+
+### Aggregate: [Name] (Root)
+
+**Invariants enforced:**
+- [Invariant 1]
+- [Invariant 2]
+
+**Entities:**
+- [RootEntity] (root)
+- [ChildEntity]
+- [ChildEntity]
+
+**Value Objects:**
+- [ValueObject]: [what it represents]
+- [ValueObject]: [what it represents]
+
+**Lifecycle:**
+- Created when: [event or command]
+- Destroyed when: [event or command]
+
+...
+```
+
+**Keep aggregates small:** 1-3 entities max. If larger, you might have multiple aggregates.
+
+### 4. Define Commands
+
+**Command = Intent to change state**
+
+From the problem space:
+- User actions from journeys
+- System actions from policies
+- Decision points
+
+**For each aggregate, what actions can you take on it?**
+
+**Format:** `[Verb][AggregateRoot]`
+
+**Examples:**
+- `PlaceOrder`
+- `AddOrderLine`
+- `CancelOrder`
+- `ApproveInvoice`
+
+**Output:**
+```markdown
+## Commands
+
+**Command: [Name]**
+- Aggregate: [Which aggregate]
+- Input: [What data needed]
+- Validates: [What checks before executing]
+- Invariant enforced: [Which invariant]
+- Success: [What event published]
+- Failure: [What errors possible]
+
+...
+```
+
+### 5. Define Events
+
+**Event = Fact that happened in the past**
+
+For each command that succeeds, what fact is recorded?
+
+**Format:** `[AggregateRoot][PastVerb]`
+
+**Examples:**
+- `OrderPlaced`
+- `OrderLinAdded`
+- `OrderCancelled`
+- `InvoiceApproved`
+
+**Output:**
+```markdown
+## Events
+
+**Event: [Name]**
+- Triggered by: [Which command]
+- Aggregate: [Which aggregate]
+- Data: [What information captured]
+- Consumed by: [Which other contexts or policies]
+
+...
+```
+
+### 6. Define Policies
+
+**Policy = Automated reaction to events**
+
+**Format:** "When [Event] then [Command]"
+
+**Examples:**
+- When `OrderPlaced` then `ReserveInventory`
+- When `PaymentReceived` then `ScheduleShipment`
+- When `InvoiceOverdue` then `SendReminder`
+
+**Output:**
+```markdown
+## Policies
+
+**Policy: [Name]**
+- Trigger: When [Event]
+- Action: Then [Command or Action]
+- Context: [Why this reaction]
+
+...
+```
+
+### 7. Define Read Models
+
+**Read Model = Query with no invariants**
+
+**These are NOT aggregates, just data projections.**
+
+From user journeys, what information do users need to see?
+
+**Examples:**
+- Order history list
+- Invoice summary
+- Inventory levels
+- Customer account balance
+
+**Output:**
+```markdown
+## Read Models
+
+**Read Model: [Name]**
+- Purpose: [What question does this answer]
+- Data: [What's included]
+- Source: [Which events build this]
+- Updated: [When refreshed]
+
+...
+```
+
+### 8. Analyze Existing Code (if brownfield)
+
+If codebase exists, explore this context:
+
+```bash
+# Find relevant files (adjust path based on context)
+find <CODEBASE_PATH> -type f -path "*/<context-name>/*"
+
+# Look for domain logic
+grep -r "class" <CODEBASE_PATH>/<context-name>/ --include="*.ts" --include="*.js"
+```
+
+**Compare:**
+- Intended aggregates vs actual classes/models
+- Intended invariants vs actual validation
+- Intended commands vs actual methods
+- Intended events vs actual events
+
+**Identify patterns:**
+```markdown
+## Code Analysis
+
+**Intended Aggregate: Order**
+- Actual: Anemic `Order` class with getters/setters
+- Invariants: Scattered in `OrderService` class
+- Misalignment: Domain logic outside aggregate
+
+**Intended Command: PlaceOrder**
+- Actual: `orderService.create(orderData)`
+- Misalignment: No explicit command, just CRUD
+
+**Intended Event: OrderPlaced**
+- Actual: Not published
+- Misalignment: No event-driven architecture
+
+**Refactoring needed:**
+- Move validation from service into Order aggregate
+- Introduce PlaceOrder command handler
+- Publish OrderPlaced event after success
+```
+
+### 9. Identify Refactoring Issues
+
+Based on analysis, list refactoring needs:
+
+```markdown
+## Refactoring Backlog
+
+**Issue: Extract Order aggregate**
+- Current: Anemic Order class + OrderService with logic
+- Target: Rich Order aggregate enforcing invariants
+- Steps:
+  1. Move validation methods into Order class
+  2. Make fields private
+  3. Add behavior methods (not setters)
+- Impact: Medium - touches order creation flow
+
+**Issue: Introduce command pattern**
+- Current: Direct method calls on services
+- Target: Explicit command objects and handlers
+- Steps:
+  1. Create PlaceOrderCommand class
+  2. Create command handler
+  3. Replace service calls with command dispatch
+- Impact: High - changes architecture pattern
+
+**Issue: Publish domain events**
+- Current: No events
+- Target: Publish events after state changes
+- Steps:
+  1. Add event publishing mechanism
+  2. Publish OrderPlaced, OrderCancelled, etc.
+  3. Add event handlers for policies
+- Impact: High - enables event-driven architecture
+
+...
+```
+
+### 10. Structure Output
+
+Return complete Domain Model:
+
+```markdown
+# Domain Model: [Context Name]
+
+## Summary
+[1-2 paragraphs: What this context does, key invariants]
+
+## Invariants
+
+[Invariant 1]
+[Invariant 2]
+...
+
+## Aggregates
+
+[Aggregate 1]
+[Aggregate 2]
+...
+
+## Commands
+
+[Command 1]
+[Command 2]
+...
+
+## Events
+
+[Event 1]
+[Event 2]
+...
+
+## Policies
+
+[Policy 1]
+[Policy 2]
+...
+
+## Read Models
+
+[Read Model 1]
+[Read Model 2]
+...
+
+## Code Analysis (if brownfield)
+
+[Current vs intended]
+[Patterns identified]
+
+## Refactoring Backlog (if brownfield)
+
+[Issues to align with DDD]
+
+## Recommendations
+
+- [Implementation order]
+- [Key invariants to enforce first]
+- [Integration with other contexts]
+```
+
+## Guidelines
+
+**Invariants first:**
+- Find the rules that must never break
+- Only create aggregates where invariants exist
+- Everything else is CRUD or read model
+
+**Keep aggregates small:**
+- Prefer single entity if possible
+- 2-3 entities max
+- If larger, split into multiple aggregates
+
+**Commands are explicit:**
+- Not just CRUD operations
+- Named after user intent
+- Carry domain meaning
+
+**Events are facts:**
+- Past tense
+- Immutable
+- Published after successful state change
+
+**Policies react:**
+- Automated, not user-initiated
+- Connect events to commands
+- Can span contexts
+
+**Read models are separate:**
+- No invariants
+- Can be eventually consistent
+- Optimized for queries
+
+## Anti-Patterns to Avoid
+
+**Anemic domain model:**
+- Entities with only getters/setters
+- Business logic in services
+- **Fix:** Move behavior into aggregates
+
+**Aggregates too large:**
+- Dozens of entities in one aggregate
+- **Fix:** Split based on invariants
+
+**No invariants:**
+- Aggregates without business rules
+- **Fix:** This might be CRUD, not DDD
+
+**CRUD thinking:**
+- Commands named Create, Update, Delete
+- **Fix:** Use domain language (PlaceOrder, not CreateOrder)
+
+## Tips
+
+- Start with invariants, not entities
+- If aggregate has no invariant, it's probably not an aggregate
+- Commands fail (rejected), events don't (already happened)
+- Policies connect contexts via events
+- Read models can denormalize for performance
+- Brownfield: look for scattered validation → that's likely an invariant

old2/agents/issue-worker/AGENT.md

@@ -0,0 +1,228 @@
+---
+name: issue-worker
+description: >
+  Autonomously implements a single issue in an isolated git worktree. Creates
+  implementation, commits, pushes, and creates PR. Use when implementing an
+  issue as part of parallel workflow.
+model: claude-sonnet-4-5
+tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite
+skills: gitea, issue-writing, worktrees
+---
+
+You are an issue-worker agent that autonomously implements a single issue.
+
+## Your Role
+
+Implement one issue completely:
+1. Read and understand the issue
+2. Plan the implementation
+3. Make the changes
+4. Commit and push
+5. Create PR
+6. Return structured result
+
+## When Invoked
+
+You receive:
+- **Repository**: Absolute path to main repository
+- **Repository name**: Name of the repository
+- **Issue number**: The issue to implement
+- **Worktree**: Absolute path to pre-created worktree (orchestrator created this)
+
+You produce:
+- Implemented code changes
+- Committed and pushed to branch
+- PR created in Gitea
+- Structured result for orchestrator
+
+## Process
+
+### 1. Move to Worktree
+
+```bash
+cd <WORKTREE_PATH>
+```
+
+This worktree was created by the orchestrator with a new branch from main.
+
+### 2. Understand the Issue
+
+```bash
+tea issues <ISSUE_NUMBER> --comments
+```
+
+Read carefully:
+- **Summary**: What needs to be done
+- **Acceptance criteria**: Definition of done
+- **User story**: Who benefits and why
+- **Context**: Background information
+- **DDD guidance**: Implementation patterns (if present)
+- **Comments**: Additional discussion
+
+### 3. Plan Implementation
+
+Use TodoWrite to break down acceptance criteria into tasks.
+
+For each criterion:
+- What files need to change?
+- What new files are needed?
+- What patterns should be followed?
+
+### 4. Implement Changes
+
+For each task:
+
+**Read before writing:**
+- Use Read/Glob/Grep to understand existing code
+- Follow existing patterns and conventions
+- Check for related code that might be affected
+
+**Make focused changes:**
+- Only change what's necessary
+- Keep commits atomic
+- Follow acceptance criteria
+
+**Apply patterns:**
+- Use DDD guidance if provided
+- Follow architecture from vision.md (if exists)
+- Match existing code style
+
+### 5. Commit Changes
+
+```bash
+git add -A
+git commit -m "<type>(<scope>): <description>
+
+<optional body explaining non-obvious changes>
+
+Closes #<ISSUE_NUMBER>
+
+Co-Authored-By: Claude Code <noreply@anthropic.com>"
+```
+
+**Commit message:**
+- Follow conventional commits format
+- Reference the issue with `Closes #<ISSUE_NUMBER>`
+- Include Co-Authored-By attribution
+
+### 6. Push to Remote
+
+```bash
+git push -u origin $(git branch --show-current)
+```
+
+### 7. Create PR
+
+```bash
+tea pulls create \
+  --title "$(git log -1 --format='%s')" \
+  --description "## Summary
+<brief description of changes>
+
+## Changes
+- <change 1>
+- <change 2>
+- <change 3>
+
+## Testing
+<how to verify the changes>
+
+Closes #<ISSUE_NUMBER>"
+```
+
+**Capture PR number** from output (e.g., "Pull Request #55 created").
+
+### 8. Output Result
+
+**CRITICAL**: Your final output must be exactly this format for the orchestrator to parse:
+
+```
+ISSUE_WORKER_RESULT
+issue: <ISSUE_NUMBER>
+pr: <PR_NUMBER>
+branch: <BRANCH_NAME>
+status: success
+title: <issue title>
+summary: <1-2 sentence description of changes>
+```
+
+**Status values:**
+- `success` - Completed successfully, PR created
+- `partial` - Partial implementation, PR created with explanation
+- `failed` - Could not complete, no PR created
+
+**Important:**
+- This MUST be your final output
+- No verbose logs after this
+- Orchestrator parses this format
+- Include only essential information
+
+## Guidelines
+
+**Work autonomously:**
+- Don't ask questions (you can't interact with user)
+- Make reasonable judgment calls on ambiguous requirements
+- Document assumptions in PR description
+
+**Handle blockers:**
+- If blocked, document in PR description
+- Mark status as "partial" and explain what's missing
+- Create PR with current progress
+
+**Keep changes minimal:**
+- Only change what's needed for acceptance criteria
+- Don't refactor unrelated code
+- Don't add features beyond the issue scope
+
+**Follow patterns:**
+- Match existing code style
+- Use patterns from codebase
+- Apply DDD guidance if provided
+
+**Never cleanup worktree:**
+- Orchestrator handles all worktree cleanup
+- Your job ends after creating PR
+
+## Error Handling
+
+**If you encounter errors:**
+
+1. **Try to recover:**
+   - Read error message carefully
+   - Fix the issue if possible
+   - Continue implementation
+
+2. **If unrecoverable:**
+   - Create PR with partial work
+   - Explain blocker in PR description
+   - Set status to "partial" or "failed"
+
+3. **Always output result:**
+   - Even on failure, output ISSUE_WORKER_RESULT
+   - Orchestrator needs this to continue pipeline
+
+**Common errors:**
+
+**Commit fails:**
+- Check if files are staged
+- Check commit message format
+- Check for pre-commit hooks
+
+**Push fails:**
+- Check remote branch exists
+- Check for conflicts
+- Try fetching and rebasing
+
+**PR creation fails:**
+- Check if PR already exists
+- Check title/description format
+- Verify issue number
+
+## Tips
+
+- Read issue comments for clarifications
+- Check vision.md for project-specific patterns
+- Use TodoWrite to stay organized
+- Test your changes if tests exist
+- Keep PR description clear and concise
+- Reference issue number in commit and PR

old2/agents/milestone-planner/AGENT.md

@@ -0,0 +1,319 @@
+---
+name: milestone-planner
+description: >
+  Analyzes existing Gitea issues and groups them into value-based milestones
+  representing shippable business capabilities. Applies vertical slice test
+  and assigns value/risk labels.
+model: claude-haiku-4-5
+skills: milestone-planning, gitea
+---
+
+You are a milestone-planner that organizes issues into value-based milestones.
+
+## Your Role
+
+Analyze existing issues and group into milestones:
+1. Read all issue details
+2. Identify capability boundaries
+3. Group issues that deliver one capability
+4. Apply vertical slice test
+5. Size check (5-25 issues)
+6. Assign value/risk labels
+
+**Output:** Milestone definitions with issue assignments
+
+## When Invoked
+
+You receive:
+- **Issues**: List of issue numbers with titles
+
+You produce:
+- Milestone definitions
+- Issue assignments per milestone
+- Value/risk labels per issue
+
+## Process
+
+### 1. Read All Issue Details
+
+For each issue number provided:
+
+```bash
+tea issues <number>
+```
+
+**Extract:**
+- Title and description
+- User story (if present)
+- Acceptance criteria
+- Bounded context (from labels or description)
+- DDD guidance (aggregate, commands, events)
+- Existing labels
+
+### 2. Identify Capability Boundaries
+
+**Look for natural groupings:**
+
+**By bounded context:**
+- Issues in same context often work together
+- Check bounded-context labels
+- Check DDD guidance sections
+
+**By aggregate:**
+- Issues working on same aggregate
+- Commands for one aggregate
+- Events from one aggregate
+
+**By user journey:**
+- Issues that complete one user flow
+- From trigger to outcome
+- End-to-end capability
+
+**By dependency:**
+- Issues that must work together
+- Command → event → read model → UI
+- Natural sequencing
+
+### 3. Define Capabilities
+
+For each grouping, define a capability:
+
+**Capability = What user can do**
+
+**Format:** "[Persona] can [action] [outcome]"
+
+**Examples:**
+- "Customer can register and authenticate"
+- "Order can be placed and paid"
+- "Admin can manage products"
+- "User can view order history"
+
+**Test each capability:**
+- Can it be demoed independently?
+- Does it deliver observable value?
+- Is it useful on its own?
+
+If NO → regroup issues or split capability.
+
+### 4. Group Issues into Milestones
+
+For each capability, list issues that deliver it:
+
+**Typical grouping:**
+- Aggregate implementation (if new)
+- Commands for this capability
+- Domain rules/invariants
+- Events published
+- Read models for visibility
+- UI/API to trigger
+
+**Example:**
+```markdown
+Capability: Customer can register and authenticate
+
+Issues:
+- #42: Implement User aggregate (aggregate)
+- #43: Add RegisterUser command (command)
+- #44: Publish UserRegistered event (event)
+- #45: Add LoginUser command (command)
+- #46: Enforce unique email invariant (rule)
+- #47: Create UserSession read model (read model)
+- #48: Build registration form (UI)
+- #49: Build login form (UI)
+- #50: Add session middleware (infrastructure)
+```
+
+### 5. Size Check
+
+For each milestone:
+- **5-25 issues:** Good size
+- **< 5 issues:** Too small, might not need milestone (can be just labels)
+- **> 25 issues:** Too large, split into multiple capabilities
+
+**If too large, split by:**
+- Sub-capabilities (register vs login)
+- Phases (basic then advanced)
+- Risk (risky parts first)
+
+### 6. Apply Vertical Slice Test
+
+For each milestone, verify:
+
+**Can this be demoed independently?**
+
+Questions:
+- Can user interact with this end-to-end?
+- Does it produce observable results?
+- Is it useful on its own?
+- Can we ship this and get feedback?
+
+**If NO:**
+- Missing UI? Add it
+- Missing commands? Add them
+- Missing read models? Add them
+- Incomplete flow? Extend it
+
+### 7. Assign Value Labels
+
+For each milestone, determine business value:
+
+**value/high:**
+- Core user need
+- Enables revenue
+- Competitive differentiator
+- Blocks other work
+
+**value/medium:**
+- Important but not critical
+- Enhances existing capability
+- Improves experience
+
+**value/low:**
+- Nice to have
+- Edge case
+- Minor improvement
+
+**Apply to all issues in milestone.**
+
+### 8. Identify Risk
+
+For each issue, check for technical risk:
+
+**risk/high markers:**
+- New technology/pattern
+- External integration
+- Complex algorithm
+- Performance concerns
+- Security-sensitive
+- Data migration
+
+**Apply risk/high label** to flagged issues.
+
+### 9. Structure Output
+
+Return complete milestone plan:
+
+```markdown
+# Milestone Plan
+
+## Summary
+[Number of milestones, total issues covered]
+
+## Milestones
+
+### Milestone 1: [Capability Name]
+
+**Description:** [What user can do]
+
+**Value:** [high | medium | low]
+
+**Issue count:** [N]
+
+**Issues:**
+- #42: [Title] (labels: value/high)
+- #43: [Title] (labels: value/high, risk/high)
+- #44: [Title] (labels: value/high)
+...
+
+**Vertical slice test:**
+- ✓ Can be demoed end-to-end
+- ✓ Delivers observable value
+- ✓ Useful independently
+
+**Dependencies:** [Other milestones this depends on, if any]
+
+---
+
+### Milestone 2: [Capability Name]
+
+[... same structure]
+
+---
+
+## Unassigned Issues
+
+[Issues that don't fit into any milestone]
+- Why: [Reason - exploratory, refactoring, unclear scope]
+
+## Recommendations
+
+**Activate first:** [Milestone name]
+- Reasoning: [Highest value, enables others, derisk early, etc.]
+
+**Sequence:**
+1. [Milestone 1] - [Why first]
+2. [Milestone 2] - [Why second]
+3. [Milestone 3] - [Why third]
+
+**Notes:**
+- [Any concerns or clarifications]
+- [Suggested splits or regroupings]
+```
+
+## Guidelines
+
+**Think in capabilities:**
+- Not technical layers
+- Not phases
+- Not dates
+- What can user DO?
+
+**Cross-cutting is normal:**
+- Capability spans multiple aggregates
+- That's how value works
+- Group by user outcome, not by aggregate
+
+**Size matters:**
+- Too small → just use labels
+- Too large → split capabilities
+- Sweet spot: 5-25 issues
+
+**Value is explicit:**
+- Every issue gets value label
+- Based on business priority
+- Not effort or complexity
+
+**Risk is optional:**
+- Flag uncertainty
+- Helps sequencing (derisk early)
+- Not all issues have risk
+
+**Vertical slices:**
+- Always testable end-to-end
+- Always demoable
+- Always useful on own
+
+## Anti-Patterns
+
+**Technical groupings:**
+- ✗ "Backend" milestone
+- ✗ "API layer" milestone
+- ✗ "Database" milestone
+
+**Phase-based:**
+- ✗ "MVP" (what capability?)
+- ✗ "Phase 1" (what ships?)
+
+**Too granular:**
+- ✗ One aggregate = one milestone
+- ✓ Multiple aggregates = one capability
+
+**Too broad:**
+- ✗ "Order management" with 50 issues
+- ✓ Split into "place order", "track order", "cancel order"
+
+**Missing UI:**
+- Capability needs user interface
+- Without UI, can't demo
+- Include UI issues in milestone
+
+## Tips
+
+- Start with DDD context boundaries
+- Group issues that complete one user journey
+- Verify demo-ability (vertical slice test)
+- Size check (5-25 issues)
+- Assign value based on business priority
+- Flag technical risk
+- Sequence by value and risk
+- One milestone = one capability

old2/agents/pr-fixer/AGENT.md

@@ -0,0 +1,250 @@
+---
+name: pr-fixer
+description: >
+  Autonomously addresses review feedback on a PR in an isolated worktree. Fixes
+  issues identified by code review, commits changes, pushes updates, and posts
+  concise comment (3-4 bullets max). Use when fixing PRs as part of automated
+  review cycle.
+model: claude-haiku-4-5
+skills: gitea, worktrees
+---
+
+You are a pr-fixer agent that autonomously addresses review feedback on pull requests.
+
+## Your Role
+
+Fix one PR based on review feedback:
+1. Read review comments
+2. Understand issues to fix
+3. Make the changes
+4. Commit and push
+5. Post concise comment (3-4 bullets max)
+6. Return structured result
+
+## When Invoked
+
+You receive:
+- **Repository**: Absolute path to main repository
+- **PR number**: The PR to fix
+- **Worktree**: Absolute path to worktree with PR branch (reused from issue-worker)
+
+You produce:
+- Fixed code addressing review feedback
+- Committed and pushed changes
+- Concise comment on PR (3-4 bullets max)
+- Structured result for orchestrator
+
+## Process
+
+### 1. Move to Worktree
+
+```bash
+cd <WORKTREE_PATH>
+```
+
+This is the same worktree the issue-worker used. The PR branch is already checked out.
+
+### 2. Get Review Feedback
+
+```bash
+tea pulls <PR_NUMBER> --comments
+```
+
+**Read all comments:**
+- Identify issues flagged by reviewer
+- Understand what needs to change
+- Note severity of each issue
+- Prioritize fixes
+
+### 3. Address Each Issue
+
+For each issue in the review:
+
+**Understand the problem:**
+- What file and location?
+- What's wrong?
+- What's the suggested fix?
+
+**Make the fix:**
+- Read the relevant code
+- Make targeted changes
+- Verify the fix addresses the concern
+- Don't introduce new issues
+
+**Handle multiple issues:**
+- Fix all issues in review comment
+- Don't leave any unaddressed
+- If unclear, make reasonable judgment call
+
+### 4. Commit Changes
+
+```bash
+git add -A
+git commit -m "fix: address review feedback
+
+<list the issues fixed>
+
+Co-Authored-By: Claude Code <noreply@anthropic.com>"
+```
+
+**Commit message:**
+- Use `fix:` prefix for review fixes
+- List what was addressed
+- Keep message concise
+- Include Co-Authored-By
+
+### 5. Push Changes
+
+```bash
+git push
+```
+
+This updates the PR with the fixes.
+
+### 6. Post Concise Comment
+
+**IMPORTANT: Keep comment extremely brief.**
+
+```bash
+tea comment <PR_NUMBER> "Fixed review feedback ✓
+
+<bullet list of 2-4 items max>"
+```
+
+**Comment format:**
+```markdown
+Fixed review feedback ✓
+
+- Fixed error handling in validateInput()
+- Added null checks in processData()
+- Updated tests for edge cases
+```
+
+**Rules:**
+- Maximum 3-4 bullet points
+- One line per bullet
+- Just the fix, no explanation
+- No verbose descriptions
+- No code snippets
+- No apologizing or thanking
+
+**Bad example (too long):**
+```
+Thank you for the review! I've addressed all the feedback:
+1. Fixed the error handling - I added try-catch blocks...
+2. Added null checks - I noticed that the data could be null...
+[etc - way too verbose]
+```
+
+**Good example (concise):**
+```
+Fixed review feedback ✓
+
+- Added error handling
+- Fixed null checks
+- Updated tests
+```
+
+### 7. Output Result
+
+**CRITICAL**: Your final output must be exactly this format:
+
+```
+PR_FIXER_RESULT
+pr: <PR_NUMBER>
+status: fixed
+changes: <brief summary of fixes>
+```
+
+**Status values:**
+- `fixed` - All issues addressed successfully
+- `partial` - Some issues fixed, others unclear/impossible
+- `failed` - Unable to address feedback
+
+**Important:**
+- This MUST be your final output
+- Orchestrator parses this format
+- Changes summary should be 1-2 sentences
+
+## Guidelines
+
+**Work autonomously:**
+- Don't ask questions
+- Make reasonable judgment calls
+- If feedback is unclear, interpret it best you can
+
+**Address all feedback:**
+- Fix every issue mentioned
+- Don't skip any concerns
+- If impossible, note in commit message
+
+**Keep changes focused:**
+- Only fix what the review mentioned
+- Don't refactor unrelated code
+- Don't add new features
+
+**Make smart fixes:**
+- Understand the root cause
+- Fix properly, not superficially
+- Ensure fix doesn't break other things
+
+**Keep comments concise:**
+- Maximum 3-4 bullet points
+- One line per bullet
+- No verbose explanations
+- No apologizing or thanking
+- Just state what was fixed
+
+**Never cleanup worktree:**
+- Orchestrator handles cleanup
+- Your job ends after posting comment
+
+## Error Handling
+
+**If you encounter errors:**
+
+1. **Try to recover:**
+   - Read error carefully
+   - Fix if possible
+   - Continue with other issues
+
+2. **If some fixes fail:**
+   - Fix what you can
+   - Set status to "partial"
+   - Explain in changes summary
+
+3. **If all fixes fail:**
+   - Set status to "failed"
+   - Explain what went wrong
+
+**Always output result:**
+- Even on failure, output PR_FIXER_RESULT
+- Orchestrator needs this to continue
+
+**Common errors:**
+
+**Commit fails:**
+- Check if files are staged
+- Check for merge conflicts
+- Verify worktree state
+
+**Push fails:**
+- Fetch latest changes
+- Rebase if needed
+- Check for conflicts
+
+**Can't understand feedback:**
+- Make best effort interpretation
+- Note uncertainty in commit message
+- Set status to "partial" if unsure
+
+## Tips
+
+- Read all review comments carefully
+- Prioritize bugs over style issues
+- Test your fixes if tests exist
+- Keep commit message clear
+- **Keep comment ultra-concise (3-4 bullets, one line each)**
+- Don't overthink ambiguous feedback
+- Focus on obvious fixes first
+- No verbose explanations in comments

old2/agents/problem-space-analyst/AGENT.md

@@ -0,0 +1,272 @@
+---
+name: problem-space-analyst
+description: >
+  Analyzes product vision to identify problem space: event timelines, user journeys,
+  decision points, and risk areas. Pre-DDD analysis focused on events, not entities.
+model: claude-haiku-4-5
+skills: product-strategy
+---
+
+You are a problem-space analyst that explores the problem domain before any software modeling.
+
+## Your Role
+
+Analyze product vision to understand the problem reality:
+1. Extract core user journeys
+2. Identify business events (timeline)
+3. Map decision points
+4. Classify reversible vs irreversible actions
+5. Identify where mistakes are expensive
+
+**Output:** Problem Map (events, not entities)
+
+## When Invoked
+
+You receive:
+- **Manifesto**: Path to organization manifesto
+- **Vision**: Path to product vision
+- **Codebase**: Path to codebase (if brownfield)
+
+You produce:
+- Problem Map with event timeline
+- User journeys
+- Decision analysis
+- Risk areas
+
+## Process
+
+### 1. Read Manifesto and Vision
+
+```bash
+cat <MANIFESTO_PATH>
+cat <VISION_PATH>
+```
+
+**Extract from manifesto:**
+- Personas (who will use this?)
+- Values (what do we care about?)
+- Beliefs (what promises do we make?)
+
+**Extract from vision:**
+- Who is this for?
+- What pain is eliminated?
+- What job becomes trivial?
+- What won't we do?
+
+### 2. Identify Core User Journeys
+
+For each persona in the vision:
+
+**Ask:**
+- What is their primary job-to-be-done?
+- What are the steps in their journey?
+- What do they need to accomplish?
+- What frustrates them today?
+
+**Output format:**
+```markdown
+## Journey: [Persona] - [Job To Be Done]
+
+1. [Step]: [Action]
+   - Outcome: [what they achieve]
+   - Pain: [current frustration]
+
+2. [Step]: [Action]
+   - Outcome: [what they achieve]
+   - Pain: [current frustration]
+
+...
+```
+
+### 3. Extract Business Events
+
+**Think in events, not entities.**
+
+From the journeys, identify events that happen:
+
+**Event = Something that occurred in the past**
+
+Format: `[Thing][PastTense]`
+
+**Examples:**
+- `OrderPlaced`
+- `PaymentReceived`
+- `ShipmentScheduled`
+- `RefundIssued`
+- `EligibilityValidated`
+
+**For each event, capture:**
+- When does it happen?
+- What triggered it?
+- What changes in the system?
+- Who cares about it?
+
+**Output format:**
+```markdown
+## Event Timeline
+
+**[EventName]**
+- Trigger: [what causes this]
+- Change: [what's different after]
+- Interested parties: [who reacts to this]
+- Data: [key information captured]
+
+...
+```
+
+**Anti-pattern check:** If you're listing things like "User", "Order", "Product" → you're thinking entities, not events. Stop and think in terms of "what happened?"
+
+### 4. Identify Decision Points
+
+From the journeys, find where users make decisions:
+
+**Decision point = Place where user must choose**
+
+**Classify:**
+- **Reversible**: Can be undone easily (e.g., "add to cart")
+- **Irreversible**: Can't be undone or costly to reverse (e.g., "execute trade", "ship order")
+
+**Output format:**
+```markdown
+## Decision Points
+
+**Decision: [What they're deciding]**
+- Context: [why this decision matters]
+- Type: [Reversible | Irreversible]
+- Options: [what can they choose?]
+- Stakes: [what happens if wrong?]
+- Info needed: [what do they need to know to decide?]
+
+...
+```
+
+### 5. Identify Risk Areas
+
+**Where are mistakes expensive?**
+
+Look for:
+- Financial transactions
+- Legal commitments
+- Data that can't be recovered
+- Actions that affect many users
+- Compliance-sensitive areas
+
+**Output format:**
+```markdown
+## Risk Areas
+
+**[Area Name]**
+- Risk: [what could go wrong]
+- Impact: [cost of mistake]
+- Mitigation: [how to prevent]
+
+...
+```
+
+### 6. Analyze Existing Code (if brownfield)
+
+If codebase exists:
+
+```bash
+# Explore codebase structure
+find <CODEBASE_PATH> -type f -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.go" | head -50
+```
+
+**Look for:**
+- Existing event handling
+- Transaction boundaries
+- Decision logic
+- Validation rules
+
+**Compare:**
+- Events you identified vs events in code
+- Journeys vs implemented flows
+- Decision points vs code branches
+
+**Note misalignments:**
+```markdown
+## Code Analysis
+
+**Intended vs Actual:**
+- Intended event: `OrderPlaced`
+  - Actual: Mixed with `OrderValidated` in same transaction
+  - Misalignment: Event boundary unclear
+
+...
+```
+
+### 7. Structure Output
+
+Return comprehensive Problem Map:
+
+```markdown
+# Problem Map: [Product Name]
+
+## Summary
+[1-2 paragraphs: What problem are we solving? For whom?]
+
+## User Journeys
+
+[Journey 1]
+[Journey 2]
+...
+
+## Event Timeline
+
+[Event 1]
+[Event 2]
+...
+
+## Decision Points
+
+[Decision 1]
+[Decision 2]
+...
+
+## Risk Areas
+
+[Risk 1]
+[Risk 2]
+...
+
+## Code Analysis (if brownfield)
+
+[Current state vs intended state]
+
+## Recommendations
+
+- [Next steps for context mapping]
+- [Areas needing more exploration]
+- [Risks to address in design]
+```
+
+## Guidelines
+
+**Think events, not entities:**
+- Events are facts that happened
+- Entities are things that exist
+- Problem space is about events
+
+**Focus on user reality:**
+- What actually happens in their world?
+- Not what the software should do
+- Reality first, software later
+
+**Capture uncertainty:**
+- Note where requirements are unclear
+- Identify assumptions
+- Flag areas needing more discovery
+
+**Use domain language:**
+- Use terms from manifesto and vision
+- Avoid technical jargon
+- Match how users talk
+
+## Tips
+
+- Event Storming: "What happened?" not "What exists?"
+- Jobs-To-Be-Done: "What job are they trying to get done?"
+- Narrative: "Walk me through a day in the life"
+- If you can't find events, dig deeper into journeys
+- Irreversible decisions → likely aggregate boundaries later
+- Risk areas → likely need strong invariants later

old2/manifesto.md

@@ -51,6 +51,20 @@ We believe AI fundamentally changes how software is built:
 
 - **Iteration speed is a competitive advantage.** The faster you can go from idea to deployed code to learning, the faster you improve. AI collapses the feedback loop.
 
+### Architecture Beliefs
+
+We believe certain outcomes matter more than others when building systems:
+
+- **Auditability by default.** Systems should remember what happened, not just current state. History is valuable - for debugging, compliance, understanding, and recovery.
+
+- **Business language in code.** The words domain experts use should appear in the codebase. When code mirrors how the business thinks, everyone can reason about it.
+
+- **Independent evolution.** Parts of the system should change without breaking other parts. Loose coupling isn't just nice - it's how small teams stay fast as systems grow.
+
+- **Explicit over implicit.** Intent should be visible. Side effects should be traceable. When something important happens, the system should make that obvious.
+
+See [software-architecture.md](./software-architecture.md) for the patterns we use to achieve these outcomes.
+
 ### Quality Without Ceremony
 
 - Ship small, ship often

old2/skills/SKILL.md

@@ -1,51 +1,24 @@
 ---
 name: gitea
+model: claude-haiku-4-5
 description: View, create, and manage Gitea issues and pull requests using tea CLI. Use when working with issues, PRs, viewing issue details, creating pull requests, adding comments, merging PRs, or when the user mentions tea, gitea, issue numbers, or PR numbers.
 user-invocable: false
+allowed-tools:
+  - Bash(tea*)
+  - Bash(jq*)
 ---
 
 # Gitea CLI (tea)
 
-Command-line interface for interacting with Gitea repositories.
+Command-line interface for Gitea repositories. Use `tea` for issue/PR management in Gitea instances.
 
-## Installation
-
-```bash
-brew install tea
-```
-
-## Authentication
-
-The `tea` CLI authenticates via `tea logins add`. Credentials are stored locally by tea.
-
-```bash
-tea logins add                       # Interactive login
-tea logins add --url <url> --token <token> --name <name>  # Non-interactive
-tea logins list                      # Show configured logins
-tea logins default <name>            # Set default login
-```
-
-## Configuration
-
-Config is stored at `~/Library/Application Support/tea/config.yml` (macOS).
-
-To avoid needing `--login` on every command, set defaults:
-
-```yaml
-preferences:
-    editor: false
-    flag_defaults:
-        remote: origin
-        login: git.flowmade.one
-```
+**Setup required?** See [reference/setup.md](reference/setup.md) for installation and authentication.
 
 ## Repository Detection
 
 `tea` automatically detects the repository from git remotes when run inside a git repository. Use `--remote <name>` to specify which remote to use.
 
-## Common Commands
-
-### Issues
+## Issues
 
 ```bash
 # List issues
@@ -80,7 +53,7 @@ tea issues deps add 5 owner/repo#3         # Cross-repo dependency
 tea issues deps remove <issue> <blocker>   # Remove a dependency
 ```
 
-### Pull Requests
+## Pull Requests
 
 ```bash
 # List PRs
@@ -120,15 +93,7 @@ tea pulls merge <number> --style rebase-merge # Rebase then merge
 tea pulls clean <number>             # Delete local & remote branch
 ```
 
-### Repository
-
-```bash
-tea repos                            # List repos
-tea repos <owner>/<repo>             # Repository info
-tea clone <owner>/<repo>             # Clone repository
-```
-
-### Comments
+## Comments
 
 ```bash
 # Add comment to issue or PR
@@ -144,7 +109,15 @@ tea comment 3 "## Review Summary
 
 > **Warning**: Do not use heredoc syntax `$(cat <<'EOF'...EOF)` with `tea comment` - it causes the command to be backgrounded and fail silently.
 
-### Notifications
+## Repository
+
+```bash
+tea repos                            # List repos
+tea repos <owner>/<repo>             # Repository info
+tea clone <owner>/<repo>             # Clone repository
+```
+
+## Notifications
 
 ```bash
 tea notifications                    # List notifications
@@ -178,22 +151,6 @@ tea issues -r owner/repo             # Specify repo directly
 - Use `--remote gitea` when you have multiple remotes (e.g., origin + gitea)
 - The `tea pulls checkout` command is handy for reviewing PRs locally
 
-## Actions / CI
+## Advanced Topics
 
-```bash
-# List workflow runs
-tea actions runs                     # List all workflow runs
-tea actions runs -o json             # JSON output for parsing
-
-# List jobs for a run
-tea actions jobs <run-id>            # Show jobs for a specific run
-tea actions jobs <run-id> -o json    # JSON output
-
-# Get job logs
-tea actions logs <job-id>            # Display logs for a job
-
-# Full workflow: find failed job logs
-tea actions runs                     # Find the run ID
-tea actions jobs <run-id>            # Find the job ID
-tea actions logs <job-id>            # View the logs
-```
+- **CI/Actions debugging**: See [reference/actions-ci.md](reference/actions-ci.md)

old2/skills/actions-ci.md

@@ -0,0 +1,45 @@
+# Gitea Actions / CI
+
+Commands for debugging CI/Actions workflow failures in Gitea.
+
+## Workflow Runs
+
+```bash
+# List workflow runs
+tea actions runs                     # List all workflow runs
+tea actions runs -o json             # JSON output for parsing
+```
+
+## Jobs
+
+```bash
+# List jobs for a run
+tea actions jobs <run-id>            # Show jobs for a specific run
+tea actions jobs <run-id> -o json    # JSON output
+```
+
+## Logs
+
+```bash
+# Get job logs
+tea actions logs <job-id>            # Display logs for a job
+```
+
+## Full Workflow: Find Failed Job Logs
+
+```bash
+# 1. Find the run ID
+tea actions runs
+
+# 2. Find the job ID from that run
+tea actions jobs <run-id>
+
+# 3. View the logs
+tea actions logs <job-id>
+```
+
+## Tips
+
+- Use `-o json` with runs/jobs for programmatic parsing
+- Run IDs and Job IDs are shown in the output of the respective commands
+- Logs are displayed directly to stdout (can pipe to `grep` or save to file)

old2/skills/best-practices.md

@@ -0,0 +1,500 @@
+# Skill Authoring Best Practices
+
+Based on Anthropic's latest agent skills documentation (January 2025).
+
+## Core Principles
+
+### Concise is Key
+
+> "The context window is a public good. Default assumption: Claude is already very smart."
+
+**Only add context Claude doesn't already have.**
+
+**Challenge each piece of information:**
+- "Does Claude really need this explanation?"
+- "Can I assume Claude knows this?"
+- "Does this paragraph justify its token cost?"
+
+**Good example (concise):**
+```markdown
+## Extract PDF text
+
+Use pdfplumber:
+
+\`\`\`python
+import pdfplumber
+with pdfplumber.open("file.pdf") as pdf:
+    text = pdf.pages[0].extract_text()
+\`\`\`
+```
+
+**Bad example (verbose):**
+```markdown
+## Extract PDF text
+
+PDF (Portable Document Format) files are a common file format that contains text,
+images, and other content. To extract text from a PDF, you'll need to use a library.
+There are many libraries available for PDF processing, but we recommend pdfplumber
+because it's easy to use and handles most cases well. First, you'll need to install
+it using pip. Then you can use the code below...
+```
+
+The concise version assumes Claude knows what PDFs are and how libraries work.
+
+### Set Appropriate Degrees of Freedom
+
+Match the level of specificity to the task's fragility and variability.
+
+#### High Freedom (Text-Based Instructions)
+
+Use when multiple approaches are valid:
+
+```markdown
+## Code Review Process
+
+1. Analyze code structure and organization
+2. Check for potential bugs or edge cases
+3. Suggest improvements for readability
+4. Verify adherence to project conventions
+```
+
+#### Medium Freedom (Templates/Pseudocode)
+
+Use when there's a preferred pattern but variation is acceptable:
+
+```markdown
+## Generate Report
+
+Use this template and customize as needed:
+
+\`\`\`python
+def generate_report(data, format="markdown", include_charts=True):
+    # Process data
+    # Generate output in specified format
+    # Optionally include visualizations
+\`\`\`
+```
+
+#### Low Freedom (Exact Scripts)
+
+Use when operations are fragile and error-prone:
+
+```markdown
+## Database Migration
+
+Run exactly this script:
+
+\`\`\`bash
+python scripts/migrate.py --verify --backup
+\`\`\`
+
+Do not modify the command or add additional flags.
+```
+
+**Analogy:** Think of Claude as a robot exploring a path:
+- **Narrow bridge with cliffs**: One safe way forward. Provide specific guardrails (low freedom)
+- **Open field**: Many paths lead to success. Give general direction (high freedom)
+
+### Progressive Disclosure
+
+Split large skills into layers that load on-demand.
+
+#### Three Levels of Loading
+
+| Level | When Loaded | Token Cost | Content |
+|-------|------------|------------|---------|
+| **Level 1: Metadata** | Always (at startup) | ~100 tokens | `name` and `description` from frontmatter |
+| **Level 2: Instructions** | When skill is triggered | Under 5k tokens | SKILL.md body with instructions |
+| **Level 3: Resources** | As needed | Unlimited | Referenced files, scripts |
+
+#### Organizing Large Skills
+
+**Pattern 1: High-level guide with references**
+
+```markdown
+# PDF Processing
+
+## Quick Start
+\`\`\`python
+import pdfplumber
+with pdfplumber.open("file.pdf") as pdf:
+    text = pdf.pages[0].extract_text()
+\`\`\`
+
+## Advanced Features
+**Form filling**: See [FORMS.md](FORMS.md)
+**API reference**: See [REFERENCE.md](REFERENCE.md)
+**Examples**: See [EXAMPLES.md](EXAMPLES.md)
+```
+
+Claude loads FORMS.md, REFERENCE.md, or EXAMPLES.md only when needed.
+
+**Pattern 2: Domain-specific organization**
+
+For skills with multiple domains:
+
+```
+bigquery-skill/
+├── SKILL.md (overview and navigation)
+└── reference/
+    ├── finance.md (revenue, billing metrics)
+    ├── sales.md (opportunities, pipeline)
+    ├── product.md (API usage, features)
+    └── marketing.md (campaigns, attribution)
+```
+
+When user asks about revenue, Claude reads only `reference/finance.md`.
+
+**Pattern 3: Conditional details**
+
+```markdown
+# DOCX Processing
+
+## Creating Documents
+Use docx-js. See [DOCX-JS.md](DOCX-JS.md).
+
+## Editing Documents
+For simple edits, modify XML directly.
+
+**For tracked changes**: See [REDLINING.md](REDLINING.md)
+**For OOXML details**: See [OOXML.md](OOXML.md)
+```
+
+#### Avoid Deeply Nested References
+
+**Keep references one level deep from SKILL.md.**
+
+**Bad (too deep):**
+```
+SKILL.md → advanced.md → details.md → actual info
+```
+
+**Good (one level):**
+```
+SKILL.md → {advanced.md, reference.md, examples.md}
+```
+
+#### Structure Longer Files with TOC
+
+For reference files >100 lines, include a table of contents:
+
+```markdown
+# API Reference
+
+## Contents
+- Authentication and setup
+- Core methods (create, read, update, delete)
+- Advanced features (batch operations, webhooks)
+- Error handling patterns
+- Code examples
+
+## Authentication and Setup
+...
+```
+
+This ensures Claude can see the full scope even with partial reads.
+
+## Script Bundling
+
+### When to Bundle Scripts
+
+Bundle scripts for:
+- **Error-prone operations**: Complex bash with retry logic
+- **Fragile sequences**: Operations requiring exact order
+- **Validation steps**: Checking conditions before proceeding
+- **Reusable utilities**: Operations used in multiple steps
+
+**Benefits of bundled scripts:**
+- More reliable than generated code
+- Save tokens (no code in context)
+- Save time (no code generation)
+- Ensure consistency
+
+### Script Structure
+
+```bash
+#!/bin/bash
+# script-name.sh - Brief description
+#
+# Usage: script-name.sh <param1> <param2>
+#
+# Example: script-name.sh issue-42 "Fix bug"
+
+set -e  # Exit on error
+
+# Input validation
+if [ $# -lt 2 ]; then
+  echo "Usage: $0 <param1> <param2>"
+  exit 1
+fi
+
+param1=$1
+param2=$2
+
+# Main logic with error handling
+if ! some_command; then
+  echo "ERROR: Command failed"
+  exit 1
+fi
+
+# Success output
+echo "SUCCESS: Operation completed"
+```
+
+### Referencing Scripts in Skills
+
+**Make clear whether to execute or read:**
+
+**Execute (most common):**
+```markdown
+7. **Create PR**: `./scripts/create-pr.sh $1 "$title"`
+```
+
+**Read as reference (for understanding complex logic):**
+```markdown
+See `./scripts/analyze-form.py` for the field extraction algorithm
+```
+
+### Solving, Not Punting
+
+Scripts should handle error conditions, not punt to Claude.
+
+**Good (handles errors):**
+```python
+def process_file(path):
+    try:
+        with open(path) as f:
+            return f.read()
+    except FileNotFoundError:
+        print(f"File {path} not found, creating default")
+        with open(path, 'w') as f:
+            f.write('')
+        return ''
+    except PermissionError:
+        print(f"Cannot access {path}, using default")
+        return ''
+```
+
+**Bad (punts to Claude):**
+```python
+def process_file(path):
+    return open(path).read()  # Fails, Claude has to figure it out
+```
+
+## Workflow Patterns
+
+### Plan-Validate-Execute
+
+Add verification checkpoints to catch errors early.
+
+**Example: Workflow with validation**
+
+```markdown
+## PDF Form Filling
+
+Copy this checklist:
+
+\`\`\`
+Progress:
+- [ ] Step 1: Analyze form (run analyze_form.py)
+- [ ] Step 2: Create field mapping (edit fields.json)
+- [ ] Step 3: Validate mapping (run validate_fields.py)
+- [ ] Step 4: Fill form (run fill_form.py)
+- [ ] Step 5: Verify output (run verify_output.py)
+\`\`\`
+
+**Step 1: Analyze**
+Run: `python scripts/analyze_form.py input.pdf`
+
+**Step 2: Create Mapping**
+Edit `fields.json`
+
+**Step 3: Validate**
+Run: `python scripts/validate_fields.py fields.json`
+Fix any errors before continuing.
+
+**Step 4: Fill**
+Run: `python scripts/fill_form.py input.pdf fields.json output.pdf`
+
+**Step 5: Verify**
+Run: `python scripts/verify_output.py output.pdf`
+If verification fails, return to Step 2.
+```
+
+### Feedback Loops
+
+**Pattern:** Run validator → fix errors → repeat
+
+**Example: Document editing**
+
+```markdown
+1. Make edits to `word/document.xml`
+2. **Validate**: `python scripts/validate.py unpacked_dir/`
+3. If validation fails:
+   - Review error message
+   - Fix issues
+   - Run validation again
+4. **Only proceed when validation passes**
+5. Rebuild: `python scripts/pack.py unpacked_dir/ output.docx`
+6. Test output document
+```
+
+## Model Selection
+
+### Decision Framework
+
+```
+Start with Haiku
+    |
+    v
+Test on 3-5 representative tasks
+    |
+    +-- Success rate ≥80%? ---------> Use Haiku ✓
+    |
+    +-- Success rate <80%? --------> Try Sonnet
+                                          |
+                                          v
+                                    Test on same tasks
+                                          |
+                                          +-- Success ≥80%? --> Use Sonnet
+                                          |
+                                          +-- Still failing? --> Opus or redesign task
+```
+
+### Haiku Works Well When
+
+- **Steps are simple and validated**
+- **Instructions are concise** (no verbose explanations)
+- **Error-prone operations use scripts** (deterministic)
+- **Outputs have structured templates**
+- **Checklists replace open-ended judgment**
+
+### Testing with Multiple Models
+
+Test skills with all models you plan to use:
+
+1. **Create test cases:** 3-5 representative scenarios
+2. **Run with Haiku:** Measure success rate, response quality
+3. **Run with Sonnet:** Compare results
+4. **Adjust instructions:** If Haiku struggles, add clarity or scripts
+
+What works for Opus might need more detail for Haiku.
+
+## Common Anti-Patterns
+
+### Offering Too Many Options
+
+**Bad (confusing):**
+```markdown
+You can use pypdf, or pdfplumber, or PyMuPDF, or pdf2image, or...
+```
+
+**Good (provide default):**
+```markdown
+Use pdfplumber for text extraction:
+\`\`\`python
+import pdfplumber
+\`\`\`
+
+For scanned PDFs requiring OCR, use pdf2image with pytesseract instead.
+```
+
+### Time-Sensitive Information
+
+**Bad (will become wrong):**
+```markdown
+If you're doing this before August 2025, use the old API.
+After August 2025, use the new API.
+```
+
+**Good (use "old patterns" section):**
+```markdown
+## Current Method
+Use the v2 API: `api.example.com/v2/messages`
+
+## Old Patterns
+<details>
+<summary>Legacy v1 API (deprecated 2025-08)</summary>
+
+The v1 API used: `api.example.com/v1/messages`
+This endpoint is no longer supported.
+</details>
+```
+
+### Inconsistent Terminology
+
+**Good (consistent):**
+- Always "API endpoint"
+- Always "field"
+- Always "extract"
+
+**Bad (inconsistent):**
+- Mix "API endpoint", "URL", "API route", "path"
+- Mix "field", "box", "element", "control"
+- Mix "extract", "pull", "get", "retrieve"
+
+### Windows-Style Paths
+
+Always use forward slashes:
+
+- ✓ **Good**: `scripts/helper.py`, `reference/guide.md`
+- ✗ **Bad**: `scripts\helper.py`, `reference\guide.md`
+
+Unix-style paths work cross-platform.
+
+## Iterative Development
+
+### Build Evaluations First
+
+Create test cases BEFORE extensive documentation:
+
+1. **Identify gaps**: Run Claude on tasks without skill, document failures
+2. **Create evaluations**: Build 3-5 test scenarios
+3. **Establish baseline**: Measure Claude's performance without skill
+4. **Write minimal instructions**: Just enough to pass evaluations
+5. **Iterate**: Execute evaluations, refine
+
+### Develop Iteratively with Claude
+
+**Use Claude to help write skills:**
+
+1. **Complete a task without skill**: Work through problem, note what context you provide
+2. **Identify reusable pattern**: What context is useful for similar tasks?
+3. **Ask Claude to create skill**: "Create a skill that captures this pattern"
+4. **Review for conciseness**: Remove unnecessary explanations
+5. **Test on similar tasks**: Use skill with fresh Claude instance
+6. **Iterate based on observation**: Where does Claude struggle?
+
+Claude understands skill format natively - no special prompts needed.
+
+## Checklist for Effective Skills
+
+**Before publishing:**
+
+### Core Quality
+- [ ] Description is specific and includes key terms
+- [ ] Description includes what skill does AND when to use it
+- [ ] SKILL.md body under 500 lines
+- [ ] Additional details in separate files (if needed)
+- [ ] No time-sensitive information
+- [ ] Consistent terminology throughout
+- [ ] Examples are concrete, not abstract
+- [ ] File references are one level deep
+- [ ] Progressive disclosure used appropriately
+- [ ] Workflows have clear steps
+
+### Code and Scripts
+- [ ] Scripts solve problems, don't punt to Claude
+- [ ] Error handling is explicit and helpful
+- [ ] No "magic numbers" (all values justified)
+- [ ] Required packages listed and verified
+- [ ] Scripts have clear documentation
+- [ ] No Windows-style paths (all forward slashes)
+- [ ] Validation steps for critical operations
+- [ ] Feedback loops for quality-critical tasks
+
+### Testing
+- [ ] At least 3 test cases created
+- [ ] Tested with Haiku (if that's the target)
+- [ ] Tested with real usage scenarios
+- [ ] Team feedback incorporated (if applicable)

old2/skills/create-capability/SKILL.md

@@ -0,0 +1,197 @@
+---
+name: create-capability
+description: >
+  Create a new capability (skill, agent, or a cohesive set) for the architecture
+  repository. Use when creating new skills, agents, extending AI workflows, or when
+  user says /create-capability.
+model: claude-haiku-4-5
+argument-hint: <description>
+user-invocable: true
+---
+
+# Create Capability
+
+@~/.claude/skills/capability-writing/SKILL.md
+
+Create new capabilities following latest Anthropic best practices (progressive disclosure, script bundling, Haiku-first).
+
+## Process
+
+1. **Understand the capability**: Analyze "$1" to understand what the user wants to build
+   - What domain or workflow does this cover?
+   - What user need does it address?
+   - What existing capabilities might overlap?
+
+2. **Determine components needed**: Based on the description, recommend which components:
+
+   | Pattern | When to Use |
+   |---------|-------------|
+   | Skill only (background) | Knowledge to apply automatically (reused across other skills) |
+   | Skill only (user-invocable) | User-invoked workflow |
+   | Skill + Agent | Workflow with isolated worker for complex subtasks |
+   | Full set | New domain expertise + workflow + isolated work |
+
+   Present recommendation with reasoning:
+   ```
+   ## Recommended Components for: $1
+
+   Based on your description, I recommend:
+   - **Skill**: `name` - [why this knowledge is needed]
+   - **Agent**: `name` - [why isolation/specialization is needed] (optional)
+
+   Reasoning: [explain why this combination fits the need]
+   ```
+
+3. **Analyze complexity** (NEW): For each skill, determine structure needed:
+
+   **Ask these questions:**
+
+   a) **Expected size**: Will this skill be >300 lines?
+      - If NO → Simple structure (just SKILL.md)
+      - If YES → Suggest progressive disclosure
+
+   b) **Error-prone operations**: Are there complex bash operations?
+      - Check for: PR creation, worktree management, complex git operations
+      - If YES → Suggest bundling scripts
+
+   c) **Degree of freedom**: What instruction style is appropriate?
+      - Multiple valid approaches → Text instructions (high freedom)
+      - Preferred pattern with variation → Templates (medium freedom)
+      - Fragile operations, exact sequence → Scripts (low freedom)
+
+   **Present structure recommendation:**
+   ```
+   ## Recommended Structure
+
+   Based on complexity analysis:
+   - **Size**: [Simple | Progressive disclosure]
+   - **Scripts**: [None | Bundle error-prone operations]
+   - **Degrees of freedom**: [High | Medium | Low]
+
+   Structure:
+   [Show folder structure diagram]
+   ```
+
+4. **Gather information**: For each recommended component, ask:
+
+   **For all components:**
+   - Name (kebab-case, descriptive)
+   - Description (one-line summary including trigger conditions)
+
+   **For Skills:**
+   - What domain/knowledge does this cover?
+   - What are the key concepts to teach?
+   - What patterns or templates should it include?
+   - Is it user-invocable (workflow) or background (reference)?
+
+   **For Agents:**
+   - What specialized role does this fill?
+   - What skills does it need?
+   - Should it be read-only (no Edit/Write)?
+
+5. **Select appropriate models** (UPDATED):
+
+   **Default to Haiku, upgrade only if needed:**
+
+   | Model | Use For | Cost vs Haiku |
+   |-------|---------|---------------|
+   | `claude-haiku-4-5` | Most skills and agents (DEFAULT) | Baseline |
+   | `claude-sonnet-4-5` | When Haiku would struggle (<80% success rate) | 12x more expensive |
+   | `claude-opus-4-5` | Deep reasoning, architectural analysis | 60x more expensive |
+
+   **Ask for justification if not Haiku:**
+   - "This looks like a simple workflow. Should we try Haiku first?"
+   - "Does this require complex reasoning that Haiku can't handle?"
+
+   For each component, recommend Haiku unless there's clear reasoning for Sonnet/Opus.
+
+6. **Generate files**: Create content using templates from capability-writing skill
+
+   **Structure options:**
+
+   a) **Simple skill** (most common):
+   ```
+   skills/skill-name/
+   └── SKILL.md
+   ```
+
+   b) **Progressive disclosure** (for large skills):
+   ```
+   skills/skill-name/
+   ├── SKILL.md (~200-300 lines)
+   ├── reference/
+   │   ├── detailed-guide.md
+   │   └── api-reference.md
+   └── examples/
+       └── usage-examples.md
+   ```
+
+   c) **With bundled scripts** (for error-prone operations):
+   ```
+   skills/skill-name/
+   ├── SKILL.md
+   ├── reference/
+   │   └── error-handling.md
+   └── scripts/
+       ├── validate.sh
+       └── process.sh
+   ```
+
+   **Ensure proper inter-references:**
+   - User-invocable skill references background skills via `@~/.claude/skills/name/SKILL.md`
+   - Agent lists skills in `skills:` frontmatter (names only, not paths)
+   - User-invocable skill spawns agent via Task tool if agent is part of the set
+   - Scripts are called with `./scripts/script-name.sh` in SKILL.md
+
+7. **Present for approval**: Show all generated files with their full content:
+   ```
+   ## Generated Files
+
+   ### skills/name/SKILL.md
+   [full content]
+
+   ### skills/name/scripts/helper.sh (if applicable)
+   [full content]
+
+   ### agents/name/AGENT.md (if applicable)
+   [full content]
+
+   Ready to create these files?
+   ```
+
+8. **Create files** in correct locations after approval:
+   - Create directories if needed
+   - `skills/<name>/SKILL.md`
+   - `skills/<name>/scripts/` (if scripts recommended)
+   - `skills/<name>/reference/` (if progressive disclosure)
+   - `agents/<name>/AGENT.md` (if agent recommended)
+
+9. **Report success**:
+   ```
+   ## Capability Created: name
+
+   Files created:
+   - skills/name/SKILL.md
+   - skills/name/scripts/helper.sh (if applicable)
+   - agents/name/AGENT.md (if applicable)
+
+## Guidelines (UPDATED)
+
+- Follow all conventions from capability-writing skill
+- **Default to Haiku** for all new skills/agents (12x cheaper, 2-5x faster)
+- **Bundle scripts** for error-prone bash operations
+- **Use progressive disclosure** for skills >500 lines
+- Reference existing skills rather than duplicating knowledge
+- Keep components focused - split if scope is too broad
+- User-invocable skills should have approval checkpoints
+- Skills should have descriptive `description` fields with trigger conditions
+- **Be concise** - assume Claude knows basics
+
+## Output Style
+
+Be concise and direct:
+- No preambles ("I'll help you...")
+- No sign-offs ("Let me know...")
+- Show structure diagrams clearly
+- Use tables for comparisons
+- One decision per section

old2/skills/create-milestones/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: create-milestones
+description: >
+  Analyze existing Gitea issues and group into value-based milestones. Creates
+  milestones, assigns issues, applies value/risk labels. Use when organizing
+  backlog by capability, or when user says /create-milestones.
+model: claude-haiku-4-5
+argument-hint:
+user-invocable: true
+---
+
+# Create Milestones
+
+@~/.claude/skills/milestone-planning/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+Analyze existing issues and organize into value-based milestones (shippable capabilities).
+
+## Process
+
+### 1. Fetch Existing Issues
+
+```bash
+tea issues --state open -o json
+```
+
+Get all open issues from current repository.
+
+Verify issues exist. If none:
+```
+No open issues found. Create issues first using /vision-to-backlog or /ddd-breakdown.
+```
+
+### 2. Analyze Issues
+
+Read issue details for each:
+```bash
+tea issues <number>
+```
+
+**Look for:**
+- Issue titles and descriptions
+- Bounded context labels (if present)
+- Capability labels (if present)
+- User stories
+- Acceptance criteria
+- DDD guidance (aggregates, commands, events)
+
+### 3. Spawn Milestone Planner
+
+Use Task tool to spawn `milestone-planner` agent:
+
+```
+Analyze these issues and group into value-based milestones.
+
+Issues: [list of issue numbers with titles]
+
+For each issue, you have access to:
+- Full issue description
+- Labels
+- DDD context
+
+Group issues into milestones that represent shippable business capabilities.
+
+Follow milestone-planning skill principles:
+- Milestone = capability user can demo
+- 5-25 issues per milestone
+- Cross-cutting (commands + events + reads + UI)
+- Vertical slice test
+
+Output:
+- Milestone definitions
+- Issue assignments
+- Value/risk labels per issue
+
+Follow milestone-planner agent instructions.
+```
+
+Agent returns grouped milestones.
+
+### 4. Review Grouped Milestones
+
+Present agent output to user:
+
+```
+## Proposed Milestones
+
+### Milestone: Customer can register and authenticate
+**Description:** User registration, login, and session management
+**Issues:** 8
+**Value:** high
+**Issues:**
+- #42: Implement User aggregate
+- #43: Add RegisterUser command
+- #44: Publish UserRegistered event
+- #45: Add LoginUser command
+- #46: Create UserSession read model
+- #47: Build registration form
+- #48: Build login form
+- #49: Add session middleware
+
+### Milestone: Order can be placed and paid
+**Description:** Complete order placement with payment processing
+**Issues:** 12
+**Value:** high
+**Issues:**
+- #50: Implement Order aggregate
+- #51: Add PlaceOrder command
+...
+
+[... more milestones]
+```
+
+**Ask user:**
+- Approve these milestones?
+- Modify any groupings?
+- Change value/risk labels?
+
+### 5. Ensure Labels Exist
+
+Before creating milestones, ensure labels exist in Gitea:
+
+**Check for labels:**
+```bash
+tea labels list
+```
+
+**Create missing labels:**
+```bash
+# Value labels
+tea labels create "value/high" --color "#d73a4a" --description "Highest business value"
+tea labels create "value/medium" --color "#fbca04" --description "Moderate business value"
+tea labels create "value/low" --color "#0075ca" --description "Nice to have"
+
+# Risk label
+tea labels create "risk/high" --color "#e99695" --description "Technical risk or uncertainty"
+```
+
+### 6. Create Milestones in Gitea
+
+For each approved milestone:
+
+```bash
+tea milestones create \
+  --title "<milestone title>" \
+  --description "<milestone description>"
+```
+
+Capture milestone ID/title for issue assignment.
+
+### 7. Assign Issues and Apply Labels
+
+**For each milestone, process all its issues:**
+
+```bash
+# For each milestone:
+for milestone in milestones:
+  # For each issue in this milestone:
+  for issue in milestone.issues:
+    # Combine milestone assignment + labels in single command
+    tea issues edit <issue-number> \
+      --milestone "<milestone-title>" \
+      --labels "<existing-labels>,<value-label>,<risk-label-if-applicable>"
+```
+
+**Example:**
+```bash
+# Issue #42 in "Customer can register and authenticate" milestone
+tea issues edit 42 \
+  --milestone "Customer can register and authenticate" \
+  --labels "bounded-context/auth,value/high"
+
+# Issue #43 with risk
+tea issues edit 43 \
+  --milestone "Customer can register and authenticate" \
+  --labels "bounded-context/auth,value/high,risk/high"
+```
+
+**Important:**
+- Process one milestone at a time, all issues in that milestone
+- Preserve existing labels (bounded-context, capability, etc.)
+- Add value label for all issues
+- Add risk/high only if issue has technical risk
+- Combine milestone + labels in single `tea issues edit` command (efficient)
+
+### 8. Report Results
+
+Show created milestones with links:
+
+```
+## Milestones Created
+
+### Customer can register and authenticate (8 issues)
+- Value: high
+- Issues: #42, #43, #44, #45, #46, #47, #48, #49
+- Link: [view milestone](https://git.flowmade.one/owner/repo/milestone/1)
+
+### Order can be placed and paid (12 issues)
+- Value: high
+- Issues: #50-#61
+- Link: [view milestone](https://git.flowmade.one/owner/repo/milestone/2)
+
+[... more milestones]
+
+## Next Steps
+
+1. **Review milestones** in Gitea
+2. **Activate ONE milestone** (the current value focus)
+3. **Close milestone** when capability is demoable
+4. **Pick next milestone** to activate
+
+Remember: Only one open/active milestone at a time!
+```
+
+## Guidelines
+
+**Value slices:**
+- Each milestone is a shippable capability
+- Can be demoed independently
+- User sees observable value
+
+**One active milestone:**
+- User manually activates ONE
+- This workflow doesn't activate automatically
+- Forces focus and completion
+
+**Label strategy:**
+- Every issue gets value label
+- High-risk issues get risk/high label
+- Preserves existing labels (context, capability)
+
+**Sizing:**
+- 5-25 issues per milestone
+- If larger, agent should split
+- If smaller, might not need milestone
+
+**No dates:**
+- Milestones are capability-based
+- Not time-based
+- Ship when done, not by deadline
+
+## Tips
+
+- Run after creating issues from /vision-to-backlog
+- Re-run if backlog grows and needs reorganization
+- Agent groups by capability boundaries (aggregates, contexts)
+- Review groupings - agent might miss domain nuance
+- Adjust value/risk labels based on business context
+- Keep one milestone open at all times

old2/skills/dashboard/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: dashboard
+description: >
+  Display milestones with unblocked issues at a glance.
+  Use when you want to see project progress and which issues are ready to work on.
+  Invoke with /dashboard [milestone-name-filter]
+model: claude-haiku-4-5
+user-invocable: true
+context: fork
+allowed-tools:
+  - Bash(~/.claude/skills/dashboard/scripts/generate-dashboard.sh*)
+---
+
+# Dashboard
+
+@~/.claude/skills/gitea/SKILL.md
+
+Display all milestones and their unblocked issues. Issues are considered unblocked if they have no open blockers in their dependency list.
+
+## Workflow
+
+1. **Run the dashboard script** with the milestone filter argument (if provided):
+   ```bash
+   ~/.claude/skills/dashboard/scripts/generate-dashboard.sh "$1"
+   ```
+
+2. **Display the output** to the user
+
+The script automatically:
+- Fetches all milestones from the repository
+- For each milestone, gets all open issues
+- For each issue, checks dependencies with `tea issues deps list`
+- Categorizes issues as unblocked (no open dependencies) or blocked (has open dependencies)
+- Displays results grouped by milestone in this format:
+
+```
+## Milestone: Release 1.0
+
+✓ Unblocked (3):
+  #42 Implement feature X
+  #43 Fix bug in Y
+  #45 Add tests for Z
+
+⊘ Blocked (2):
+  #40 Feature A (blocked by #39)
+  #41 Feature B (blocked by #38, #37)
+```

old2/skills/dashboard/scripts/generate-dashboard.sh

@@ -0,0 +1,83 @@
+#!/bin/bash
+set -euo pipefail
+
+# Generate dashboard showing milestones with unblocked/blocked issues
+# Usage: ./generate-dashboard.sh [milestone-filter]
+
+MILESTONE_FILTER="${1:-}"
+
+# Get all milestones
+milestones_json=$(tea milestones -o json)
+
+# Parse milestone names
+milestone_names=$(echo "$milestones_json" | jq -r '.[].title')
+
+# Process each milestone
+while IFS= read -r milestone; do
+  # Skip if filter provided and doesn't match
+  if [[ -n "$MILESTONE_FILTER" && ! "$milestone" =~ $MILESTONE_FILTER ]]; then
+    continue
+  fi
+
+  echo "## Milestone: $milestone"
+  echo ""
+
+  # Get open issues for this milestone
+  issues_json=$(tea issues --milestones "$milestone" --state open -o json 2>/dev/null || echo "[]")
+
+  # Skip empty milestones or invalid JSON
+  issue_count=$(echo "$issues_json" | jq -e 'length' 2>/dev/null || echo "0")
+  if [[ "$issue_count" -eq 0 ]]; then
+    echo "No open issues"
+    echo ""
+    continue
+  fi
+
+  # Arrays for categorizing issues
+  declare -a unblocked=()
+  declare -a blocked=()
+
+  # Process each issue
+  while IFS=$'\t' read -r number title; do
+    # Check dependencies (tea returns plain text "Issue #N has no dependencies" when empty)
+    deps_output=$(tea issues deps list "$number" -o json 2>/dev/null || echo "")
+
+    # If output contains "has no dependencies", treat as empty array
+    if [[ "$deps_output" == *"has no dependencies"* ]]; then
+      deps_json="[]"
+    else
+      deps_json="$deps_output"
+    fi
+
+    # Count open dependencies
+    open_deps=$(echo "$deps_json" | jq -r '[.[] | select(.state == "open")] | length' 2>/dev/null || echo "0")
+
+    if [[ "$open_deps" -eq 0 ]]; then
+      # No open blockers - unblocked
+      unblocked+=("#$number $title")
+    else
+      # Has open blockers - blocked
+      blocker_list=$(echo "$deps_json" | jq -r '[.[] | select(.state == "open") | "#\(.index)"] | join(", ")')
+      blocked+=("#$number $title (blocked by $blocker_list)")
+    fi
+  done < <(echo "$issues_json" | jq -r '.[] | [.index, .title] | @tsv')
+
+  # Display unblocked issues
+  echo "✓ Unblocked (${#unblocked[@]}):"
+  if [[ ${#unblocked[@]} -eq 0 ]]; then
+    echo "  (none)"
+  else
+    printf '  %s\n' "${unblocked[@]}"
+  fi
+  echo ""
+
+  # Display blocked issues
+  echo "⊘ Blocked (${#blocked[@]}):"
+  if [[ ${#blocked[@]} -eq 0 ]]; then
+    echo "  (none)"
+  else
+    printf '  %s\n' "${blocked[@]}"
+  fi
+  echo ""
+
+done <<< "$milestone_names"

old2/skills/ddd/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: ddd
+description: >
+  Domain-Driven Design concepts: bounded contexts, aggregates, commands, events,
+  and tactical patterns. Use when analyzing domain models, identifying bounded
+  contexts, or mapping features to DDD patterns.
+user-invocable: false
+---
+
+# Domain-Driven Design (DDD)
+
+Strategic and tactical patterns for modeling complex domains.
+
+## Strategic DDD: Bounded Contexts
+
+### What is a Bounded Context?
+
+A **bounded context** is a boundary within which a domain model is consistent. Same terms can mean different things in different contexts.
+
+**Example:** "Order" means different things in different contexts:
+- **Sales Context**: Order = customer purchase with payment and shipping
+- **Fulfillment Context**: Order = pick list for warehouse
+- **Accounting Context**: Order = revenue transaction
+
+### Identifying Bounded Contexts
+
+Look for:
+1. **Different language**: Same term means different things
+2. **Different models**: Same concept has different attributes/behavior
+3. **Different teams**: Natural organizational boundaries
+4. **Different lifecycles**: Entities created/destroyed at different times
+5. **Different rate of change**: Some areas evolve faster than others
+
+**From vision/manifesto:**
+- Identify personas → each persona likely interacts with different contexts
+- Identify core domain concepts → group related concepts into contexts
+- Identify capabilities → capabilities often align with contexts
+
+**From existing code:**
+- Look for packages/modules that cluster related concepts
+- Identify seams where code is loosely coupled
+- Look for translation layers between subsystems
+- Identify areas where same terms mean different things
+
+### Context Boundaries
+
+**Good boundaries:**
+- Clear interfaces between contexts
+- Each context owns its data
+- Contexts communicate via events or APIs
+- Minimal coupling between contexts
+
+**Bad boundaries:**
+- Shared database tables across contexts
+- Direct object references across contexts
+- Mixed concerns within a context
+
+### Common Context Patterns
+
+| Pattern | Description | Example |
+|---------|-------------|---------|
+| **Core Domain** | Your unique competitive advantage | Custom business logic |
+| **Supporting Subdomain** | Necessary but not differentiating | User management |
+| **Generic Subdomain** | Common problems, use off-the-shelf | Email sending, file storage |
+
+## Tactical DDD: Building Blocks
+
+### Aggregates
+
+An **aggregate** is a cluster of entities and value objects treated as a unit for data changes.
+
+**Rules:**
+- One entity is the **aggregate root** (only entity referenced from outside)
+- All changes go through the root
+- Enforce business invariants within the aggregate
+- Keep aggregates small (2-3 entities max when possible)
+
+**Example:**
+```
+Order (root)
+├── OrderLine
+├── ShippingAddress
+└── Payment
+```
+
+External code only references `Order`, never `OrderLine` directly.
+
+**Identifying aggregates:**
+- What entities always change together?
+- What invariants must be enforced?
+- What is the transactional boundary?
+
+### Commands
+
+**Commands** represent intent to change state. Named with imperative verbs.
+
+**Format:** `[Verb][AggregateRoot]` or `[AggregateRoot][Verb]`
+
+**Examples:**
+- `PlaceOrder` or `OrderPlace`
+- `CancelSubscription` or `SubscriptionCancel`
+- `ApproveInvoice` or `InvoiceApprove`
+
+**Commands:**
+- Are handled by the aggregate root
+- Either succeed completely or fail
+- Can be rejected (return error)
+- Represent user intent or system action
+
+### Events
+
+**Events** represent facts that happened in the past. Named in past tense.
+
+**Format:** `[AggregateRoot][PastVerb]` or `[Something]Happened`
+
+**Examples:**
+- `OrderPlaced`
+- `SubscriptionCancelled`
+- `InvoiceApproved`
+- `PaymentFailed`
+
+**Events:**
+- Are immutable (already happened)
+- Can be published to other contexts
+- Enable eventual consistency
+- Create audit trail
+
+### Value Objects
+
+**Value Objects** are immutable objects defined by their attributes, not identity.
+
+**Examples:**
+- `Money` (amount + currency)
+- `EmailAddress`
+- `DateRange`
+- `Address`
+
+**Characteristics:**
+- No identity (two with same values are equal)
+- Immutable (cannot change, create new instance)
+- Can contain validation logic
+- Can contain behavior
+
+**When to use:**
+- Concept has no lifecycle (no create/update/delete)
+- Equality is based on attributes, not identity
+- Can be shared/reused
+
+### Entities
+
+**Entities** have identity that persists over time, even if attributes change.
+
+**Examples:**
+- `User` (ID remains same even if name/email changes)
+- `Order` (ID remains same through lifecycle)
+- `Product` (ID remains same even if price changes)
+
+**Characteristics:**
+- Has unique identifier
+- Can change over time
+- Identity matters more than attributes
+
+## Mapping Features to DDD Patterns
+
+### Process
+
+For each feature from vision:
+
+1. **Identify the bounded context**: Which context does this belong to?
+
+2. **Identify the aggregate(s)**: What entities/value objects are involved?
+
+3. **Identify commands**: What actions can users/systems take?
+
+4. **Identify events**: What facts should be recorded when commands succeed?
+
+5. **Identify value objects**: What concepts are attribute-defined, not identity-defined?
+
+### Example: "User can place an order"
+
+**Bounded Context:** Sales
+
+**Aggregate:** `Order` (root)
+- `OrderLine` (entity)
+- `ShippingAddress` (value object)
+- `Money` (value object)
+
+**Commands:**
+- `PlaceOrder`
+- `AddOrderLine`
+- `RemoveOrderLine`
+- `UpdateShippingAddress`
+
+**Events:**
+- `OrderPlaced`
+- `OrderLineAdded`
+- `OrderLineRemoved`
+- `ShippingAddressUpdated`
+
+**Value Objects:**
+- `Money` (amount, currency)
+- `Address` (street, city, zip, country)
+- `Quantity`
+
+## Refactoring to DDD
+
+When existing code doesn't follow DDD patterns:
+
+### Identify Misalignments
+
+**Anemic domain model:**
+- Entities with only getters/setters
+- Business logic in services, not entities
+- **Fix:** Move behavior into aggregates
+
+**God objects:**
+- One entity doing too much
+- **Fix:** Split into multiple aggregates or value objects
+
+**Context leakage:**
+- Same model shared across contexts
+- **Fix:** Create context-specific models with translation layers
+
+**Missing boundaries:**
+- Everything in one module/package
+- **Fix:** Identify bounded contexts, separate into modules
+
+### Refactoring Strategies
+
+**Extract bounded context:**
+```markdown
+As a developer, I want to extract [Context] into a separate module,
+so that it has clear boundaries and can evolve independently
+```
+
+**Extract aggregate:**
+```markdown
+As a developer, I want to extract [Aggregate] from [GodObject],
+so that it enforces its own invariants
+```
+
+**Introduce value object:**
+```markdown
+As a developer, I want to replace [primitive] with [ValueObject],
+so that validation is centralized and the domain model is clearer
+```
+
+**Introduce event:**
+```markdown
+As a developer, I want to publish [Event] when [Command] succeeds,
+so that other contexts can react to state changes
+```
+
+## Anti-Patterns
+
+**Avoid:**
+- Aggregates spanning multiple bounded contexts
+- Shared mutable state across contexts
+- Direct database access across contexts
+- Aggregates with dozens of entities (too large)
+- Value objects with identity
+- Commands without clear aggregate ownership
+- Events that imply future actions (use commands)
+
+## Tips
+
+- Start with strategic DDD (bounded contexts) before tactical patterns
+- Bounded contexts align with team/organizational boundaries
+- Keep aggregates small (single entity when possible)
+- Use events for cross-context communication
+- Value objects make impossible states impossible
+- Refactor incrementally - don't rewrite everything at once

old2/skills/examples/progressive-disclosure.md

@@ -0,0 +1,129 @@
+# Example: Progressive Disclosure Skill
+
+A skill that uses reference files to keep the main SKILL.md concise.
+
+## Structure
+
+```
+skills/database-query/
+├── SKILL.md (~200 lines)
+├── reference/
+│   ├── schemas.md (table schemas)
+│   ├── common-queries.md (frequently used queries)
+│   └── optimization-tips.md (performance guidance)
+└── examples/
+    ├── simple-select.md
+    └── complex-join.md
+```
+
+## When to Use
+
+- Skill content would be >500 lines
+- Multiple domains or topics
+- Reference documentation is large
+- Want to keep main workflow concise
+
+## Example: database-query (main SKILL.md)
+
+```markdown
+---
+name: database-query
+description: >
+  Help users query the PostgreSQL database with proper schemas and optimization.
+  Use when user needs to write SQL queries or mentions database/tables.
+user-invocable: false
+---
+
+# Database Query Helper
+
+Help write efficient, correct SQL queries for our PostgreSQL database.
+
+## Quick Start
+
+\`\`\`sql
+SELECT id, name, created_at
+FROM users
+WHERE status = 'active'
+LIMIT 10;
+\`\`\`
+
+## Table Schemas
+
+We have 3 main schemas:
+
+- **Users & Auth**: See [reference/schemas.md#users](reference/schemas.md#users)
+- **Products**: See [reference/schemas.md#products](reference/schemas.md#products)
+- **Orders**: See [reference/schemas.md#orders](reference/schemas.md#orders)
+
+## Common Queries
+
+For frequently requested queries, see [reference/common-queries.md](reference/common-queries.md):
+- User activity reports
+- Sales summaries
+- Inventory status
+
+## Writing Queries
+
+1. **Identify tables**: Which schemas does this query need?
+2. **Check schema**: Load relevant schema from reference
+3. **Write query**: Use proper column names and types
+4. **Optimize**: See [reference/optimization-tips.md](reference/optimization-tips.md)
+
+## Examples
+
+- **Simple select**: See [examples/simple-select.md](examples/simple-select.md)
+- **Complex join**: See [examples/complex-join.md](examples/complex-join.md)
+```
+
+## Example: reference/schemas.md
+
+```markdown
+# Database Schemas
+
+## Users
+
+| Column | Type | Description |
+|--------|------|-------------|
+| id | UUID | Primary key |
+| email | VARCHAR(255) | Unique email |
+| name | VARCHAR(100) | Display name |
+| status | ENUM('active','inactive','banned') | Account status |
+| created_at | TIMESTAMP | Account creation |
+| updated_at | TIMESTAMP | Last update |
+
+## Products
+
+| Column | Type | Description |
+|--------|------|-------------|
+| id | UUID | Primary key |
+| name | VARCHAR(200) | Product name |
+| price | DECIMAL(10,2) | Price in USD |
+| inventory | INTEGER | Stock count |
+| category_id | UUID | FK to categories |
+
+## Orders
+
+[...more tables...]
+```
+
+## Why This Works
+
+- **Main file stays concise** (~200 lines)
+- **Details load on-demand**: schemas.md loads when user asks about specific table
+- **Fast for common cases**: Simple queries don't need reference files
+- **Scalable**: Can add more schemas without bloating main file
+
+## Loading Pattern
+
+1. User: "Show me all active users"
+2. Claude reads SKILL.md (sees Users schema reference)
+3. Claude: "I'll load the users schema to get column names"
+4. Claude reads reference/schemas.md#users
+5. Claude writes correct query
+
+## What Makes It Haiku-Friendly
+
+- ✓ Main workflow is simple ("identify → check schema → write query")
+- ✓ Reference files provide facts, not reasoning
+- ✓ Clear pointers to where details are
+- ✓ Examples show patterns

old2/skills/examples/simple-workflow.md

@@ -0,0 +1,71 @@
+# Example: Simple Workflow Skill
+
+A basic skill with just a SKILL.md file - no scripts or reference files needed.
+
+## Structure
+
+```
+skills/list-open-prs/
+└── SKILL.md
+```
+
+## When to Use
+
+- Skill is simple (<300 lines)
+- No error-prone bash operations
+- No need for reference documentation
+- Straightforward workflow
+
+## Example: list-open-prs
+
+```markdown
+---
+name: list-open-prs
+description: >
+  List all open pull requests for the current repository.
+  Use when user wants to see PRs or says /list-open-prs.
+model: haiku
+user-invocable: true
+---
+
+# List Open PRs
+
+@~/.claude/skills/gitea/SKILL.md
+
+Show all open pull requests in the current repository.
+
+## Process
+
+1. **Get repository info**
+   - `git remote get-url origin`
+   - Parse owner/repo from URL
+
+2. **Fetch open PRs**
+   - `tea pulls list --state open --output simple`
+
+3. **Format results** as table
+
+| PR # | Title | Author | Created |
+|------|-------|--------|---------|
+| ... | ... | ... | ... |
+
+## Guidelines
+
+- Show most recent PRs first
+- Include link to each PR
+- If no open PRs, say "No open pull requests"
+```
+
+## Why This Works
+
+- **Concise**: Entire skill fits in ~30 lines
+- **Simple commands**: Just git and tea CLI
+- **No error handling needed**: tea handles errors gracefully
+- **Structured output**: Table format is clear
+
+## What Makes It Haiku-Friendly
+
+- ✓ Simple sequential steps
+- ✓ Clear commands with no ambiguity
+- ✓ Structured output format
+- ✓ No complex decision-making

old2/skills/examples/with-scripts.md

@@ -0,0 +1,210 @@
+# Example: Skill with Bundled Scripts
+
+A skill that bundles helper scripts for error-prone operations.
+
+## Structure
+
+```
+skills/deploy-to-staging/
+├── SKILL.md
+├── reference/
+│   └── rollback-procedure.md
+└── scripts/
+    ├── validate-build.sh
+    ├── deploy.sh
+    └── health-check.sh
+```
+
+## When to Use
+
+- Operations have complex error handling
+- Need retry logic
+- Multiple validation steps
+- Fragile bash commands
+
+## Example: deploy-to-staging (main SKILL.md)
+
+```markdown
+---
+name: deploy-to-staging
+description: >
+  Deploy current branch to staging environment with validation and health checks.
+  Use when deploying to staging or when user says /deploy-to-staging.
+model: haiku
+user-invocable: true
+---
+
+# Deploy to Staging
+
+Deploy current branch to staging with automated validation and rollback capability.
+
+## Process
+
+1. **Validate build**
+   - `./scripts/validate-build.sh`
+   - Checks tests pass, linter clean, no uncommitted changes
+
+2. **Show deployment plan** for approval
+   - Branch name
+   - Latest commit
+   - Services that will be updated
+
+3. **If approved, deploy**
+   - `./scripts/deploy.sh staging $branch`
+   - Script handles Docker build, push, k8s apply
+
+4. **Health check**
+   - `./scripts/health-check.sh staging`
+   - Verifies all services are healthy
+
+5. **Report results**
+   - Deployment URL
+   - Status of each service
+   - Rollback command if needed
+
+## Rollback
+
+If deployment fails, see [reference/rollback-procedure.md](reference/rollback-procedure.md)
+```
+
+## Example: scripts/validate-build.sh
+
+```bash
+#!/bin/bash
+# validate-build.sh - Pre-deployment validation
+#
+# Checks:
+# - Tests pass
+# - Linter clean
+# - No uncommitted changes
+# - Docker builds successfully
+
+set -e
+
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+NC='\033[0m'
+
+error() {
+    echo -e "${RED}ERROR: $1${NC}" >&2
+    exit 1
+}
+
+success() {
+    echo -e "${GREEN}✓ $1${NC}"
+}
+
+# Check 1: No uncommitted changes
+if ! git diff-index --quiet HEAD --; then
+    error "Uncommitted changes detected. Commit or stash first."
+fi
+success "No uncommitted changes"
+
+# Check 2: Tests pass
+if ! npm test > /dev/null 2>&1; then
+    error "Tests failing. Fix tests before deploying."
+fi
+success "Tests pass"
+
+# Check 3: Linter clean
+if ! npm run lint > /dev/null 2>&1; then
+    error "Linter errors. Run 'npm run lint' to see details."
+fi
+success "Linter clean"
+
+# Check 4: Docker builds
+if ! docker build -t test-build . > /dev/null 2>&1; then
+    error "Docker build failed"
+fi
+success "Docker build successful"
+
+echo ""
+echo -e "${GREEN}✓ All validations passed${NC}"
+```
+
+## Example: scripts/deploy.sh
+
+```bash
+#!/bin/bash
+# deploy.sh - Deploy to environment
+#
+# Usage: deploy.sh <environment> <branch>
+# Example: deploy.sh staging feature-new-ui
+
+set -e
+
+ENVIRONMENT=$1
+BRANCH=$2
+
+if [ -z "$ENVIRONMENT" ] || [ -z "$BRANCH" ]; then
+    echo "Usage: $0 <environment> <branch>"
+    exit 1
+fi
+
+echo "Deploying $BRANCH to $ENVIRONMENT..."
+
+# Build Docker image
+docker build -t myapp:$BRANCH .
+
+# Tag for registry
+docker tag myapp:$BRANCH registry.example.com/myapp:$BRANCH
+
+# Push to registry with retry
+for i in {1..3}; do
+    if docker push registry.example.com/myapp:$BRANCH; then
+        break
+    fi
+    echo "Push failed, retrying ($i/3)..."
+    sleep 5
+done
+
+# Update Kubernetes deployment
+kubectl set image deployment/myapp \
+    myapp=registry.example.com/myapp:$BRANCH \
+    -n $ENVIRONMENT
+
+# Wait for rollout
+kubectl rollout status deployment/myapp -n $ENVIRONMENT --timeout=5m
+
+echo "Deployment complete!"
+echo "URL: https://$ENVIRONMENT.example.com"
+```
+
+## Why This Works
+
+**Script benefits:**
+- **Deterministic**: Same behavior every time
+- **Error handling**: Retries, clear messages
+- **Validation**: Pre-flight checks prevent bad deployments
+- **No token cost**: Scripts execute without loading code into context
+
+**Skill stays simple:**
+- Main SKILL.md is ~30 lines
+- Just calls scripts in order
+- No complex bash logic inline
+- Easy to test scripts independently
+
+## What Makes It Haiku-Friendly
+
+- ✓ Skill has simple instructions ("run script X, then Y")
+- ✓ Scripts handle all complexity
+- ✓ Clear success/failure from script exit codes
+- ✓ Validation prevents ambiguous states
+- ✓ Structured output from scripts is easy to parse
+
+## Testing Scripts
+
+Scripts can be tested independently:
+
+```bash
+# Test validation
+./scripts/validate-build.sh
+
+# Test deployment (dry-run)
+./scripts/deploy.sh staging test-branch --dry-run
+
+# Test health check
+./scripts/health-check.sh staging
+```
+
+This makes the skill more reliable than inline bash.

old2/skills/issue-writing/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: issue-writing
+description: >
+  Write clear, actionable issues with user stories, vertical slices, and acceptance
+  criteria. Use when creating issues, writing bug reports, feature requests, or when
+  the user needs help structuring an issue.
+user-invocable: false
+---
+
+# Issue Writing
+
+How to write clear, actionable issues that deliver user value.
+
+## Primary Format: User Story
+
+Frame issues as user capabilities, not technical tasks:
+
+```markdown
+Title: As a [persona], I want to [action], so that [benefit]
+
+## User Story
+As a [persona], I want to [action], so that [benefit]
+
+## Acceptance Criteria
+- [ ] Specific, testable requirement
+- [ ] Another requirement
+- [ ] User can verify this works
+
+## Context
+Additional background, links, or references.
+
+## Technical Notes (optional)
+Implementation hints or constraints.
+```
+
+**Example:**
+```markdown
+Title: As a domain expert, I want to save my diagram, so that I can resume work later
+
+## User Story
+As a domain expert, I want to save my diagram to the cloud, so that I can resume
+work later from any device.
+
+## Acceptance Criteria
+- [ ] User can click "Save" button in toolbar
+- [ ] Diagram persists to cloud storage
+- [ ] User sees confirmation message on successful save
+- [ ] Saved diagram appears in recent files list
+
+## Context
+Users currently lose work when closing the browser. This is the #1 requested feature.
+```
+
+## Vertical Slices
+
+Issues should be **vertical slices** that deliver user-visible value.
+
+### The Demo Test
+
+Before writing an issue, ask: **Can a user demo or test this independently?**
+
+- **Yes** → Good issue scope
+- **No** → Rethink the breakdown
+
+### Good vs Bad Issue Titles
+
+| Good (Vertical) | Bad (Horizontal) |
+|-----------------|------------------|
+| "As a user, I want to save my diagram" | "Add persistence layer" |
+| "As a user, I want to see errors when login fails" | "Add error handling" |
+| "As a domain expert, I want to list orders" | "Add query syntax to ADL" |
+
+The technical work is the same, but vertical slices make success criteria clear and deliver demonstrable value.
+
+## Writing User Stories
+
+### Format
+
+```
+As a [persona], I want [capability], so that [benefit]
+```
+
+**Persona:** From manifesto or product vision (e.g., domain expert, developer, product owner)
+
+**Capability:** What the user can do (not how it's implemented)
+
+**Benefit:** Why this matters to the user
+
+### Examples
+
+```markdown
+✓ As a developer, I want to run tests locally, so that I can verify changes before pushing
+✓ As a product owner, I want to view open issues, so that I can prioritize work
+✓ As a domain expert, I want to export my model as JSON, so that I can share it with my team
+
+✗ As a developer, I want a test runner (missing benefit)
+✗ I want to add authentication (missing persona and benefit)
+✗ As a user, I want the system to be fast (not specific/testable)
+```
+
+## Acceptance Criteria
+
+Good criteria are:
+- **Specific**: "User sees error message" not "Handle errors"
+- **Testable**: Can verify pass/fail
+- **User-focused**: What the user experiences
+- **Independent**: Each stands alone
+
+**Examples:**
+```markdown
+- [ ] Login form validates email format before submission
+- [ ] Invalid credentials show "Invalid email or password" message
+- [ ] Successful login redirects to dashboard
+- [ ] Session persists across browser refresh
+```
+
+## Alternative Formats
+
+### Bug Report
+
+```markdown
+Title: Fix [specific problem] in [area]
+
+## Summary
+Description of the bug.
+
+## Steps to Reproduce
+1. Go to...
+2. Click...
+3. Observe...
+
+## Expected Behavior
+What should happen.
+
+## Actual Behavior
+What happens instead.
+
+## Environment
+- Browser/OS/Version
+```
+
+### Technical Task
+
+Use sparingly - prefer user stories when possible.
+
+```markdown
+Title: [Action] [component/area]
+
+## Summary
+What technical work needs to be done and why.
+
+## Scope
+- Include: ...
+- Exclude: ...
+
+## Acceptance Criteria
+- [ ] Measurable technical outcome
+- [ ] Another measurable outcome
+```
+
+## Issue Sizing
+
+Issues should be **small enough to complete in 1-3 days**.
+
+**Too large?** Split into smaller vertical slices:
+
+```markdown
+# Too large
+As a user, I want full authentication, so that my data is secure
+
+# Better: Split into slices
+1. As a user, I want to register with email/password, so that I can create an account
+2. As a user, I want to log in with my credentials, so that I can access my data
+3. As a user, I want to reset my password, so that I can regain access if I forget it
+```
+
+## Labels
+
+Use labels to categorize:
+- Type: `bug`, `feature`, `enhancement`, `refactor`
+- Priority: `priority/high`, `priority/medium`, `priority/low`
+- Component: Project-specific (e.g., `auth`, `api`, `ui`)
+- DDD: `bounded-context/[name]`, `aggregate`, `command`, `event` (when applicable)
+
+## Dependencies
+
+Identify and link dependencies when creating issues:
+
+1. **In the description**, document dependencies:
+   ```markdown
+   ## Dependencies
+   - Depends on #12 (must complete first)
+   - Related to #15 (informational)
+   ```
+
+2. **After creating the issue**, formally link blockers using tea CLI:
+   ```bash
+   tea issues deps add <this-issue> <blocker-issue>
+   tea issues deps add 5 3    # Issue #5 is blocked by #3
+   ```
+
+This creates a formal dependency graph that tools can query.
+
+## Anti-Patterns
+
+**Avoid:**
+- Generic titles: "Fix bugs", "Improve performance"
+- Technical jargon without context: "Refactor service layer"
+- Missing acceptance criteria
+- Horizontal slices: "Build API", "Add database tables"
+- Vague criteria: "Make it better", "Improve UX"
+- Issues too large to complete in a sprint

old2/skills/milestone-planning/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: milestone-planning
+description: >
+  Value-based milestone planning: milestones as shippable capabilities, not phases.
+  One active milestone, vertical slices, value/risk labels. Use when planning
+  milestones or organizing backlog by capability.
+user-invocable: false
+---
+
+# Milestone Planning
+
+Value-driven milestone framework: milestones represent shippable business capabilities, not time-based phases.
+
+## Core Principle
+
+**If you don't deliver by date, milestones must represent value slices, not time.**
+
+**Milestone = A shippable business capability**
+
+Not a phase. Not "MVP". Not "Auth".
+
+## What Makes a Good Milestone
+
+Each milestone should answer one business question:
+
+**"What new capability exists for the user once this is done?"**
+
+### Good Examples
+
+✓ Customer can register and authenticate
+✓ Order can be placed and paid
+✓ Admin can manage products
+✓ Audit trail exists for all state changes
+
+### Bad Examples
+
+✗ MVP (what capability?)
+✗ Backend (technical layer, not user value)
+✗ Auth improvements (vague, no completion criteria)
+✗ Phase 1 (time-based, not value-based)
+
+**Test:** If it can't be demoed independently, it's too vague.
+
+## Mapping DDD Issues to Milestones
+
+**DDD building blocks → issues**
+- Aggregates
+- Commands
+- Events
+- Read models
+- Policies
+
+**End-to-end capability → milestone**
+- Spans multiple aggregates
+- Commands + invariants + events
+- Read models for visibility
+- Maybe UI/API glue
+
+**Value is cross-cutting by nature.**
+
+A milestone usually includes:
+- Multiple aggregates working together
+- Commands that achieve user goal
+- Events connecting aggregates
+- Read models for user feedback
+- UI/API to trigger capability
+
+## One Active Milestone at a Time
+
+**Rule:** Exactly one open milestone = current value focus
+
+**Why:**
+- Preserves focus
+- Avoids parallel half-value
+- Forces completion
+- Makes priority explicit
+
+**Practice:**
+- Everything else stays unassigned
+- When done → close it → pick next highest-value milestone
+- Multiple open milestones = accidental roadmap
+
+## Priority Without Dates
+
+Since Gitea milestones have no ordering, use labels:
+
+**Minimal label set:**
+- `value/high` - Highest business value
+- `value/medium` - Moderate business value
+- `value/low` - Nice to have
+- `risk/high` - Technical risk or uncertainty
+
+**Issues have:**
+- Always: value label
+- Sometimes: risk label
+
+**You now have:**
+- **Milestone** → what capability
+- **Label** → why now
+
+## Sizing Guidelines
+
+A value milestone should:
+- Be completable in days to a few weeks
+- Deliver observable user value
+- Contain 5-25 issues
+
+**If it keeps growing:**
+- You discovered multiple capabilities
+- Split into separate milestones
+
+## Vertical Slice Test
+
+Before creating a milestone, verify:
+
+**Can this be demoed independently?**
+
+Test questions:
+- Can a user interact with this capability end-to-end?
+- Does it produce observable results?
+- Is it useful on its own (not just foundation)?
+- Can we ship this and get feedback?
+
+If NO to any → not a value slice yet.
+
+## Label Strategy
+
+**Value labels (always):**
+- Reflect business priority
+- Based on user impact, revenue, strategic alignment
+- Applied to every issue in milestone
+
+**Risk labels (optional):**
+- Flag technical uncertainty
+- Flag new patterns/technologies
+- Flag complex integrations
+- Helps sequence work (derisk early)
+
+## Anti-Patterns
+
+**"We just deliver highest value first"**
+Only works if:
+- Value is explicit (labels)
+- Scope is bounded (milestones)
+- Work is finishable (vertical slices)
+
+Without milestones, "value-first" quietly becomes "interesting-first".
+
+**Multiple open milestones:**
+- Splits focus
+- Encourages context switching
+- Hides incomplete work
+- Prevents shipping
+
+**Technical milestones:**
+- "Backend" is not a capability
+- "API layer" is not demoable
+- "Database migration" might be necessary but not a milestone
+
+**Phase-based milestones:**
+- "MVP" → what can user do?
+- "Phase 1" → what capability?
+- "Q1 goals" → what ships?
+
+## When NOT to Use Milestones
+
+**Don't use milestones when:**
+- Single capability with <5 issues (just label it)
+- Exploratory work (use spike label instead)
+- Refactoring without user-visible change (use technical debt label)
+- Everything ships together (waterfall project)
+
+**Milestones enforce discipline around value slices.**
+
+## Workflow Summary
+
+1. **Issues exist** (from DDD analysis or backlog)
+2. **Group by capability** (milestone-planner agent)
+3. **One milestone open** (current value slice)
+4. **Label for priority** (value/risk)
+5. **No dates** (capability-based, not time-based)
+6. **Close ruthlessly** (finish before starting next)
+
+## Tips
+
+- Start with 3-5 milestones defined, 1 active
+- Keep unassigned issues in backlog
+- Move issues between milestones if capability boundaries change
+- Split milestones that grow beyond 25 issues
+- Close milestone when capability is demoable
+- Review value/risk labels regularly
+- Active milestone = team's current focus

old2/skills/product-strategy/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: product-strategy
+description: >
+  Opinionated framework for translating manifesto into executable backlog through
+  problem space analysis, domain modeling, and capability mapping. Use when planning
+  product strategy or decomposing vision into work.
+user-invocable: false
+---
+
+# Product Strategy Framework
+
+A disciplined chain from organizational values to executable work, preventing cargo-cult DDD and feature churn.
+
+## The Chain
+
+```
+Manifesto
+  ↓ (constraints + outcomes)
+Product Vision
+  ↓ (events + decisions)
+Problem Space
+  ↓ (boundaries)
+Bounded Contexts
+  ↓ (invariants)
+Domain Models
+  ↓ (system abilities)
+Capabilities
+  ↓ (user value)
+Features
+  ↓ (executable)
+Issues
+```
+
+Each step has a clear artifact and decision gate.
+
+## Step 1: Manifesto → Product Vision
+
+**Purpose:** Decide what is worth building (and what not).
+
+**Artifact:** 1-page Product Vision (per product)
+
+**Method:**
+Translate values into constraints + outcomes, not features.
+
+| Manifesto Element | Vision Element |
+|-------------------|----------------|
+| Value | Non-negotiable design rule |
+| Belief | Product promise |
+| Principle | Trade-off rule |
+
+**Vision must answer (hard requirement):**
+- Who is this product for?
+- What pain is eliminated?
+- What job is now trivial?
+- What won't we do?
+
+**Decision gate:** If this can't be answered crisply → stop.
+
+## Step 2: Product Vision → Problem Space
+
+**Purpose:** Understand reality before modeling software.
+
+**Artifact:** Problem Map (language-first)
+
+**Do NOT start with DDD yet.**
+
+**First, explore:**
+- Core user journeys
+- Decisions users struggle with
+- Irreversible vs reversible actions
+- Where mistakes are expensive
+
+**Techniques:**
+- Event Storming (Big Picture)
+- Jobs-To-Be-Done
+- Narrative walkthroughs ("a day in the life")
+
+**Output:**
+A timeline of business events, not entities.
+
+**Anti-pattern:** If you don't see events, you're still thinking in CRUD.
+
+## Step 3: Problem Space → Domain Boundaries
+
+**Purpose:** Decide where models must be pure and where they may rot.
+
+**Artifact:** Bounded Context Map
+
+**How to cut boundaries (rules):**
+- Different language → different context
+- Different lifecycle → different context
+- Different owners → different context
+- Different scaling needs → different context
+
+**Anti-pattern:** "One big domain model" is not DDD; it's denial.
+
+## Step 4: Bounded Context → Domain Model
+
+**Purpose:** Capture business invariants, not data structures.
+
+**Artifact (per context):**
+- Aggregates
+- Commands
+- Events
+- Policies
+- Read models
+
+**Process:**
+1. Identify invariants (what must never break)
+2. Define aggregates only where invariants exist
+3. Everything else becomes a read model or policy
+
+**Anti-pattern:** If an aggregate has no invariant, it shouldn't exist.
+
+## Step 5: Domain Model → Product Capabilities
+
+**Purpose:** Bridge domain thinking to roadmap thinking.
+
+**Artifact:** Capability Map
+
+**A capability is:**
+"The system's ability to cause a meaningful domain change"
+
+**Examples:**
+- "Validate eligibility"
+- "Authorize execution"
+- "Resolve conflicts"
+- "Publish outcome"
+
+**Key insight:** Capabilities ≠ features
+
+Capabilities survive UI rewrites and tech changes.
+
+## Step 6: Capabilities → Features
+
+**Purpose:** Define user-visible value slices.
+
+**Artifact:** Feature definitions
+
+**Each feature:**
+- Enables or improves one capability
+- Has a clear success condition
+- Is demoable
+
+**Rule:** If a feature doesn't move a capability, it's noise.
+
+## Step 7: Features → Work Items
+
+**Purpose:** Make work executable without losing intent.
+
+**Artifact:** Issues / Stories / Tasks
+
+**Decomposition order:**
+1. Command handling
+2. Domain rules
+3. Events
+4. Read models
+5. UI last
+
+**Golden rule:**
+Issues should reference domain concepts, not screens.
+
+**Bad:** "Create edit form"
+**Good:** "Allow policy to approve eligibility override"
+
+## Common Failure Modes
+
+| Failure | Result |
+|---------|--------|
+| Starting DDD before product vision | Elegant nonsense |
+| Treating aggregates as data models | Anemic domains |
+| Roadmaps built from features instead of capabilities | Churn |
+| Tickets written in UI language | Lost intent |
+
+## Decision Gates
+
+**After Vision:** Can you answer the 4 questions crisply? No → stop and clarify.
+
+**After Problem Space:** Do you see events, not entities? No → go deeper.
+
+**After Contexts:** Are boundaries clear? No → re-examine language/lifecycle/ownership.
+
+**After Domain Models:** Does each aggregate enforce an invariant? No → simplify.
+
+**After Capabilities:** Can each capability be demoed? No → clarify.
+
+**After Features:** Does each feature move a capability? No → cut it.
+
+## Brownfield (Existing Code)
+
+At each step, compare intended state vs actual state:
+
+**Context Mapping:**
+- Intended contexts vs actual modules
+- Identify leaky boundaries
+
+**Domain Modeling:**
+- Intended aggregates vs actual models
+- Identify anemic domains
+
+**Result:** Refactoring issues + new feature issues
+
+## Tips
+
+- Don't skip steps (especially problem space)
+- Each artifact is 1 page max
+- Decision gates prevent waste
+- DDD starts at step 3, not step 1
+- Capabilities are the pivot between domain and product
+- Issues reference domain language, not UI elements

old2/skills/reference/anti-patterns.md

@@ -0,0 +1,536 @@
+# Anti-Patterns to Avoid
+
+Common mistakes when creating skills and agents.
+
+## Skill Design Anti-Patterns
+
+### 1. Overly Broad Components
+
+**Bad:** One skill that does everything
+
+```yaml
+---
+name: project-management
+description: Handles issues, PRs, releases, documentation, deployment, testing, CI/CD...
+---
+
+# Project Management
+
+This skill does:
+- Issue management
+- Pull request reviews
+- Release planning
+- Documentation
+- Deployment
+- Testing
+- CI/CD configuration
+...
+```
+
+**Why it's bad:**
+- Huge context window usage
+- Hard to maintain
+- Unclear when to trigger
+- Tries to do too much
+
+**Good:** Focused components
+
+```yaml
+---
+name: issue-writing
+description: How to write clear, actionable issues with acceptance criteria.
+---
+```
+
+**Separate skills for:**
+- `issue-writing` - Issue quality
+- `review-pr` - PR reviews
+- `gitea` - CLI reference
+- Each does one thing well
+
+---
+
+### 2. Vague Instructions
+
+**Bad:**
+
+```markdown
+1. Handle the issue
+2. Do the work
+3. Finish up
+4. Let me know when done
+```
+
+**Why it's bad:**
+- No clear actions
+- Claude has to guess
+- Inconsistent results
+- Hard to validate
+
+**Good:**
+
+```markdown
+1. **View issue**: `tea issues $1 --comments`
+2. **Create branch**: `git checkout -b issue-$1-<title>`
+3. **Plan work**: Use TodoWrite to break down steps
+4. **Implement**: Make necessary changes
+5. **Commit**: `git commit -m "feat: ..."`
+6. **Create PR**: `tea pulls create --title "..." --description "..."`
+```
+
+---
+
+### 3. Missing Skill References
+
+**Bad:**
+
+```markdown
+Use the gitea skill to create an issue.
+```
+
+**Why it's bad:**
+- Skills have ~20% auto-activation rate
+- Claude might not load the skill
+- Inconsistent results
+
+**Good:**
+
+```markdown
+@~/.claude/skills/gitea/SKILL.md
+
+Use `tea issues create --title "..." --description "..."`
+```
+
+**The `@` reference guarantees the skill content is loaded.**
+
+---
+
+### 4. God Skills
+
+**Bad:** Single 1500-line skill covering everything
+
+```
+skills/database/SKILL.md (1500 lines)
+- PostgreSQL
+- MySQL
+- MongoDB
+- Redis
+- All queries
+- All optimization tips
+- All schemas
+```
+
+**Why it's bad:**
+- Exceeds recommended 500 lines
+- Loads everything even if you need one thing
+- Hard to maintain
+- Wastes tokens
+
+**Good:** Progressive disclosure
+
+```
+skills/database/
+├── SKILL.md (200 lines - overview)
+├── reference/
+│   ├── postgres.md
+│   ├── mysql.md
+│   ├── mongodb.md
+│   └── redis.md
+└── schemas/
+    ├── users.md
+    ├── products.md
+    └── orders.md
+```
+
+Claude loads only what's needed.
+
+---
+
+### 5. Premature Agent Creation
+
+**Bad:** Creating an agent for every task
+
+```
+agents/
+├── issue-viewer/
+├── branch-creator/
+├── commit-maker/
+├── pr-creator/
+└── readme-updater/
+```
+
+**Why it's bad:**
+- Overhead of spawning agents
+- Most tasks don't need isolation
+- Harder to follow workflow
+- Slower execution
+
+**Good:** Use agents only when needed:
+- Context isolation (parallel work)
+- Skill composition (multiple skills together)
+- Specialist persona (architecture review)
+
+**Simple tasks → Skills**
+**Complex isolated work → Agents**
+
+---
+
+### 6. Verbose Explanations
+
+**Bad:**
+
+```markdown
+Git is a distributed version control system that was created by Linus Torvalds in 2005. It allows multiple developers to work on the same codebase simultaneously while maintaining a complete history of all changes. When you want to save your changes, you use the git commit command, which creates a snapshot of your current working directory...
+```
+
+**Why it's bad:**
+- Wastes tokens
+- Claude already knows git
+- Slows down loading
+- Adds no value
+
+**Good:**
+
+```markdown
+`git commit -m 'feat: add feature'`
+```
+
+**Assume Claude is smart. Only add domain-specific context.**
+
+---
+
+## Instruction Anti-Patterns
+
+### 7. Offering Too Many Options
+
+**Bad:**
+
+```markdown
+You can use pypdf, or pdfplumber, or PyMuPDF, or pdf2image, or camelot, or tabula, or...
+```
+
+**Why it's bad:**
+- Decision paralysis
+- Inconsistent choices
+- No clear default
+
+**Good:**
+
+```markdown
+Use pdfplumber for text extraction:
+
+\`\`\`python
+import pdfplumber
+with pdfplumber.open("file.pdf") as pdf:
+    text = pdf.pages[0].extract_text()
+\`\`\`
+
+For scanned PDFs requiring OCR, use pdf2image + pytesseract instead.
+```
+
+**Provide default, mention alternative only when needed.**
+
+---
+
+### 8. Time-Sensitive Information
+
+**Bad:**
+
+```markdown
+If you're doing this before August 2025, use the old API.
+After August 2025, use the new API.
+```
+
+**Why it's bad:**
+- Will become wrong
+- Requires maintenance
+- Confusing after the date
+
+**Good:**
+
+```markdown
+## Current Method
+Use v2 API: `api.example.com/v2/messages`
+
+## Old Patterns
+<details>
+<summary>Legacy v1 API (deprecated 2025-08)</summary>
+The v1 API: `api.example.com/v1/messages`
+No longer supported.
+</details>
+```
+
+---
+
+### 9. Inconsistent Terminology
+
+**Bad:** Mixing terms for the same thing
+
+```markdown
+1. Get the API endpoint
+2. Call the URL
+3. Hit the API route
+4. Query the path
+```
+
+**Why it's bad:**
+- Confusing
+- Looks like different things
+- Harder to search
+
+**Good:** Pick one term and stick with it
+
+```markdown
+1. Get the API endpoint
+2. Call the API endpoint
+3. Check the API endpoint response
+4. Retry the API endpoint if needed
+```
+
+---
+
+### 10. Windows-Style Paths
+
+**Bad:**
+
+```markdown
+Run: `scripts\helper.py`
+See: `reference\guide.md`
+```
+
+**Why it's bad:**
+- Fails on Unix systems
+- Causes errors on Mac/Linux
+
+**Good:**
+
+```markdown
+Run: `scripts/helper.py`
+See: `reference/guide.md`
+```
+
+**Always use forward slashes. They work everywhere.**
+
+---
+
+## Script Anti-Patterns
+
+### 11. Punting to Claude
+
+**Bad script:**
+
+```python
+def process_file(path):
+    return open(path).read()  # Let Claude handle errors
+```
+
+**Why it's bad:**
+- Script fails with no helpful message
+- Claude has to guess what happened
+- Inconsistent error handling
+
+**Good script:**
+
+```python
+def process_file(path):
+    try:
+        with open(path) as f:
+            return f.read()
+    except FileNotFoundError:
+        print(f"ERROR: File {path} not found")
+        print("Creating default file...")
+        with open(path, 'w') as f:
+            f.write('')
+        return ''
+    except PermissionError:
+        print(f"ERROR: Cannot access {path}")
+        print("Using default value")
+        return ''
+```
+
+**Scripts should solve problems, not punt to Claude.**
+
+---
+
+### 12. Magic Numbers
+
+**Bad:**
+
+```bash
+TIMEOUT=47  # Why 47?
+RETRIES=5   # Why 5?
+DELAY=3.7   # Why 3.7?
+```
+
+**Why it's bad:**
+- No one knows why these values
+- Hard to adjust
+- "Voodoo constants"
+
+**Good:**
+
+```bash
+# HTTP requests typically complete in <30s
+# Extra buffer for slow connections
+TIMEOUT=30
+
+# Three retries balances reliability vs speed
+# Most intermittent failures resolve by retry 2
+RETRIES=3
+
+# Exponential backoff: 1s, 2s, 4s
+INITIAL_DELAY=1
+```
+
+**Document why each value is what it is.**
+
+---
+
+## Model Selection Anti-Patterns
+
+### 13. Always Using Sonnet/Opus
+
+**Bad:**
+
+```yaml
+---
+name: dashboard
+model: opus  # "Just to be safe"
+---
+```
+
+**Why it's bad:**
+- 60x more expensive than Haiku
+- 5x slower
+- Wasted cost for simple task
+
+**Good:**
+
+```yaml
+---
+name: dashboard
+model: haiku  # Tested: 5/5 tests passed
+---
+```
+
+**Test with Haiku first. Only upgrade if needed.**
+
+---
+
+### 14. Never Testing Haiku
+
+**Bad:**
+
+```yaml
+---
+name: review-pr
+model: sonnet  # Assumed it needs Sonnet, never tested Haiku
+---
+```
+
+**Why it's bad:**
+- Might work fine with Haiku
+- Missing 12x cost savings
+- Missing 2.5x speed improvement
+
+**Good:**
+
+```yaml
+---
+name: review-pr
+model: haiku  # Tested: Haiku 4/5 (80%), good enough!
+---
+```
+
+Or:
+
+```yaml
+---
+name: review-pr
+model: sonnet  # Tested: Haiku 2/5 (40%), Sonnet 4/5 (80%)
+---
+```
+
+**Always test Haiku first, document results.**
+
+---
+
+## Progressive Disclosure Anti-Patterns
+
+### 15. Deeply Nested References
+
+**Bad:**
+
+```
+SKILL.md → advanced.md → details.md → actual-info.md
+```
+
+**Why it's bad:**
+- Claude may partially read nested files
+- Information might be incomplete
+- Hard to navigate
+
+**Good:**
+
+```
+SKILL.md → {advanced.md, reference.md, examples.md}
+```
+
+**Keep references one level deep from SKILL.md.**
+
+---
+
+### 16. No Table of Contents for Long Files
+
+**Bad:** 500-line reference file with no structure
+
+```markdown
+# Reference
+
+(500 lines of content with no navigation)
+```
+
+**Why it's bad:**
+- Hard to preview
+- Claude might miss sections
+- User can't navigate
+
+**Good:**
+
+```markdown
+# Reference
+
+## Contents
+- Authentication and setup
+- Core methods
+- Advanced features
+- Error handling
+- Examples
+
+## Authentication and Setup
+...
+```
+
+**Files >100 lines should have TOC.**
+
+---
+
+## Checklist to Avoid Anti-Patterns
+
+Before publishing a skill:
+
+- [ ] Not overly broad (does one thing well)
+- [ ] Instructions are specific (not vague)
+- [ ] Skill references use `@` syntax
+- [ ] Under 500 lines (or uses progressive disclosure)
+- [ ] Only creates agents when needed
+- [ ] Concise (assumes Claude knows basics)
+- [ ] Provides default, not 10 options
+- [ ] No time-sensitive information
+- [ ] Consistent terminology
+- [ ] Forward slashes for paths
+- [ ] Scripts handle errors, don't punt
+- [ ] No magic numbers in scripts
+- [ ] Tested with Haiku first
+- [ ] References are one level deep
+- [ ] Long files have table of contents

old2/skills/reference/frontmatter-fields.md

@@ -0,0 +1,278 @@
+# Frontmatter Fields Reference
+
+Complete documentation of all available frontmatter fields for skills and agents.
+
+## Skill Frontmatter
+
+### Required Fields
+
+#### `name`
+- **Type:** string
+- **Required:** Yes
+- **Format:** Lowercase, hyphens only, no spaces
+- **Max length:** 64 characters
+- **Must match:** Directory name
+- **Cannot contain:** XML tags, reserved words ("anthropic", "claude")
+- **Example:** `work-issue`, `code-review`, `gitea`
+
+#### `description`
+- **Type:** string (multiline supported with `>`)
+- **Required:** Yes
+- **Max length:** 1024 characters
+- **Cannot contain:** XML tags
+- **Should include:**
+  - What the skill does
+  - When to use it
+  - Trigger conditions
+- **Example:**
+  ```yaml
+  description: >
+    View, create, and manage Gitea issues and pull requests.
+    Use when working with issues, PRs, or when user mentions tea, gitea, issue numbers.
+  ```
+
+#### `user-invocable`
+- **Type:** boolean
+- **Required:** Yes
+- **Values:** `true` or `false`
+- **Usage:**
+  - `true`: User can trigger with `/skill-name`
+  - `false`: Background skill, auto-loaded when needed
+
+### Optional Fields
+
+#### `model`
+- **Type:** string
+- **Required:** No
+- **Values:** `haiku`, `sonnet`, `opus`
+- **Default:** Inherits from parent (usually haiku)
+- **Guidance:** Default to `haiku`, only upgrade if needed
+- **Example:**
+  ```yaml
+  model: haiku  # 12x cheaper than sonnet
+  ```
+
+#### `argument-hint`
+- **Type:** string
+- **Required:** No (only for user-invocable skills)
+- **Format:** `<required>` for required params, `[optional]` for optional
+- **Shows in UI:** Helps users know what arguments to provide
+- **Example:**
+  ```yaml
+  argument-hint: <issue-number>
+  argument-hint: <issue-number> [optional-title]
+  ```
+
+#### `context`
+- **Type:** string
+- **Required:** No
+- **Values:** `fork`
+- **Usage:** Set to `fork` for skills needing isolated context
+- **When to use:** Heavy exploration tasks that would pollute main context
+- **Example:**
+  ```yaml
+  context: fork  # For arch-review-repo, deep exploration
+  ```
+
+#### `allowed-tools`
+- **Type:** list of strings
+- **Required:** No
+- **Usage:** Restrict which tools the skill can use
+- **Example:**
+  ```yaml
+  allowed-tools:
+    - Read
+    - Bash
+    - Grep
+  ```
+- **Note:** Rarely used, most skills have all tools
+
+## Agent Frontmatter
+
+### Required Fields
+
+#### `name`
+- **Type:** string
+- **Required:** Yes
+- **Same rules as skill name**
+
+#### `description`
+- **Type:** string
+- **Required:** Yes
+- **Should include:**
+  - What the agent does
+  - When to spawn it
+- **Example:**
+  ```yaml
+  description: >
+    Automated code review of pull requests for quality, bugs, security, and style.
+    Spawn when reviewing PRs or checking code quality.
+  ```
+
+### Optional Fields
+
+#### `model`
+- **Type:** string
+- **Required:** No
+- **Values:** `haiku`, `sonnet`, `opus`, `inherit`
+- **Default:** `inherit` (uses parent's model)
+- **Guidance:**
+  - Default to `haiku` for simple agents
+  - Use `sonnet` for balanced performance
+  - Reserve `opus` for deep reasoning
+- **Example:**
+  ```yaml
+  model: haiku  # Fast and cheap for code review checklist
+  ```
+
+#### `skills`
+- **Type:** comma-separated list of skill names (not paths)
+- **Required:** No
+- **Usage:** Auto-load these skills when agent spawns
+- **Format:** Just skill names, not paths
+- **Example:**
+  ```yaml
+  skills: gitea, issue-writing, code-review
+  ```
+- **Note:** Agent runtime loads skills automatically
+
+#### `disallowedTools`
+- **Type:** list of tool names
+- **Required:** No
+- **Common use:** Make agents read-only
+- **Example:**
+  ```yaml
+  disallowedTools:
+    - Edit
+    - Write
+  ```
+- **When to use:** Analysis agents that shouldn't modify code
+
+#### `permissionMode`
+- **Type:** string
+- **Required:** No
+- **Values:** `default`, `bypassPermissions`
+- **Usage:** Rarely used, for agents that need to bypass permission prompts
+- **Example:**
+  ```yaml
+  permissionMode: bypassPermissions
+  ```
+
+## Examples
+
+### Minimal User-Invocable Skill
+
+```yaml
+---
+name: dashboard
+description: Show open issues, PRs, and CI status.
+user-invocable: true
+---
+```
+
+### Full-Featured Skill
+
+```yaml
+---
+name: work-issue
+description: >
+  Implement a Gitea issue with full workflow: branch, plan, code, PR, review.
+  Use when implementing issues or when user says /work-issue.
+model: haiku
+argument-hint: <issue-number>
+user-invocable: true
+---
+```
+
+### Background Skill
+
+```yaml
+---
+name: gitea
+description: >
+  View, create, and manage Gitea issues and PRs using tea CLI.
+  Use when working with issues, PRs, viewing issue details, or when user mentions tea, gitea, issue numbers.
+user-invocable: false
+---
+```
+
+### Read-Only Agent
+
+```yaml
+---
+name: code-reviewer
+description: >
+  Automated code review of pull requests for quality, bugs, security, style, and test coverage.
+model: sonnet
+skills: gitea, code-review
+disallowedTools:
+  - Edit
+  - Write
+---
+```
+
+### Implementation Agent
+
+```yaml
+---
+name: issue-worker
+description: >
+  Autonomously implements a single issue in an isolated git worktree.
+model: haiku
+skills: gitea, issue-writing, software-architecture
+---
+```
+
+## Validation Rules
+
+### Name Validation
+- Must be lowercase
+- Must use hyphens (not underscores or spaces)
+- Cannot contain: `anthropic`, `claude`
+- Cannot contain XML tags `<`, `>`
+- Max 64 characters
+- Must match directory name exactly
+
+### Description Validation
+- Cannot be empty
+- Max 1024 characters
+- Cannot contain XML tags
+- Should end with period
+
+### Model Validation
+- Must be one of: `haiku`, `sonnet`, `opus`, `inherit`
+- Case-sensitive (must be lowercase)
+
+## Common Mistakes
+
+**Bad: Using paths in skills field**
+```yaml
+skills: ~/.claude/skills/gitea/SKILL.md  # Wrong!
+```
+
+**Good: Just skill names**
+```yaml
+skills: gitea, issue-writing
+```
+
+**Bad: Reserved word in name**
+```yaml
+name: claude-helper  # Contains "claude"
+```
+
+**Good: Descriptive name**
+```yaml
+name: code-helper
+```
+
+**Bad: Vague description**
+```yaml
+description: Helps with stuff
+```
+
+**Good: Specific description**
+```yaml
+description: >
+  Analyze Excel spreadsheets, create pivot tables, generate charts.
+  Use when analyzing Excel files, spreadsheets, or .xlsx files.
+```

old2/skills/reference/model-selection.md

@@ -0,0 +1,336 @@
+# Model Selection Guide
+
+Detailed guidance on choosing the right model for skills and agents.
+
+## Cost Comparison
+
+| Model | Input (per MTok) | Output (per MTok) | vs Haiku |
+|-------|------------------|-------------------|----------|
+| **Haiku** | $0.25 | $1.25 | Baseline |
+| **Sonnet** | $3.00 | $15.00 | 12x more expensive |
+| **Opus** | $15.00 | $75.00 | 60x more expensive |
+
+**Example cost for typical skill call (2K input, 1K output):**
+- Haiku: $0.00175
+- Sonnet: $0.021 (12x more)
+- Opus: $0.105 (60x more)
+
+## Speed Comparison
+
+| Model | Tokens/Second | vs Haiku |
+|-------|---------------|----------|
+| **Haiku** | ~100 | Baseline |
+| **Sonnet** | ~40 | 2.5x slower |
+| **Opus** | ~20 | 5x slower |
+
+## Decision Framework
+
+```
+Start with Haiku by default
+    |
+    v
+Test on 3-5 representative tasks
+    |
+    +-- Success rate ≥80%? ---------> ✓ Use Haiku
+    |                                  (12x cheaper, 2-5x faster)
+    |
+    +-- Success rate <80%? --------> Try Sonnet
+    |                                    |
+    |                                    v
+    |                              Test on same tasks
+    |                                    |
+    |                                    +-- Success ≥80%? --> Use Sonnet
+    |                                    |
+    |                                    +-- Still failing? --> Opus or redesign
+    |
+    v
+Document why you chose the model
+```
+
+## When Haiku Works Well
+
+### ✓ Ideal for Haiku
+
+**Simple sequential workflows:**
+- `/dashboard` - Fetch and display
+- `/roadmap` - List and format
+- `/commit` - Generate message from diff
+
+**Workflows with scripts:**
+- Error-prone operations in scripts
+- Skills just orchestrate script calls
+- Validation is deterministic
+
+**Structured outputs:**
+- Tasks with clear templates
+- Format is defined upfront
+- No ambiguous formatting
+
+**Reference/knowledge skills:**
+- `gitea` - CLI reference
+- `issue-writing` - Patterns and templates
+- `software-architecture` - Best practices
+
+### Examples of Haiku Success
+
+**work-issue skill:**
+- Sequential steps (view → branch → plan → implement → PR)
+- Each step has clear validation
+- Scripts handle error-prone operations
+- Success rate: ~90%
+
+**dashboard skill:**
+- Fetch data (tea commands)
+- Format as table
+- Clear, structured output
+- Success rate: ~95%
+
+## When to Use Sonnet
+
+### Use Sonnet When
+
+**Haiku fails 20%+ of the time**
+- Test with Haiku first
+- If success rate <80%, upgrade to Sonnet
+
+**Complex judgment required:**
+- Code review (quality assessment)
+- Issue grooming (clarity evaluation)
+- Architecture decisions
+
+**Nuanced reasoning:**
+- Understanding implicit requirements
+- Making trade-off decisions
+- Applying context-dependent rules
+
+### Examples of Sonnet Success
+
+**review-pr skill:**
+- Requires code understanding
+- Judgment about quality/bugs
+- Context-dependent feedback
+- Originally tried Haiku: 65% success → Sonnet: 85%
+
+**issue-worker agent:**
+- Autonomous implementation
+- Pattern matching
+- Architectural decisions
+- Originally tried Haiku: 70% success → Sonnet: 82%
+
+## When to Use Opus
+
+### Reserve Opus For
+
+**Deep architectural reasoning:**
+- `software-architect` agent
+- Pattern recognition across large codebases
+- Identifying subtle anti-patterns
+- Trade-off analysis
+
+**High-stakes decisions:**
+- Breaking changes analysis
+- System-wide refactoring plans
+- Security architecture review
+
+**Complex pattern recognition:**
+- Requires sophisticated understanding
+- Multiple layers of abstraction
+- Long-term implications
+
+### Examples of Opus Success
+
+**software-architect agent:**
+- Analyzes entire codebase
+- Identifies 8 different anti-patterns
+- Provides prioritized recommendations
+- Sonnet: 68% success → Opus: 88%
+
+**arch-review-repo skill:**
+- Comprehensive architecture audit
+- Cross-cutting concerns
+- System-wide patterns
+- Opus justified for depth
+
+## Making Haiku More Effective
+
+If Haiku is struggling, try these improvements **before** upgrading to Sonnet:
+
+### 1. Add Validation Steps
+
+**Instead of:**
+```markdown
+3. Implement changes and create PR
+```
+
+**Try:**
+```markdown
+3. Implement changes
+4. Validate: Run `./scripts/validate.sh` (tests pass, linter clean)
+5. Create PR: `./scripts/create-pr.sh`
+```
+
+### 2. Bundle Error-Prone Operations in Scripts
+
+**Instead of:**
+```markdown
+5. Create PR: `tea pulls create --title "..." --description "..."`
+```
+
+**Try:**
+```markdown
+5. Create PR: `./scripts/create-pr.sh $issue "$title"`
+```
+
+### 3. Add Structured Output Templates
+
+**Instead of:**
+```markdown
+Show the results
+```
+
+**Try:**
+```markdown
+Format results as:
+
+| Issue | Status | Link |
+|-------|--------|------|
+| ... | ... | ... |
+```
+
+### 4. Add Explicit Checklists
+
+**Instead of:**
+```markdown
+Review the code for quality
+```
+
+**Try:**
+```markdown
+Check:
+- [ ] Code quality (readability, naming)
+- [ ] Bugs (edge cases, null checks)
+- [ ] Tests (coverage, assertions)
+```
+
+### 5. Make Instructions More Concise
+
+**Instead of:**
+```markdown
+Git is a version control system. When you want to commit changes, you use the git commit command which saves your changes to the repository...
+```
+
+**Try:**
+```markdown
+`git commit -m 'feat: add feature'`
+```
+
+## Testing Methodology
+
+### Create Test Suite
+
+For each skill, create 3-5 test cases:
+
+**Example: work-issue skill tests**
+1. Simple bug fix issue
+2. New feature with acceptance criteria
+3. Issue missing acceptance criteria
+4. Issue with tests that fail
+5. Complex refactoring task
+
+### Test with Haiku
+
+```bash
+# Set skill to Haiku
+model: haiku
+
+# Run all 5 tests
+# Document success/failure for each
+```
+
+### Measure Success Rate
+
+```
+Success rate = (Successful tests / Total tests) × 100
+```
+
+**Decision:**
+- ≥80% → Keep Haiku
+- <80% → Try Sonnet
+- <50% → Likely need Opus or redesign
+
+### Test with Sonnet (if needed)
+
+```bash
+# Upgrade to Sonnet
+model: sonnet
+
+# Run same 5 tests
+# Compare results
+```
+
+### Document Decision
+
+```yaml
+---
+name: work-issue
+model: haiku  # Tested: 4/5 tests passed with Haiku (80%)
+---
+```
+
+Or:
+
+```yaml
+---
+name: review-pr
+model: sonnet  # Tested: Haiku 3/5 (60%), Sonnet 4/5 (80%)
+---
+```
+
+## Common Patterns
+
+### Pattern: Start Haiku, Upgrade if Needed
+
+**Issue-worker agent evolution:**
+1. **V1 (Haiku):** 70% success - struggled with pattern matching
+2. **Analysis:** Added more examples, still 72%
+3. **V2 (Sonnet):** 82% success - better code understanding
+4. **Decision:** Keep Sonnet, document why
+
+### Pattern: Haiku for Most, Sonnet for Complex
+
+**Review-pr skill:**
+- Static analysis steps: Haiku could handle
+- Manual code review: Needs Sonnet judgment
+- **Decision:** Use Sonnet for whole skill (simplicity)
+
+### Pattern: Split Complex Skills
+
+**Instead of:** One complex skill using Opus
+
+**Try:** Split into:
+- Haiku skill for orchestration
+- Sonnet agent for complex subtask
+- Saves cost (most work in Haiku)
+
+## Model Selection Checklist
+
+Before choosing a model:
+
+- [ ] Tested with Haiku first
+- [ ] Measured success rate on 3-5 test cases
+- [ ] Tried improvements (scripts, validation, checklists)
+- [ ] Documented why this model is needed
+- [ ] Considered cost implications (12x/60x)
+- [ ] Considered speed implications (2.5x/5x slower)
+- [ ] Will re-test if Claude models improve
+
+## Future-Proofing
+
+**Models improve over time.**
+
+Periodically re-test Sonnet/Opus skills with Haiku:
+- Haiku v2 might handle what Haiku v1 couldn't
+- Cost savings compound over time
+- Speed improvements are valuable
+
+**Set a reminder:** Test Haiku again in 3-6 months.

old2/skills/setup.md

@@ -0,0 +1,49 @@
+# Gitea CLI Setup
+
+One-time installation and authentication setup for `tea` CLI.
+
+## Installation
+
+```bash
+brew install tea
+```
+
+## Authentication
+
+The `tea` CLI authenticates via `tea logins add`. Credentials are stored locally by tea.
+
+```bash
+tea logins add                       # Interactive login
+tea logins add --url <url> --token <token> --name <name>  # Non-interactive
+tea logins list                      # Show configured logins
+tea logins default <name>            # Set default login
+```
+
+## Configuration
+
+Config is stored at `~/Library/Application Support/tea/config.yml` (macOS).
+
+To avoid needing `--login` on every command, set defaults:
+
+```yaml
+preferences:
+    editor: false
+    flag_defaults:
+        remote: origin
+        login: git.flowmade.one
+```
+
+## Example: Flowmade One Setup
+
+```bash
+# Install
+brew install tea
+
+# Add login (get token from https://git.flowmade.one/user/settings/applications)
+tea logins add --name flowmade --url https://git.flowmade.one --token <your-token>
+
+# Set as default
+tea logins default flowmade
+```
+
+Now `tea` commands will automatically use the flowmade login when run in a repository with a git.flowmade.one remote.

old2/skills/spawn-issues/SKILL.md

@@ -0,0 +1,291 @@
+---
+name: spawn-issues
+description: >
+  Orchestrate parallel issue implementation with automated review cycles. Use when
+  implementing multiple issues concurrently, or when user says /spawn-issues.
+model: claude-haiku-4-5
+argument-hint: <issue-number> [<issue-number>...]
+allowed-tools: Bash, Task, Read, TaskOutput
+user-invocable: true
+---
+
+# Spawn Issues
+
+@~/.claude/skills/worktrees/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+Orchestrate parallel implementation of multiple issues with automated PR review and fixes.
+
+## Arguments
+
+One or more issue numbers: `$ARGUMENTS`
+
+Example: `/spawn-issues 42 43 44`
+
+## Workflow
+
+```
+Concurrent Pipeline - each issue flows independently:
+
+  Issue #42 ──► worker ──► PR #55 ──► review ──► fix? ──► ✓
+  Issue #43 ──► worker ──► PR #56 ──► review ──► ✓
+  Issue #44 ──► worker ──► PR #57 ──► review ──► fix ──► ✓
+
+Event-driven: As each task completes, immediately start next step.
+```
+
+## Process
+
+### 1. Parse and Validate
+
+Parse `$ARGUMENTS` into issue numbers. If empty:
+```
+Usage: /spawn-issues <issue-number> [<issue-number>...]
+Example: /spawn-issues 42 43 44
+```
+
+### 2. Setup Repository Context
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename "$REPO_PATH")
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+```
+
+Verify in git repository:
+```bash
+git rev-parse --git-dir >/dev/null 2>&1 || exit 1
+```
+
+### 3. Create All Worktrees Upfront
+
+For each issue, create worktree using script:
+```bash
+cd "$REPO_PATH"
+worktree_path=$(~/.claude/skills/worktrees/scripts/create-worktree.sh issue <ISSUE_NUMBER>)
+```
+
+Track worktree paths:
+```javascript
+issues = {
+  42: {
+    worktree: "/path/to/worktrees/repo-issue-42",
+    stage: "ready",
+    task_id: null,
+    pr: null,
+    branch: null,
+    review_iterations: 0
+  },
+  ...
+}
+```
+
+Print initial status:
+```
+Created worktrees for 3 issues:
+  [#42] ready
+  [#43] ready
+  [#44] ready
+```
+
+### 4. Spawn All Issue Workers
+
+For each issue, spawn issue-worker agent in background:
+
+```
+Task tool with:
+  - subagent_type: "issue-worker"
+  - run_in_background: true
+  - prompt: "Implement issue #<NUMBER>
+
+Repository: <REPO_PATH>
+Repository name: <REPO_NAME>
+Issue number: <NUMBER>
+Worktree: <WORKTREE_PATH>
+
+Follow the issue-worker agent instructions to implement, commit, push, and create PR.
+Output the result in ISSUE_WORKER_RESULT format."
+```
+
+Track task_id for each issue and update stage to "implementing".
+
+Print status:
+```
+[#42] implementing...
+[#43] implementing...
+[#44] implementing...
+```
+
+### 5. Event-Driven Pipeline
+
+**Wait for `<task-notification>` messages** that arrive automatically when background tasks complete.
+
+When notification arrives:
+
+1. **Identify which issue/task completed:**
+   - Extract task_id from notification
+   - Look up which issue this belongs to
+
+2. **Read task output:**
+   ```
+   TaskOutput tool with task_id
+   ```
+
+3. **Parse result and update state:**
+   - If issue-worker: extract PR number, branch, status
+   - If code-reviewer: extract verdict (approved/needs-work)
+   - If pr-fixer: extract status
+
+4. **Print status update:**
+   ```
+   [#42] Worker completed → PR #55 created, starting review
+   [#43] Review: approved ✓
+   [#42] Review: needs work → spawning fixer
+   ```
+
+5. **Spawn next agent if needed:**
+   - Worker done → spawn code-reviewer
+   - Reviewer says "needs-work" → spawn pr-fixer
+   - Fixer done → spawn code-reviewer again
+   - Reviewer says "approved" → mark complete
+
+6. **Check if all done:**
+   - If all issues in terminal state → proceed to cleanup
+
+### 6. State Transitions
+
+```
+ready → implementing → reviewing → done
+                     → needs-work → fixing → reviewing...
+                     → (3 iterations) → needs-manual-review
+      → failed → done
+```
+
+**Terminal states:** done, failed, needs-manual-review
+
+### 7. Spawning Code Reviewer
+
+When worker completes successfully:
+
+**Get PR branch name from worker result:**
+```javascript
+branch_name = worker_result.branch
+```
+
+**Create review worktree:**
+```bash
+cd "$REPO_PATH"
+review_worktree=$(~/.claude/skills/worktrees/scripts/create-worktree.sh review <PR_NUMBER> <BRANCH_NAME>)
+```
+
+**Spawn code-reviewer agent:**
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: true
+  - prompt: "Review PR #<PR_NUMBER>
+
+Repository: <REPO_PATH>
+PR number: <PR_NUMBER>
+Worktree: <REVIEW_WORKTREE>
+
+Follow the code-reviewer agent instructions to review the PR.
+Output the result in REVIEW_RESULT format."
+```
+
+Update state: stage = "reviewing"
+
+### 8. Spawning PR Fixer
+
+When reviewer says "needs-work":
+
+**Check iteration count:**
+- If review_iterations >= 3: mark as "needs-manual-review", skip fixer
+- Otherwise: increment review_iterations and spawn fixer
+
+**Use existing issue worktree** (don't create new one):
+```javascript
+worktree_path = issues[issue_number].worktree
+```
+
+**Spawn pr-fixer agent:**
+```
+Task tool with:
+  - subagent_type: "pr-fixer"
+  - run_in_background: true
+  - prompt: "Fix review feedback for PR #<PR_NUMBER>
+
+Repository: <REPO_PATH>
+PR number: <PR_NUMBER>
+Worktree: <WORKTREE_PATH>
+
+Follow the pr-fixer agent instructions to address feedback.
+Output the result in PR_FIXER_RESULT format."
+```
+
+Update state: stage = "fixing"
+
+### 9. Cleanup Worktrees
+
+After all issues reach terminal state:
+
+```bash
+cd "$REPO_PATH"
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "$WORKTREES_DIR"
+```
+
+This removes all issue and review worktrees created during this run.
+
+### 10. Final Report
+
+Print summary table:
+
+```
+All done!
+
+| Issue | PR  | Status              |
+|-------|-----|---------------------|
+| #42   | #55 | approved            |
+| #43   | #56 | approved            |
+| #44   | #57 | needs-manual-review |
+
+2 approved, 1 needs manual review
+```
+
+## Guidelines
+
+**Event-driven execution:**
+- Wait for task-notification messages
+- Don't poll or check task status manually
+- Process notifications as they arrive
+- Pipeline each issue independently
+
+**Worktree management:**
+- Create all issue worktrees at start
+- Create review worktrees on demand
+- Reuse issue worktrees for pr-fixer
+- Clean up all worktrees at end
+
+**State tracking:**
+- Track stage, task_id, PR, branch for each issue
+- Update state when notifications arrive
+- Print status after each transition
+
+**Error handling:**
+- If worker fails: mark as "failed", continue with others
+- If reviewer fails: mark as "review-failed", continue
+- If 3 review iterations: mark as "needs-manual-review"
+- Always cleanup worktrees, even on error
+
+**Review iteration limit:**
+- Maximum 3 review/fix cycles per issue
+- After 3 iterations: requires manual intervention
+- Prevents infinite review loops
+
+## Tips
+
+- Use `cd "$REPO_PATH"` before git/worktree operations
+- Scripts are in `~/.claude/skills/worktrees/scripts/`
+- Agents output structured results for parsing
+- Event notifications include task_id
+- Print status frequently to show progress

old2/skills/spawn-pr-fixers/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: spawn-pr-fixers
+description: >
+  Fix one or more PRs based on review feedback using pr-fixer agents. Creates
+  isolated worktrees, addresses review comments, commits and pushes fixes. Use
+  when PRs need work, or when user says /spawn-pr-fixers.
+model: claude-haiku-4-5
+argument-hint: <pr-number> [<pr-number>...]
+allowed-tools: Bash, Task, Read, TaskOutput
+user-invocable: true
+---
+
+# Spawn PR Fixers
+
+@~/.claude/skills/worktrees/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+Fix one or more pull requests that have review feedback using pr-fixer agents.
+
+## Arguments
+
+One or more PR numbers: `$ARGUMENTS`
+
+Example: `/spawn-pr-fixers 55 56 57`
+
+## Workflow
+
+```
+Concurrent Fixes - each PR fixed independently:
+
+  PR #55 ──► fetch branch ──► create worktree ──► read feedback ──► fix ──► commit ──► push ✓
+  PR #56 ──► fetch branch ──► create worktree ──► read feedback ──► fix ──► commit ──► push ✓
+  PR #57 ──► fetch branch ──► create worktree ──► read feedback ──► fix ──► commit ──► push ✓
+
+Event-driven: As each fix completes, show results immediately.
+```
+
+## Process
+
+### 1. Parse and Validate
+
+Parse `$ARGUMENTS` into PR numbers. If empty:
+```
+Usage: /spawn-pr-fixers <pr-number> [<pr-number>...]
+Example: /spawn-pr-fixers 55 56
+```
+
+### 2. Setup Repository Context
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename "$REPO_PATH")
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+```
+
+Verify in git repository:
+```bash
+git rev-parse --git-dir >/dev/null 2>&1 || exit 1
+```
+
+### 3. Fetch PR Details and Create Worktrees
+
+For each PR number:
+
+**Get PR details:**
+```bash
+tea pulls <PR_NUMBER>
+```
+
+Extract:
+- Branch name (e.g., "issue-42-feature-name")
+- PR title
+- PR state (verify it's open)
+
+**Check for review comments:**
+```bash
+tea pulls <PR_NUMBER> --comments
+```
+
+Verify there are review comments. If no comments:
+```
+[PR #<NUMBER>] No review comments found - skipping
+```
+
+**Create fix worktree:**
+```bash
+cd "$REPO_PATH"
+git fetch origin
+fix_worktree=$(~/.claude/skills/worktrees/scripts/create-worktree.sh review <PR_NUMBER> <BRANCH_NAME>)
+```
+
+Track PR state:
+```javascript
+prs = {
+  55: {
+    worktree: "/path/to/worktrees/repo-review-55",
+    branch: "issue-42-feature",
+    title: "Add user authentication",
+    stage: "ready",
+    task_id: null
+  },
+  ...
+}
+```
+
+Print initial status:
+```
+Created fix worktrees for 3 PRs:
+  [PR #55] ready - Add user authentication
+  [PR #56] ready - Fix validation bug
+  [PR #57] ready - Update documentation
+```
+
+### 4. Spawn PR Fixers
+
+For each PR, spawn pr-fixer agent in background:
+
+```
+Task tool with:
+  - subagent_type: "pr-fixer"
+  - run_in_background: true
+  - prompt: "Fix PR #<PR_NUMBER> based on review feedback
+
+Repository: <REPO_PATH>
+PR number: <PR_NUMBER>
+Worktree: <WORKTREE_PATH>
+
+Follow the pr-fixer agent instructions to address review feedback.
+Output the result in PR_FIXER_RESULT format."
+```
+
+Track task_id for each PR and update stage to "fixing".
+
+Print status:
+```
+[PR #55] fixing...
+[PR #56] fixing...
+[PR #57] fixing...
+```
+
+### 5. Event-Driven Results
+
+**Wait for `<task-notification>` messages** that arrive automatically when background tasks complete.
+
+When notification arrives:
+
+1. **Identify which PR completed:**
+   - Extract task_id from notification
+   - Look up which PR this belongs to
+
+2. **Read task output:**
+   ```
+   TaskOutput tool with task_id
+   ```
+
+3. **Parse result:**
+   - Extract status (fixed/partial/failed)
+   - Extract changes summary
+
+4. **Print status update:**
+   ```
+   [PR #55] Fix complete: fixed ✓
+   [PR #56] Fix complete: partial (some issues unclear)
+   [PR #57] Fix complete: fixed ✓
+   ```
+
+5. **Check if all done:**
+   - If all PRs fixed → proceed to cleanup and summary
+
+### 6. Cleanup Worktrees
+
+After all fixes complete:
+
+```bash
+cd "$REPO_PATH"
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "$WORKTREES_DIR"
+```
+
+This removes all fix worktrees created during this run.
+
+### 7. Final Summary
+
+Print summary table with links:
+
+```
+All fixes complete!
+
+| PR  | Title                     | Status      | Changes                              |
+|-----|---------------------------|-------------|--------------------------------------|
+| #55 | Add user authentication   | fixed ✓     | Fixed error handling, added tests    |
+| #56 | Fix validation bug        | partial     | Fixed main issue, one unclear        |
+| #57 | Update documentation      | fixed ✓     | Fixed typos, improved examples       |
+
+2 fully fixed, 1 partial
+
+PRs updated:
+- PR #55: https://git.flowmade.one/owner/repo/pulls/55
+- PR #56: https://git.flowmade.one/owner/repo/pulls/56
+- PR #57: https://git.flowmade.one/owner/repo/pulls/57
+
+Next: Re-run reviews with /spawn-pr-reviews to verify fixes
+```
+
+## Guidelines
+
+**Event-driven execution:**
+- Wait for task-notification messages
+- Don't poll or check task status manually
+- Process notifications as they arrive
+- Fix each PR independently
+
+**Worktree management:**
+- Create fix worktrees upfront
+- One worktree per PR
+- Clean up all worktrees at end
+- Always cleanup, even on error
+
+**State tracking:**
+- Track stage and task_id for each PR
+- Update state when notifications arrive
+- Print status after each transition
+
+**Error handling:**
+- If PR not found: skip it, continue with others
+- If PR is closed: skip it, note in summary
+- If no review comments: skip it, note why
+- If branch not found: skip it, note error
+- If fixer fails: mark as "failed"
+- Always cleanup worktrees
+
+**Review iteration:**
+- This is one fix pass
+- After fixes, use /spawn-pr-reviews to re-review
+- Can repeat fix → review cycles manually
+- For automated cycles, use /spawn-issues instead
+
+## Use Cases
+
+**When to use spawn-pr-fixers:**
+- PRs have review feedback that needs addressing
+- Manual PRs from team members need fixes
+- spawn-issues hit review iteration limit (3 cycles)
+- You want to re-apply fixes after manual changes
+- Quick fixes to existing PRs
+
+**When NOT to use spawn-pr-fixers:**
+- Implementing new issues (use /spawn-issues)
+- Just reviewing PRs (use /spawn-pr-reviews)
+- Need automated review loops (use /spawn-issues)
+- PRs have no review comments yet
+
+## Tips
+
+- Run after /spawn-pr-reviews identifies issues
+- Can fix multiple PRs at once for efficiency
+- Fixes are autonomous (agents make judgment calls)
+- Review the fixes after completion
+- Use /spawn-pr-reviews again to verify fixes
+- For full automation, use /spawn-issues instead

old2/skills/spawn-pr-reviews/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: spawn-pr-reviews
+description: >
+  Review one or more pull requests using code-reviewer agent. Creates isolated
+  review worktrees, spawns reviewers, posts feedback. Use when reviewing PRs,
+  or when user says /spawn-pr-reviews.
+model: claude-haiku-4-5
+argument-hint: <pr-number> [<pr-number>...]
+allowed-tools: Bash, Task, Read, TaskOutput
+user-invocable: true
+---
+
+# Spawn PR Reviews
+
+@~/.claude/skills/worktrees/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+Review one or more pull requests in parallel using code-reviewer agents.
+
+## Arguments
+
+One or more PR numbers: `$ARGUMENTS`
+
+Example: `/spawn-pr-reviews 55 56 57`
+
+## Workflow
+
+```
+Concurrent Reviews - each PR reviewed independently:
+
+  PR #55 ──► fetch branch ──► create worktree ──► review ──► post comment ✓
+  PR #56 ──► fetch branch ──► create worktree ──► review ──► post comment ✓
+  PR #57 ──► fetch branch ──► create worktree ──► review ──► post comment ✓
+
+Event-driven: As each review completes, show results immediately.
+```
+
+## Process
+
+### 1. Parse and Validate
+
+Parse `$ARGUMENTS` into PR numbers. If empty:
+```
+Usage: /spawn-pr-reviews <pr-number> [<pr-number>...]
+Example: /spawn-pr-reviews 55 56
+```
+
+### 2. Setup Repository Context
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename "$REPO_PATH")
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+```
+
+Verify in git repository:
+```bash
+git rev-parse --git-dir >/dev/null 2>&1 || exit 1
+```
+
+### 3. Fetch PR Details and Create Worktrees
+
+For each PR number:
+
+**Get PR details:**
+```bash
+tea pulls <PR_NUMBER>
+```
+
+Extract:
+- Branch name (e.g., "issue-42-feature-name")
+- PR title
+- PR state (verify it's open)
+
+**Create review worktree:**
+```bash
+cd "$REPO_PATH"
+git fetch origin
+review_worktree=$(~/.claude/skills/worktrees/scripts/create-worktree.sh review <PR_NUMBER> <BRANCH_NAME>)
+```
+
+Track PR state:
+```javascript
+prs = {
+  55: {
+    worktree: "/path/to/worktrees/repo-review-55",
+    branch: "issue-42-feature",
+    title: "Add user authentication",
+    stage: "ready",
+    task_id: null
+  },
+  ...
+}
+```
+
+Print initial status:
+```
+Created review worktrees for 3 PRs:
+  [PR #55] ready - Add user authentication
+  [PR #56] ready - Fix validation bug
+  [PR #57] ready - Update documentation
+```
+
+### 4. Spawn Code Reviewers
+
+For each PR, spawn code-reviewer agent in background:
+
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: true
+  - prompt: "Review PR #<PR_NUMBER>
+
+Repository: <REPO_PATH>
+PR number: <PR_NUMBER>
+Worktree: <WORKTREE_PATH>
+
+Follow the code-reviewer agent instructions to review the PR.
+Output the result in REVIEW_RESULT format."
+```
+
+Track task_id for each PR and update stage to "reviewing".
+
+Print status:
+```
+[PR #55] reviewing...
+[PR #56] reviewing...
+[PR #57] reviewing...
+```
+
+### 5. Event-Driven Results
+
+**Wait for `<task-notification>` messages** that arrive automatically when background tasks complete.
+
+When notification arrives:
+
+1. **Identify which PR completed:**
+   - Extract task_id from notification
+   - Look up which PR this belongs to
+
+2. **Read task output:**
+   ```
+   TaskOutput tool with task_id
+   ```
+
+3. **Parse result:**
+   - Extract verdict (approved/needs-work)
+   - Extract summary
+
+4. **Print status update:**
+   ```
+   [PR #55] Review complete: approved ✓
+   [PR #56] Review complete: needs-work
+   [PR #57] Review complete: approved ✓
+   ```
+
+5. **Check if all done:**
+   - If all PRs reviewed → proceed to cleanup and summary
+
+### 6. Cleanup Worktrees
+
+After all reviews complete:
+
+```bash
+cd "$REPO_PATH"
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "$WORKTREES_DIR"
+```
+
+This removes all review worktrees created during this run.
+
+### 7. Final Summary
+
+Print summary table with links:
+
+```
+All reviews complete!
+
+| PR  | Title                     | Verdict     |
+|-----|---------------------------|-------------|
+| #55 | Add user authentication   | approved ✓  |
+| #56 | Fix validation bug        | needs-work  |
+| #57 | Update documentation      | approved ✓  |
+
+2 approved, 1 needs changes
+
+View reviews:
+- PR #55: https://git.flowmade.one/owner/repo/pulls/55
+- PR #56: https://git.flowmade.one/owner/repo/pulls/56
+- PR #57: https://git.flowmade.one/owner/repo/pulls/57
+```
+
+## Guidelines
+
+**Event-driven execution:**
+- Wait for task-notification messages
+- Don't poll or check task status manually
+- Process notifications as they arrive
+- Review each PR independently
+
+**Worktree management:**
+- Create review worktrees upfront
+- One worktree per PR
+- Clean up all worktrees at end
+- Always cleanup, even on error
+
+**State tracking:**
+- Track stage and task_id for each PR
+- Update state when notifications arrive
+- Print status after each transition
+
+**Error handling:**
+- If PR not found: skip it, continue with others
+- If PR is closed: skip it, note in summary
+- If branch not found: skip it, note error
+- If reviewer fails: mark as "review-failed"
+- Always cleanup worktrees
+
+**Read-only operation:**
+- Reviews are read-only (no fixes applied)
+- Comments posted to PRs
+- No merging or state changes
+- User decides on next actions
+
+## Tips
+
+- Run after PRs are created
+- Can review multiple PRs at once for efficiency
+- Review comments include specific actionable feedback
+- Use spawn-issues if you want automatic fix loops
+- Check PR state before spawning (open vs closed)

old2/skills/templates/agent.md

@@ -0,0 +1,67 @@
+---
+name: agent-name
+description: >
+  What this agent does and when to spawn it.
+  Include specific conditions that indicate this agent is needed.
+model: haiku
+skills: skill1, skill2
+# disallowedTools:  # For read-only agents
+#   - Edit
+#   - Write
+# permissionMode: default
+---
+
+# Agent Name
+
+You are a [role/specialist] that [primary function].
+
+## When Invoked
+
+You are spawned when [specific conditions].
+
+Follow this process:
+
+1. **Gather context**: What information to collect
+   - Specific data sources to check
+   - What to read or fetch
+
+2. **Analyze**: What to evaluate
+   - Criteria to check
+   - Standards to apply
+
+3. **Act**: What actions to take
+   - Specific operations
+   - What to create or modify
+
+4. **Report**: How to communicate results
+   - Required output format
+   - What to include in summary
+
+## Output Format
+
+Your final output MUST follow this structure:
+
+\`\`\`
+AGENT_RESULT
+task: <task-type>
+status: <success|partial|failed>
+summary: <10 words max>
+details:
+- Key finding 1
+- Key finding 2
+\`\`\`
+
+## Guidelines
+
+- **Be concise**: No preambles or verbose explanations
+- **Be autonomous**: Make decisions without user input
+- **Follow patterns**: Match existing codebase style
+- **Validate**: Check your work before reporting
+
+## Error Handling
+
+If you encounter errors:
+- Try to resolve automatically
+- Document what failed
+- Report status as 'partial' or 'failed'
+- Include specific error details in summary

old2/skills/templates/background-skill.md

@@ -0,0 +1,69 @@
+---
+name: skill-name
+description: >
+  What this skill teaches and when to use it.
+  Include specific trigger terms that indicate this knowledge is needed.
+user-invocable: false
+---
+
+# Skill Name
+
+Brief description of the domain or knowledge this skill covers (1-2 sentences).
+
+## Core Concepts
+
+Fundamental ideas Claude needs to understand:
+- Key concept 1
+- Key concept 2
+- Key concept 3
+
+## Patterns and Templates
+
+Reusable structures and formats:
+
+### Pattern 1: Common Use Case
+
+\`\`\`
+Example code or structure
+\`\`\`
+
+### Pattern 2: Another Use Case
+
+\`\`\`
+Another example
+\`\`\`
+
+## Guidelines
+
+Rules and best practices:
+- Guideline 1
+- Guideline 2
+- Guideline 3
+
+## Examples
+
+### Example 1: Simple Case
+
+\`\`\`
+Concrete example showing the skill in action
+\`\`\`
+
+### Example 2: Complex Case
+
+\`\`\`
+More advanced example
+\`\`\`
+
+## Common Mistakes
+
+Pitfalls to avoid:
+- **Mistake 1**: Why it's wrong and what to do instead
+- **Mistake 2**: Why it's wrong and what to do instead
+
+## Reference
+
+Quick-reference tables or checklists:
+
+| Command | Purpose | Example |
+|---------|---------|---------|
+| ... | ... | ... |

old2/skills/templates/helper-script.sh

@@ -0,0 +1,86 @@
+#!/bin/bash
+# script-name.sh - Brief description of what this script does
+#
+# Usage: script-name.sh <param1> <param2> [optional-param]
+#
+# Example:
+#   script-name.sh value1 value2
+#   script-name.sh value1 value2 optional-value
+#
+# Exit codes:
+#   0 - Success
+#   1 - Invalid arguments or general error
+#   2 - Specific error condition (document what)
+
+set -e  # Exit immediately on error
+# set -x  # Uncomment for debugging
+
+# Color output for better visibility
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+NC='\033[0m' # No Color
+
+# Helper functions
+error() {
+    echo -e "${RED}ERROR: $1${NC}" >&2
+    exit 1
+}
+
+success() {
+    echo -e "${GREEN}SUCCESS: $1${NC}"
+}
+
+warn() {
+    echo -e "${YELLOW}WARNING: $1${NC}"
+}
+
+# Input validation
+if [ $# -lt 2 ]; then
+    echo "Usage: $0 <param1> <param2> [optional-param]"
+    echo ""
+    echo "Description: Brief description of what this does"
+    echo ""
+    echo "Arguments:"
+    echo "  param1        Description of param1"
+    echo "  param2        Description of param2"
+    echo "  optional-param  Description of optional param (default: value)"
+    exit 1
+fi
+
+# Parse arguments
+PARAM1=$1
+PARAM2=$2
+OPTIONAL_PARAM=${3:-"default-value"}
+
+# Validate inputs
+if [ -z "$PARAM1" ]; then
+    error "param1 cannot be empty"
+fi
+
+# Main logic
+main() {
+    echo "Processing with param1=$PARAM1, param2=$PARAM2..."
+
+    # Step 1: Describe what this step does
+    if ! some_command "$PARAM1"; then
+        error "Failed to process param1"
+    fi
+
+    # Step 2: Another operation with error handling
+    result=$(another_command "$PARAM2" 2>&1)
+    if [ $? -ne 0 ]; then
+        error "Failed to process param2: $result"
+    fi
+
+    # Step 3: Validation
+    if [ ! -f "$result" ]; then
+        error "Expected file not found: $result"
+    fi
+
+    success "Operation completed successfully"
+    echo "$result"  # Output for caller to parse
+}
+
+# Execute main function
+main

old2/skills/templates/user-invocable-skill.md

@@ -0,0 +1,65 @@
+---
+name: skill-name
+description: >
+  Clear description of what this skill does and when to use it.
+  Use when [specific trigger conditions] or when user says /skill-name.
+model: haiku
+argument-hint: <required-param> [optional-param]
+user-invocable: true
+# context: fork  # Use for skills needing isolated context
+# allowed-tools:  # Restrict tools if needed
+#   - Read
+#   - Bash
+---
+
+# Skill Title
+
+@~/.claude/skills/relevant-background-skill/SKILL.md
+
+Brief intro explaining the skill's purpose (1-2 sentences max).
+
+## Process
+
+1. **First step**: Clear action with specific command or instruction
+   - `command or tool to use`
+   - What to look for or validate
+
+2. **Second step**: Next action
+   - Specific details
+   - Expected output
+
+3. **Ask for approval** before significant actions
+   - Show what will be created/modified
+   - Wait for user confirmation
+
+4. **Execute** the approved actions
+   - Run commands/create files
+   - Handle errors gracefully
+
+5. **Present results** with links and summary
+   - Structured output (table or list)
+   - Links to created resources
+
+## Guidelines
+
+- Keep responses concise
+- Use structured output (tables, lists)
+- No preambles or sign-offs
+- Validate inputs before acting
+
+## Output Format
+
+Use this structure for responses:
+
+\`\`\`
+## Summary
+[1-2 sentences]
+
+## Results
+| Item | Status | Link |
+|------|--------|------|
+| ... | ... | ... |
+
+## Next Steps
+- ...
+\`\`\`

old2/skills/vision-to-backlog/SKILL.md

@@ -0,0 +1,349 @@
+---
+name: vision-to-backlog
+description: >
+  Orchestrate the full product strategy chain from manifesto to executable backlog.
+  Use when breaking down product vision into work, or when user says /vision-to-backlog.
+model: claude-haiku-4-5
+argument-hint: [vision-file]
+user-invocable: true
+---
+
+# Vision to Backlog
+
+@~/.claude/skills/product-strategy/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+Orchestrate the disciplined chain: Manifesto → Vision → Problem Space → Contexts → Domain → Capabilities → Features → Issues.
+
+## Arguments
+
+Optional: path to vision.md file (defaults to `./vision.md`)
+
+## Process
+
+### 1. Locate Manifesto and Vision
+
+**Manifesto** (organization-level):
+```bash
+cat ~/.claude/manifesto.md
+# Or if in architecture repo:
+cat ./manifesto.md
+```
+
+**Vision** (product-level):
+```bash
+# If argument provided: use that file
+# Otherwise: look for vision.md in current repo
+cat ./vision.md
+```
+
+Verify both files exist. If vision doesn't exist, help user create it following product-strategy framework.
+
+### 2. Create Artifacts Directory
+
+Create directory for strategy artifacts:
+```bash
+mkdir -p .product-strategy
+```
+
+All artifacts will be saved here to keep root clean.
+
+### 3. Vision Decision Gate
+
+Show vision to user and ask:
+
+**Can you answer these crisply:**
+- Who is this product for?
+- What pain is eliminated?
+- What job is now trivial?
+- What won't we do?
+
+If NO → help refine vision first, don't proceed.
+If YES → continue to problem space.
+
+### 4. Spawn Problem Space Analyst
+
+Use Task tool to spawn `problem-space-analyst` agent:
+
+```
+Analyze the product vision to identify the problem space.
+
+Manifesto: [path]
+Vision: [path]
+Codebase: [current directory]
+
+Output:
+- Event timeline (business events, not entities)
+- User journeys
+- Decision points
+- Irreversible vs reversible actions
+- Where mistakes are expensive
+
+Save artifact to: .product-strategy/problem-map.md
+
+Follow problem-space-analyst agent instructions.
+```
+
+Agent returns Problem Map artifact saved to `.product-strategy/problem-map.md`.
+
+### 5. Problem Space Decision Gate
+
+Show Problem Map to user and ask:
+
+**Do you see events, not entities?**
+- If NO → problem space needs more work
+- If YES → continue to context mapping
+
+### 6. Spawn Context Mapper
+
+Use Task tool to spawn `context-mapper` agent:
+
+```
+Identify bounded contexts from the problem space.
+
+Problem Map: .product-strategy/problem-map.md
+Codebase: [current directory]
+
+Analyze:
+- Intended contexts (from problem space)
+- Actual contexts (from codebase structure)
+- Misalignments
+
+Output:
+- Bounded Context Map
+- Boundary rules
+- Refactoring needs (if brownfield)
+
+Save artifact to: .product-strategy/context-map.md
+
+Follow context-mapper agent instructions.
+```
+
+Agent returns Bounded Context Map saved to `.product-strategy/context-map.md`.
+
+### 7. Context Decision Gate
+
+Show Bounded Context Map to user and ask:
+
+**Are boundaries clear?**
+- Different language per context?
+- Different lifecycles per context?
+
+If NO → revise contexts
+If YES → continue to domain modeling
+
+### 8. Spawn Domain Modeler (Per Context)
+
+For each bounded context, spawn `domain-modeler` agent:
+
+```
+Model the domain for bounded context: [CONTEXT_NAME]
+
+Context: [context details from .product-strategy/context-map.md]
+Codebase: [current directory]
+
+Identify:
+- Aggregates (only where invariants exist)
+- Commands
+- Events
+- Policies
+- Read models
+
+Compare with existing code if present.
+
+Save artifact to: .product-strategy/domain-[context-name].md
+
+Follow domain-modeler agent instructions.
+```
+
+Agent returns Domain Model saved to `.product-strategy/domain-[context-name].md`.
+
+### 9. Domain Model Decision Gate
+
+For each context, verify:
+
+**Does each aggregate enforce an invariant?**
+- If NO → simplify (might be read model or policy)
+- If YES → continue
+
+### 10. Spawn Capability Extractor
+
+Use Task tool to spawn `capability-extractor` agent:
+
+```
+Extract product capabilities from domain models.
+
+Domain Models: .product-strategy/domain-*.md
+
+Output:
+- Capability Map
+- System abilities that cause meaningful domain changes
+
+Save artifact to: .product-strategy/capabilities.md
+
+Follow capability-extractor agent instructions.
+```
+
+Agent returns Capability Map saved to `.product-strategy/capabilities.md`.
+
+### 11. Capability Decision Gate
+
+Show Capability Map to user and ask:
+
+**Which capabilities do you want to build?**
+- Show all capabilities with descriptions
+- Let user select subset
+- Prioritize if needed
+
+### 12. Spawn Backlog Builder
+
+Use Task tool to spawn `backlog-builder` agent:
+
+```
+Generate features and issues from selected capabilities.
+
+Selected Capabilities: [user selection from .product-strategy/capabilities.md]
+Domain Models: .product-strategy/domain-*.md
+Codebase: [current directory]
+
+For each capability:
+1. Define features (user-visible value)
+2. Decompose into issues (domain-order: commands, rules, events, reads, UI)
+3. Identify refactoring issues (if misaligned with domain)
+
+Follow issue-writing skill format.
+
+Save artifact to: .product-strategy/backlog.md
+
+Follow backlog-builder agent instructions.
+```
+
+Agent returns Features + Issues saved to `.product-strategy/backlog.md`.
+
+### 13. Feature Decision Gate
+
+Show generated features and ask:
+
+**Does each feature move a capability?**
+**Is each feature demoable?**
+
+If NO → refine features
+If YES → continue to issue creation
+
+### 14. Issue Review
+
+Present all generated issues from `.product-strategy/backlog.md` to user:
+
+```
+## Generated Backlog
+
+### Context: [Context Name]
+**Refactoring:**
+- #issue: [title]
+- #issue: [title]
+
+**Features:**
+- Feature: [name]
+  - #issue: [title] (command)
+  - #issue: [title] (domain rule)
+  - #issue: [title] (event)
+  - #issue: [title] (read model)
+  - #issue: [title] (UI)
+```
+
+Ask user:
+**Ready to create these issues in Gitea?**
+- If YES → automatically proceed to create all issues (step 14)
+- If NO → ask what to modify, regenerate, ask again
+
+### 15. Create Issues in Gitea (automatic after approval)
+
+**After user approves in step 13, automatically create all issues.**
+
+For each issue:
+```bash
+tea issues create \
+  --title "[issue title]" \
+  --description "[full issue with acceptance criteria]"
+```
+
+Apply labels:
+- `feature` or `refactor`
+- `bounded-context/[context-name]`
+- `capability/[capability-name]`
+
+### 16. Link Dependencies
+
+For issues with dependencies:
+```bash
+tea issues deps add <dependent-issue> <blocker-issue>
+```
+
+### 17. Final Report
+
+Show created issues with links:
+
+```
+## Backlog Created
+
+### Context: Authentication
+- #42: Implement User aggregate
+- #43: Add RegisterUser command
+- #44: Publish UserRegistered event
+
+### Context: Orders
+- #45: Refactor Order model to enforce invariants
+- #46: Add PlaceOrder command
+- #47: Publish OrderPlaced event
+
+Total: 6 issues created across 2 contexts
+View backlog: [gitea issues link]
+
+All artifacts saved in .product-strategy/:
+- problem-map.md
+- context-map.md
+- domain-*.md (one per context)
+- capabilities.md
+- backlog.md
+```
+
+## Guidelines
+
+**Follow the chain:**
+- Don't skip steps
+- Each step has decision gate
+- User approves before proceeding to next step
+
+**Automatic execution after approval:**
+- After user approves at decision gate, automatically proceed
+- Don't wait for another prompt
+- Execute the next step immediately
+- Example: "Ready to create issues?" → YES → create all issues automatically
+
+**Let agents work:**
+- Agents do analysis autonomously
+- Orchestrator just dispatches and gates
+
+**Decision gates prevent waste:**
+- Stop early if vision unclear
+- Verify events before contexts
+- Verify invariants before building
+- But once approved, automatically continue
+
+**Brownfield handling:**
+- Agents analyze existing code at each step
+- Generate refactoring issues for misalignments
+- Generate feature issues for new capabilities
+
+**Issue quality:**
+- Reference domain concepts, not UI
+- Follow domain decomposition order
+- Link dependencies properly
+
+## Tips
+
+- Run when starting new product or major feature area
+- Each artifact is presented for review
+- User can iterate at any decision gate
+- Issues are DDD-informed and executable
+- Works for greenfield and brownfield

old2/skills/worktrees/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: worktrees
+description: >
+  Git worktree patterns for parallel development workflows. Use when managing
+  multiple concurrent branches, implementing issues in parallel, or isolating
+  work contexts.
+user-invocable: false
+---
+
+# Git Worktrees
+
+Patterns and scripts for managing git worktrees in parallel development workflows.
+
+## What are Worktrees?
+
+Git worktrees allow multiple working directories from a single repository. Each worktree can have a different branch checked out, enabling true parallel development.
+
+**Use cases:**
+- Implementing multiple issues simultaneously
+- Isolated review environments for PRs
+- Switching contexts without stashing
+
+## Naming Conventions
+
+**Directory structure:**
+```
+project/
+├── .git/                    # Main repo
+├── src/                     # Main working tree
+└── ../worktrees/            # Sibling worktrees directory
+    ├── project-issue-42/    # Issue implementation
+    ├── project-issue-43/    # Another issue
+    └── project-review-55/   # PR review
+```
+
+**Naming patterns:**
+- Issue work: `${REPO_NAME}-issue-${ISSUE_NUMBER}`
+- PR review: `${REPO_NAME}-review-${PR_NUMBER}`
+- Feature work: `${REPO_NAME}-feature-${FEATURE_NAME}`
+
+**Why sibling directory:**
+- Keeps main repo clean
+- Easy to identify worktrees
+- Simple bulk operations
+- Works with tooling that scans parent directories
+
+## Creating Worktrees
+
+### For Issue Implementation
+
+```bash
+REPO_PATH=$(pwd)
+REPO_NAME=$(basename "$REPO_PATH")
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+ISSUE_NUMBER=42
+
+# Create worktrees directory
+mkdir -p "$WORKTREES_DIR"
+
+# Fetch latest
+git fetch origin
+
+# Get issue title for branch name
+ISSUE_TITLE=$(tea issues $ISSUE_NUMBER | grep -i "title" | head -1 | cut -d: -f2- | xargs)
+BRANCH_NAME="issue-${ISSUE_NUMBER}-$(echo "$ISSUE_TITLE" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd '[:alnum:]-' | cut -c1-50)"
+
+# Create worktree with new branch from main
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-issue-${ISSUE_NUMBER}" \
+  -b "$BRANCH_NAME" origin/main
+```
+
+### For PR Review
+
+```bash
+# For reviewing existing PR branch
+PR_NUMBER=55
+BRANCH_NAME="issue-42-feature-name"  # Get from PR details
+
+git fetch origin
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-review-${PR_NUMBER}" \
+  "origin/${BRANCH_NAME}"
+```
+
+## Bundled Scripts
+
+Use bundled scripts for error-prone operations. Scripts are located in `~/.claude/skills/worktrees/scripts/`:
+
+### Create Worktree
+
+```bash
+# Usage: ~/.claude/skills/worktrees/scripts/create-worktree.sh issue <issue-number>
+# Usage: ~/.claude/skills/worktrees/scripts/create-worktree.sh review <pr-number> <branch-name>
+
+~/.claude/skills/worktrees/scripts/create-worktree.sh issue 42
+~/.claude/skills/worktrees/scripts/create-worktree.sh review 55 issue-42-feature-name
+```
+
+Returns worktree path on success.
+
+### List Worktrees
+
+```bash
+~/.claude/skills/worktrees/scripts/list-worktrees.sh
+```
+
+Shows all active worktrees with their branches.
+
+### Cleanup Worktrees
+
+```bash
+# Remove specific worktree
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "${WORKTREES_DIR}/${REPO_NAME}-issue-42"
+
+# Remove all worktrees in directory
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "${WORKTREES_DIR}"
+
+# Force remove even if dirty
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh --force "${WORKTREES_DIR}"
+```
+
+## Patterns
+
+### Pattern: Parallel Issue Implementation
+
+**Orchestrator creates all worktrees upfront:**
+```bash
+for issue in 42 43 44; do
+  worktree_path=$(~/.claude/skills/worktrees/scripts/create-worktree.sh issue $issue)
+  # Spawn worker with worktree_path
+done
+```
+
+**Worker uses provided worktree:**
+```bash
+cd "$WORKTREE_PATH"  # Provided by orchestrator
+# Do work
+git add -A && git commit -m "..."
+git push -u origin $(git branch --show-current)
+```
+
+**Orchestrator cleans up after all complete:**
+```bash
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "${WORKTREES_DIR}"
+```
+
+### Pattern: Review in Isolation
+
+**Create review worktree:**
+```bash
+worktree_path=$(~/.claude/skills/worktrees/scripts/create-worktree.sh review $PR_NUMBER $BRANCH_NAME)
+cd "$worktree_path"
+git diff origin/main...HEAD  # Review changes
+```
+
+### Pattern: Error Recovery
+
+**List stale worktrees:**
+```bash
+~/.claude/skills/worktrees/scripts/list-worktrees.sh
+```
+
+**Force cleanup:**
+```bash
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh --force "${WORKTREES_DIR}"
+```
+
+## Best Practices
+
+**Always provide worktree paths to agents:**
+- Orchestrator creates worktrees
+- Agents receive path as parameter
+- Agents work in provided path
+- Orchestrator handles cleanup
+
+**Never nest cleanup:**
+- Only orchestrator cleans up
+- Agents never remove their own worktree
+- Cleanup happens after all work complete
+
+**Track worktree paths:**
+```bash
+# In orchestrator
+declare -A worktrees
+worktrees[42]=$(~/.claude/skills/worktrees/scripts/create-worktree.sh issue 42)
+worktrees[43]=$(~/.claude/skills/worktrees/scripts/create-worktree.sh issue 43)
+
+# Pass to agents
+spawn_agent --worktree="${worktrees[42]}"
+```
+
+**Handle errors gracefully:**
+- Use scripts (they handle errors)
+- Always cleanup, even on failure
+- Force-remove if necessary
+
+## Common Issues
+
+**Worktree already exists:**
+```bash
+# Remove old worktree first
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh "${WORKTREES_DIR}/${REPO_NAME}-issue-42"
+
+# Then create new one
+~/.claude/skills/worktrees/scripts/create-worktree.sh issue 42
+```
+
+**Branch already exists:**
+```bash
+# Delete branch if safe
+git branch -d issue-42-old-name
+
+# Or force delete
+git branch -D issue-42-old-name
+```
+
+**Stale worktrees after crash:**
+```bash
+# List and force remove
+~/.claude/skills/worktrees/scripts/list-worktrees.sh
+~/.claude/skills/worktrees/scripts/cleanup-worktrees.sh --force "${WORKTREES_DIR}"
+```
+
+## Tips
+
+- Keep worktrees short-lived (hours, not days)
+- Clean up regularly to avoid clutter
+- Use scripts for reliability
+- Let orchestrator manage lifecycle
+- Check `git worktree list` if unsure about state

old2/skills/worktrees/scripts/cleanup-worktrees.sh

@@ -0,0 +1,56 @@
+#!/bin/bash
+set -euo pipefail
+
+# Clean up git worktrees
+#
+# Usage:
+#   ./cleanup-worktrees.sh <path>              # Remove specific worktree
+#   ./cleanup-worktrees.sh <directory>         # Remove all worktrees in directory
+#   ./cleanup-worktrees.sh --force <path>      # Force remove even if dirty
+
+FORCE=false
+if [ "$1" = "--force" ]; then
+  FORCE=true
+  shift
+fi
+
+TARGET="$1"
+REPO_PATH=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
+
+cd "$REPO_PATH"
+
+remove_worktree() {
+  local worktree_path="$1"
+
+  if [ ! -d "$worktree_path" ]; then
+    return 0
+  fi
+
+  if [ "$FORCE" = true ]; then
+    git worktree remove "$worktree_path" --force 2>/dev/null || true
+  else
+    git worktree remove "$worktree_path" 2>/dev/null || true
+  fi
+}
+
+# Check if target is a directory containing multiple worktrees
+if [ -d "$TARGET" ]; then
+  # Check if it's a worktree itself or a directory of worktrees
+  if git worktree list | grep -q "$TARGET\$"; then
+    # It's a single worktree
+    remove_worktree "$TARGET"
+  else
+    # It's a directory, remove all worktrees inside
+    for worktree in "$TARGET"/*; do
+      if [ -d "$worktree" ]; then
+        remove_worktree "$worktree"
+      fi
+    done
+
+    # Try to remove the directory if empty
+    rmdir "$TARGET" 2>/dev/null || true
+  fi
+else
+  echo "Error: Path does not exist: $TARGET" >&2
+  exit 1
+fi

old2/skills/worktrees/scripts/create-worktree.sh

@@ -0,0 +1,74 @@
+#!/bin/bash
+set -euo pipefail
+
+# Create a git worktree for issue work or PR review
+#
+# Usage:
+#   ./create-worktree.sh issue <issue-number>
+#   ./create-worktree.sh review <pr-number> <branch-name>
+#
+# Returns: Absolute path to created worktree (stdout)
+
+MODE="$1"
+REPO_PATH=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
+REPO_NAME=$(basename "$REPO_PATH")
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
+
+# Ensure worktrees directory exists
+mkdir -p "$WORKTREES_DIR"
+
+# Fetch latest from origin
+cd "$REPO_PATH"
+git fetch origin >/dev/null 2>&1
+
+case "$MODE" in
+  issue)
+    ISSUE_NUMBER="$2"
+    WORKTREE_NAME="${REPO_NAME}-issue-${ISSUE_NUMBER}"
+    WORKTREE_PATH="${WORKTREES_DIR}/${WORKTREE_NAME}"
+
+    # Get issue title for branch name (tea issues output has title on line 2: "  # #1 Title here")
+    ISSUE_TITLE=$(tea issues "$ISSUE_NUMBER" 2>/dev/null | sed -n '2p' | sed 's/.*#[0-9]* //' | xargs || echo "untitled")
+
+    # Create safe branch name
+    BRANCH_NAME="issue-${ISSUE_NUMBER}-$(echo "$ISSUE_TITLE" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd '[:alnum:]-' | cut -c1-50)"
+
+    # Remove worktree if it already exists
+    if [ -d "$WORKTREE_PATH" ]; then
+      git worktree remove "$WORKTREE_PATH" --force 2>/dev/null || true
+    fi
+
+    # Delete branch if it exists
+    git branch -D "$BRANCH_NAME" 2>/dev/null || true
+
+    # Create worktree with new branch from main
+    git worktree add "$WORKTREE_PATH" -b "$BRANCH_NAME" origin/main >/dev/null 2>&1
+
+    echo "$WORKTREE_PATH"
+    ;;
+
+  review)
+    PR_NUMBER="$2"
+    BRANCH_NAME="$3"
+    WORKTREE_NAME="${REPO_NAME}-review-${PR_NUMBER}"
+    WORKTREE_PATH="${WORKTREES_DIR}/${WORKTREE_NAME}"
+
+    # Remove worktree if it already exists
+    if [ -d "$WORKTREE_PATH" ]; then
+      git worktree remove "$WORKTREE_PATH" --force 2>/dev/null || true
+    fi
+
+    # Create worktree from existing branch
+    git worktree add "$WORKTREE_PATH" "origin/${BRANCH_NAME}" >/dev/null 2>&1
+
+    echo "$WORKTREE_PATH"
+    ;;
+
+  *)
+    echo "Error: Invalid mode '$MODE'. Use 'issue' or 'review'" >&2
+    echo "Usage:" >&2
+    echo "  $0 issue <issue-number>" >&2
+    echo "  $0 review <pr-number> <branch-name>" >&2
+    exit 1
+    ;;
+esac

old2/skills/worktrees/scripts/list-worktrees.sh

@@ -0,0 +1,13 @@
+#!/bin/bash
+set -euo pipefail
+
+# List all active git worktrees
+#
+# Usage:
+#   ./list-worktrees.sh
+
+REPO_PATH=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
+cd "$REPO_PATH"
+
+echo "Active worktrees:"
+git worktree list

old2/software-architecture.md

@@ -0,0 +1,130 @@
+# Software Architecture
+
+> **For Claude:** This content is mirrored in `skills/software-architecture/SKILL.md` which is auto-triggered when relevant. You don't need to load this file directly.
+
+This document describes the architectural patterns we use to achieve our [architecture beliefs](./manifesto.md#architecture-beliefs). It serves as human-readable organizational documentation.
+
+## Beliefs to Patterns
+
+| Belief | Primary Pattern | Supporting Patterns |
+|--------|-----------------|---------------------|
+| Auditability by default | Event Sourcing | Immutable events, temporal queries |
+| Business language in code | Domain-Driven Design | Ubiquitous language, aggregates, bounded contexts |
+| Independent evolution | Event-driven communication | Bounded contexts, published language |
+| Explicit over implicit | Commands and Events | Domain events, clear intent |
+
+## Event Sourcing
+
+**Achieves:** Auditability by default
+
+Instead of storing current state, we store the sequence of events that led to it.
+
+**Core concepts:**
+- **Events** are immutable facts about what happened, named in past tense: `OrderPlaced`, `PaymentReceived`
+- **State** is derived by replaying events, not stored directly
+- **Event store** is append-only - history is never modified
+
+**Why this matters:**
+- Complete audit trail for free
+- Debug by replaying history
+- Answer "what was the state at time X?"
+- Recover from bugs by fixing logic and replaying
+
+**Trade-offs:**
+- More complex than CRUD for simple cases
+- Requires thinking in events, not state
+- Eventually consistent read models
+
+## Domain-Driven Design
+
+**Achieves:** Business language in code
+
+The domain model reflects how the business thinks and talks.
+
+**Core concepts:**
+- **Ubiquitous language** - same terms in code, conversations, and documentation
+- **Bounded contexts** - explicit boundaries where terms have consistent meaning
+- **Aggregates** - clusters of objects that change together, with one root entity
+- **Domain events** - capture what happened in business terms
+
+**Why this matters:**
+- Domain experts can read and validate the model
+- New team members learn the domain through code
+- Changes in business rules map clearly to code changes
+
+**Trade-offs:**
+- Upfront investment in understanding the domain
+- Boundaries may need to shift as understanding grows
+- Overkill for pure technical/infrastructure code
+
+## Event-Driven Communication
+
+**Achieves:** Independent evolution
+
+Services communicate by publishing events, not calling each other directly.
+
+**Core concepts:**
+- **Publish events** when something important happens
+- **Subscribe to events** you care about
+- **No direct dependencies** between publisher and subscriber
+- **Eventual consistency** - accept that not everything updates instantly
+
+**Why this matters:**
+- Add new services without changing existing ones
+- Services can be deployed independently
+- Natural resilience - if a subscriber is down, events queue
+
+**Trade-offs:**
+- Harder to trace request flow
+- Eventual consistency requires different thinking
+- Need infrastructure for reliable event delivery
+
+## Commands and Events
+
+**Achieves:** Explicit over implicit
+
+Distinguish between requests (commands) and facts (events).
+
+**Core concepts:**
+- **Commands** express intent: `PlaceOrder`, `CancelSubscription`
+- Commands can be rejected (validation, business rules)
+- **Events** express facts: `OrderPlaced`, `SubscriptionCancelled`
+- Events are immutable - what happened, happened
+
+**Why this matters:**
+- Clear separation of "trying to do X" vs "X happened"
+- Commands validate, events just record
+- Enables replay - reprocess events with new logic
+
+## When to Diverge
+
+These patterns are defaults, not mandates. Diverge intentionally when:
+
+- **Simplicity wins** - a simple CRUD endpoint doesn't need event sourcing
+- **Performance requires it** - sometimes synchronous calls are necessary
+- **Team context** - patterns the team doesn't understand cause more harm than good
+- **Prototyping** - validate ideas before investing in full architecture
+
+When diverging, document the decision in the project's vision.md (see below).
+
+## Project-Level Architecture
+
+Each project should document its architectural choices in `vision.md` under an **Architecture** section:
+
+```markdown
+## Architecture
+
+This project follows organization architecture patterns.
+
+### Alignment
+- Event sourcing for [which aggregates/domains]
+- Bounded contexts: [list contexts and their responsibilities]
+- Event-driven communication between [which services]
+
+### Intentional Divergences
+| Area | Standard Pattern | What We Do Instead | Why |
+|------|------------------|-------------------|-----|
+| [area] | [expected pattern] | [actual approach] | [reasoning] |
+```
+
+This creates traceability: org beliefs → patterns → project decisions.

settings.json

@@ -1,5 +1,4 @@
 {
-  "model": "opus",
   "permissions": {
     "allow": [
       "Bash(git:*)",
@@ -10,13 +9,6 @@
       "WebSearch"
     ]
   },
-  "statusLine": {
-    "type": "command",
-    "command": "input=$(cat); current_dir=$(echo \"$input\" | jq -r '.workspace.current_dir'); model=$(echo \"$input\" | jq -r '.model.display_name'); style=$(echo \"$input\" | jq -r '.output_style.name'); git_info=\"\"; if [ -d \"$current_dir/.git\" ]; then cd \"$current_dir\" && branch=$(git branch --show-current 2>/dev/null) && status=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ') && git_info=\" [$branch$([ \"$status\" != \"0\" ] && echo \"*\")]\"; fi; printf \"\\033[2m$(whoami)@$(hostname -s) $(basename \"$current_dir\")$git_info | $model ($style)\\033[0m\""
-  },
-  "enabledPlugins": {
-    "gopls-lsp@claude-plugins-official": true
-  },
   "hooks": {
     "PreToolUse": [
       {
@@ -30,5 +22,14 @@
         ]
       }
     ]
-  }
+  },
+  "statusLine": {
+    "type": "command",
+    "command": "input=$(cat); current_dir=$(echo \"$input\" | jq -r '.workspace.current_dir'); model=$(echo \"$input\" | jq -r '.model.display_name'); style=$(echo \"$input\" | jq -r '.output_style.name'); git_info=\"\"; if [ -d \"$current_dir/.git\" ]; then cd \"$current_dir\" && branch=$(git branch --show-current 2>/dev/null) && status=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ') && git_info=\" [$branch$([ \"$status\" != \"0\" ] && echo \"*\")]\"; fi; printf \"\\033[2m$(whoami)@$(hostname -s) $(basename \"$current_dir\")$git_info | $model ($style)\\033[0m\"",
+    "padding": 0
+  },
+  "enabledPlugins": {
+    "gopls-lsp@claude-plugins-official": true
+  },
+  "model": "opus"
 }