Create learnings/ folder with structure and template

Adds learnings folder for capturing insights from retros and daily work.
Learnings serve as historical record, governance reference, and encoding
source for skills/commands/agents.

README includes:
- Purpose explanation (historical + governance + encoding)
- Learning template with all sections
- Encoding process and destination guide
- Periodic review guidance
- Naming conventions

Closes #39

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

CLAUDE.md

@@ -16,8 +16,8 @@ make install
 ```
 ai/
 ├── commands/       # Slash commands (/work-issue, /dashboard)
-├── skills/         # Auto-triggered capabilities
+├── skills/         # Knowledge modules (auto-triggered)
-├── agents/         # Subagents with isolated context
+├── agents/         # Focused subtask handlers (isolated context)
 ├── scripts/        # Hook scripts (pre-commit, token loading)
 ├── settings.json   # Claude Code settings
 └── Makefile        # Install/uninstall symlinks
@@ -25,6 +25,42 @@ ai/
 
 All files symlink to `~/.claude/` via `make install`.
 
+## Architecture
+
+### Skills
+Knowledge modules that teach Claude how to do something. Referenced by commands via `@~/.claude/skills/xxx/SKILL.md`.
+
+- **Purpose**: Encode best practices and tool knowledge
+- **Location**: `skills/<name>/SKILL.md`
+- **Usage**: Included in commands for context, auto-triggered by Claude Code
+
+Example: `gitea` skill teaches tea CLI usage, `issue-writing` teaches how to structure issues.
+
+### Commands
+User-facing entry points invoked with `/command-name`. Run in main conversation context.
+
+- **Purpose**: Orchestrate workflows with user interaction
+- **Location**: `commands/<name>.md`
+- **Usage**: User types `/dashboard`, `/work-issue 42`, etc.
+
+Commands reference skills for knowledge and optionally spawn agents for subtasks.
+
+### Agents
+Small, focused units that handle specific subtasks in isolated context.
+
+- **Purpose**: Complex subtasks that benefit from isolation
+- **Location**: `agents/<name>/agent.md`
+- **Usage**: Spawned via Task tool, return results to caller
+
+Good agent candidates:
+- Code review (analyze diff, report issues)
+- Content generation (write issue body, PR description)
+- Analysis tasks (categorize, prioritize, summarize)
+
+**When to use agents vs direct execution:**
+- Use agents when: task is self-contained, benefits from isolation, can run in parallel
+- Use direct execution when: task needs conversation history, requires user interaction mid-task
+
 ## Gitea Integration
 
 Uses `tea` CLI for issue/PR management:
@@ -37,7 +73,7 @@ tea logins add --name flowmade --url https://git.flowmade.one --token <your-toke
 # Create token at: https://git.flowmade.one/user/settings/applications
 ```
 
-### Available Commands
+## Available Commands
 
 | Command | Description |
 |---------|-------------|
@@ -45,8 +81,11 @@ tea logins add --name flowmade --url https://git.flowmade.one --token <your-toke
 | `/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 from completed work, create improvement issues |
+| `/retro` | Capture learnings, create improvement issues |
+| `/vision` | View/manage product vision and milestones |
+| `/plan-issues` | Break down features into issues |
+| `/improve` | Identify gaps between vision and backlog |
 
-## Usage
+## Vision & Goals
 
-This project is meant to be used alongside Claude Code to enhance productivity and maintain consistent workflows.
+Product vision lives in `vision.md` (philosophy) and Gitea milestones (goals with progress tracking). See `/vision` command.

VISION.md

@@ -36,14 +36,21 @@ Skills don't do anything on their own. They're building blocks.
 
 ### Agents
 
-Agents combine multiple skills into specialized personas that can work autonomously.
+Agents are small, focused units that handle specific subtasks in isolated context.
 
-The `product-manager` agent combines issue-writing, backlog-grooming, and roadmap-planning skills to handle complex PM tasks. It can explore the codebase, plan features, and create well-structured issues—all with isolated context so it doesn't pollute the main conversation.
+Unlike commands (which run in the main conversation), agents are spawned via the Task tool to do a specific job and report back. They should be:
+- **Small and focused**: One clear responsibility
+- **Isolated**: Work without needing conversation history
+- **Result-oriented**: Return a specific output (analysis, categorization, generated content)
+
+Examples:
+- `code-reviewer`: Reviews a PR diff and reports issues
+- A hypothetical `categorize-milestone`: Given an issue, determines which milestone it belongs to
 
 Agents enable:
 - **Parallel processing**: Multiple agents can work simultaneously
-- **Context preservation**: Each agent maintains its own focused context
+- **Context isolation**: Complex subtasks don't pollute the main conversation
-- **Complex workflows**: Combine skills for multi-step tasks
+- **Reusability**: Same agent can be spawned by different commands
 
 ### Commands
 
@@ -51,11 +58,12 @@ Commands are the user-facing entry points—what you actually invoke.
 
 When you run `/plan-issues add dark mode`, the command:
 1. Understands what you're asking for
-2. Invokes the right agents and skills
+2. References skills for knowledge (how to write issues, use Gitea, etc.)
-3. Guides you through the workflow with approvals
+3. Optionally spawns agents for complex subtasks
-4. Takes action (creates issues, PRs, etc.)
+4. Guides you through the workflow with approvals
+5. Takes action (creates issues, PRs, etc.)
 
-Commands make the power of skills and agents accessible through simple invocations.
+Commands run in the main conversation context, using skills for knowledge and spawning agents only when isolated processing is beneficial.
 
 ## Target Users
 

agents/product-manager/AGENT.md

@@ -1,25 +0,0 @@
----
-name: product-manager
-description: Backlog management and roadmap planning specialist. Use for batch issue operations, comprehensive backlog reviews, or feature planning that requires codebase exploration.
-# Model: sonnet handles planning and issue-writing well.
-# Tasks follow structured patterns from skills; opus not required.
-model: sonnet
-skills: gitea, issue-writing, backlog-grooming, roadmap-planning
----
-
-You are a product manager specializing in backlog management and roadmap planning.
-
-## Capabilities
-
-You can:
-- Review and improve existing issues
-- Create new well-structured issues
-- Analyze the backlog for gaps and priorities
-- Plan feature breakdowns
-- Maintain roadmap clarity
-
-## Behavior
-
-- Always fetch current issue state before making changes
-- Ask for approval before creating or modifying issues
-- Provide clear summaries of actions taken

commands/create-issue.md

@@ -7,13 +7,37 @@ argument-hint: [title] or "batch"
 
 @~/.claude/skills/gitea/SKILL.md
 
+## Milestone Assignment
+
+Before creating issues, fetch available milestones:
+
+```bash
+tea milestones -f title,description
+```
+
+For each issue, automatically assign to the most relevant milestone by matching:
+- Issue content/problem area → Milestone title and description
+- If no clear match, ask the user which milestone (goal) the issue supports
+- If no milestones exist, skip milestone assignment
+
+Include `--milestone "<milestone>"` in the create command when a milestone is assigned.
+
 ## Single Issue (default)
-If title provided, create an issue with that title and ask for description.
+
+If title provided:
+1. Create an issue with that title
+2. Ask for description
+3. Assign to appropriate milestone (see above)
+4. Ask if this issue depends on any existing issues
+5. If dependencies exist, link them: `tea issues deps add <new-issue> <blocker>`
 
 ## Batch Mode
+
 If $1 is "batch":
 1. Ask user for the plan/direction
-2. Generate list of issues with titles and descriptions
+2. Fetch available milestones
-3. Show for approval
+3. Generate list of issues with titles, descriptions, milestone assignments, and dependencies
-4. Create each issue
+4. Show for approval
-5. Display all created issue numbers
+5. Create each issue with milestone (in dependency order)
+6. Link dependencies between created issues: `tea issues deps add <issue> <blocker>`
+7. Display all created issue numbers with dependency graph

commands/groom.md

@@ -11,23 +11,27 @@ argument-hint: [issue-number]
 
 ## If issue number provided ($1):
 
-1. **Fetch the issue** details
+1. **Fetch the issue** details with `tea issues <number> --comments`
-2. **Evaluate** against grooming checklist
+2. **Check dependencies** with `tea issues deps list <number>`
-3. **Suggest improvements** for:
+3. **Evaluate** against grooming checklist
+4. **Suggest improvements** for:
    - Title clarity
    - Description completeness
    - Acceptance criteria quality
    - Scope definition
-4. **Ask user** if they want to apply changes
+   - Missing or incorrect dependencies
-5. **Update issue** if approved
+5. **Ask user** if they want to apply changes
+6. **Update issue** if approved
+7. **Link/unlink dependencies** if needed: `tea issues deps add/remove <issue> <dep>`
 
 ## If no argument (groom all):
 
 1. **List open issues**
-2. **Review each** against grooming checklist
+2. **Review each** against grooming checklist (including dependencies)
 3. **Categorize**:
-   - Ready: Well-defined, can start work
+   - Ready: Well-defined, dependencies linked, can start work
-   - Needs work: Missing info or unclear
+   - Blocked: Has unresolved dependencies
+   - Needs work: Missing info, unclear, or missing dependency links
    - Stale: No longer relevant
-4. **Present summary** table
+4. **Present summary** table with dependency status
-5. **Offer to improve** issues that need work
+5. **Offer to improve** issues that need work (including linking dependencies)

commands/improve.md

@@ -0,0 +1,82 @@
+---
+description: Identify improvement opportunities based on product vision. Analyzes gaps between vision goals and current backlog.
+---
+
+# Improvement Analysis
+
+@~/.claude/skills/vision-management/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/issue-writing/SKILL.md
+@~/.claude/skills/roadmap-planning/SKILL.md
+
+## Process
+
+1. **Read the vision**: Load `vision.md` from the repo root.
+   - If no vision exists, suggest running `/vision` first
+
+2. **Fetch current backlog**: Get all open issues from Gitea using `tea issues`
+
+3. **Analyze alignment**:
+
+   For each vision goal, check:
+   - Are there issues supporting this goal?
+   - Is there recent activity/progress?
+   - Are issues blocked or stalled?
+
+   For each open issue, check:
+   - Does it align with a vision goal?
+   - Is it supporting the current focus?
+
+4. **Identify gaps and opportunities**:
+
+   - **Unsupported goals**: Vision goals with no issues
+   - **Stalled goals**: Goals with issues but no recent progress
+   - **Orphan issues**: Issues that don't support any goal
+   - **Focus misalignment**: Issues not aligned with current focus getting priority
+   - **Missing non-goals**: Patterns suggesting things we should explicitly avoid
+
+5. **Present findings**:
+
+   ```
+   ## Vision Alignment Report
+
+   ### Goals Coverage
+   - Goal 1: [status] - N issues, [progress]
+   - Goal 2: [status] - N issues, [progress]
+
+   ### Gaps Identified
+   1. [Gap description]
+      Suggestion: [concrete action]
+
+   2. [Gap description]
+      Suggestion: [concrete action]
+
+   ### Orphan Issues
+   - #N: [title] - No goal alignment
+
+   ### Recommended Actions
+   1. [Action with rationale]
+   2. [Action with rationale]
+   ```
+
+6. **Offer to take action**:
+
+   For unsupported goals:
+   - Ask if user wants to plan issues for the gap
+   - If yes, run the `/plan-issues` workflow for that goal
+   - This breaks down the goal into concrete, actionable issues
+
+   For other findings:
+   - Re-prioritize issues based on focus
+   - Close or re-scope orphan issues
+   - Update vision with suggested changes
+
+   Always ask for approval before making changes.
+
+## Guidelines
+
+- Focus on actionable improvements, not just observations
+- Prioritize suggestions by impact on vision goals
+- Keep suggestions specific and concrete
+- One issue per improvement (don't bundle)
+- Reference specific goals when suggesting new issues

commands/plan-issues.md

@@ -1,5 +1,5 @@
 ---
-description: Plan and create issues for a feature or improvement. Breaks down work into well-structured issues.
+description: Plan and create issues for a feature or improvement. Breaks down work into well-structured issues with vision alignment.
 argument-hint: <feature-description>
 ---
 
@@ -8,18 +8,26 @@ argument-hint: <feature-description>
 @~/.claude/skills/gitea/SKILL.md
 @~/.claude/skills/roadmap-planning/SKILL.md
 @~/.claude/skills/issue-writing/SKILL.md
+@~/.claude/skills/vision-management/SKILL.md
 
-1. **Understand the feature**: Analyze what "$1" involves
+1. **Check vision context**: If `vision.md` exists, read it to understand personas, jobs to be done, and goals
-2. **Explore the codebase** if needed to understand context
+2. **Identify persona**: Which persona does "$1" serve?
-3. **Break down** into discrete, actionable issues:
+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:
    - Each issue should be independently completable
    - Clear dependencies between issues
    - Appropriate scope (not too big, not too small)
 
-4. **Present the plan**:
+7. **Present the plan** (include vision alignment if vision exists):
    ```
    ## Proposed Issues for: $1
 
+   For: [Persona name]
+   Job: "[Job to be done this enables]"
+   Supports: [Milestone/Goal name]
+
    1. [Title] - Brief description
       Dependencies: none
 
@@ -30,7 +38,13 @@ argument-hint: <feature-description>
       Dependencies: #1, #2
    ```
 
-5. **Ask for approval** before creating issues
+   If the feature doesn't align with any persona/job/goal, note this and ask if:
-6. **Create issues** in order
+   - A new persona or job should be added to the vision
-7. **Update dependencies** with actual issue numbers after creation
+   - A new milestone should be created
-8. **Present summary** with links to created issues
+   - 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

commands/retro.md

@@ -1,11 +1,13 @@
 ---
-description: Run a retrospective on completed work. Captures learnings and creates improvement issues in the AI repo.
+description: Run a retrospective on completed work. Captures learnings, creates improvement issues, and updates product vision.
 argument-hint: [task-description]
 ---
 
 # Retrospective
 
-Capture learnings from completed AI-assisted work to improve the workflow.
+Capture learnings from completed AI-assisted work to improve the workflow and refine the product vision.
+
+@~/.claude/skills/vision-management/SKILL.md
 
 ## Process
 
@@ -22,12 +24,38 @@ Capture learnings from completed AI-assisted work to improve the workflow.
    - **Tool issues**: Problems with tea CLI, git, or other tools
    - **Context gaps**: Missing documentation or skills
 
-4. **Generate improvement issues**: For each actionable improvement, create an issue in the AI repo using:
+4. **Connect to vision** (if `vision.md` exists in the target repo):
+   - Did this work make progress on any vision goals?
+   - Did learnings reveal new priorities that should become goals?
+   - Did we discover something that should be a non-goal?
+   - Should the current focus shift based on what we learned?
+
+   If any vision updates are needed:
+   - Present suggested changes to `vision.md`
+   - Ask for approval
+   - Update the vision file and sync to Gitea
+
+5. **Generate improvement issues**: For each actionable improvement:
+   - Determine the appropriate milestone (see Milestone Categorization below)
+   - Create an issue in the AI repo with the milestone assigned:
 
 ```bash
-tea issues create -r flowmade-one/ai --title "<title>" --description "<body>"
+tea issues create -r flowmade-one/ai --title "<title>" --description "<body>" --milestone "<milestone>"
 ```
 
+## Milestone Assignment
+
+Before creating issues, fetch available milestones:
+
+```bash
+tea milestones -f title,description
+```
+
+For each issue, automatically assign to the most relevant milestone by matching:
+- Issue content/problem area → Milestone title and description
+- If no clear match, ask the user which milestone (goal) the issue supports
+- If no milestones exist, skip milestone assignment
+
 ## Issue Format
 
 Use this structure for retrospective issues:

commands/review-pr.md

@@ -7,7 +7,7 @@ argument-hint: <pr-number>
 
 @~/.claude/skills/gitea/SKILL.md
 
-1. **View PR details** including description and metadata
+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:

commands/vision.md

@@ -0,0 +1,96 @@
+---
+description: View the product vision and goal progress. Manages vision.md and Gitea milestones.
+argument-hint: [goals]
+---
+
+# Product Vision
+
+@~/.claude/skills/vision-management/SKILL.md
+@~/.claude/skills/gitea/SKILL.md
+
+## Architecture
+
+The vision system has two layers:
+
+| Layer | Purpose | Location |
+|-------|---------|----------|
+| **vision.md** | North star philosophy (why, principles, non-goals) | File in repo root |
+| **Milestones** | Goals with progress tracking | Gitea milestones |
+
+Issues are assigned to milestones. Progress is visible through milestone completion.
+
+## Process
+
+1. **Check for existing vision**: Look for `vision.md` in the current repo root.
+
+2. **If no vision exists**:
+   - Ask the user if they want to create one
+   - Guide them through defining:
+     1. **Personas**: Who are we building for? (2-4 specific personas)
+     2. **Jobs to be done**: What are they trying to achieve?
+     3. **The problem**: What pain points exist today?
+     4. **The solution**: How does this product address their jobs?
+     5. **Guiding principles**: What beliefs guide decisions?
+     6. **Non-goals**: What are we explicitly NOT doing?
+   - Create `vision.md` (do NOT include goals/progress - that's milestones)
+   - Ask about initial goals tied to personas/jobs, create as Gitea milestones
+
+3. **If vision exists**:
+   - Display the vision philosophy from `vision.md`
+   - Show current milestones and their progress: `tea milestones`
+   - Check if `$1` specifies an action:
+     - `goals`: Manage milestones (add, close, view progress)
+   - If no action specified, just display the current state
+
+4. **Managing Goals (milestones)**:
+   ```bash
+   # List milestones with progress
+   tea milestones
+
+   # Create a new goal
+   tea milestones create --title "<goal>" --description "<success criteria>"
+
+   # View issues in a milestone
+   tea milestones issues <milestone-name>
+
+   # Close a completed goal
+   tea milestones close <milestone-name>
+   ```
+
+## Output Format
+
+```
+## Who We Serve
+
+- **[Persona 1]**: [Brief description]
+- **[Persona 2]**: [Brief description]
+
+## What They're Trying to Achieve
+
+- "[Job to be done 1]"
+- "[Job to be done 2]"
+
+## Vision
+
+[Summary of problem/solution from vision.md]
+
+## Goals (Milestones)
+
+| Goal | For | Progress | Due |
+|------|-----|----------|-----|
+| [title] | [Persona] | 3/5 issues | [date] |
+
+## Current Focus
+
+[Open milestones with nearest due dates or most activity]
+```
+
+## Guidelines
+
+- vision.md is the stable "why" and "who" document - update rarely
+- Personas and jobs to be done are foundational - everything traces back to them
+- Milestones are actionable goals - each should serve a specific persona's job
+- Assign issues to milestones to track progress
+- Use milestone descriptions for: persona, job, success criteria
+- Due dates on milestones are optional but help prioritization
+- If you can't tie work to a persona/job, question whether it should be done

commands/work-issue.md

@@ -7,7 +7,7 @@ argument-hint: <issue-number>
 
 @~/.claude/skills/gitea/SKILL.md
 
-1. **View the issue** to understand requirements
+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

learnings/README.md

@@ -0,0 +1,88 @@
+# Learnings
+
+This folder captures learnings from retrospectives and day-to-day work. Learnings serve three purposes:
+
+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
+
+## The Learning Flow
+
+```
+Experience → Learning captured → Encoded into system → Knowledge is actionable
+                   ↓
+            Stays here for:
+            - Historical reference
+            - Governance validation
+            - 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.
+
+## Writing a Learning
+
+Create a new file: `YYYY-MM-DD-short-title.md`
+
+Use this template:
+
+```markdown
+# [Title]
+
+**Date**: YYYY-MM-DD
+**Context**: What triggered this learning (task, incident, observation)
+
+## Learning
+
+The insight we gained. Be specific and actionable.
+
+## Encoded In
+
+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
+
+If not yet encoded, note: "Pending: Issue #XX"
+
+## Governance
+
+What this learning means for how we work going forward. This is the "why" that justifies the encoding.
+```
+
+## Encoding Process
+
+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
+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.
+
+## What Gets Encoded Where
+
+| Learning Type | Encode In |
+|---------------|-----------|
+| How to use a tool | `skills/` |
+| Workflow improvement | `commands/` |
+| Subtask behavior | `agents/` |
+| Organization belief | `manifesto.md` |
+| Product direction | `vision.md` (in product repo) |
+
+## Periodic Review
+
+Periodically review learnings to:
+
+- Verify encoded locations still reflect the learning
+- Check if governance is still being followed
+- Identify patterns across multiple learnings
+- Archive or update outdated learnings
+
+## Naming Convention
+
+Files follow the pattern: `YYYY-MM-DD-short-kebab-title.md`
+
+Examples:
+- `2024-01-15-always-use-comments-flag.md`
+- `2024-01-20-verify-before-cleanup.md`
+- `2024-02-01-small-prs-merge-faster.md`

manifesto.md

@@ -0,0 +1,78 @@
+# Manifesto
+
+## Who We Are
+
+We are a small, focused team of AI-native builders. We believe the future of software development is human-AI collaboration, and we're building the tools and practices to make that real.
+
+We move fast with intention. We value quality over quantity. We encode our knowledge into systems that amplify what we can accomplish.
+
+## Who We Serve
+
+### Solo Developer
+The individual shipping side projects, MVPs, or freelance work. Time is their scarcest resource. They context-switch between coding, design, ops, and everything else. They need to move fast without sacrificing quality, and they can't afford to remember every command or best practice.
+
+### Small Team (2-5 people)
+The startup or small product team that needs to punch above their weight. They don't have dedicated specialists for every function. They need consistency across contributors and visibility into what's happening without heavyweight process.
+
+### Agency / Consultancy
+Building for clients under deadlines. They need speed, consistency, and the ability to apply learnings across projects. Every efficiency gain multiplies across engagements.
+
+## What They're Trying to Achieve
+
+- "Help me ship without getting bogged down in repetitive tasks"
+- "Help me maintain quality without slowing down"
+- "Help me know what to work on next without checking multiple tools"
+- "Help me apply best practices without memorizing them"
+- "Help me onboard to codebases faster"
+- "Help me stay in flow instead of context-switching"
+
+## What We Believe
+
+### AI-Augmented Development
+
+We believe AI fundamentally changes how software is built:
+
+- **Developers become orchestrators.** The role shifts from writing every line to directing, reviewing, and refining. The human provides judgment, context, and intent. AI handles execution and recall.
+
+- **Repetitive tasks should be automated.** If you do something more than twice, encode it. Commits, PR creation, issue management, code review - these should flow, not interrupt.
+
+- **AI amplifies individuals.** A solo developer with good AI tooling can accomplish what used to require a team. Small teams can tackle problems that used to need departments.
+
+- **Knowledge belongs in systems, not heads.** Best practices, patterns, and learnings should be encoded where AI can apply them. Tribal knowledge is a liability.
+
+- **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.
+
+### Quality Without Ceremony
+
+- Ship small, ship often
+- Automate verification, not just generation
+- Good defaults beat extensive configuration
+- Working software over comprehensive documentation
+
+### Sustainable Pace
+
+- Tools should reduce cognitive load, not add to it
+- Automation should free humans for judgment calls
+- The goal is flow, not burnout
+
+## Guiding Principles
+
+1. **Encode, don't document.** If something is important enough to write down, it's important enough to encode into a skill, command, or agent that can act on it.
+
+2. **Small teams, big leverage.** Design for amplification. Every tool, pattern, and practice should multiply what individuals can accomplish.
+
+3. **Opinionated defaults, escape hatches available.** Make the right thing easy. Make customization possible but not required.
+
+4. **Learn in public.** Capture learnings. Update the system. Share what works.
+
+5. **Ship to learn.** Prefer shipping something imperfect and learning from reality over planning for perfection.
+
+## Non-Goals
+
+- **Building for enterprises with complex compliance needs.** We optimize for speed and small teams, not audit trails and approval workflows.
+
+- **Supporting every tool and platform.** We go deep on our chosen stack rather than shallow on everything.
+
+- **Replacing developer judgment.** AI augments human decision-making; it doesn't replace it. Critical thinking, architecture decisions, and user empathy remain human responsibilities.
+
+- **Comprehensive documentation for its own sake.** We encode knowledge into actionable systems. Docs exist to explain the "why," not to duplicate what the system already does.

skills/backlog-grooming/SKILL.md

@@ -33,10 +33,18 @@ For each issue, verify:
 - [ ] Clear boundaries (what's included/excluded)
 
 ### 5. Dependencies
-- [ ] Dependencies identified
+- [ ] Dependencies identified in description
+- [ ] Dependencies formally linked (`tea issues deps list <number>`)
 - [ ] No circular dependencies
 - [ ] Blocking issues are tracked
 
+To check/fix dependencies:
+```bash
+tea issues deps list <number>           # View current dependencies
+tea issues deps add <issue> <blocker>   # Add missing dependency
+tea issues deps remove <issue> <dep>    # Remove incorrect dependency
+```
+
 ### 6. Labels
 - [ ] Type label (bug/feature/etc)
 - [ ] Priority if applicable

skills/gitea/SKILL.md

@@ -70,6 +70,13 @@ tea issues reopen <number>
 
 # Labels
 tea issues edit <number> --labels "bug,help wanted"
+
+# Dependencies
+tea issues deps list <number>              # List blockers for an issue
+tea issues deps add <issue> <blocker>      # Add dependency (issue is blocked by blocker)
+tea issues deps add 5 3                    # Issue #5 depends on #3
+tea issues deps add 5 owner/repo#3         # Cross-repo dependency
+tea issues deps remove <issue> <blocker>   # Remove a dependency
 ```
 
 ### Pull Requests

skills/issue-writing/SKILL.md

@@ -104,7 +104,19 @@ Use labels to categorize:
 
 ## Dependencies
 
-Reference related issues:
+Identify and link dependencies when creating issues:
-- "Depends on #N" - Must complete first
+
-- "Blocks #N" - This blocks another
+1. **In the description**, document dependencies:
-- "Related to #N" - Informational link
+   ```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.

skills/roadmap-planning/SKILL.md

@@ -80,6 +80,13 @@ In issue descriptions:
 - Depends on #13 (API setup)
 ```
 
+After creating issues, formally link dependencies:
+```bash
+tea issues deps add <issue> <blocker>
+tea issues deps add 14 12    # Issue #14 depends on #12
+tea issues deps add 14 13    # Issue #14 depends on #13
+```
+
 ## Creating Issues
 
 Use the gitea skill for issue operations.

skills/vision-management/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: vision-management
+description: Create, maintain, and evolve a product vision. Use when initializing a vision, updating goals, aligning work with vision, or connecting learnings to vision refinement.
+---
+
+# Vision Management
+
+How to create, maintain, and evolve a product vision for continuous improvement.
+
+## Architecture
+
+The vision system has two layers:
+
+| Layer | Purpose | Location |
+|-------|---------|----------|
+| **vision.md** | North star philosophy (why, principles, non-goals) | File in repo root |
+| **Milestones** | Goals with progress tracking | Gitea milestones |
+
+- **vision.md** is stable - updated rarely when direction changes
+- **Milestones** are actionable - created/closed as goals evolve
+- **Issues** are assigned to milestones to track progress
+
+## Vision Document Structure
+
+The vision.md file should contain the stable "why" and "who" - not progress tracking:
+
+```markdown
+# Vision
+
+## Who We Serve (Personas)
+The people we're building for and what characterizes them.
+
+- **Persona Name**: Brief description of who they are, their context, constraints
+
+## What They're Trying to Achieve (Jobs to Be Done)
+The outcomes our personas are trying to accomplish - in their words.
+
+- "Help me [achieve outcome] without [pain point]"
+- "Help me [do thing] so I can [benefit]"
+
+## The Problem
+Current pain points that prevent our personas from achieving their jobs.
+
+## The Solution
+How this product addresses the jobs to be done.
+
+## Guiding Principles
+Core beliefs that guide decisions.
+
+## Non-Goals
+What we're explicitly NOT doing (and why).
+```
+
+Do NOT include goals, progress, or focus in vision.md - that's what milestones are for.
+
+## Defining Personas
+
+Good personas are:
+- **Specific**: Not "developers" but "solo developers shipping MVPs"
+- **Characterized**: Include constraints, context, priorities
+- **Limited**: 2-4 personas max, or you're building for everyone (no one)
+
+| Bad | Good |
+|-----|------|
+| "Users" | "Solo developer shipping side projects on evenings/weekends" |
+| "Developers" | "Small team lead coordinating 2-5 engineers" |
+| "Companies" | "Early-stage startup with no dedicated DevOps" |
+
+## Defining Jobs to Be Done
+
+Jobs should be:
+- **Outcome-focused**: What they want to achieve, not what they do
+- **In their voice**: How they'd describe it, not technical jargon
+- **Pain-aware**: Include what's hard about it today
+
+Format: "Help me [outcome] without [pain]" or "Help me [action] so I can [benefit]"
+
+| Bad | Good |
+|-----|------|
+| "Git integration" | "Help me commit and push without remembering git commands" |
+| "Issue tracking" | "Help me know what to work on next without checking 5 tools" |
+| "Code review" | "Help me catch bugs before they ship without slowing down" |
+
+## Creating a Vision
+
+When no vision exists:
+
+1. **Define personas**: Who are we building for? (2-4 specific personas)
+2. **Identify jobs to be done**: What are they trying to achieve?
+3. **Articulate the problem**: What pain points prevent them from achieving their jobs?
+4. **Define the solution**: How does the product address these jobs?
+5. **Set guiding principles**: What beliefs guide decisions?
+6. **Document non-goals**: What are you explicitly NOT doing?
+7. **Create initial milestones**: 3-5 measurable goals tied to personas/jobs
+
+### Good Goals (Milestones)
+
+- Specific and measurable
+- Tied to a persona and job to be done
+- Outcome-focused (not activity-focused)
+- Have clear success criteria in the description
+
+| Bad | Good |
+|-----|------|
+| "Improve performance" | "Page load under 2 seconds" |
+| "Better UX" | "User can complete checkout in under 60 seconds" |
+| "More features" | "Support 3 export formats (CSV, JSON, PDF)" |
+
+### Tying Milestones to Personas
+
+Each milestone should clearly serve a persona's job to be done:
+
+```
+Milestone: "Automate routine git workflows"
+For: Solo developer
+Job: "Help me commit and push without remembering git commands"
+Success: /commit, /pr commands handle 80% of git workflows
+```
+
+Include persona context in milestone descriptions:
+```bash
+tea milestones create --title "Automate routine git workflows" \
+  --description "For: Solo developer
+Job: Ship without context switching to git commands
+Success: /commit and /pr commands handle 80% of workflows"
+```
+
+## Managing Goals with Milestones
+
+```bash
+# List milestones with progress
+tea milestones
+tea milestones -f title,items_open,items_closed,state
+
+# Create a new goal
+tea milestones create --title "Automate repetitive workflows" \
+  --description "Success: 80% of routine tasks handled by slash commands"
+
+# View issues in a milestone
+tea milestones issues "Automate repetitive workflows"
+
+# Close a completed goal
+tea milestones close "Automate repetitive workflows"
+```
+
+### Assigning Issues to Milestones
+
+When creating issues, assign them to the relevant milestone:
+
+```bash
+tea issues create --title "Add /commit command" \
+  --description "..." \
+  --milestone "Automate repetitive workflows"
+```
+
+Progress is automatically tracked through open/closed issue counts.
+
+## Aligning Issues with Vision
+
+When creating or reviewing issues:
+
+1. **Check persona alignment**: Which persona does this serve?
+2. **Check job alignment**: Which job to be done does this enable?
+3. **Check goal alignment**: Does this issue support a milestone?
+4. **Assign to milestone**: Link the issue to the relevant goal
+5. **Prioritize by focus**: Issues in priority milestones get worked first
+6. **Flag misalignment**: Issues without clear persona/milestone need justification
+
+Every issue should trace back to: "This helps [persona] achieve [job] by [outcome]."
+
+### Identifying Gaps
+
+Compare vision to current work:
+
+- **Underserved personas**: Which personas have few milestones/issues?
+- **Unaddressed jobs**: Which jobs to be done have no work toward them?
+- **Empty milestones**: Which milestones have no issues?
+- **Stalled milestones**: Which milestones have no recent progress?
+- **Orphan issues**: Are there issues without a milestone?
+
+## Connecting Retros to Vision
+
+After a retrospective:
+
+1. **Review learnings**: Any that affect the vision or goals?
+2. **Milestone changes**: Should any goals be added, closed, or modified?
+3. **Non-goal additions**: Did we learn something to add to vision.md?
+4. **Progress check**: Did completed work close any milestones?
+
+### Retro-to-Vision Questions
+
+- "Did this work reveal a new goal we should add as a milestone?"
+- "Did we learn something that should become a non-goal in vision.md?"
+- "Should we close or modify any milestones based on what we learned?"
+- "Are any milestones ready to close?"
+
+## Continuous Improvement Loop
+
+```
+Vision → Milestones → Issues → Work → Retro → (Vision/Milestones updated)
+```
+
+1. **Vision** defines why and principles (stable)
+2. **Milestones** define measurable goals
+3. **Issues** are work items toward those goals
+4. **Work** implements the issues
+5. **Retros** capture learnings
+6. **Updates** refine vision and create/close milestones
+
+The vision is stable. The milestones evolve as you learn and achieve goals.