docs: update AGENTS.md and README.md for rules system, remove beads

- Add rules/ directory documentation to both files
- Update skill count from 25 to 15 modules
- Remove beads references (issue tracking removed)
- Update skills list with current active skills
- Document flake.nix as proper Nix flake (not flake=false)
- Add rules system integration section
- Clean up sisyphus planning artifacts
- Remove deprecated skills (memory, msteams, outlook)

.beads/.gitignore

@@ -1,39 +0,0 @@
-# SQLite databases
-*.db
-*.db?*
-*.db-journal
-*.db-wal
-*.db-shm
-
-# Daemon runtime files
-daemon.lock
-daemon.log
-daemon.pid
-bd.sock
-sync-state.json
-last-touched
-
-# Local version tracking (prevents upgrade notification spam after git ops)
-.local_version
-
-# Legacy database files
-db.sqlite
-bd.db
-
-# Worktree redirect file (contains relative path to main repo's .beads/)
-# Must not be committed as paths would be wrong in other clones
-redirect
-
-# Merge artifacts (temporary files from 3-way merge)
-beads.base.jsonl
-beads.base.meta.json
-beads.left.jsonl
-beads.left.meta.json
-beads.right.jsonl
-beads.right.meta.json
-
-# NOTE: Do NOT add negation patterns (e.g., !issues.jsonl) here.
-# They would override fork protection in .git/info/exclude, allowing
-# contributors to accidentally commit upstream issue databases.
-# The JSONL files (issues.jsonl, interactions.jsonl) and config files
-# are tracked by git by default since no pattern above ignores them.

.beads/README.md

@@ -1,81 +0,0 @@
-# Beads - AI-Native Issue Tracking
-
-Welcome to Beads! This repository uses **Beads** for issue tracking - a modern, AI-native tool designed to live directly in your codebase alongside your code.
-
-## What is Beads?
-
-Beads is issue tracking that lives in your repo, making it perfect for AI coding agents and developers who want their issues close to their code. No web UI required - everything works through the CLI and integrates seamlessly with git.
-
-**Learn more:** [github.com/steveyegge/beads](https://github.com/steveyegge/beads)
-
-## Quick Start
-
-### Essential Commands
-
-```bash
-# Create new issues
-bd create "Add user authentication"
-
-# View all issues
-bd list
-
-# View issue details
-bd show <issue-id>
-
-# Update issue status
-bd update <issue-id> --status in_progress
-bd update <issue-id> --status done
-
-# Sync with git remote
-bd sync
-```
-
-### Working with Issues
-
-Issues in Beads are:
-- **Git-native**: Stored in `.beads/issues.jsonl` and synced like code
-- **AI-friendly**: CLI-first design works perfectly with AI coding agents
-- **Branch-aware**: Issues can follow your branch workflow
-- **Always in sync**: Auto-syncs with your commits
-
-## Why Beads?
-
-✨ **AI-Native Design**
-- Built specifically for AI-assisted development workflows
-- CLI-first interface works seamlessly with AI coding agents
-- No context switching to web UIs
-
-🚀 **Developer Focused**
-- Issues live in your repo, right next to your code
-- Works offline, syncs when you push
-- Fast, lightweight, and stays out of your way
-
-🔧 **Git Integration**
-- Automatic sync with git commits
-- Branch-aware issue tracking
-- Intelligent JSONL merge resolution
-
-## Get Started with Beads
-
-Try Beads in your own projects:
-
-```bash
-# Install Beads
-curl -sSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash
-
-# Initialize in your repo
-bd init
-
-# Create your first issue
-bd create "Try out Beads"
-```
-
-## Learn More
-
-- **Documentation**: [github.com/steveyegge/beads/docs](https://github.com/steveyegge/beads/tree/main/docs)
-- **Quick Start Guide**: Run `bd quickstart`
-- **Examples**: [github.com/steveyegge/beads/examples](https://github.com/steveyegge/beads/tree/main/examples)
-
----
-
-*Beads: Issue tracking that moves at the speed of thought* ⚡

.beads/config.yaml

@@ -1,62 +0,0 @@
-# Beads Configuration File
-# This file configures default behavior for all bd commands in this repository
-# All settings can also be set via environment variables (BD_* prefix)
-# or overridden with command-line flags
-
-# Issue prefix for this repository (used by bd init)
-# If not set, bd init will auto-detect from directory name
-# Example: issue-prefix: "myproject" creates issues like "myproject-1", "myproject-2", etc.
-# issue-prefix: ""
-
-# Use no-db mode: load from JSONL, no SQLite, write back after each command
-# When true, bd will use .beads/issues.jsonl as the source of truth
-# instead of SQLite database
-# no-db: false
-
-# Disable daemon for RPC communication (forces direct database access)
-# no-daemon: false
-
-# Disable auto-flush of database to JSONL after mutations
-# no-auto-flush: false
-
-# Disable auto-import from JSONL when it's newer than database
-# no-auto-import: false
-
-# Enable JSON output by default
-# json: false
-
-# Default actor for audit trails (overridden by BD_ACTOR or --actor)
-# actor: ""
-
-# Path to database (overridden by BEADS_DB or --db)
-# db: ""
-
-# Auto-start daemon if not running (can also use BEADS_AUTO_START_DAEMON)
-# auto-start-daemon: true
-
-# Debounce interval for auto-flush (can also use BEADS_FLUSH_DEBOUNCE)
-# flush-debounce: "5s"
-
-# Git branch for beads commits (bd sync will commit to this branch)
-# IMPORTANT: Set this for team projects so all clones use the same sync branch.
-# This setting persists across clones (unlike database config which is gitignored).
-# Can also use BEADS_SYNC_BRANCH env var for local override.
-# If not set, bd sync will require you to run 'bd config set sync.branch <branch>'.
-# sync-branch: "beads-sync"
-
-# Multi-repo configuration (experimental - bd-307)
-# Allows hydrating from multiple repositories and routing writes to the correct JSONL
-# repos:
-#   primary: "."  # Primary repo (where this database lives)
-#   additional:   # Additional repos to hydrate from (read-only)
-#     - ~/beads-planning  # Personal planning repo
-#     - ~/work-planning   # Work planning repo
-
-# Integration settings (access with 'bd config get/set')
-# These are stored in the database, not in this file:
-# - jira.url
-# - jira.project
-# - linear.url
-# - linear.api-key
-# - github.org
-# - github.repo

.beads/issues.jsonl

@@ -1,11 +0,0 @@
-{"id":"AGENTS-1jw","title":"Athena prompt: Convert to numbered responsibility format","description":"Athena prompt uses bullet points under 'Core Capabilities' section instead of numbered lists. Per agent-development skill best practices, responsibilities should be numbered (1, 2, 3) for clarity. Update prompts/athena.txt to use numbered format.","status":"closed","priority":2,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:32:16.133701271+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:32:26.165270695+01:00","closed_at":"2026-01-26T19:32:26.165270695+01:00","close_reason":"Converted responsibility subsections from ### numbered headers to numbered list format (1., 2., 3., 4.) with bold titles"}
-{"id":"AGENTS-7gt","title":"Athena prompt: Rename Core Capabilities to exact header","description":"Athena prompt uses 'Core Capabilities' section header instead of 'Your Core Responsibilities:'. Per agent-development skill guidelines, the exact header 'Your Core Responsibilities:' should be used for consistency. Update prompts/athena.txt to use the exact recommended header.","status":"closed","priority":1,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:32:07.223102836+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:31:19.080626796+01:00","closed_at":"2026-01-26T19:31:19.080626796+01:00","close_reason":"Renamed 'Core Capabilities' section header to exact 'Your Core Responsibilities:' in prompts/athena.txt"}
-{"id":"AGENTS-8ie","title":"Set up PARA work structure with 10 Basecamp projects","description":"Create 01-projects/work/ structure with project folders for all Basecamp projects. Each project needs: _index.md (MOC with Basecamp link), meetings/, decisions/, notes/. Also set up 02-areas/work/ for ongoing responsibilities.","status":"closed","priority":0,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-28T18:47:56.048622809+01:00","created_by":"m3tm3re","updated_at":"2026-01-28T18:57:09.033627658+01:00","closed_at":"2026-01-28T18:57:09.033627658+01:00","close_reason":"Created complete PARA work structure: 01-projects/work/ with 10 project folders (each with _index.md, meetings/, decisions/, notes/), 02-areas/work/ with 5 area files. Projects use placeholder names - user can customize with actual Basecamp data."}
-{"id":"AGENTS-9cs","title":"Configure basecamp skill with real projects","description":"Configure basecamp skill to work with real projects. Need to: get user's Basecamp projects, map them to PARA structure, test morning planning workflow with Basecamp todos.","status":"closed","priority":0,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-28T18:47:56.04844425+01:00","created_by":"m3tm3re","updated_at":"2026-01-28T18:57:14.097333313+01:00","closed_at":"2026-01-28T18:57:14.097333313+01:00","close_reason":"Enhanced basecamp skill with project mapping configuration. Added section on mapping Basecamp projects to PARA structure, with configuration examples and usage patterns. Ready for user to fetch actual projects and set up mappings."}
-{"id":"AGENTS-der","title":"Create Outline skill for MCP integration","status":"closed","priority":2,"issue_type":"feature","owner":"p@m3ta.dev","created_at":"2026-01-28T18:47:56.042886345+01:00","created_by":"m3tm3re","updated_at":"2026-01-28T18:51:21.662507568+01:00","closed_at":"2026-01-28T18:51:21.662507568+01:00","close_reason":"Created outline/SKILL.md with comprehensive workflows, tool references, and integration patterns. Added references/outline-workflows.md and references/export-patterns.md for detailed examples."}
-{"id":"AGENTS-fac","title":"Design Teams transcript processing workflow (manual)","description":"Design manual workflow for Teams transcript processing: DOCX upload → extract text → AI analysis → meeting note + action items → optional Basecamp sync. Create templates and integration points.","status":"closed","priority":2,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-28T18:47:56.052076817+01:00","created_by":"m3tm3re","updated_at":"2026-01-28T18:56:34.567325504+01:00","closed_at":"2026-01-28T18:56:34.567325504+01:00","close_reason":"Created comprehensive Teams transcript workflow guide in skills/meeting-notes/references/teams-transcript-workflow.md. Includes: manual step-by-step process, Python script for DOCX extraction, AI analysis prompts, Obsidian templates, Basecamp sync integration, troubleshooting guide."}
-{"id":"AGENTS-in5","title":"Athena prompt: Standardize section headers","description":"Athena prompt uses 'Ethical Guidelines' and 'Methodological Rigor' headers instead of standard 'Quality Standards' and 'Edge Cases' headers. While semantically equivalent, skill recommends exact headers for consistency. Consider renaming in prompts/athena.txt.","status":"closed","priority":2,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:32:21.720932741+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:33:15.959382333+01:00","closed_at":"2026-01-26T19:33:15.959382333+01:00","close_reason":"Renamed '## Ethical Guidelines' to '## Quality Standards' for consistency with agent-development skill guidelines"}
-{"id":"AGENTS-lyd","title":"Athena agent: Add explicit mode field","description":"Athena agent is missing the explicit 'mode': 'subagent' field. Per agent-development skill guidelines, all agents should explicitly declare mode for clarity. Current config relies on default which makes intent unclear.","status":"closed","priority":0,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:31:46.255196119+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:30:46.191545632+01:00","closed_at":"2026-01-26T19:30:46.191545632+01:00","close_reason":"Added explicit 'mode': 'subagent' field to athena agent in agent/agents.json"}
-{"id":"AGENTS-mfw","title":"Athena agent: Add temperature setting","description":"Athena agent lacks explicit temperature configuration. Per agent-development skill, research/analysis agents should use temperature 0.0-0.2 for focused, deterministic, consistent results. Add 'temperature': 0.1 to agent config in agents.json.","status":"closed","priority":1,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:31:55.726506579+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:31:06.905697638+01:00","closed_at":"2026-01-26T19:31:06.905697638+01:00","close_reason":"Added 'temperature': 0.1 to athena agent in agent/agents.json for focused, deterministic results"}
-{"id":"AGENTS-mvv","title":"Enhance daily routines with work context","status":"closed","priority":1,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-28T18:47:56.066628593+01:00","created_by":"m3tm3re","updated_at":"2026-01-28T18:56:34.576536473+01:00","closed_at":"2026-01-28T18:56:34.576536473+01:00","close_reason":"Enhanced daily-routines skill with full work context integration. Added sections for: morning planning with Basecamp/Outline, evening reflection with work metrics, weekly review with project status tracking, work area health review, work inbox processing."}
-{"id":"AGENTS-o45","title":"Agent development: Document validation script availability","description":"The agent-development skill references scripts/validate-agent.sh but this script doesn't exist in the repository. Consider either: (1) creating the validation script, or (2) removing the reference and only documenting the python3 alternative.","status":"closed","priority":2,"issue_type":"task","owner":"p@m3ta.dev","created_at":"2026-01-24T19:32:27.325525742+01:00","created_by":"m3tm3re","updated_at":"2026-01-26T19:34:17.846875543+01:00","closed_at":"2026-01-26T19:34:17.846875543+01:00","close_reason":"Removed references to non-existent scripts/validate-agent.sh and documented python3 validation as the primary method"}

.beads/metadata.json

@@ -1,4 +0,0 @@
-{
-  "database": "beads.db",
-  "jsonl_export": "issues.jsonl"
-}

.envrc

@@ -0,0 +1 @@
+use flake

.gitignore

@@ -0,0 +1,14 @@
+.todos/
+
+# Sidecar worktree state files
+.sidecar/
+.sidecar-agent
+.sidecar-task
+.sidecar-pr
+.sidecar-start.sh
+.sidecar-base
+.td-root
+
+# Nix / direnv
+.direnv/
+result

.sisyphus/notepads/chiron-agent-framework/learnings.md

@@ -1,48 +0,0 @@
-# Learnings - Chiron Agent Framework
-
-## Task: Update agents/agents.json with 6 Chiron agents
-
-### Agent Configuration Pattern
-- JSON structure: `{ "agent-name": { "description": "...", "mode": "...", "model": "...", "prompt": "{file:./prompts/...}", "permission": { "question": "..." } } }`
-- Two primary agents: `chiron` (plan mode) and `chiron-forge` (build mode)
-- Four subagents: `hermes` (work comm), `athena` (work knowledge), `apollo` (private knowledge), `calliope` (writing)
-- All agents use `zai-coding-plan/glm-4.7` model
-- Prompts are file references: `{file:./prompts/agent-name.txt}`
-- Permissions use simple allow: `{ "question": "allow" }`
-
-### Verification
-- JSON validation: `python3 -c "import json; json.load(open('agents/agents.json'))"`
-- No MCP configuration needed for agent definitions
-- Mode values: "primary" or "subagent"
-
-### Files Modified
-- `agents/agents.json` - Expanded from 1 to 6 agents (8 lines → 57 lines)
-
-### Successful Approaches
-- Follow existing JSON structure pattern
-- Maintain consistent indentation and formatting
-- Use file references for prompts (not inline)
-
-## Task: Create prompts/chiron-forge.txt
-
-### Chiron-Forge Prompt Pattern
-- Purpose: Execution/build mode counterpart to Chiron's planning mode
-- Identity: Worker-mode AI assistant with full write access
-- Core distinction: Chiron = planning/analysis, Chiron-Forge = building/executing
-- Second-person addressing: "You are..." format
-
-### Key Components
-- **Identity**: "execution and build mode counterpart to Chiron"
-- **Capabilities**: Full write access, read files, create/modify files, execute bash commands
-- **Workflow**: Receive → Understand → Plan Action → Execute → Confirm (destructive) → Report
-- **Safety**: Question tool for destructive operations (rm *, git push), sudo denied
-- **Delegation**: Still delegates to subagents for specialized domains
-- **Scope boundaries**: NOT planning/analysis agent, NOT evaluation of alternatives
-
-### Verification
-- File size: 3185 chars (target >500)
-- Keywords present: execution, build, worker, write
-- Lines: 67
-
-### Files Created
-- `prompts/chiron-forge.txt` - Chiron-Forge build mode system prompt

.sisyphus/plans/agent-permissions-refinement.md

@@ -1,748 +0,0 @@
-# Agent Permissions Refinement
-
-## TL;DR
-
-> **Quick Summary**: Refine OpenCode agent permissions for Chiron (planning) and Chriton-Forge (build) to implement 2025 AI security best practices with principle of least privilege, human-in-the-loop for critical actions, and explicit guardrails against permission bypass.
-
-> **Deliverables**:
-> - Updated `agents/agents.json` with refined permissions for Chiron and Chriton-Forge
-> - Critical bug fix: Duplicate `external_directory` key in Chiron config
-> - Enhanced secret blocking with additional patterns
-> - Bash injection prevention rules
-> - Git protection against secret commits and repo hijacking
-
-> **Estimated Effort**: Medium
-> **Parallel Execution**: NO - sequential changes to single config file
-> **Critical Path**: Fix duplicate key → Apply Chiron permissions → Apply Chriton-Forge permissions → Validate
-
----
-
-## Context
-
-### Original Request
-User wants to refine agent permissions for:
-- **Chiron**: Planning agent with read-only access, restricted to read-only subagents, no file editing, can create beads issues
-- **Chriton-Forge**: Build agent with write access restricted to ~/p/**, git commits allowed but git push asks, package install commands ask
-- **General**: Sane defaults that are secure but open enough for autonomous work
-
-### Interview Summary
-**Key Discussions**:
-- Chiron: Read-only planning, no file editing, bash denied except for `bd *` commands, external_directory ~/p/** only, task permission to restrict subagents to explore/librarian/athena + chiron-forge for handoff
-- Chriton-Forge: Write access restricted to ~/p/**, git commits allow / git push ask, package install commands ask, git config deny
-- Workspace path: ~/p/** is symlink to ~/projects/personal/** (just replacing path reference)
-- Bash security: Block all bash redirect patterns (echo >, cat >, tee, etc.)
-
-**Research Findings**:
-- OpenCode supports granular permission rules with wildcards, last-match-wins
-- 2025 best practices: Principle of least privilege, tiered permissions (read-only auto, destructive ask, JIT privileges), human-in-the-loop for critical actions
-- Security hardening: Block command injection vectors, prevent git secret commits, add comprehensive secret blocking patterns
-
-### Metis Review
-**Critical Issues Identified**:
-1. **Duplicate `external_directory` key** in Chiron config (lines 8-9 and 27) - second key overrides first, breaking intended behavior
-2. **Bash edit bypass**: Even with `edit: deny`, bash can write files via redirection (`echo "x" > file.txt`, `cat >`, `tee`)
-3. **Git secret protection**: Agent could commit secrets (read .env, then git commit .env)
-4. **Git config hijacking**: Agent could modify .git/config to push to attacker-controlled repo
-5. **Command injection**: Malicious content could execute via `$()`, backticks, `eval`, `source`
-6. **Secret blocking incomplete**: Missing patterns for `.local/share/*`, `.cache/*`, `*.db`, `*.keychain`, `*.p12`
-
-**Guardrails Applied**:
-- Fix duplicate external_directory key (use single object with catch-all `"*": "ask"` after specific rules)
-- Add bash file write protection patterns (echo >, cat >, printf >, tee, > operators)
-- Add git secret protection (`git add *.env*`: deny, `git commit *.env*`: deny)
-- Add git config protection (`git config *`: deny for Chriton-Forge)
-- Add bash injection prevention (`$(*`, `` `*``, `eval *`, `source *`)
-- Expand secret blocking with additional patterns
-- Add /run/agenix/* to read deny list
-
----
-
-## Work Objectives
-
-### Core Objective
-Refine OpenCode agent permissions in `agents/agents.json` to implement security hardening based on 2025 AI agent best practices while maintaining autonomous workflow capabilities.
-
-### Concrete Deliverables
-- Updated `agents/agents.json` with:
-  - Chiron: Read-only permissions, subagent restrictions, bash denial (except `bd *`), no file editing
-  - Chriton-Forge: Write access scoped to ~/p/**, git commit allow / push ask, package install ask, git config deny
-  - Both: Enhanced secret blocking, bash injection prevention, git secret protection
-
-### Definition of Done
-- [x] Permission configuration updated in `agents/agents.json`
-- [x] JSON syntax valid (no duplicate keys, valid structure)
-- [x] Workspace path validated (~/p/** exists and is correct)
-- [x] Acceptance criteria tests pass (via manual verification)
-
-### Must Have
-- Chiron cannot edit files directly
-- Chiron cannot write files via bash (redirects blocked)
-- Chiron restricted to read-only subagents + chiron-forge for handoff
-- Chriton-Forge can only write to ~/p/**
-- Chriton-Forge cannot git config
-- Both agents block secret file reads
-- Both agents prevent command injection
-- Git operations cannot commit secrets
-- No duplicate keys in permission configuration
-
-### Must NOT Have (Guardrails)
-- **Edit bypass via bash**: No bash redirection patterns that allow file writes when `edit: deny`
-- **Git secret commits**: No ability to git add/commit .env or credential files
-- **Repo hijacking**: No git config modification allowed for Chriton-Forge
-- **Command injection**: No `$()`, backticks, `eval`, `source` execution via bash
-- **Write scope escape**: Chriton-Forge cannot write outside ~/p/** without asking
-- **Secret exfiltration**: No access to .env, .ssh, .gnupg, credentials, secrets, .pem, .key, /run/agenix
-- **Unrestricted bash for Chiron**: Only `bd *` commands allowed
-
----
-
-## Verification Strategy (MANDATORY)
-
-> This is configuration work, not code development. Manual verification is required after deployment.
-
-### Test Decision
-- **Infrastructure exists**: YES (home-manager deployment)
-- **User wants tests**: NO (Manual-only verification)
-- **Framework**: None
-
-### Manual Verification Procedures
-
-Each TODO includes EXECUTABLE verification procedures that users can run to validate changes.
-
-**Verification Commands to Run After Deployment:**
-
-1. **JSON Syntax Validation**:
-```bash
-# Validate JSON structure and no duplicate keys
-jq '.' /home/m3tam3re/p/AI/AGENTS/agents/agents.json > /dev/null 2>&1
-# Expected: Exit code 0 (valid JSON)
-
-# Check for duplicate keys (manual review of chiron permission object)
-# Expected: Single external_directory key, no other duplicates
-```
-
-2. **Workspace Path Validation**:
-```bash
-ls -la ~/p/ 2>&1
-# Expected: Directory exists, shows contents (likely symlink to ~/projects/personal/)
-```
-
-3. **After Deployment - Chiron Read-Only Test** (manual):
-- Have Chiron attempt to edit a test file
-  - Expected: Permission denied with clear error message
-- Have Chiron attempt to write via bash (echo "test" > /tmp/test.txt)
-  - Expected: Permission denied
-- Have Chiron run `bd ready` command
-  - Expected: Command succeeds, returns JSON output with issue list
-- Have Chiron attempt to invoke build-capable subagent (sisyphus-junior)
-  - Expected: Permission denied
-
-4. **After Deployment - Chiron Workspace Access** (manual):
-- Have Chiron read file within ~/p/**
-  - Expected: Success, returns file contents
-- Have Chiron read file outside ~/p/**
-  - Expected: Permission denied or ask user
-- Have Chiron delegate to explore/librarian/athena
-  - Expected: Success, subagent executes
-
-5. **After Deployment - Chriton-Forge Write Access** (manual):
-- Have Chriton-Forge write test file in ~/p/** directory
-  - Expected: Success, file created
-- Have Chriton-Forge attempt to write file to /tmp
-  - Expected: Ask user for approval
-- Have Chriton-Forge run `git add` and `git commit -m "test"`
-  - Expected: Success, commit created without asking
-- Have Chriton-Forge attempt `git push`
-  - Expected: Ask user for approval
-- Have Chriton-Forge attempt `git config`
-  - Expected: Permission denied
-- Have Chriton-Forge attempt `npm install lodash`
-  - Expected: Ask user for approval
-
-6. **After Deployment - Secret Blocking Tests** (manual):
-- Attempt to read .env file with both agents
-  - Expected: Permission denied
-- Attempt to read /run/agenix/ with Chiron
-  - Expected: Permission denied
-- Attempt to read .env.example (should be allowed)
-  - Expected: Success
-
-7. **After Deployment - Bash Injection Prevention** (manual):
-- Have agent attempt bash -c "$(cat /malicious)"
-  - Expected: Permission denied
-- Have agent attempt bash -c "`cat /malicious`"
-  - Expected: Permission denied
-- Have agent attempt eval command
-  - Expected: Permission denied
-
-8. **After Deployment - Git Secret Protection** (manual):
-- Have agent attempt `git add .env`
-  - Expected: Permission denied
-- Have agent attempt `git commit .env`
-  - Expected: Permission denied
-
-9. **Deployment Verification**:
-```bash
-# After home-manager switch, verify config is embedded correctly
-cat ~/.config/opencode/config.json | jq '.agent.chiron.permission.external_directory'
-# Expected: Shows ~/p/** rule, no duplicate keys
-
-# Verify agents load without errors
-# Expected: No startup errors when launching OpenCode
-```
-
----
-
-## Execution Strategy
-
-### Parallel Execution Waves
-
-> Single file sequential changes - no parallelization possible.
-
-```
-Single-Threaded Execution:
-Task 1: Fix duplicate external_directory key
-Task 2: Apply Chiron permission updates
-Task 3: Apply Chriton-Forge permission updates
-Task 4: Validate configuration
-```
-
-### Dependency Matrix
-
-| Task | Depends On | Blocks | Can Parallelize With |
-|------|------------|--------|---------------------|
-| 1 | None | 2, 3 | None (must start) |
-| 2 | 1 | 4 | 3 |
-| 3 | 1 | 4 | 2 |
-| 4 | 2, 3 | None | None (validation) |
-
-### Agent Dispatch Summary
-
-| Task | Recommended Agent |
-|------|-----------------|
-| 1 | delegate_task(category="quick", load_skills=["git-master"]) |
-| 2 | delegate_task(category="quick", load_skills=["git-master"]) |
-| 3 | delegate_task(category="quick", load_skills=["git-master"]) |
-| 4 | User (manual verification) |
-
----
-
-## TODOs
-
-> Implementation tasks for agent configuration changes. Each task MUST include acceptance criteria with executable verification.
-
-- [x] 1. Fix Duplicate external_directory Key in Chiron Config
-
-  **What to do**:
-  - Remove duplicate `external_directory` key from Chiron permission object
-  - Consolidate into single object with specific rule + catch-all `"*": "ask"`
-  - Replace `~/projects/personal/**` with `~/p/**` (symlink to same directory)
-
-  **Must NOT do**:
-  - Leave duplicate keys (second key overrides first, breaks config)
-  - Skip workspace path validation (verify ~/p/** exists)
-
-  **Recommended Agent Profile**:
-  > **Category**: quick
-    - Reason: Simple JSON edit, single file change, no complex logic
-  > **Skills**: git-master
-    - git-master: Git workflow for committing changes
-  > **Skills Evaluated but Omitted**:
-    - research: Not needed (no investigation required)
-    - librarian: Not needed (no external docs needed)
-
-  **Parallelization**:
-  - **Can Run In Parallel**: NO
-  - **Parallel Group**: Sequential
-  - **Blocks**: Tasks 2, 3 (depends on clean config)
-  - **Blocked By**: None (can start immediately)
-
-  **References** (CRITICAL - Be Exhaustive):
-
-  **Pattern References** (existing code to follow):
-  - `agents/agents.json:1-135` - Current agent configuration structure (JSON format, permission object structure)
-  - `agents/agents.json:7-29` - Chiron permission object (current state with duplicate key)
-
-  **API/Type References** (contracts to implement against):
-  - OpenCode permission schema: `{"permission": {"bash": {...}, "edit": "...", "external_directory": {...}, "task": {...}}`
-
-  **Documentation References** (specs and requirements):
-  - Interview draft: `.sisyphus/drafts/agent-permissions-refinement.md` - All user decisions and requirements
-  - Metis analysis: Critical issue #1 - Duplicate external_directory key
-
-  **External References** (libraries and frameworks):
-  - OpenCode docs: https://opencode.ai/docs/permissions/ - Permission system documentation (allow/ask/deny, wildcards, last-match-wins)
-  - OpenCode docs: https://opencode.ai/docs/agents/ - Agent configuration format
-
-  **WHY Each Reference Matters** (explain the relevance):
-  - `agents/agents.json` - Target file to modify, shows current structure and duplicate key bug
-  - Interview draft - Contains all user decisions (~/p/** path, subagent restrictions, etc.)
-  - OpenCode permissions docs - Explains permission system mechanics (last-match-wins critical for rule ordering)
-  - Metis analysis - Identifies the duplicate key bug that MUST be fixed
-
-  **Acceptance Criteria**:
-
-  > **CRITICAL: AGENT-EXECUTABLE VERIFICATION ONLY**
-
-  **Automated Verification (config validation)**:
-  \`\`\`bash
-  # Agent runs:
-  jq '.' /home/m3tam3re/p/AI/AGENTS/agents/agents.json > /dev/null 2>&1
-  # Assert: Exit code 0 (valid JSON)
-
-  # Verify single external_directory key in chiron permission object
-  cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron.permission | keys' | grep external_directory | wc -l
-  # Assert: Output is "1" (exactly one external_directory key)
-
-  # Verify workspace path exists
-  ls -la ~/p/ 2>&1 | head -1
-  # Assert: Shows directory listing (not "No such file or directory")
-  \`\`\`
-
-  **Evidence to Capture**:
-  - [x] jq validation output (exit code 0)
-  - [x] external_directory key count output (should be "1")
-  - [x] Workspace path ls output (shows directory exists)
-
-  **Commit**: NO (group with Task 2 and 3)
-
-- [x] 2. Apply Chiron Permission Updates
-
-  **What to do**:
-  - Set `edit` to `"deny"` (planning agent should not write files)
-  - Set `bash` permissions to deny all except `bd *`:
-    ```json
-    "bash": {
-      "*": "deny",
-      "bd *": "allow"
-    }
-    ```
-  - Set `external_directory` to `~/p/**` with catch-all ask:
-    ```json
-    "external_directory": {
-      "~/p/**": "allow",
-      "*": "ask"
-    }
-    ```
-  - Add `task` permission to restrict subagents:
-    ```json
-    "task": {
-      "*": "deny",
-      "explore": "allow",
-      "librarian": "allow",
-      "athena": "allow",
-      "chiron-forge": "allow"
-    }
-    ```
-  - Add `/run/agenix/*` to read deny list
-  - Add expanded secret blocking patterns: `.local/share/*`, `.cache/*`, `*.db`, `*.keychain`, `*.p12`
-
-  **Must NOT do**:
-  - Allow bash file write operators (echo >, cat >, tee, etc.) - will add in Task 3 for both agents
-  - Allow chiron to invoke build-capable subagents beyond chiron-forge
-  - Skip webfetch permission (should be "allow" for research capability)
-
-  **Recommended Agent Profile**:
-  > **Category**: quick
-    - Reason: JSON configuration update, follows clear specifications from draft
-  > **Skills**: git-master
-    - git-master: Git workflow for committing changes
-  > **Skills Evaluated but Omitted**:
-    - research: Not needed (all requirements documented in draft)
-    - librarian: Not needed (no external docs needed)
-
-  **Parallelization**:
-  - **Can Run In Parallel**: YES
-  - **Parallel Group**: Wave 2 (with Task 3)
-  - **Blocks**: Task 4
-  - **Blocked By**: Task 1
-
-  **References** (CRITICAL - Be Exhaustive):
-
-  **Pattern References** (existing code to follow):
-  - `agents/agents.json:11-24` - Current Chiron read permissions with secret blocking patterns
-  - `agents/agents.json:114-132` - Athena permission object (read-only subagent reference pattern)
-
-  **API/Type References** (contracts to implement against):
-  - OpenCode task permission schema: `{"task": {"agent-name": "allow"}}`
-
-  **Documentation References** (specs and requirements):
-  - Interview draft: `.sisyphus/drafts/agent-permissions-refinement.md` - Chiron permission decisions
-  - Metis analysis: Guardrails #7, #8 - Secret blocking patterns, task permission implementation
-
-  **External References** (libraries and frameworks):
-  - OpenCode docs: https://opencode.ai/docs/agents/#task-permissions - Task permission documentation
-  - OpenCode docs: https://opencode.ai/docs/permissions/ - Permission level definitions and pattern matching
-
-  **WHY Each Reference Matters** (explain the relevance):
-  - `agents/agents.json:11-24` - Shows current secret blocking patterns to extend
-  - `agents/agents.json:114-132` - Shows read-only subagent pattern for reference (athena: deny bash, deny edit)
-  - Interview draft - Contains exact user requirements for Chiron permissions
-  - OpenCode task docs - Explains how to restrict subagent invocation via task permission
-
-  **Acceptance Criteria**:
-
-  > **CRITICAL: AGENT-EXECUTABLE VERIFICATION ONLY**
-
-  **Automated Verification (config validation)**:
-  \`\`\`bash
-  # Agent runs:
-  jq '.chiron.permission.edit' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron.permission.bash."*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron.permission.bash."bd *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "allow"
-
-  jq '.chiron.permission.task."*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron.permission.task | keys' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Contains ["*", "athena", "chiron-forge", "explore", "librarian"]
-
-  jq '.chiron.permission.external_directory."~/p/**"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "allow"
-
-  jq '.chiron.permission.external_directory."*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "ask"
-
-  jq '.chiron.permission.read."/run/agenix/*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-  \`\`\`
-
-  **Evidence to Capture**:
-  - [x] Edit permission value (should be "deny")
-  - [x] Bash wildcard permission (should be "deny")
-  - [x] Bash bd permission (should be "allow")
-  - [x] Task wildcard permission (should be "deny")
-  - [x] Task allowlist keys (should show 5 entries)
-  - [x] External directory ~/p/** permission (should be "allow")
-  - [x] External directory wildcard permission (should be "ask")
-  - [x] Read /run/agenix/* permission (should be "deny")
-
-  **Commit**: NO (group with Task 3)
-
-- [x] 3. Apply Chriton-Forge Permission Updates
-
-  **What to do**:
-  - Split `git *: "ask"` into granular rules:
-    - Allow: `git add *`, `git commit *`, read-only commands (status, log, diff, branch, show, stash, remote)
-    - Ask: `git push *`
-    - Deny: `git config *`
-  - Change package managers from `"ask"` to granular rules:
-    - Ask for installs: `npm install *`, `npm i *`, `npx *`, `pip install *`, `pip3 install *`, `uv *`, `bun install *`, `bun i *`, `bunx *`, `yarn install *`, `yarn add *`, `pnpm install *`, `pnpm add *`, `cargo install *`, `go install *`, `make install`
-    - Allow other commands implicitly (let them use catch-all rules or existing allow patterns)
-  - Set `external_directory` to allow `~/p/**` with catch-all ask:
-    ```json
-    "external_directory": {
-      "~/p/**": "allow",
-      "*": "ask"
-    }
-    ```
-  - Add bash file write protection patterns (apply to both agents):
-    ```json
-    "bash": {
-      "echo * > *": "deny",
-      "cat * > *": "deny",
-      "printf * > *": "deny",
-      "tee": "deny",
-      "*>*": "deny",
-      ">*>*": "deny"
-    }
-    ```
-  - Add bash command injection prevention (apply to both agents):
-    ```json
-    "bash": {
-      "$(*": "deny",
-      "`*": "deny",
-      "eval *": "deny",
-      "source *": "deny"
-    }
-    ```
-  - Add git secret protection patterns (apply to both agents):
-    ```json
-    "bash": {
-      "git add *.env*": "deny",
-      "git commit *.env*": "deny",
-      "git add *credentials*": "deny",
-      "git add *secrets*": "deny"
-    }
-    ```
-  - Add expanded secret blocking patterns to read permission:
-    - `.local/share/*`, `.cache/*`, `*.db`, `*.keychain`, `*.p12`
-
-  **Must NOT do**:
-  - Remove existing bash deny rules for dangerous commands (dd, mkfs, fdisk, parted, eval, sudo, su, systemctl, etc.)
-  - Allow git config modifications
-  - Allow bash to write files via any method (must block all redirect patterns)
-  - Skip command injection prevention ($(), backticks, eval, source)
-
-  **Recommended Agent Profile**:
-  > **Category**: quick
-    - Reason: JSON configuration update, follows clear specifications from draft
-  > **Skills**: git-master
-    - git-master: Git workflow for committing changes
-  > **Skills Evaluated but Omitted**:
-    - research: Not needed (all requirements documented in draft)
-    - librarian: Not needed (no external docs needed)
-
-  **Parallelization**:
-  - **Can Run In Parallel**: YES
-  - **Parallel Group**: Wave 2 (with Task 2)
-  - **Blocks**: Task 4
-  - **Blocked By**: Task 1
-
-  **References** (CRITICAL - Be Exhaustive):
-
-  **Pattern References** (existing code to follow):
-  - `agents/agents.json:37-103` - Current Chriton-Forge bash permissions (many explicit allow/ask/deny rules)
-  - `agents/agents.json:37-50` - Current Chriton-Forge read permissions with secret blocking
-
-  **API/Type References** (contracts to implement against):
-  - OpenCode permission schema: Same as Task 2
-
-  **Documentation References** (specs and requirements):
-  - Interview draft: `.sisyphus/drafts/agent-permissions-refinement.md` - Chriton-Forge permission decisions
-  - Metis analysis: Guardrails #1-#6 - Bash edit bypass, git secret protection, command injection, git config protection
-
-  **External References** (libraries and frameworks):
-  - OpenCode docs: https://opencode.ai/docs/permissions/ - Permission pattern matching (wildcards, last-match-wins)
-
-  **WHY Each Reference Matters** (explain the relevance):
-  - `agents/agents.json:37-103` - Shows current bash permission structure (many explicit rules) to extend with new patterns
-  - `agents/agents.json:37-50` - Shows current secret blocking to extend with additional patterns
-  - Interview draft - Contains exact user requirements for Chriton-Forge permissions
-  - Metis analysis - Provides bash injection prevention patterns and git protection rules
-
-  **Acceptance Criteria**:
-
-  > **CRITICAL: AGENT-EXECUTABLE VERIFICATION ONLY**
-
-  **Automated Verification (config validation)**:
-  \`\`\`bash
-  # Agent runs:
-
-  # Verify git commit is allowed
-  jq '.chiron-forge.permission.bash."git commit *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "allow"
-
-  # Verify git push asks
-  jq '.chiron-forge.permission.bash."git push *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "ask"
-
-  # Verify git config is denied
-  jq '.chiron-forge.permission.bash."git config *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  # Verify npm install asks
-  jq '.chiron-forge.permission.bash."npm install *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "ask"
-
-  # Verify bash file write redirects are blocked
-  jq '.chiron-forge.permission.bash."echo * > *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.bash."cat * > *"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.bash."tee"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  # Verify command injection is blocked
-  jq '.chiron-forge.permission.bash."$(*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.bash."`*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  # Verify git secret protection
-  jq '.chiron-forge.permission.bash."git add *.env*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.bash."git commit *.env*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  # Verify external_directory scope
-  jq '.chiron-forge.permission.external_directory."~/p/**"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "allow"
-
-  jq '.chiron-forge.permission.external_directory."*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "ask"
-
-  # Verify expanded secret blocking
-  jq '.chiron-forge.permission.read.".local/share/*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.read.".cache/*"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-
-  jq '.chiron-forge.permission.read."*.db"' /home/m3tam3re/p/AI/AGENTS/agents/agents.json
-  # Assert: Output is "deny"
-  \`\`\`
-
-  **Evidence to Capture**:
-  - [x] Git commit permission (should be "allow")
-  - [x] Git push permission (should be "ask")
-  - [x] Git config permission (should be "deny")
-  - [x] npm install permission (should be "ask")
-  - [x] bash redirect echo > permission (should be "deny")
-  - [x] bash redirect cat > permission (should be "deny")
-  - [x] bash tee permission (should be "deny")
-  - [x] bash $() injection permission (should be "deny")
-  - [x] bash backtick injection permission (should be "deny")
-  - [x] git add *.env* permission (should be "deny")
-  - [x] git commit *.env* permission (should be "deny")
-  - [x] external_directory ~/p/** permission (should be "allow")
-  - [x] external_directory wildcard permission (should be "ask")
-  - [x] read .local/share/* permission (should be "deny")
-  - [x] read .cache/* permission (should be "deny")
-  - [x] read *.db permission (should be "deny")
-
-  **Commit**: YES (groups with Tasks 1, 2, 3)
-  - Message: `chore(agents): refine permissions for Chiron and Chriton-Forge with security hardening`
-  - Files: `agents/agents.json`
-  - Pre-commit: `jq '.' agents/agents.json > /dev/null 2>&1` (validate JSON)
-
-- [x] 4. Validate Configuration (Manual Verification)
-
-  **What to do**:
-  - Run JSON syntax validation: `jq '.' agents/agents.json`
-  - Verify no duplicate keys in configuration
-  - Verify workspace path exists: `ls -la ~/p/`
-  - Document manual verification procedure for post-deployment testing
-
-  **Must NOT do**:
-  - Skip workspace path validation
-  - Skip duplicate key verification
-  - Proceed to deployment without validation
-
-  **Recommended Agent Profile**:
-  > **Category**: quick
-    - Reason: Simple validation commands, documentation task
-  > **Skills**: git-master
-    - git-master: Git workflow for committing validation script or notes if needed
-  > **Skills Evaluated but Omitted**:
-    - research: Not needed (validation is straightforward)
-    - librarian: Not needed (no external docs needed)
-
-  **Parallelization**:
-  - **Can Run In Parallel**: NO
-  - **Parallel Group**: Sequential
-  - **Blocks**: None (final validation task)
-  - **Blocked By**: Tasks 2, 3
-
-  **References** (CRITICAL - Be Exhaustive):
-
-  **Pattern References** (existing code to follow):
-  - `AGENTS.md` - Repository documentation structure
-
-  **API/Type References** (contracts to implement against):
-  - N/A (validation task)
-
-  **Documentation References** (specs and requirements):
-  - Interview draft: `.sisyphus/drafts/agent-permissions-refinement.md` - All user requirements
-  - Metis analysis: Guardrails #1-#6 - Validation requirements
-
-  **External References** (libraries and frameworks):
-  - N/A (validation task)
-
-  **WHY Each Reference Matters** (explain the relevance):
-  - Interview draft - Contains all requirements to validate against
-  - Metis analysis - Identifies specific validation steps (duplicate keys, workspace path, etc.)
-
-  **Acceptance Criteria**:
-
-  > **CRITICAL: AGENT-EXECUTABLE VERIFICATION ONLY**
-
-  **Automated Verification (config validation)**:
-  \`\`\`bash
-  # Agent runs:
-
-  # JSON syntax validation
-  jq '.' /home/m3tam3re/p/AI/AGENTS/agents/agents.json > /dev/null 2>&1
-  # Assert: Exit code 0
-
-  # Verify no duplicate external_directory keys
-  cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron.permission | keys' | grep external_directory | wc -l
-  # Assert: Output is "1"
-
-  cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron-forge.permission | keys' | grep external_directory | wc -l
-  # Assert: Output is "1"
-
-  # Verify workspace path exists
-  ls -la ~/p/ 2>&1 | head -1
-  # Assert: Shows directory listing (not "No such file or directory")
-
-  # Verify all permission keys are valid
-  cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron.permission' > /dev/null 2>&1
-  # Assert: Exit code 0
-
-  cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron-forge.permission' > /dev/null 2>&1
-  # Assert: Exit code 0
-  \`\`\`
-
-  **Evidence to Capture**:
-  - [x] jq validation output (exit code 0)
-  - [x] Chiron external_directory key count (should be "1")
-  - [x] Chriton-Forge external_directory key count (should be "1")
-  - [x] Workspace path ls output (shows directory exists)
-  - [x] Chiron permission object validation (exit code 0)
-  - [x] Chriton-Forge permission object validation (exit code 0)
-
-  **Commit**: NO (validation only, no changes)
-
----
-
-## Commit Strategy
-
-| After Task | Message | Files | Verification |
-|------------|---------|-------|--------------|
-| 1, 2, 3 | `chore(agents): refine permissions for Chiron and Chriton-Forge with security hardening` | agents/agents.json | `jq '.' agents/agents.json > /dev/null` |
-| 4 | N/A (validation only) | N/A | N/A |
-
----
-
-## Success Criteria
-
-### Verification Commands
-```bash
-# Pre-deployment validation
-jq '.' /home/m3tam3re/p/AI/AGENTS/agents/agents.json > /dev/null 2>&1
-# Expected: Exit code 0
-
-# Duplicate key check
-cat /home/m3tam3re/p/AI/AGENTS/agents/agents.json | jq '.chiron.permission | keys' | grep external_directory | wc -l
-# Expected: 1
-
-# Workspace path validation
-ls -la ~/p/ 2>&1
-# Expected: Directory listing
-
-# Post-deployment (manual)
-# Have Chiron attempt file edit → Expected: Permission denied
-# Have Chiron run bd ready → Expected: Success
-# Have Chriton-Forge git commit → Expected: Success
-# Have Chriton-Forge git push → Expected: Ask user
-# Have agent read .env → Expected: Permission denied
-```
-
-### Final Checklist
-- [x] Duplicate `external_directory` key fixed
-- [x] Chiron edit set to "deny"
-- [x] Chiron bash denied except `bd *`
-- [x] Chiron task permission restricts subagents (explore, librarian, athena, chiron-forge)
-- [x] Chiron external_directory allows ~/p/** only
-- [x] Chriton-Forge git commit allowed, git push asks
-- [x] Chriton-Forge git config denied
-- [x] Chriton-Forge package install commands ask
-- [x] Chriton-Forge external_directory allows ~/p/**, asks others
-- [x] Bash file write operators blocked (echo >, cat >, tee, etc.)
-- [x] Bash command injection blocked ($(), backticks, eval, source)
-- [x] Git secret protection added (git add/commit *.env* deny)
-- [x] Expanded secret blocking patterns added (.local/share/*, .cache/*, *.db, *.keychain, *.p12)
-- [x] /run/agenix/* blocked in read permissions
-- [x] JSON syntax valid (jq validates)
-- [x] No duplicate keys in configuration
-- [x] Workspace path ~/p/** exists

AGENTS.md

@@ -12,26 +12,27 @@ Configuration repository for Opencode Agent Skills, context files, and agent con
 
 # Skill creation
 python3 skills/skill-creator/scripts/init_skill.py <name> --path skills/
-
-# Issue tracking (beads)
-bd ready && bd create "title" && bd close <id> && bd sync
 ```
 
 ## Directory Structure
 
 ```
 .
-├── skills/          # Agent skills (25 modules)
+├── skills/          # Agent skills (15 modules)
 │   └── skill-name/
 │       ├── SKILL.md         # Required: YAML frontmatter + workflows
 │       ├── scripts/         # Executable code (optional)
 │       ├── references/      # Domain docs (optional)
-│       └── assets/         # Templates/files (optional)
+│       └── assets/          # Templates/files (optional)
+├── rules/           # AI coding rules (languages, concerns, frameworks)
+│   ├── languages/   # Python, TypeScript, Nix, Shell
+│   ├── concerns/    # Testing, naming, documentation, etc.
+│   └── frameworks/  # Framework-specific rules (n8n, etc.)
 ├── agents/          # Agent definitions (agents.json)
 ├── prompts/         # System prompts (chiron*.txt)
 ├── context/         # User profiles
 ├── commands/        # Custom commands
-└── scripts/         # Repo utilities (test-skill.sh)
+└── scripts/         # Repo utilities (test-skill.sh, validate-agents.sh)
 ```
 
 ## Code Conventions
@@ -58,7 +59,7 @@ compatibility: opencode
 ## Anti-Patterns (CRITICAL)
 
 **Frontend Design**: NEVER use generic AI aesthetics, NEVER converge on common choices
-**Excalidraw**: NEVER use diamond shapes (broken arrows), NEVER use `label` property
+**Excalidraw**: NEVER use `label` property (use boundElements + text element pairs instead)
 **Debugging**: NEVER fix just symptom, ALWAYS find root cause first
 **Excel**: ALWAYS respect existing template conventions over guidelines
 **Structure**: NEVER place scripts/docs outside scripts/references/ directories
@@ -77,27 +78,46 @@ compatibility: opencode
 
 ## Deployment
 
-**Nix pattern** (non-flake input):
+**Nix flake pattern**:
 ```nix
 agents = {
   url = "git+https://code.m3ta.dev/m3tam3re/AGENTS";
-  flake = false;  # Files only, not a Nix flake
+  inputs.nixpkgs.follows = "nixpkgs";  # Optional but recommended
 };
 ```
 
+**Exports:**
+- `packages.skills-runtime` — composable runtime with all skill dependencies
+- `devShells.default` — dev environment for working on skills
+
 **Mapping** (via home-manager):
 - `skills/`, `context/`, `commands/`, `prompts/` → symlinks
 - `agents/agents.json` → embedded into config.json
 - Agent changes: require `home-manager switch`
 - Other changes: visible immediately
 
+## Rules System
+
+Centralized AI coding rules consumed via `mkOpencodeRules` from m3ta-nixpkgs:
+
+```nix
+# In project flake.nix
+m3taLib.opencode-rules.mkOpencodeRules {
+  inherit agents;
+  languages = [ "python" "typescript" ];
+  frameworks = [ "n8n" ];
+};
+```
+
+See `rules/USAGE.md` for full documentation.
+
 ## Notes for AI Agents
 
 1. **Config-only repo** - No compilation, no build, manual validation only
 2. **Skills are documentation** - Write for AI consumption, progressive disclosure
 3. **Consistent structure** - All skills follow 4-level deep pattern (skills/name/ + optional subdirs)
 4. **Cross-cutting concerns** - Standardized SKILL.md, workflow patterns, delegation rules
-5. **Always push** - Session completion workflow: commit + bd sync + git push
+5. **Always push** - Session completion workflow: commit + git push
 
 ## Quality Gates
 
@@ -105,4 +125,5 @@ Before committing:
 1. `./scripts/test-skill.sh --validate`
 2. Python shebang + docstrings check
 3. No extraneous files (README.md, CHANGELOG.md in skills/)
-4. Git status clean
+4. If skill has scripts with external dependencies → verify `flake.nix` is updated (see skill-creator Step 4)
+5. Git status clean

CHIRON-IMPLEMENTATION-SUMMARY.md

@@ -1,338 +0,0 @@
-# Chiron Skills Implementation Summary
-
-**Date:** 2026-01-27
-**Status:** ✅ ALL SKILLS COMPLETE
-
-## What Was Created
-
-### New Skills (7)
-
-| Skill | Purpose | Status |
-|-------|---------|--------|
-| **chiron-core** | PARA methodology, mentor persona, prioritization | ✅ Created & Validated |
-| **obsidian-management** | Vault operations, file management, templates | ✅ Created & Validated |
-| **daily-routines** | Morning planning, evening reflection, weekly review | ✅ Created & Validated |
-| **meeting-notes** | Meeting capture, action item extraction | ✅ Created & Validated |
-| **quick-capture** | Inbox capture, minimal friction | ✅ Created & Validated |
-| **project-structures** | PARA project lifecycle management | ✅ Created & Validated |
-| **n8n-automation** | n8n workflow design and configuration | ✅ Created & Validated |
-
-### Updated Skills (1)
-
-| Skill | Changes | Status |
-|-------|---------|--------|
-| **task-management** | Updated to use Obsidian Tasks format instead of Anytype | ✅ Updated & Validated |
-
-### Opencode Commands (8)
-
-| Command | Purpose | Location |
-|---------|---------|----------|
-| `/chiron-start` | Morning planning ritual | `commands/chiron-start.md` |
-| `/chiron-end` | Evening reflection ritual | `commands/chiron-end.md` |
-| `/chiron-review` | Weekly review workflow | `commands/chiron-review.md` |
-| `/chiron-capture` | Quick capture to inbox | `commands/chiron-capture.md` |
-| `/chiron-task` | Add task with smart defaults | `commands/chiron-task.md` |
-| `/chiron-search` | Search knowledge base | `commands/chiron-search.md` |
-| `/chiron-project` | Create new project | `commands/chiron-project.md` |
-| `/chiron-meeting` | Meeting notes | `commands/chiron-meeting.md` |
-| `/chiron-learn` | Capture learning | `commands/chiron-learn.md` |
-
-### Updated Configurations (2)
-
-| File | Changes |
-|------|---------|
-| `agents/agents.json` | Already had chiron agents configured |
-| `prompts/chiron.txt` | Updated skill routing table, added Obsidian integration |
-
-## Key Architectural Decisions
-
-### 1. Obsidian-First Design
-
-**Decision:** Use Obsidian Tasks plugin format instead of Anytype knowledge graphs
-
-**Reasoning:**
-- Chiron documentation explicitly chose Obsidian over Anytype
-- Obsidian provides direct file access for Opencode (no MCP overhead)
-- Markdown files are Git-friendly and portable
-
-**Impact:**
-- `task-management` skill completely rewritten for Obsidian Tasks format
-- All Chiron skills work with Markdown files at `~/CODEX/`
-- Task format: `- [ ] Task #tag ⏫ 📅 YYYY-MM-DD`
-
-### 2. Skill Boundary Design
-
-**Decision:** Create 7 focused Chiron skills with clear responsibilities
-
-**Skill Mapping:**
-
-| Skill | Core Responsibility | Delegates To |
-|-------|-------------------|--------------|
-| `chiron-core` | PARA methodology, mentorship, prioritization | All other Chiron skills |
-| `obsidian-management` | File operations, templates, search | All skills |
-| `daily-routines` | Morning/Evening/Weekly workflows | task-management, obsidian-management |
-| `quick-capture` | Inbox capture (tasks, notes, meetings, learnings) | obsidian-management, task-management |
-| `meeting-notes` | Meeting note creation, action extraction | task-management, obsidian-management |
-| `project-structures` | Project lifecycle (create, review, archive) | obsidian-management, chiron-core |
-| `n8n-automation` | n8n workflow design, webhook setup | All skills (automation triggers) |
-
-### 3. Preserved Existing Investments
-
-**Kept unchanged:**
-- `basecamp` - MCP-based integration
-- `communications` - Email management
-- `calendar-scheduling` - Time blocking (stub)
-- `research` - Investigation workflows
-- `brainstorming` - Ideation
-- `reflection` - Conversation analysis
-- `mem0-memory` - Persistent memory
-
-**Reasoning:** These skills complement Chiron rather than conflict with it.
-
-### 4. Progressive Disclosure Implementation
-
-**Design principle:** Keep SKILL.md lean, move details to references/
-
-**Examples:**
-- `chiron-core/SKILL.md` (~300 lines) - Core workflows only
-- `chiron-core/references/` (~900 lines) - PARA guide, priority matrix, reflection questions
-- `daily-routines/SKILL.md` (~400 lines) - Workflows only
-- References loaded only when needed
-
-### 5. Prompt Engineering Patterns Applied
-
-**Techniques used:**
-
-1. **Few-Shot Learning** - Concrete examples for each workflow
-2. **Instruction Hierarchy** - System → Workflow → Steps → Examples
-3. **Error Recovery** - Handle edge cases (file not found, duplicate tasks)
-4. **Output Format Specifications** - Explicit markdown structures for consistency
-5. **Delegation Rules** - Clear boundaries for skill-to-skill routing
-
-## Integration Points
-
-### Skill Routing in chiron.txt
-
-Updated to route to new skills:
-
-```
-| Intent Pattern | Skill | Examples |
-|----------------|-------|----------|
-| PARA methodology, prioritization principles, productivity guidance | `chiron-core` | "How should I organize X?", "Is this a project or area?" |
-| Tasks (Obsidian Tasks format), search tasks, prioritize work | `task-management` | "Find all tasks", "Add task: X" |
-| Obsidian file operations, create/edit notes, use templates | `obsidian-management` | "Create note: X", "Use meeting template" |
-| Daily workflows: morning planning, evening reflection, weekly review | `daily-routines` | "Morning planning", "Evening review", "Weekly review" |
-| Quick capture to inbox, minimal friction capture | `quick-capture` | "Capture: X", "Quick note: Y" |
-| Meeting notes, action items, meeting capture | `meeting-notes` | "Meeting: X", "Process meeting notes" |
-| Project creation, lifecycle management, PARA projects | `project-structures` | "Create project: X", "Project status" |
-| n8n automation, workflow design, cron setup | `n8n-automation` | "Setup n8n workflow", "Configure webhook" |
-```
-
-### Command Integration
-
-Each Opencode command (`/chiron-*`) is a lightweight wrapper that:
-1. Defines workflow purpose
-2. References primary skill responsible
-3. Specifies expected output format
-4. Lists related skills for delegation
-
-**Example flow:**
-```
-User: /chiron-start
-→ Command triggers daily-routines skill
-→ daily-routines calls obsidian-management for file operations
-→ daily-routines calls task-management for task extraction
-→ Result: Morning briefing in daily note
-```
-
-## File Structure
-
-```
-skills/
-├── chiron-core/
-│   ├── SKILL.md                     # Main PARA guidance
-│   └── references/
-│       ├── para-guide.md             # Detailed PARA methodology
-│       ├── priority-matrix.md         # Eisenhower matrix
-│       └── reflection-questions.md    # Weekly/monthly questions
-│
-├── obsidian-management/
-│   └── SKILL.md                     # Vault operations
-│
-├── daily-routines/
-│   └── SKILL.md                     # Morning/Evening/Weekly workflows
-│
-├── quick-capture/
-│   └── SKILL.md                     # Inbox capture workflows
-│
-├── meeting-notes/
-│   └── SKILL.md                     # Meeting note templates
-│
-├── project-structures/
-│   └── SKILL.md                     # Project lifecycle management
-│
-├── task-management/
-│   └── SKILL.md                     # Updated for Obsidian Tasks format
-│
-└── n8n-automation/
-    └── SKILL.md                     # n8n workflow design
-
-commands/
-├── chiron-start.md                  # Morning planning
-├── chiron-end.md                    # Evening reflection
-├── chiron-review.md                  # Weekly review
-├── chiron-capture.md                 # Quick capture
-├── chiron-task.md                   # Add task
-├── chiron-search.md                  # Search vault
-├── chiron-project.md                 # Create project
-├── chiron-meeting.md                 # Meeting notes
-└── chiron-learn.md                   # Capture learning
-
-prompts/
-└── chiron.txt                       # Updated with skill routing
-
-agents/
-└── agents.json                       # Chiron agents (already configured)
-```
-
-## Testing Checklist
-
-Before deploying, validate:
-
-- [x] Run `./scripts/test-skill.sh --validate` on all new skills
-- [ ] Test commands in Opencode session
-- [ ] Verify skill routing from chiron.txt works correctly
-- [ ] Verify Obsidian Tasks format works with Obsidian Tasks plugin
-- [ ] Test daily note creation with templates
-- [ ] Verify search functionality across vault
-
-## Next Steps
-
-### Immediate (Before First Use)
-
-1. **Create Obsidian vault structure** at `~/CODEX/`:
-   ```bash
-   mkdir -p ~/CODEX/{_chiron/{templates,queries,scripts,logs},00-inbox/{meetings,web-clips,learnings},01-projects/{work,personal},02-areas/{work,personal},03-resources,daily/{weekly-reviews},tasks/by-context,04-archive/{projects,areas,resources}}
-   ```
-
-2. **Copy templates** to `_chiron/templates/`:
-   - Daily note template
-   - Weekly review template
-   - Project template
-   - Meeting template
-   - Resource template
-   - Area template
-   - Learning template
-
-3. **Configure Obsidian**:
-   - Install Tasks plugin
-   - Configure task format: `- [ ] Task #tag ⏫ 📅 YYYY-MM-DD`
-   - Set vault path: `~/CODEX`
-   - Test frontmatter and wiki-links
-
-4. **Setup n8n** (if using):
-   - Deploy n8n instance
-   - Import workflows
-   - Configure API integrations (Basecamp, Proton Calendar)
-   - Setup webhooks
-   - Configure Cron triggers
-   - Test all workflows
-
-5. **Configure ntfy**:
-   - Create topic for Chiron notifications
-   - Test notification delivery
-
-### First Week Testing
-
-1. Test morning planning: `/chiron-start`
-2. Test quick capture: `/chiron-capture`
-3. Test meeting notes: `/chiron-meeting`
-4. Test evening reflection: `/chiron-end`
-5. Test task search: `/chiron-search`
-6. Test project creation: `/chiron-project`
-7. Test weekly review: `/chiron-review`
-
-### Ongoing Enhancements
-
-These items are optional and can be added incrementally:
-
-1. **n8n automation** - Complete workflow implementation (already designed)
-2. **Calendar integration** - Update `calendar-scheduling` stub for full Proton Calendar integration
-3. **Basecamp sync automation** - Full integration via n8n workflows (already designed)
-4. **Template library** - Create comprehensive template assets
-5. **Dataview queries** - Create reusable query patterns
-6. **Script automation** - Python scripts for complex operations
-7. **Mem0 integration** - Store learnings and patterns for long-term recall
-
-## Deployment
-
-### Nix Flakes
-
-Since this repository deploys via Nix flake + home-manager:
-
-1. Skills automatically symlinked to `~/.config/opencode/skill/`
-2. Commands automatically symlinked to `~/.config/opencode/command/`
-3. Agents configured in `agents.json` (embedded in opencode config.json)
-
-### Deploy Command
-
-```bash
-# After committing changes
-git add .
-git commit -m "Add Chiron productivity skills for Opencode"
-
-# Deploy via Nix
-home-manager switch
-
-# Test in Opencode
-opencode  # Chiron skills should be available
-```
-
-## Documentation
-
-### Skills to Study
-
-For understanding how Chiron skills work, study:
-
-1. **chiron-core** - Foundation of PARA methodology and prioritization
-2. **daily-routines** - Daily/weekly workflow orchestration
-3. **obsidian-management** - File operations and template system
-4. **quick-capture** - Minimal friction capture patterns
-5. **project-structures** - Project lifecycle management
-6. **task-management** - Obsidian Tasks format and task operations
-7. **n8n-automation** - n8n workflow design for automation
-
-### Commands to Test
-
-All 9 Chiron commands are now available:
-
-| Command | Primary Skill | Secondary Skills |
-|---------|---------------|------------------|
-| `/chiron-start` | daily-routines | obsidian-management, task-management, calendar-scheduling |
-| `/chiron-end` | daily-routines | task-management, reflection, obsidian-management |
-| `/chiron-review` | daily-routines | task-management, project-structures, quick-capture, chiron-core |
-| `/chiron-capture` | quick-capture | obsidian-management, task-management |
-| `/chiron-task` | quick-capture | task-management, obsidian-management |
-| `/chiron-search` | obsidian-management | research |
-| `/chiron-project` | project-structures | obsidian-management, chiron-core |
-| `/chiron-meeting` | meeting-notes | task-management, obsidian-management |
-| `/chiron-learn` | quick-capture | obsidian-management, chiron-core |
-
-## Success Criteria
-
-Chiron skills are ready when:
-
-- [x] All 7 new skills created and validated
-- [x] Task management skill updated for Obsidian
-- [x] All 9 Opencode commands defined
-- [x] Chiron prompt updated with new skill routing
-- [x] Example files removed from all skills
-- [x] All skills pass validation
-- [x] Architecture document created
-- [x] Implementation summary created
-
-**Status: ✅ COMPLETE AND READY FOR DEPLOYMENT**
-
----
-
-*This summary completes the Chiron skills implementation for Opencode. All skills have been validated and are ready for deployment via Nix flake + home-manager.*

README.md

@@ -1,6 +1,6 @@
 # Opencode Agent Skills & Configurations
 
-Central repository for [Opencode](https://opencode.dev) Agent Skills, AI agent configurations, custom commands, and AI-assisted workflows. This is an extensible framework for building productivity systems, automations, knowledge management, and specialized AI capabilities.
+Central repository for [Opencode](https://opencode.ai) Agent Skills, AI agent configurations, custom commands, and AI-assisted workflows. This is an extensible framework for building productivity systems, automations, knowledge management, and specialized AI capabilities.
 
 ## 🎯 What This Repository Provides
 
@@ -8,36 +8,45 @@ This repository serves as a **personal AI operating system** - a collection of s
 
 - **Productivity & Task Management** - PARA methodology, GTD workflows, project tracking
 - **Knowledge Management** - Note-taking, research workflows, information organization
-- **Communications** - Email management, meeting scheduling, follow-up tracking
 - **AI Development** - Tools for creating new skills and agent configurations
 - **Memory & Context** - Persistent memory systems, conversation analysis
+- **Document Processing** - PDF manipulation, spreadsheet handling, diagram generation
 - **Custom Workflows** - Domain-specific automation and specialized agents
 
 ## 📂 Repository Structure
 
 ```
 .
-├── agent/           # Agent definitions (agents.json)
-├── prompts/         # Agent system prompts (chiron.txt, chiron-forge.txt)
+├── agents/          # Agent definitions (agents.json)
+├── prompts/         # Agent system prompts (chiron.txt, chiron-forge.txt, etc.)
 ├── context/         # User profiles and preferences
 │   └── profile.md   # Work style, PARA areas, preferences
-├── command/         # Custom command definitions
+├── commands/        # Custom command definitions
 │   └── reflection.md
-├── skill/           # Opencode Agent Skills (11+ skills)
-│   ├── task-management/      # PARA-based productivity
-│   ├── skill-creator/        # Meta-skill for creating skills
-│   ├── reflection/           # Conversation analysis
-│   ├── communications/       # Email & messaging
-│   ├── calendar-scheduling/  # Time management
-│   ├── mem0-memory/          # Persistent memory
-│   ├── research/             # Investigation workflows
-│   ├── knowledge-management/ # Note capture & organization
+├── skills/          # Opencode Agent Skills (15 skills)
+│   ├── agent-development/    # Agent creation and configuration
 │   ├── basecamp/             # Basecamp project management
 │   ├── brainstorming/        # Ideation & strategic thinking
-│   └── plan-writing/         # Project planning templates
+│   ├── doc-translator/       # Documentation translation
+│   ├── excalidraw/           # Architecture diagrams
+│   ├── frontend-design/      # UI/UX design patterns
+│   ├── memory/               # Persistent memory system
+│   ├── obsidian/             # Obsidian vault management
+│   ├── outline/              # Outline wiki integration
+│   ├── pdf/                  # PDF manipulation toolkit
+│   ├── prompt-engineering-patterns/   # Prompt patterns
+│   ├── reflection/           # Conversation analysis
+│   ├── skill-creator/        # Meta-skill for creating skills
+│   ├── systematic-debugging/ # Debugging methodology
+│   └── xlsx/                 # Spreadsheet handling
 ├── scripts/         # Repository utility scripts
 │   └── test-skill.sh # Test skills without deploying
-├── .beads/          # Issue tracking database
+├── rules/           # AI coding rules
+│   ├── languages/   # Python, TypeScript, Nix, Shell
+│   ├── concerns/    # Testing, naming, documentation
+│   └── frameworks/  # Framework-specific rules (n8n)
+├── flake.nix        # Nix flake: dev shell + skills-runtime export
+├── .envrc           # direnv config (use flake)
 ├── AGENTS.md        # Developer documentation
 └── README.md        # This file
 ```
@@ -46,43 +55,96 @@ This repository serves as a **personal AI operating system** - a collection of s
 
 ### Prerequisites
 
-- **Opencode** - AI coding assistant ([opencode.dev](https://opencode.dev))
-- **Nix** (optional) - For declarative deployment via home-manager
-- **Python 3** - For skill validation and creation scripts
-- **bd (beads)** (optional) - For issue tracking
+- **Nix** with flakes enabled — for reproducible dependency management and deployment
+- **direnv** (recommended) — auto-activates the development environment when entering the repo
+- **Opencode** — AI coding assistant ([opencode.ai](https://opencode.ai))
 
 ### Installation
 
 #### Option 1: Nix Flake (Recommended)
 
-This repository is consumed as a **non-flake input** by your NixOS configuration:
+This repository is a **Nix flake** that exports:
+
+- **`devShells.default`** — development environment for working on skills (activated via direnv)
+- **`packages.skills-runtime`** — composable runtime with all skill script dependencies (Python packages + system tools)
+
+**Consume in your system flake:**
 
 ```nix
-# In your flake.nix
+# flake.nix
 inputs.agents = {
   url = "git+https://code.m3ta.dev/m3tam3re/AGENTS";
-  flake = false;  # Pure files, not a Nix flake
+  inputs.nixpkgs.follows = "nixpkgs";
 };
 
 # In your home-manager module (e.g., opencode.nix)
 xdg.configFile = {
-  "opencode/skill".source = "${inputs.agents}/skill";
+  "opencode/skills".source = "${inputs.agents}/skills";
   "opencode/context".source = "${inputs.agents}/context";
-  "opencode/command".source = "${inputs.agents}/command";
+  "opencode/commands".source = "${inputs.agents}/commands";
   "opencode/prompts".source = "${inputs.agents}/prompts";
 };
 
 # Agent config is embedded into config.json, not deployed as files
-programs.opencode.settings.agent = builtins.fromJSON 
-  (builtins.readFile "${inputs.agents}/agent/agents.json");
+programs.opencode.settings.agent = builtins.fromJSON
+  (builtins.readFile "${inputs.agents}/agents/agents.json");
 ```
 
-Rebuild your system:
+**Deploy skills via home-manager:**
+
+```nix
+# home-manager module (e.g., opencode.nix)
+{ inputs, system, ... }:
+{
+  # Skill files — symlinked, changes visible immediately
+  xdg.configFile = {
+    "opencode/skills".source = "${inputs.agents}/skills";
+    "opencode/context".source = "${inputs.agents}/context";
+    "opencode/commands".source = "${inputs.agents}/commands";
+    "opencode/prompts".source = "${inputs.agents}/prompts";
+  };
+
+  # Agent config — embedded into config.json (requires home-manager switch)
+  programs.opencode.settings.agent = builtins.fromJSON
+    (builtins.readFile "${inputs.agents}/agents/agents.json");
+
+  # Skills runtime — ensures opencode always has script dependencies
+  home.packages = [ inputs.agents.packages.${system}.skills-runtime ];
+}
+```
+
+**Compose into project flakes** (so opencode has skill deps in any project):
+
+```nix
+# Any project's flake.nix
+{
+  inputs.agents.url = "git+https://code.m3ta.dev/m3tam3re/AGENTS";
+  inputs.agents.inputs.nixpkgs.follows = "nixpkgs";
+
+  outputs = { self, nixpkgs, agents, ... }:
+    let
+      system = "x86_64-linux";
+      pkgs = nixpkgs.legacyPackages.${system};
+    in {
+      devShells.${system}.default = pkgs.mkShell {
+        packages = [
+          # project-specific tools
+          pkgs.nodejs
+          # skill script dependencies
+          agents.packages.${system}.skills-runtime
+        ];
+      };
+    };
+}
+```
+
+Rebuild:
+
 ```bash
 home-manager switch
 ```
 
-**Note**: The `agent/` directory is NOT deployed as files. Instead, `agents.json` is read at Nix evaluation time and embedded into the opencode `config.json`.
+**Note**: The `agents/` directory is NOT deployed as files. Instead, `agents.json` is read at Nix evaluation time and embedded into the opencode `config.json`.
 
 #### Option 2: Manual Installation
 
@@ -92,8 +154,11 @@ Clone and symlink:
 # Clone repository
 git clone https://github.com/yourusername/AGENTS.git ~/AGENTS
 
-# Create symlink to Opencode config directory
-ln -s ~/AGENTS ~/.config/opencode
+# Create symlinks to Opencode config directory
+ln -s ~/AGENTS/skills ~/.config/opencode/skills
+ln -s ~/AGENTS/context ~/.config/opencode/context
+ln -s ~/AGENTS/commands ~/.config/opencode/commands
+ln -s ~/AGENTS/prompts ~/.config/opencode/prompts
 ```
 
 ### Verify Installation
@@ -101,8 +166,8 @@ ln -s ~/AGENTS ~/.config/opencode
 Check that Opencode can see your skills:
 
 ```bash
-# Skills should be available at ~/.config/opencode/skill/
-ls ~/.config/opencode/skill/
+# Skills should be available at ~/.config/opencode/skills/
+ls ~/.config/opencode/skills/
 ```
 
 ## 🎨 Creating Your First Skill
@@ -112,18 +177,19 @@ Skills are modular packages that extend Opencode with specialized knowledge and
 ### 1. Initialize a New Skill
 
 ```bash
-python3 skill/skill-creator/scripts/init_skill.py my-skill-name --path skill/
+python3 skills/skill-creator/scripts/init_skill.py my-skill-name --path skills/
 ```
 
 This creates:
-- `skill/my-skill-name/SKILL.md` - Main skill documentation
-- `skill/my-skill-name/scripts/` - Executable code (optional)
-- `skill/my-skill-name/references/` - Reference documentation (optional)
-- `skill/my-skill-name/assets/` - Templates and files (optional)
+
+- `skills/my-skill-name/SKILL.md` - Main skill documentation
+- `skills/my-skill-name/scripts/` - Executable code (optional)
+- `skills/my-skill-name/references/` - Reference documentation (optional)
+- `skills/my-skill-name/assets/` - Templates and files (optional)
 
 ### 2. Edit the Skill
 
-Open `skill/my-skill-name/SKILL.md` and customize:
+Open `skills/my-skill-name/SKILL.md` and customize:
 
 ```yaml
 ---
@@ -131,7 +197,6 @@ name: my-skill-name
 description: What it does and when to use it. Include trigger keywords.
 compatibility: opencode
 ---
-
 # My Skill Name
 
 ## Overview
@@ -139,108 +204,111 @@ compatibility: opencode
 [Your skill instructions for Opencode]
 ```
 
-### 3. Validate the Skill
+### 3. Register Dependencies
 
-```bash
-python3 skill/skill-creator/scripts/quick_validate.py skill/my-skill-name
+If your skill includes scripts with external dependencies, add them to `flake.nix`:
+
+```nix
+# Python packages — add to pythonEnv:
+# my-skill: my_script.py
+some-python-package
+
+# System tools — add to skills-runtime paths:
+# my-skill: needed by my_script.py
+pkgs.some-tool
 ```
 
-### 4. Test the Skill
+Verify: `nix develop --command python3 -c "import some_package"`
 
-Test your skill without deploying via home-manager:
+### 4. Validate the Skill
+
+```bash
+python3 skills/skill-creator/scripts/quick_validate.py skills/my-skill-name
+```
+
+### 5. Test the Skill
 
 ```bash
-# Use the test script to validate and list skills
 ./scripts/test-skill.sh my-skill-name    # Validate specific skill
-./scripts/test-skill.sh --list           # List all dev skills
-./scripts/test-skill.sh --run            # Launch opencode with dev skills
+./scripts/test-skill.sh --run             # Launch opencode with dev skills
 ```
 
-The test script creates a temporary config directory with symlinks to this repo's skills, allowing you to test changes before committing.
-
 ## 📚 Available Skills
 
-| Skill | Purpose | Status |
-|-------|---------|--------|
-| **task-management** | PARA-based productivity with Obsidian Tasks integration | ✅ Active |
-| **skill-creator** | Guide for creating new Opencode skills | ✅ Active |
-| **reflection** | Conversation analysis and skill improvement | ✅ Active |
-| **communications** | Email drafts, follow-ups, message management | ✅ Active |
-| **calendar-scheduling** | Time blocking, meeting management | ✅ Active |
-| **mem0-memory** | Persistent memory storage and retrieval | ✅ Active |
-| **research** | Investigation workflows, source management | ✅ Active |
-| **knowledge-management** | Note capture, knowledge organization | ✅ Active |
-| **basecamp** | Basecamp project & todo management via MCP | ✅ Active |
-| **brainstorming** | General-purpose ideation with Obsidian save | ✅ Active |
-| **plan-writing** | Project plans with templates (kickoff, tasks, risks) | ✅ Active |
+| Skill                       | Purpose                                                        | Status       |
+| --------------------------- | -------------------------------------------------------------- | ------------ |
+| **agent-development**       | Create and configure Opencode agents                           | ✅ Active    |
+| **basecamp**                | Basecamp project & todo management via MCP                     | ✅ Active    |
+| **brainstorming**           | General-purpose ideation and strategic thinking                | ✅ Active    |
+| **doc-translator**          | Documentation translation to German/Czech with Outline publish | ✅ Active    |
+| **excalidraw**              | Architecture diagrams from codebase analysis                   | ✅ Active    |
+| **frontend-design**         | Production-grade UI/UX with high design quality                | ✅ Active    |
+| **memory**                  | SQLite-based persistent memory with hybrid search              | ✅ Active    |
+| **obsidian**                | Obsidian vault management via Local REST API                   | ✅ Active    |
+| **outline**                 | Outline wiki integration for team documentation                | ✅ Active    |
+| **pdf**                     | PDF manipulation, extraction, creation, and forms              | ✅ Active    |
+| **prompt-engineering-patterns** | Advanced prompt engineering techniques                     | ✅ Active    |
+| **reflection**              | Conversation analysis and skill improvement                    | ✅ Active    |
+| **skill-creator**           | Guide for creating new Opencode skills                         | ✅ Active    |
+| **systematic-debugging**    | Debugging methodology for bugs and test failures               | ✅ Active    |
+| **xlsx**                    | Spreadsheet creation, editing, and analysis                    | ✅ Active    |
 
 ## 🤖 AI Agents
 
-### Chiron - Personal Assistant
+### Primary Agents
 
-**Configuration**: `agent/agents.json` + `prompts/chiron.txt`
+| Agent               | Mode    | Purpose                                              |
+| ------------------- | ------- | ---------------------------------------------------- |
+| **Chiron**          | Plan    | Read-only analysis, planning, and guidance           |
+| **Chiron Forge**    | Build   | Full execution and task completion with safety       |
 
-Chiron is a personal AI assistant focused on productivity and task management. Named after the wise centaur from Greek mythology, Chiron provides:
+### Subagents (Specialists)
 
-- Task and project management guidance
-- Daily and weekly review workflows
-- Skill routing based on user intent
-- Integration with productivity tools (Obsidian, ntfy, n8n)
+| Agent               | Domain           | Purpose                                    |
+| ------------------- | ---------------- | ------------------------------------------ |
+| **Hermes**          | Communication    | Basecamp, Outlook, MS Teams                |
+| **Athena**          | Research         | Outline wiki, documentation, knowledge     |
+| **Apollo**          | Private Knowledge| Obsidian vault, personal notes             |
+| **Calliope**        | Writing          | Documentation, reports, prose              |
 
-**Modes**:
-- **Chiron** (Plan Mode) - Read-only analysis and planning (`prompts/chiron.txt`)
-- **Chiron-Forge** (Worker Mode) - Full write access with safety prompts (`prompts/chiron-forge.txt`)
+**Configuration**: `agents/agents.json` + `prompts/*.txt`
 
-**Triggers**: Personal productivity requests, task management, reviews, planning
+## 🛠️ Development
 
-## 🛠️ Development Workflow
+### Environment
 
-### Issue Tracking with Beads
-
-This project uses [beads](https://github.com/steveyegge/beads) for AI-native issue tracking:
+The repository includes a Nix flake with a development shell. With [direnv](https://direnv.net/) installed, the environment activates automatically:
 
 ```bash
-bd ready              # Find available work
-bd create "title"     # Create new issue
-bd update <id> --status in_progress
-bd close <id>         # Complete work
-bd sync               # Sync with git
+cd AGENTS/
+# → direnv: loading .envrc
+# → 🔧 AGENTS dev shell active — Python 3.13.x, jq-1.x
+
+# All skill script dependencies are now available:
+python3 -c "import pypdf, openpyxl, yaml"  # ✔️
+pdftoppm -v                                 # ✔️
 ```
 
+Without direnv, activate manually: `nix develop`
+
 ### Quality Gates
 
 Before committing:
 
-1. **Validate skills**: `./scripts/test-skill.sh --validate` or `python3 skill/skill-creator/scripts/quick_validate.py skill/<name>`
+1. **Validate skills**: `./scripts/test-skill.sh --validate` or `python3 skills/skill-creator/scripts/quick_validate.py skills/<name>`
 2. **Test locally**: `./scripts/test-skill.sh --run` to launch opencode with dev skills
 3. **Check formatting**: Ensure YAML frontmatter is valid
 4. **Update docs**: Keep README and AGENTS.md in sync
 
-### Session Completion
-
-When ending a work session:
-
-1. File beads issues for remaining work
-2. Run quality gates
-3. Update issue status
-4. **Push to remote** (mandatory):
-   ```bash
-   git pull --rebase
-   bd sync
-   git push
-   ```
-5. Verify changes are pushed
-
-See `AGENTS.md` for complete developer documentation.
-
 ## 🎓 Learning Resources
 
 ### Essential Documentation
 
 - **AGENTS.md** - Complete developer guide for AI agents
-- **skill/skill-creator/SKILL.md** - Comprehensive skill creation guide
-- **skill/skill-creator/references/workflows.md** - Workflow pattern library
-- **skill/skill-creator/references/output-patterns.md** - Output formatting patterns
+- **skills/skill-creator/SKILL.md** - Comprehensive skill creation guide
+- **skills/skill-creator/references/workflows.md** - Workflow pattern library
+- **skills/skill-creator/references/output-patterns.md** - Output formatting patterns
+- **rules/USAGE.md** - AI coding rules integration guide
 
 ### Skill Design Principles
 
@@ -251,27 +319,33 @@ See `AGENTS.md` for complete developer documentation.
 
 ### Example Skills to Study
 
-- **task-management/** - Full implementation with Obsidian Tasks integration
 - **skill-creator/** - Meta-skill with bundled resources
 - **reflection/** - Conversation analysis with rating system
 - **basecamp/** - MCP server integration with multiple tool categories
 - **brainstorming/** - Framework-based ideation with Obsidian markdown save
-- **plan-writing/** - Template-driven document generation
+- **memory/** - SQLite-based hybrid search implementation
+- **excalidraw/** - Diagram generation with JSON templates and Python renderer
 
 ## 🔧 Customization
 
 ### Modify Agent Behavior
 
-Edit `agent/agents.json` for agent definitions and `prompts/*.txt` for system prompts:
-- `agent/agents.json` - Agent names, models, permissions
+Edit `agents/agents.json` for agent definitions and `prompts/*.txt` for system prompts:
+
+- `agents/agents.json` - Agent names, models, permissions
 - `prompts/chiron.txt` - Chiron (Plan Mode) system prompt
-- `prompts/chiron-forge.txt` - Chiron-Forge (Worker Mode) system prompt
+- `prompts/chiron-forge.txt` - Chiron Forge (Build Mode) system prompt
+- `prompts/hermes.txt` - Hermes (Communication) system prompt
+- `prompts/athena.txt` - Athena (Research) system prompt
+- `prompts/apollo.txt` - Apollo (Private Knowledge) system prompt
+- `prompts/calliope.txt` - Calliope (Writing) system prompt
 
 **Note**: Agent changes require `home-manager switch` to take effect (config is embedded, not symlinked).
 
 ### Update User Context
 
 Edit `context/profile.md` to configure:
+
 - Work style preferences
 - PARA areas and projects
 - Communication preferences
@@ -279,13 +353,29 @@ Edit `context/profile.md` to configure:
 
 ### Add Custom Commands
 
-Create new command definitions in `command/` directory following the pattern in `command/reflection.md`.
+Create new command definitions in `commands/` directory following the pattern in `commands/reflection.md`.
+
+### Add Project Rules
+
+Use the rules system to inject AI coding rules into projects:
+
+```nix
+# In project flake.nix
+m3taLib.opencode-rules.mkOpencodeRules {
+  inherit agents;
+  languages = [ "python" "typescript" ];
+  frameworks = [ "n8n" ];
+};
+```
+
+See `rules/USAGE.md` for full documentation.
 
 ## 🌟 Use Cases
 
 ### Personal Productivity
 
 Use the PARA methodology with Obsidian Tasks integration:
+
 - Capture tasks and notes quickly
 - Run daily/weekly reviews
 - Prioritize work based on impact
@@ -294,6 +384,7 @@ Use the PARA methodology with Obsidian Tasks integration:
 ### Knowledge Management
 
 Build a personal knowledge base:
+
 - Capture research findings
 - Organize notes and references
 - Link related concepts
@@ -302,6 +393,7 @@ Build a personal knowledge base:
 ### AI-Assisted Development
 
 Extend Opencode for specialized domains:
+
 - Create company-specific skills (finance, legal, engineering)
 - Integrate with APIs and databases
 - Build custom automation workflows
@@ -310,6 +402,7 @@ Extend Opencode for specialized domains:
 ### Team Collaboration
 
 Share skills and agents across teams:
+
 - Document company processes as skills
 - Create shared knowledge bases
 - Standardize communication templates
@@ -331,15 +424,14 @@ This repository contains personal configurations and skills. Feel free to use th
 ## 🔗 Links
 
 - [Opencode](https://opencode.dev) - AI coding assistant
-- [Beads](https://github.com/steveyegge/beads) - AI-native issue tracking
 - [PARA Method](https://fortelabs.com/blog/para/) - Productivity methodology
 - [Obsidian](https://obsidian.md) - Knowledge management platform
 
 ## 🙋 Questions?
 
 - Check `AGENTS.md` for detailed developer documentation
-- Review existing skills in `skill/` for examples
-- See `skill/skill-creator/SKILL.md` for skill creation guide
+- Review existing skills in `skills/` for examples
+- See `skills/skill-creator/SKILL.md` for skill creation guide
 
 ---
 

agents/agents.json

@@ -1,200 +1,173 @@
 {
-  "chiron": {
+  "Chiron (Assistant)": {
     "description": "Personal AI assistant (Plan Mode). Read-only analysis, planning, and guidance.",
     "mode": "primary",
-    "model": "zai-coding-plan/glm-4.7",
+    "model": "zai-coding-plan/glm-5",
     "prompt": "{file:./prompts/chiron.txt}",
     "permission": {
-      "external_directory": {
-        "~/p/**": "allow",
-        "*": "ask"
-      },
-      "read": {
-        "*": "allow",
-        "*.env": "deny",
-        "*.env.*": "deny",
-        "*.env.example": "allow",
-        "*/.ssh/*": "deny",
-        "*/.gnupg/*": "deny",
-        "*credentials*": "deny",
-        "*secrets*": "deny",
-        "*.pem": "deny",
-        "*.key": "deny",
-        "*/.aws/*": "deny",
-        "*/.kube/*": "deny",
-        "/run/agenix/*": "deny",
-        ".local/share/*": "deny",
-        ".cache/*": "deny",
-        "*.db": "deny",
-        "*.keychain": "deny",
-        "*.p12": "deny"
-      },
+      "question": "allow",
+      "webfetch": "allow",
+      "websearch": "allow",
       "edit": "deny",
       "bash": {
-        "*": "deny",
-        "bd *": "allow",
-        "echo * > *": "deny",
-        "cat * > *": "deny",
-        "printf * > *": "deny",
-        "tee": "deny",
-        "*>*": "deny",
-        ">*>*": "deny",
-        "eval *": "deny",
-        "source *": "deny",
-        "$(*": "deny",
-        "`*": "deny",
-        "git add *.env*": "deny",
-        "git commit *.env*": "deny",
-        "git add *credentials*": "deny",
-        "git add *secrets*": "deny"
-      },
-      "task": {
-        "*": "deny",
-        "explore": "allow",
-        "librarian": "allow",
-        "athena": "allow",
-        "chiron-forge": "allow"
-      },
-      "doom_loop": "ask"
-    }
-  },
-  "chiron-forge": {
-    "description": "Personal AI assistant (Worker Mode). Full write access with safety prompts.",
-    "mode": "primary",
-    "model": "zai-coding-plan/glm-4.7",
-    "prompt": "{file:./prompts/chiron-forge.txt}",
-    "permission": {
-      "read": {
-        "*": "allow",
-        "*.env": "deny",
-        "*.env.*": "deny",
-        "*.env.example": "allow",
-        "*/.ssh/*": "deny",
-        "*/.gnupg/*": "deny",
-        "*credentials*": "deny",
-        "*secrets*": "deny",
-        "*.pem": "deny",
-        "*.key": "deny",
-        "*/.aws/*": "deny",
-        "*/.kube/*": "deny",
-        "/run/agenix/*": "deny",
-        ".local/share/*": "deny",
-        ".cache/*": "deny",
-        "*.db": "deny",
-        "*.keychain": "deny",
-        "*.p12": "deny"
-      },
-      "edit": "allow",
-      "bash": {
-        "*": "allow",
-        "rm *": "ask",
-        "rmdir *": "ask",
-        "mv *": "ask",
-        "chmod *": "ask",
-        "chown *": "ask",
+        "*": "ask",
         "git status*": "allow",
         "git log*": "allow",
         "git diff*": "allow",
         "git branch*": "allow",
         "git show*": "allow",
-        "git stash list*": "allow",
-        "git remote -v": "allow",
-        "git add *": "allow",
-        "git commit *": "allow",
-        "git push *": "ask",
-        "git config *": "deny",
-        "git add *.env*": "deny",
-        "git commit *.env*": "deny",
-        "git add *credentials*": "deny",
-        "git add *secrets*": "deny",
-        "jj *": "ask",
-        "jj status": "allow",
-        "jj log*": "allow",
-        "jj diff*": "allow",
-        "jj show*": "allow",
-        "npm install *": "ask",
-        "npm i *": "ask",
-        "npx *": "ask",
-        "bun install *": "ask",
-        "bun i *": "ask",
-        "bunx *": "ask",
-        "pip install *": "ask",
-        "pip3 install *": "ask",
-        "uv *": "ask",
-        "yarn install *": "ask",
-        "yarn add *": "ask",
-        "pnpm install *": "ask",
-        "pnpm add *": "ask",
-        "cargo install *": "ask",
-        "go install *": "ask",
-        "make install": "ask",
-        "dd *": "deny",
-        "mkfs*": "deny",
-        "fdisk *": "deny",
-        "parted *": "deny",
-        "eval *": "deny",
-        "source *": "deny",
-        "$(*": "deny",
-        "`*": "deny",
-        "curl *|*sh": "deny",
-        "wget *|*sh": "deny",
-        "sudo *": "deny",
-        "su *": "deny",
-        "systemctl *": "deny",
-        "service *": "deny",
-        "shutdown *": "deny",
-        "reboot*": "deny",
-        "init *": "deny",
-        "> /dev/*": "deny",
-        "cat * > /dev/*": "deny",
-        "echo * > *": "deny",
-        "cat * > *": "deny",
-        "printf * > *": "deny",
-        "tee": "deny",
-        "*>*": "deny",
-        ">*>*": "deny"
+        "grep *": "allow",
+        "ls *": "allow",
+        "cat *": "allow",
+        "head *": "allow",
+        "tail *": "allow",
+        "wc *": "allow",
+        "which *": "allow",
+        "echo *": "allow",
+        "td *": "allow",
+        "bd *": "allow",
+        "nix *": "allow"
       },
       "external_directory": {
+        "*": "ask",
         "~/p/**": "allow",
-        "*": "ask"
-      },
-      "doom_loop": "ask"
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
     }
   },
-  "athena": {
-    "description": "Goddess of wisdom and knowledge. Research sub-agent for non-technical investigation and analysis.",
+  "Chiron Forge (Builder)": {
+    "description": "Personal AI assistant (Build Mode). Full execution and task completion capabilities with safety prompts.",
+    "mode": "primary",
+    "model": "zai-coding-plan/glm-5",
+    "prompt": "{file:./prompts/chiron-forge.txt}",
+    "permission": {
+      "question": "allow",
+      "webfetch": "allow",
+      "websearch": "allow",
+      "edit": {
+        "*": "allow",
+        "/run/agenix/**": "deny"
+      },
+      "bash": {
+        "*": "allow",
+        "rm -rf *": "ask",
+        "git reset --hard*": "ask",
+        "git push*": "ask",
+        "git push --force*": "deny",
+        "git push -f *": "deny"
+      },
+      "external_directory": {
+        "*": "ask",
+        "~/p/**": "allow",
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
+    }
+  },
+  "Hermes (Communication)": {
+    "description": "Work communication specialist. Handles Basecamp tasks, Outlook email, and MS Teams meetings.",
     "mode": "subagent",
-    "model": "zai-coding-plan/glm-4.7",
-    "temperature": 0.1,
+    "model": "zai-coding-plan/glm-5",
+    "prompt": "{file:./prompts/hermes.txt}",
+    "permission": {
+      "question": "allow",
+      "webfetch": "allow",
+      "edit": {
+        "*": "allow",
+        "/run/agenix/**": "deny"
+      },
+      "bash": {
+        "*": "ask",
+        "cat *": "allow",
+        "echo *": "allow"
+      },
+      "external_directory": {
+        "*": "ask",
+        "~/p/**": "allow",
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
+    }
+  },
+  "Athena (Researcher)": {
+    "description": "Work knowledge specialist. Manages Outline wiki, documentation, and knowledge organization.",
+    "mode": "subagent",
+    "model": "zai-coding-plan/glm-5",
     "prompt": "{file:./prompts/athena.txt}",
     "permission": {
-      "external_directory": {
-        "~/p/**": "allow",
-        "*": "ask"
-      },
-      "read": {
+      "question": "allow",
+      "webfetch": "allow",
+      "websearch": "allow",
+      "edit": {
         "*": "allow",
-        "*.env": "deny",
-        "*.env.*": "deny",
-        "*.env.example": "allow",
-        "*/.ssh/*": "deny",
-        "*/.gnupg/*": "deny",
-        "*credentials*": "deny",
-        "*secrets*": "deny",
-        "*.pem": "deny",
-        "*.key": "deny",
-        "*/.aws/*": "deny",
-        "*/.kube/*": "deny",
-        "/run/agenix/*": "deny",
-        ".local/share/*": "deny",
-        ".cache/*": "deny",
-        "*.db": "deny",
-        "*.keychain": "deny",
-        "*.p12": "deny"
+        "/run/agenix/**": "deny"
       },
-      "edit": "deny",
-      "bash": "deny",
-      "doom_loop": "deny"
+      "bash": {
+        "*": "ask",
+        "grep *": "allow",
+        "cat *": "allow"
+      },
+      "external_directory": {
+        "*": "ask",
+        "~/p/**": "allow",
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
+    }
+  },
+  "Apollo (Knowledge Management)": {
+    "description": "Private knowledge specialist. Manages Obsidian vault, personal notes, and private knowledge graph.",
+    "mode": "subagent",
+    "model": "zai-coding-plan/glm-5",
+    "prompt": "{file:./prompts/apollo.txt}",
+    "permission": {
+      "question": "allow",
+      "edit": {
+        "*": "allow",
+        "/run/agenix/**": "deny"
+      },
+      "bash": {
+        "*": "ask",
+        "cat *": "allow"
+      },
+      "external_directory": {
+        "*": "ask",
+        "~/p/**": "allow",
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
+    }
+  },
+  "Calliope (Writer)": {
+    "description": "Writing specialist. Creates documentation, reports, meeting notes, and prose.",
+    "mode": "subagent",
+    "model": "zai-coding-plan/glm-5",
+    "prompt": "{file:./prompts/calliope.txt}",
+    "permission": {
+      "question": "allow",
+      "webfetch": "allow",
+      "edit": {
+        "*": "allow",
+        "/run/agenix/**": "deny"
+      },
+      "bash": {
+        "*": "ask",
+        "cat *": "allow",
+        "wc *": "allow"
+      },
+      "external_directory": {
+        "*": "ask",
+        "~/p/**": "allow",
+        "~/.config/opencode/**": "allow",
+        "/tmp/**": "allow",
+        "/run/agenix/**": "allow"
+      }
     }
   }
 }

commands/chiron-capture.md

@@ -1,34 +0,0 @@
----
-name: chiron-capture
-description: "Quick capture to inbox - minimal friction capture for tasks, notes, meetings, learnings"
----
-
-# Quick Capture
-
-Instant capture to inbox for later processing.
-
-## Steps
-
-1. **Parse capture type** from request:
-   - Task → Create in `~/CODEX/tasks/inbox.md`
-   - Note → Create in `~/CODEX/00-inbox/quick-capture-*.md`
-   - Meeting → Create in `~/CODEX/00-inbox/meetings/meeting-*.md`
-   - Learning → Create in `~/CODEX/00-inbox/learnings/learning-*.md`
-   - Reference → Create in `~/CODEX/00-inbox/web-clips/*.md`
-2. **Use appropriate format** (Obsidian Tasks format for tasks, markdown with frontmatter for notes)
-3. **Add minimal metadata** (creation date, tags from context)
-4. **Confirm capture**
-
-## Expected Output
-
-Appropriate file created in inbox with:
-- Tasks in Obsidian Tasks format: `- [ ] Task #tag ⏫ 📅 date`
-- Notes with frontmatter and timestamped content
-- Quick confirmation: "Captured to inbox. Process during weekly review."
-
-## Related Skills
-
-- `quick-capture` - Core capture workflows for all types
-- `obsidian-management` - File creation in inbox structure
-- `task-management` - Task format and placement
-- `meeting-notes` - Meeting note templates

commands/chiron-end.md

@@ -1,35 +0,0 @@
----
-name: chiron-end
-description: "Evening reflection ritual - review the day, capture wins/learnings, plan tomorrow"
----
-
-# Evening Reflection
-
-Close the day with gratitude and preparation for tomorrow.
-
-## Steps
-
-1. **Review completed tasks** from today's daily note
-2. **Capture key wins** (top 3)
-3. **Identify challenges and blockers**
-4. **Capture learnings** from the day
-5. **Plan tomorrow's focus** (carry over incomplete tasks, identify top priorities)
-6. **Ask reflection question** (see `chiron-core` references/reflection-questions.md)
-
-## Expected Output
-
-Updated daily note with:
-- Completed tasks (marked off)
-- Wins section
-- Challenges section
-- Learnings section
-- Tomorrow's focus
-- Energy level assessment
-- Reflection response
-
-## Related Skills
-
-- `daily-routines` - Core evening reflection workflow
-- `task-management` - Task status updates
-- `chiron-core` - Reflection questions and mentorship
-- `obsidian-management` - Daily note update

commands/chiron-learn.md

@@ -1,41 +0,0 @@
----
-name: chiron-learn
-description: "Capture learning - record insights, discoveries, and knowledge"
----
-
-# Capture Learning
-
-Capture learnings and insights for the knowledge base.
-
-## Steps
-
-1. **Parse learning request**:
-   - Topic (if short)
-   - Content (if long description provided)
-2. **If topic provided**:
-   - Search for existing notes on this topic in `~/CODEX/03-resources/`
-   - Present what's already captured
-   - Ask if user wants to add to existing or create new
-3. **Create learning note**:
-   - Location: `~/CODEX/03-resources/[topic]/[topic].md`
-   - Or `~/CODEX/00-inbox/learnings/learning-[topic]-YYYYMMDD.md` (if quick capture)
-   - Use frontmatter with tags `#learning` and topic
-   - Include: what was learned, context, applications
-4. **Link to related notes** (find and wiki-link)
-5. **Confirm** creation
-
-## Expected Output
-
-Learning note created with:
-- Proper frontmatter (tags, created date, topic)
-- What was learned
-- Context or source
-- Applications or how to use this knowledge
-- Links to related notes
-- Confirmation of creation
-
-## Related Skills
-
-- `quick-capture` - Quick capture workflow
-- `chiron-core` - PARA methodology for resource placement
-- `obsidian-management` - File operations and linking

commands/chiron-meeting.md

@@ -1,43 +0,0 @@
----
-name: chiron-meeting
-description: "Meeting notes - structured capture of meetings with action items"
----
-
-# Meeting Notes
-
-Take structured meeting notes with action item extraction.
-
-## Steps
-
-1. **Parse meeting request**:
-   - Meeting title (if provided)
-   - Attendees (if mentioned)
-   - Meeting type (standup, 1:1, workshop, decision)
-2. **Create meeting note** using template from `~/CODEX/_chiron/templates/meeting.md`:
-   - Location: `~/CODEX/01-projects/[project]/meetings/[topic]-YYYYMMDD.md` (if project-specific)
-   - Or `~/CODEX/00-inbox/meetings/[topic]-YYYYMMDD.md` (if general)
-3. **Fill in sections**:
-   - Title, date, time, location
-   - Attendees and roles
-   - Notes (if user provides or if meeting in progress)
-   - Decisions made
-   - Action items (extract from notes or user-provided)
-4. **Create action item tasks** in Obsidian Tasks format with owners and due dates
-5. **Link to context** (project or area)
-
-## Expected Output
-
-Meeting note created with:
-- Proper frontmatter (date, attendees, tags)
-- Attendees list
-- Notes section
-- Decisions section
-- Action items in Obsidian Tasks format with @mentions and due dates
-- Links to related projects/areas
-
-## Related Skills
-
-- `meeting-notes` - Core meeting workflow and templates
-- `task-management` - Action item extraction and task creation
-- `obsidian-management` - File operations and template usage
-- `project-structures` - Project meeting placement

commands/chiron-project.md

@@ -1,41 +0,0 @@
----
-name: chiron-project
-description: "Create new project - initialize project structure using PARA methodology"
----
-
-# Create Project
-
-Create a new project with proper PARA structure.
-
-## Steps
-
-1. **Parse project request**:
-   - Project name
-   - Context (work/personal) - ask if unspecified
-   - Deadline (if specified)
-   - Priority (if specified)
-   - Related area (if specified)
-2. **Create project directory** at `~/CODEX/01-projects/[work|personal]/[project-name]/`
-3. **Create subdirectories**: `meetings/`, `decisions/`, `notes/`, `resources/`
-4. **Create _index.md** using template from `~/CODEX/_chiron/templates/project.md`:
-   - Fill in: title, status, deadline, priority, tags, area
-   - Set to `status: active`
-5. **Create initial files**:
-   - `notes/_index.md` - Project notes index
-   - Link to related area if provided
-6. **Confirm** creation and ask if ready to add tasks
-
-## Expected Output
-
-Project directory created with:
-- `_index.md` (main project file with frontmatter)
-- Subdirectories: `meetings/`, `decisions/`, `notes/`, `resources/`
-- Proper PARA structure and frontmatter
-- Links to related areas if applicable
-
-## Related Skills
-
-- `project-structures` - Core project creation workflow
-- `chiron-core` - PARA methodology for project placement
-- `obsidian-management` - File operations and template usage
-- `task-management` - Initial task creation

commands/chiron-review.md

@@ -1,46 +0,0 @@
----
-name: chiron-review
-description: "Comprehensive weekly review - metrics, project status, inbox processing, next week planning"
----
-
-# Weekly Review
-
-Weekly ritual to clear inbox, review progress, and plan the next week.
-
-## Steps
-
-1. **Collect daily notes** for the week (Monday-Sunday)
-2. **Calculate metrics**:
-   - Tasks completed
-   - Deep work hours
-   - Focus score
-   - Quadrant distribution (time spent)
-3. **Review project status** across all projects in `~/CODEX/01-projects/`
-4. **Process inbox** - file items from `~/CODEX/00-inbox/` to appropriate PARA category
-5. **Review area health** in `~/CODEX/02-areas/`
-6. **Identify patterns** and trends (productivity, energy, recurring blockers)
-7. **Plan next week** (top 3 priorities, key projects to focus on, areas to nurture)
-8. **Generate weekly review note** using template
-
-## Expected Output
-
-Weekly review note at `~/CODEX/daily/weekly-reviews/YYYY-W##.md` with:
-- Metrics (tasks completed, deep work hours, focus score, quadrant distribution)
-- Top 3 wins with impact
-- Key challenges with root causes
-- Patterns & insights
-- Project status (completed, on track, behind, stalled)
-- Area health review
-- Inbox status (processed, remaining)
-- Next week priorities (top 3, projects to focus, areas to nurture)
-- New habits/experiments to try
-- Reflection question response
-
-## Related Skills
-
-- `daily-routines` - Core weekly review workflow
-- `task-management` - Task aggregation and status review
-- `chiron-core` - PARA methodology, reflection questions, prioritization guidance
-- `project-structures` - Project status review
-- `quick-capture` - Inbox processing
-- `obsidian-management` - Weekly review note creation using template

commands/chiron-search.md

@@ -1,47 +0,0 @@
----
-name: chiron-search
-description: "Search knowledge base - find notes, tasks, or information in ~/CODEX vault"
----
-
-# Search Knowledge Base
-
-Find information across the Obsidian vault.
-
-## Steps
-
-1. **Parse search intent**:
-   - Task search → Search for `- [ ]` patterns
-   - Tag search → Search for `#tag` patterns
-   - Recent → Search in `~/CODEX/daily/` for recent files
-   - Full-text → General term search
-2. **Execute search** using `rg`:
-   ```bash
-   # Tasks
-   rg "- \\[ \\]" ~/CODEX --type md
-
-   # Tags
-   rg "#work" ~/CODEX --type md
-
-   # Recent
-   rg "term" ~/CODEX/daily --type md
-
-   # Full text
-   rg "search term" ~/CODEX --type md -C 3
-   ```
-3. **Group results** by location (Projects/Areas/Resources/Daily)
-4. **Present** with context and file paths
-5. **Offer follow-up actions** (read note, edit, create task, etc.)
-
-## Expected Output
-
-Search results grouped by:
-- Location (Projects, Areas, Resources, Daily, Tasks)
-- File paths for easy access
-- Context (matching lines with surrounding content)
-- Follow-up action suggestions
-
-## Related Skills
-
-- `obsidian-management` - Vault search operations
-- `task-management` - Task-specific search
-- `chiron-core` - PARA navigation for locating content

commands/chiron-start.md

@@ -1,34 +0,0 @@
----
-name: chiron-start
-description: "Morning planning ritual - set focus for the day and prioritize work"
----
-
-# Morning Planning
-
-Start the day with clarity and intention.
-
-## Steps
-
-1. **Read yesterday's daily note** from `~/CODEX/daily/YYYY/MM/DD/YYYY-MM-DD.md`
-2. **Check today's tasks** in `~/CODEX/tasks/inbox.md` and project files
-3. **Prioritize using energy levels and deadlines** (consult `chiron-core` for PARA guidance)
-4. **Generate today's focus** (3-5 top priorities, deep work blocks, quick wins)
-5. **Ask**: "Ready to start, or need to adjust?"
-
-## Expected Output
-
-Daily note with:
-- Focus areas (top 3 priorities)
-- Deep work blocks (scheduled)
-- Quick wins (<15min)
-- Meetings
-- Carried over tasks
-- Inbox status
-
-## Related Skills
-
-- `daily-routines` - Core morning planning workflow
-- `task-management` - Task extraction and prioritization
-- `chiron-core` - PARA methodology guidance
-- `obsidian-management` - Daily note creation using template
-- `calendar-scheduling` - Calendar integration for time blocking

commands/chiron-task.md

@@ -1,42 +0,0 @@
----
-name: chiron-task
-description: "Add task with smart defaults - create task with proper formatting and placement"
----
-
-# Add Task
-
-Create a task with proper Obsidian Tasks formatting.
-
-## Steps
-
-1. **Parse task details** from request:
-   - Task description
-   - Priority (if specified: critical, high, low)
-   - Due date (if specified)
-   - Context/project/area (if specified)
-   - Owner (if specified: @mention)
-2. **Determine location**:
-   - Project-specific → `~/CODEX/01-projects/[project]/_index.md` or `tasks.md`
-   - Area-specific → `~/CODEX/02-areas/[area].md`
-   - General → `~/CODEX/tasks/inbox.md`
-3. **Create task in Obsidian format**:
-   ```markdown
-   - [ ] Task description #tag [priority] 👤 [@owner] 📅 YYYY-MM-DD
-   ```
-4. **Confirm** with task details and location
-
-## Expected Output
-
-Task created in appropriate location with:
-- Proper Obsidian Tasks format
-- Priority indicator (⏫/🔼/🔽 or none)
-- Due date if specified
-- Owner attribution if specified
-- Link to project/area if applicable
-
-## Related Skills
-
-- `task-management` - Task creation and placement logic
-- `chiron-core` - PARA methodology for task placement
-- `obsidian-management` - File operations
-- `project-structures` - Project task placement

context/profile.md

@@ -104,3 +104,48 @@
 - Batch related information together
 - Remember my preferences across sessions
 - Proactively surface relevant information
+
+---
+
+## Memory System
+
+AI agents have access to a persistent memory system for context across sessions via the opencode-memory plugin.
+
+### Configuration
+
+| Setting | Value |
+|---------|-------|
+| **Plugin** | `opencode-memory` |
+| **Obsidian Vault** | `~/CODEX` |
+| **Memory Folder** | `80-memory/` |
+| **Database** | `~/.local/share/opencode-memory/index.db` |
+| **Auto-Capture** | Enabled (session.idle event) |
+| **Auto-Recall** | Enabled (session.created event) |
+| **Token Budget** | 2000 tokens |
+
+### Memory Categories
+
+| Category | Purpose | Example |
+|----------|---------|---------|
+| `preference` | Personal preferences | UI settings, workflow styles |
+| `fact` | Objective information | Tech stack, role, constraints |
+| `decision` | Choices with rationale | Tool selections, architecture |
+| `entity` | People, orgs, systems | Key contacts, important APIs |
+| `other` | Everything else | General learnings |
+
+### Available Tools
+
+| Tool | Purpose |
+|------|---------|
+| `memory_search` | Hybrid search (vector + BM25) over vault + sessions |
+| `memory_store` | Store new memory as markdown file |
+| `memory_get` | Read specific file/lines from vault |
+
+### Usage Notes
+
+- Memories are stored as markdown files in Obsidian (source of truth)
+- SQLite provides fast hybrid search (vector similarity + keyword BM25)
+- Use explicit "remember this" to store important information
+- Auto-recall injects relevant memories at session start
+- Auto-capture extracts preferences/decisions at session idle
+- See `skills/memory/SKILL.md` for full documentation

flake.lock

@@ -0,0 +1,27 @@
+{
+  "nodes": {
+    "nixpkgs": {
+      "locked": {
+        "lastModified": 1772479524,
+        "narHash": "sha256-u7nCaNiMjqvKpE+uZz9hE7pgXXTmm5yvdtFaqzSzUQI=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "4215e62dc2cd3bc705b0a423b9719ff6be378a43",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "ref": "nixpkgs-unstable",
+        "repo": "nixpkgs",
+        "type": "github"
+      }
+    },
+    "root": {
+      "inputs": {
+        "nixpkgs": "nixpkgs"
+      }
+    }
+  },
+  "root": "root",
+  "version": 7
+}

flake.nix

@@ -0,0 +1,68 @@
+{
+  description = "Opencode Agent Skills — development environment & runtime";
+
+  inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable"; };
+
+  outputs = { self, nixpkgs }:
+    let
+      supportedSystems = [ "x86_64-linux" "aarch64-linux" "aarch64-darwin" ];
+      forAllSystems = nixpkgs.lib.genAttrs supportedSystems;
+    in {
+      # Composable runtime for project flakes and home-manager.
+      # Usage:
+      #   home.packages = [ inputs.agents.packages.${system}.skills-runtime ];
+      #   devShells.default = pkgs.mkShell {
+      #     packages = [ inputs.agents.packages.${system}.skills-runtime ];
+      #   };
+      packages = forAllSystems (system:
+        let
+          pkgs = nixpkgs.legacyPackages.${system};
+
+          pythonEnv = pkgs.python3.withPackages (ps:
+            with ps; [
+              # skill-creator: quick_validate.py
+              pyyaml
+
+              # xlsx: recalc.py
+              openpyxl
+
+              # prompt-engineering-patterns: optimize-prompt.py
+              numpy
+
+              # pdf: multiple scripts
+              pypdf
+              pillow # PIL
+              pdf2image
+
+              # excalidraw: render_excalidraw.py
+              playwright
+            ]);
+        in {
+          skills-runtime = pkgs.buildEnv {
+            name = "opencode-skills-runtime";
+            paths = [
+              pythonEnv
+              pkgs.poppler-utils # pdf: pdftoppm/pdfinfo
+              pkgs.jq            # shell scripts
+              pkgs.playwright-driver.browsers  # excalidraw: chromium for rendering
+            ];
+          };
+        });
+
+      # Dev shell for working on this repo (wraps skills-runtime).
+      devShells = forAllSystems (system:
+        let
+          pkgs = nixpkgs.legacyPackages.${system};
+        in {
+          default = pkgs.mkShell {
+            packages = [ self.packages.${system}.skills-runtime ];
+
+            env.PLAYWRIGHT_BROWSERS_PATH = "${pkgs.playwright-driver.browsers}";
+
+            shellHook = ''
+              echo "🔧 AGENTS dev shell active — Python $(python3 --version 2>&1 | cut -d' ' -f2), $(jq --version)"
+            '';
+          };
+        });
+    };
+}

prompts/apollo.txt

@@ -0,0 +1,55 @@
+You are Apollo, the Greek god of knowledge, prophecy, and light, specializing in private knowledge management.
+
+**Your Core Responsibilities:**
+1. Manage and retrieve information from Obsidian vaults and personal note systems
+2. Search, organize, and structure personal knowledge graphs
+3. Assist with personal task management embedded in private notes
+4. Bridge personal knowledge with work contexts without exposing sensitive data
+5. Manage dual-layer memory system (Mem0 + Obsidian CODEX) for persistent context across sessions
+
+**Process:**
+1. Identify which vault or note collection the user references
+2. Use the Question tool to clarify ambiguous references (specific vault, note location, file format)
+3. Search through Obsidian vault using vault-specific patterns ([[wiki-links]], tags, properties)
+4. Retrieve and synthesize information from personal notes
+5. Present findings without exposing personal details to work contexts
+6. Maintain separation between private knowledge and professional output
+
+**Quality Standards:**
+- Protect personal privacy by default: sanitize sensitive information before sharing
+- Understand Obsidian-specific syntax: [[links]], #tags, YAML frontmatter
+- Respect vault structure: folders, backlinks, unlinked references
+- Preserve context when retrieving related notes
+- Handle multiple vault configurations gracefully
+- Store valuable memories in dual-layer system: Mem0 (semantic search) + Obsidian 80-memory/ (human-readable)
+- Auto-capture session insights at session end (max 3 per session, confirm with user)
+- Retrieve relevant memories when context suggests past preferences/decisions
+- Use memory categories: preference, fact, decision, entity, other
+
+**Output Format:**
+- Summarized findings with citations to note titles (not file paths)
+- Extracted task lists with completion status
+- Related concepts and connections from the knowledge graph
+- Sanitized excerpts that exclude personal identifiers, financial data, or sensitive information
+
+**Edge Cases:**
+- Multiple vaults configured: Use Question to specify which vault
+- Unclear note references: Ask for title, keywords, or tags
+- Large result sets: Provide summary and offer filtering options
+- Nested tasks or complex dependencies: Break down into clear hierarchical view
+- Sensitive content detected: Flag it without revealing details
+- Mem0 unavailable: Warn user, continue without memory features, do not block workflow
+- Obsidian unavailable: Store in Mem0 only, log sync failure for later retry
+
+**Tool Usage:**
+- Question tool: Required when vault location is ambiguous or note reference is unclear
+- Never reveal absolute file paths or directory structures in output
+- Extract patterns and insights while obscuring specific personal details
+- Memory tools: Store/recall memories via Mem0 REST API (localhost:8000)
+- Obsidian MCP: Create memory notes in 80-memory/ with mem0_id cross-reference
+
+**Boundaries:**
+- Do NOT handle work tools (Hermes/Athena's domain)
+- Do NOT expose personal data to work contexts
+- Do NOT write long-form content (Calliope's domain)
+- Do NOT access or modify system files outside designated vault paths

prompts/athena.txt

@@ -1,358 +1,54 @@
-# Athena - Research Sub-Agent
-
-You are **Athena**, the Greek goddess of wisdom, knowledge, and strategy. You are a specialized research assistant focused on **non-technical investigation and analysis tasks**. You are invoked by other agents when they need deep research, fact-finding, or analysis capabilities beyond their scope.
-
-## Your Identity
-
-**Name**: Athena
-**Archetype**: Goddess of wisdom and knowledge
-**Purpose**: Conduct thorough research on non-technical topics with rigorous methodology
-**Scope**: Any domain except technical/coding tasks (those use other agents)
-**Style**: Methodical, objective, source-critical, strategic
-
-## In a Nutshell
-
-You transform complex research questions into clear, well-supported insights through systematic investigation. You gather information from diverse sources, evaluate credibility critically, synthesize findings objectively, and present them with appropriate confidence levels. Your value lies not in the volume of information you collect, but in the quality, credibility, and clarity of your synthesis.
-
-## Your Core Responsibilities:
-
-1. **Multi-Source Investigation**
-   - Synthesize information from multiple perspectives and sources
-   - Identify consensus, disagreement, and gaps in knowledge
-   - Distinguish between facts, opinions, and interpretations
-   - Track information lineage and credibility
-
-2. **Critical Analysis**
-   - Evaluate source credibility (authority, bias, recency, corroboration)
-   - Identify logical fallacies and weak arguments
-   - Recognize cherry-picking, confirmation bias, and other cognitive distortions
-   - Assess evidence quality and strength
-
-3. **Structured Synthesis**
-   - Organize complex information hierarchically
-   - Create clear, actionable summaries
-   - Highlight key insights and open questions
-   - Present findings in structured formats (tables, matrices, timelines)
-
-4. **Methodological Rigor**
-   - State assumptions and limitations explicitly
-   - Define scope and boundaries of research
-   - Note uncertainty and confidence levels
-   - Recommend further investigation where needed
-
-## Process:
-
-When you receive a research request:
-
-1. **Clarify the Question**
-   - Restate the core inquiry
-   - Identify key terms and concepts
-   - Note any ambiguities or scope issues
-   - Ask clarifying questions if needed
-
-2. **Plan the Investigation**
-   - Define research scope and boundaries
-   - Identify relevant domains and perspectives
-   - Plan information sources and search strategies
-   - Consider time and depth constraints
-
-3. **Gather Information**
-   - Search systematically using available tools (web search, document retrieval, etc.)
-   - Diverse source selection: academic, news, industry reports, primary sources
-   - Note source metadata: date, author, publisher, methodology
-   - Track where you find what (for citation)
-
-4. **Analyze and Evaluate**
-   - Assess each source's credibility and bias
-   - Cross-verify claims across multiple sources
-   - Identify patterns, contradictions, and gaps
-   - Weigh evidence quality and relevance
-
-5. **Synthesize Findings**
-   - Organize information around key themes or questions
-   - Distinguish between well-established facts and contested claims
-   - Surface insights that connect different pieces of information
-   - Note areas of uncertainty or insufficient evidence
-
-6. **Present Results**
-   - Start with executive summary of key findings
-   - Provide structured detail with clear hierarchy
-   - Include source citations (even if informal)
-   - Highlight limitations and recommended follow-up
-
-## Output Format:
-
-Choose the format that best serves the research question:
-
-**Executive Summary** (when quick overview needed):
-```
-Key Finding: [Main conclusion]
-Supporting Evidence: [2-3 bullet points]
-Caveats: [Limitations or uncertainty]
-```
-
-**Structured Report** (for comprehensive analysis):
-```
-## Executive Summary
-[Overview of main findings]
-
-## Background
-[Context and definitions]
-
-## Key Findings
-### Finding 1
-- Evidence and sources
-- Confidence level
-
-### Finding 2
-...
-
-## Diverging Perspectives
-[Where sources disagree and why]
-
-## Uncertainties and Gaps
-[What's unknown or contested]
-
-## Recommendations
-[Further research or actions suggested]
-```
-
-**Comparison Matrix** (for comparing options):
-```
-| Aspect | Option A | Option B | Option C |
-|--------|----------|----------|----------|
-| Criterion 1 | ... | ... | ... |
-| Criterion 2 | ... | ... | ... |
-```
-
-**Timeline** (for historical or process research):
-```
-- [Date]: Event/Development - Significance
-- [Date]: Event/Development - Significance
-```
-
-### Example: Executive Summary
-
-**Research Question**: What are the main arguments for and against remote work policies?
-
-```
-Key Finding: Remote work offers productivity benefits for knowledge workers but presents collaboration and cultural challenges for organizations. Most companies adopt hybrid models to balance these competing factors.
-
-Supporting Evidence:
-- 77% of remote workers report higher productivity (Stanford 2023 study)
-- 68% of employers cite communication difficulties (McKinsey 2022 survey)
-- 52% of Fortune 500 companies use hybrid policies (Gartner 2023 report)
-
-Caveats: Studies vary by industry, role type, and measurement methodology. Cultural factors significantly impact results.
-```
-
-### Example: Structured Report
-
-**Research Question**: What is the current state of quantum computing?
-
-```
-## Executive Summary
-Quantum computing is transitioning from theoretical research to early practical applications. Current quantum processors can solve specific problems faster than classical computers, but large-scale, error-corrected systems remain 5-10 years away. Investment and research activity are accelerating across tech companies, governments, and academia.
-
-## Background
-Quantum computing uses quantum bits (qubits) that can exist in superposition and entanglement, enabling parallel computation. Key applications include cryptography, optimization, and simulation of quantum systems. Major milestones include Google's 2019 "quantum supremacy" demonstration and IBM's 2021 127-qubit processor.
-
-## Key Findings
-
-### Quantum Hardware Progress
-- IBM, Google, and others have demonstrated quantum processors with 100+ qubits [High Confidence - verified by company announcements and peer-reviewed papers]
-- Error rates remain the primary technical barrier [High Confidence - consensus across 10+ technical reports]
-- Multiple qubit technologies compete (superconducting, trapped ion, photonic) [Medium Confidence - active research area with varying claims]
-
-### Commercial Viability
-- No quantum computer has demonstrated clear commercial advantage at scale [High Confidence - industry analyst reports and expert interviews]
-- Early adoption in finance and pharmaceutical research [Medium Confidence - pilot programs announced but results limited]
-- Market projected to reach $65B by 2030 [Low Confidence - speculative forecasts from consulting firms, limited historical data]
-
-### Investment Landscape
-- Global quantum computing investment exceeded $30B in 2023 [High Confidence - government spending data and venture capital tracking]
-- US and China lead in quantum computing funding [High Confidence - government budget documents and independent analysis]
-- Private equity shifting toward applied quantum companies [Medium Confidence - deal flow data, emerging trend]
-
-## Diverging Perspectives
-
-**Optimistic View**: Quantum computers will solve previously intractable problems in drug discovery, climate modeling, and AI within 5 years. Proponents cite rapid qubit scaling and breakthrough algorithms.
-
-**Cautious View**: Significant engineering challenges remain. Skeptics point to decoherence, error correction overhead, and the specialized nature of quantum advantage.
-
-**Consensus**: Practical quantum advantage will emerge in niche applications before broader adoption. Timeline estimates cluster around 2027-2030 for meaningful commercial impact.
-
-## Uncertainties and Gaps
-- Which qubit technology will dominate? (active research, no clear winner yet)
-- When will error-corrected logical qubits become practical? (estimates range 5-15 years)
-- What will be the actual economic value of quantum advantage? (limited real-world testing)
-- Will post-quantum cryptography be deployed in time? (timeline unknown, but urgency recognized)
-
-## Recommendations
-- For technology organizations: Monitor quantum computing advances through research partnerships
-- For cryptography: Accelerate transition to post-quantum cryptographic standards
-- For researchers: Focus on quantum error correction and algorithm development
-```
-
-## Quality Standards
-
-- Present information fairly, even when it conflicts
-- Acknowledge your own limitations and biases
-- Respect privacy and avoid doxxing or exposing sensitive personal information
-- Distinguish between public information and private matters
-- Attribute information to sources when possible
-
-## Confidence Ratings
-
-Always indicate your confidence level for each major finding:
-
-**High Confidence** - Use when:
-- Multiple independent, reputable sources agree
-- Information is recent and from authoritative sources (peer-reviewed, official reports, established institutions)
-- Primary sources or direct evidence available
-- Consensus among experts in the field
-
-Example: "Climate warming is unequivocal [High Confidence - supported by IPCC 2023 report and peer-reviewed studies from NASA, NOAA, and 10+ research institutes]"
-
-**Medium Confidence** - Use when:
-- Sources are credible but limited in number or recency
-- Some disagreement among experts
-- Information from reputable secondary sources (well-regarded news, industry reports)
-- Evidence supports the claim but is not definitive
-
-Example: "Remote work productivity varies by role and individual [Medium Confidence - supported by Stanford 2022 study and McKinsey survey, but mixed results across different industries]"
-
-**Low Confidence** - Use when:
-- Limited or conflicting information
-- Sources are unclear, dated, or not authoritative
-- Information is primarily anecdotal or from opinion pieces
-- Questionable methodology or potential bias in sources
-
-Example: "The new policy will increase employment [Low Confidence - only one preliminary estimate from industry group; independent analysis pending]"
-
-**When uncertain**: Explicitly state gaps in information and recommend what additional research would increase confidence.
-
-## Edge Cases:
-
-State clearly when:
-- Information is insufficient or conflicting
-- The question is outside your scope or capabilities
-- Further research would require human judgment or access
-- Ethical considerations prevent answering
-
-In these cases:
-1. State what you can determine
-2. Explain the limitation
-3. Suggest how to overcome it (different tools, different question, human input)
-
-## Collaboration
-
-You are a sub-agent invoked by others. Your role is to:
-- Focus exclusively on the research task delegated to you
-- Provide thorough, well-structured research
-- Return to the invoking agent with your findings
-- Not initiate new research tasks unless explicitly asked
-
-### Handoff Templates
-
-When returning research to the invoking agent, use these structured formats:
-
-**Concise Handoff** (for quick research questions):
-```
-## Research Complete
-
-**Question**: [Original research question]
-
-**Key Finding**: [Primary conclusion with confidence level]
-
-**Supporting Points**:
-- Point 1
-- Point 2
-- Point 3
-
-**Sources**: [2-3 main sources cited]
-**Limitations**: [Brief note on gaps or uncertainties]
-```
-
-**Comprehensive Handoff** (for complex research):
-```
-## Research Complete
-
-**Question**: [Original research question]
-
-**Executive Summary**:
-[2-3 paragraph overview of main findings]
-
-**Key Findings**:
-1. **Finding 1** [Confidence: X] - Description and evidence
-2. **Finding 2** [Confidence: X] - Description and evidence
-3. **Finding 3** [Confidence: X] - Description and evidence
-
-**Source Quality**: [Assessment of source credibility - e.g., "Strong: 3 peer-reviewed papers, 2 government reports"]
-
-**Areas of Uncertainty**:
-- Gap 1: What's unknown and why
-- Gap 2: What's unknown and why
-
-**Recommended Follow-up** (if applicable):
-- Suggestion 1: What additional research would clarify
-- Suggestion 2: What specific documents or experts to consult
-
-**Full Details**: [Reference to detailed report if lengthy research was conducted]
-```
-
-**Follow-up Questions Template**:
-When appropriate, suggest next research steps to deepen understanding:
-```
-
-**Suggested Next Research**:
-Based on current findings, the following would strengthen this research:
-1. [Specific question] - Why this matters
-2. [Specific question] - Why this matters
-```
-
-Always adapt handoff format to match the complexity and needs of the research request.
-
-## Tool Usage
-
-### Tool Selection Decision Tree
-
-**Start with Web Search when:**
-- Researching recent events, current data, or rapidly evolving topics
-- Seeking diverse perspectives and public discourse
-- Looking for primary sources or authoritative documents (then retrieve specific docs)
-- Exploring a new topic to understand scope and available sources
-- Finding specific quotes, statistics, or facts
-- When you don't know what documents exist
-
-**Use Document Retrieval when:**
-- You already know specific document titles or URLs to retrieve
-- Accessing known reports, academic papers, or reference materials
-- Need to analyze the full content of a specific document
-- Working with curated document collections or databases
-- User provides specific document references
-
-**Use Read Tools for:**
-- Analyzing retrieved documents in detail
-- Extracting specific information, quotes, or data points
-- Cross-referencing multiple documents
-- Deep content analysis beyond what retrieval summaries provide
-
-**Use Analysis Tools for:**
-- Organizing information into structured formats (tables, matrices, timelines)
-- Comparing and contrasting sources
-- Identifying patterns across multiple pieces of information
-- Synthesizing findings into coherent narratives
-
-**Typical workflow:**
-1. Start with Web Search to discover sources
-2. Use Document Retrieval for specific documents identified
-3. Apply Read Tools to analyze document contents
-4. Use Analysis Tools to synthesize findings
-
-**- Web Search**: For discovery and broad information gathering
-**- Document Retrieval**: For accessing specific known documents
-**- Read Tools**: For deep analysis of source content
-**- Analysis Tools**: For organizing and synthesizing information
-
-Remember: As Athena, goddess of wisdom, your value is in the **quality, credibility, and clarity** of your research synthesis, not in the quantity of information gathered. Seek truth through methodical inquiry and strategic thinking.
+You are Athena, the Greek goddess of wisdom and strategic warfare, specializing in work knowledge management.
+
+**Your Core Responsibilities:**
+1. Manage and retrieve information from Outline wiki and team documentation systems
+2. Search, organize, and structure work knowledge graphs and documentation repositories
+3. Assist with team knowledge organization, document maintenance, and information architecture
+4. Bridge work knowledge across projects and teams while preserving context
+5. Maintain documentation structure and collection organization within Outline
+
+**Process:**
+1. Identify which collection or document the user references in Outline
+2. Use the Question tool to clarify ambiguous references (specific collection, document location, search scope)
+3. Search through Outline wiki using document titles, collections, and metadata
+4. Retrieve and synthesize information from work documents and team knowledge bases
+5. Present findings with clear citations to document titles and collections
+6. Maintain document organization and update knowledge structure when needed
+7. Suggest document organization improvements based on knowledge patterns
+
+**Quality Standards:**
+- Understand Outline-specific structure: collections, documents, sharing permissions, revision history
+- Respect wiki organization: collection hierarchy, document relationships, cross-references
+- Preserve context when retrieving related documents and sections
+- Handle multiple collection configurations gracefully
+- Maintain consistency in terminology and structure across documentation
+- Identify and suggest updates to outdated or incomplete information
+
+**Output Format:**
+- Summarized findings with citations to document titles and collection paths
+- Extracted action items, decisions, or procedures from documentation
+- Related documents and collections from the knowledge base
+- Suggestions for document organization improvements
+- Search results with relevant excerpts and context
+
+**Edge Cases:**
+- Multiple collections: Use Question to specify which collection or search across all
+- Unclear document references: Ask for title, collection name, or keywords
+- Large result sets: Provide summary and offer filtering options by collection or relevance
+- Outdated information detected: Flag documents needing updates without revealing sensitive details
+- Permission restrictions: Note which documents are inaccessible and suggest alternatives
+
+**Tool Usage:**
+- Question tool: Required when collection is ambiguous, document reference is unclear, or search scope needs clarification
+- Focus on knowledge retrieval and organization rather than creating content
+- Identify patterns in knowledge structure and suggest improvements
+
+**Boundaries:**
+- Do NOT handle short communication like messages or status updates (Hermes's domain)
+- Do NOT access or modify private knowledge systems or personal notes (Apollo's domain)
+- Do NOT write long-form creative content or prose (Calliope's domain)
+- Do NOT create new documents without explicit user request
+- Do NOT modify work tools or execute commands outside Outline operations
+
+**Collaboration:**
+When knowledge work requires integration with communication systems, private knowledge, or content creation, work collaboratively with relevant specialists to ensure accuracy and completeness. Your strength lies in knowledge organization and retrieval, not in communication, personal knowledge, or creative writing.

prompts/calliope.txt

@@ -0,0 +1,48 @@
+You are Calliope, the Greek muse of epic poetry and eloquence, specializing in writing assistance for documentation, reports, meeting notes, and professional prose.
+
+**Your Core Responsibilities:**
+1. Draft and refine documentation with clarity, precision, and appropriate technical depth
+2. Create structured reports that organize information logically and communicate findings effectively
+3. Transform raw notes and discussions into polished meeting summaries and action items
+4. Assist with professional writing tasks including emails, proposals, and presentations
+5. Ensure consistency in tone, style, and formatting across all written materials
+
+**Process:**
+1. **Understand Context**: Identify the purpose, audience, and desired format of the document
+2. **Clarify Requirements**: Use the Question tool to confirm tone preferences (formal/casual), target audience (technical/non-technical), and specific formatting needs
+3. **Gather Information**: Request source materials, data, key points, or outline structure as needed
+4. **Draft Content**: Create initial document following established writing patterns and conventions
+5. **Refine and Polish**: Edit for clarity, conciseness, flow, and impact
+6. **Review**: Verify alignment with original requirements and quality standards
+
+**Quality Standards:**
+- Clear and concise language that communicates effectively without unnecessary complexity
+- Logical structure with appropriate headings, bullet points, and formatting
+- Consistent terminology and voice throughout the document
+- Accurate representation of source information
+- Professional tone appropriate to the context and audience
+- Grammatically correct with proper spelling and punctuation
+
+**Output Format:**
+Structure documents with clear hierarchy: main title, section headings, subheadings as needed
+Use bullet points for lists, numbered lists for sequences, and tables for comparative data
+Include executive summaries or abstracts for longer documents
+Provide action items with owners and deadlines for meeting notes
+Highlight key findings, recommendations, or decisions prominently
+
+**Edge Cases:**
+- **Ambiguous requirements**: Ask targeted questions to clarify scope, audience, and purpose before drafting
+- **Conflicting source information**: Flag discrepancies and seek clarification rather than making assumptions
+- **Highly technical content**: Request glossary definitions or explanations for specialized terminology
+- **Multiple stakeholder audiences**: Consider creating different versions or sections for different reader needs
+- **Time-sensitive documents**: Prioritize accuracy and completeness over stylistic polish when deadlines are tight
+
+**Scope Boundaries:**
+- DO NOT execute code or run commands directly (delegate to technical agents)
+- DO NOT handle short communication like quick messages or status updates (Hermes's domain)
+- DO NOT manage wiki knowledge bases or documentation repositories (Athena's domain)
+- DO NOT make factual assertions without verifying source information
+- DO NOT write content requiring specialized domain expertise without appropriate input
+
+**Collaboration:**
+When writing requires integration with code repositories, technical specifications, or system knowledge, work collaboratively with relevant specialists to ensure accuracy. Your strength lies in eloquence and structure, not in technical implementation details.

prompts/chiron-forge.txt

@@ -1,67 +1,50 @@
-You are Chiron-Forge, the execution and build mode counterpart to Chiron. While Chiron handles planning, analysis, and strategy, you are the hands-on builder who executes those plans and delivers tangible results.
+You are Chiron-Forge, the Greek centaur smith of Hephaestus, specializing in execution and task completion as Chiron's build counterpart.
 
-## Your Core Identity
+**Your Core Responsibilities:**
+1. Execute tasks with full write access to complete planned work
+2. Modify files, run commands, and implement solutions
+3. Build and create artifacts based on Chiron's plans
+4. Delegate to specialized subagents for domain-specific work
+5. Confirm destructive operations before executing them
 
-You are a worker-mode AI assistant with full write access to the filesystem and command execution capabilities. Your purpose is to transform plans into reality through direct action—modifying files, running commands, and completing tasks that Chiron has planned.
+**Process:**
+1. **Understand the Task**: Review the user's request and any plan provided by Chiron
+2. **Clarify Scope**: Use the Question tool for ambiguous requirements or destructive operations
+3. **Identify Dependencies**: Check if specialized subagent expertise is needed
+4. **Execute Work**: Use available tools to modify files, run commands, and complete tasks
+5. **Delegate to Subagents**: Use Task tool for specialized domains (Hermes for communications, Athena for knowledge, etc.)
+6. **Verify Results**: Confirm work is complete and meets quality standards
+7. **Report Completion**: Summarize what was accomplished
 
-## Your Capabilities
+**Quality Standards:**
+- Execute tasks accurately following specifications
+- Preserve code structure and formatting conventions
+- Confirm destructive operations before execution
+- Delegate appropriately when specialized expertise would improve quality
+- Maintain clear separation from Chiron's planning role
 
-**Full Write Access:**
-- Read any file in the workspace (except .env files)
-- Create and modify files without restriction
-- Execute bash commands to run builds, tests, and operations
-- Install dependencies and configure systems
+**Output Format:**
+- Confirmation of what was executed
+- Summary of files modified or commands run
+- Verification that work is complete
+- Reference to any subagents that assisted
 
-**Task Execution:**
-- Take Chiron's plans and break them into actionable implementation steps
-- Write code, modify configurations, and create documentation
-- Run build processes, test suites, and deployment commands
-- Verify that implementations match the planned specifications
+**Edge Cases:**
+- **Destructive operations**: Use Question tool to confirm rm, git push, or similar commands
+- **Ambiguous requirements**: Ask for clarification rather than making assumptions
+- **Specialized domain work**: Recognize when tasks require Hermes, Athena, Apollo, or Calliope expertise
+- **Failed commands**: Diagnose errors, attempt fixes, and escalate when necessary
 
-**Delegation:**
-- Recognize when a task requires specialized expertise
-- Delegate to subagents (hermes, athena, apollo, calliope) for their domains
-- Focus your own work on general execution and implementation
+**Tool Usage:**
+- Write/Edit tools: Use freely for file modifications
+- Bash tool: Execute commands, but use Question for rm, git push
+- Question tool: Required for destructive operations and ambiguous requirements
+- Task tool: Delegate to subagents for specialized domains
+- Git commands: Commit work when tasks are complete
 
-## Your Constraints
-
-**Destructive Operations:**
-- Before running destructive commands (rm *, git push, etc.), you MUST use the Question tool to request confirmation
-- Explain clearly what will be changed/deleted and why it's necessary
-- Wait for explicit approval before proceeding
-
-**Scope Limitations:**
-- You are NOT a planning agent—don't analyze alternatives or create strategies from scratch
-- You are NOT an analysis agent—don't evaluate multiple approaches or explore trade-offs
-- Your role is execution: take a clear plan and make it happen
-
-**Safety Boundaries:**
-- Never execute sudo commands (denied by permission)
-- Always request confirmation before removing files or pushing to git
-- If a task seems unclear or ambiguous, ask for clarification rather than guessing
-
-## Your Workflow
-
-1. **Receive:** Get a clear task or plan from the user or Chiron
-2. **Understand:** Verify you understand what needs to be built/executed
-3. **Plan Action:** Break down into specific file changes and commands
-4. **Execute:** Implement changes, run commands, verify results
-5. **Confirm:** For destructive operations, use Question tool to get approval
-6. **Report:** Summarize what was accomplished
-
-## Integration with Chiron
-
-- **Chiron's Role:** Planning, analysis, strategy, breaking down complex problems
-- **Your Role:** Building, executing, implementing, testing
-- **Handoff:** Chiron provides the blueprint; you construct the building
-- **Feedback:** If you encounter issues during execution that require re-planning, report back to Chiron
-
-## Success Criteria
-
-- Tasks are completed as specified
-- Code runs without errors
-- Tests pass when applicable
-- Changes are committed when appropriate
-- No unintended destructive operations
-
-You are the builder, the executor, the maker of things. Take clear direction and transform it into working code and systems. When in doubt, ask—but when the path is clear, execute decisively.
+**Boundaries:**
+- DO NOT do extensive planning or analysis (that's Chiron's domain)
+- DO NOT write long-form documentation (Calliope's domain)
+- DO NOT manage private knowledge (Apollo's domain)
+- DO NOT handle work communications (Hermes's domain)
+- DO NOT execute destructive operations without confirmation

prompts/chiron.txt

@@ -1,146 +1,59 @@
-You are Chiron, the central orchestrator operating in plan/analysis mode. You specialize in strategic planning, deep analysis, task decomposition, and intelligent delegation to specialized subagents.
+You are Chiron, the wise centaur from Greek mythology, serving as the main orchestrator in plan and analysis mode. You coordinate specialized subagents and provide high-level guidance without direct execution.
 
 **Your Core Responsibilities:**
-1. Analyze user requests to understand goals, requirements, and context
-2. Create comprehensive plans that break down complex work into atomic, executable tasks
-3. Delegate appropriate work to specialized subagents (Hermes, Athena, Apollo, Calliope)
-4. Use the Question tool to clarify ambiguous requirements before proceeding
-5. Provide guidance and direction while maintaining read-only access to the codebase
-6. Ensure all delegation is purposeful, atomic, and verifiable
+1. Analyze user requests and determine optimal routing to specialized subagents or direct handling
+2. Provide strategic planning and analysis for complex workflows that require multiple agent capabilities
+3. Delegate tasks to appropriate subagents: Hermes (communication), Athena (work knowledge), Apollo (private knowledge), Calliope (writing)
+4. Coordinate multi-step workflows that span multiple domains and require agent collaboration
+5. Offer guidance and decision support for productivity, project management, and knowledge work
+6. Bridge personal and work contexts while maintaining appropriate boundaries between domains
 
-**Planning and Analysis Process:**
-1. **Understand the Request**: Thoroughly analyze what the user wants to accomplish
-   - Identify the core objective
-   - Determine scope and boundaries
-   - Note any constraints or preferences
+**Process:**
+1. **Analyze Request**: Identify the user's intent, required domains (communication, knowledge, writing, or combination), and complexity level
+2. **Clarify Ambiguity**: Use the Question tool when the request is vague, requires context, or needs clarification before proceeding
+3. **Determine Approach**: Decide whether to handle directly, delegate to a single subagent, or orchestrate multiple subagents
+4. **Delegate or Execute**: Route to appropriate subagent(s) with clear context, or provide direct analysis/guidance
+5. **Synthesize Results**: Combine outputs from multiple subagents into coherent recommendations or action plans
+6. **Provide Guidance**: Offer strategic insights, priorities, and next steps based on the analysis
 
-2. **Assess Ambiguity**: Check if requirements are clear enough to proceed
-   - If any aspect is unclear, ambiguous, or missing context, use the Question tool
-   - Never guess or make assumptions about user intent
-   - Ask specific questions that resolve uncertainty
-
-3. **Gather Context**: Read relevant files to understand the current state
-   - Use Read tool to examine code, configuration, and documentation
-   - Check AGENTS.md for conventions and patterns
-   - Review plan files and notepads if available
-   - Maintain read-only access - no modifications allowed
-
-4. **Create a Plan**: Develop a comprehensive, step-by-step approach
-   - Break down work into atomic, single-responsibility tasks
-   - Identify dependencies between tasks
-   - Order tasks logically (dependent tasks first)
-   - Each task should be specific, measurable, and completable
-
-5. **Determine Delegation Strategy**: Decide which subagent handles each task
-   - **Hermes** (work comm): Task and workflow management, beads operations
-   - **Athena** (work knowledge): Public documentation, codebase research, technical exploration
-   - **Apollo** (private knowledge): Private context analysis, user-specific information
-   - **Calliope** (writing): Documentation, prose, technical writing, communication
-   - Match task requirements to subagent capabilities
-   - Only delegate what benefits from specialization
-
-6. **Execute Delegation**: Use delegate_task or call_omo_agent appropriately
-   - Provide clear, specific prompts to each subagent
-   - Include necessary context and constraints
-   - Set run_in_background=true for parallel independent tasks
-   - Use session_id to continue conversations with the same subagent
-
-7. **Monitor and Verify**: Track delegation outcomes and ensure quality
-   - Wait for background tasks to complete
-   - Review results from each subagent
-   - Verify that delegated work meets requirements
-   - Identify any issues or gaps that need addressing
-
-8. **Synthesize and Report**: Combine results and provide clear summary
-   - Present completed work in organized format
-   - Highlight key findings and outcomes
-   - Note any outstanding items or next steps
-   - Ensure the user understands what was accomplished
-
-**Delegation Guidelines:**
-
-**When to Delegate:**
-- Multi-step exploration tasks that can run in parallel
-- Specialized work requiring domain expertise (writing, research, workflow management)
-- Operations that benefit from background execution
-- Tasks requiring tools or skills beyond basic read operations
-
-**When NOT to Delegate:**
-- Simple, single-file reads
-- Quick clarifications or context gathering
-- Work that you can complete faster than delegation overhead
-- Analysis that requires your full understanding of the request
-
-**Subagent Capabilities:**
-- **Hermes**: Beads workflow, task tracking, issue management
-- **Athena**: Code exploration, documentation research, technical analysis
-- **Apollo**: Private context, user-specific data, personalization
-- **Calliope**: Writing, documentation creation, communication refinement
-
-**Question Tool Usage:**
-Use the Question tool whenever:
-- User request is vague or unclear
-- Multiple valid interpretations exist
-- Critical context is missing
-- User preference or direction is needed
-- Risk of wrong assumption exists
+**Delegation Logic:**
+- **Hermes**: Work communication tasks (email drafts, message management, meeting coordination)
+- **Athena**: Work knowledge retrieval (wiki searches, documentation lookup, project information)
+- **Apollo**: Private knowledge management (Obsidian vault access, personal notes, task tracking)
+- **Calliope**: Writing assistance (documentation, reports, meeting summaries, professional prose)
+- **Chiron-Forge**: Execution tasks requiring file modifications, command execution, or direct system changes
 
 **Quality Standards:**
-- Plans are atomic, specific, and unambiguous
-- Every delegated task has clear purpose and expected outcome
-- All ambiguity is resolved before execution begins
-- Delegation is purposeful, not reflexive
-- Results are verified before marking work complete
-- Communication is clear, concise, and actionable
-- Read-only access is strictly maintained (no write/edit operations)
+- Clarify ambiguous requests before proceeding with delegation or analysis
+- Provide clear rationale when delegating to specific subagents
+- Maintain appropriate separation between personal (Apollo) and work (Athena/Hermes) domains
+- Synthesize multi-agent outputs into coherent, actionable guidance
+- Respect permission boundaries (read-only analysis, delegate execution to Chiron-Forge)
+- Offer strategic context alongside tactical recommendations
 
 **Output Format:**
-
-For planning requests:
-## Analysis Summary
-[2-3 sentences of what was understood and what will be done]
-
-## Plan
-1. [Atomic task 1]
-2. [Atomic task 2]
-3. [Continue with specific steps]
-
-## Delegation Strategy
-- [Subagent]: [Task they will handle]
-- [Subagent]: [Task they will handle]
-
-For analysis requests:
-## Analysis Results
-[Findings with specific references and context]
-
-## Key Insights
-[Patterns, issues, opportunities identified]
-
-## Recommendations
-[Actionable suggestions based on analysis]
-
-For completed delegation:
-## Completed Work
-- [Task]: [Result achieved]
-- [Task]: [Result achieved]
-
-## Summary
-[Overall accomplishment and next steps]
+For direct analysis: Provide structured insights with clear reasoning and recommendations
+For delegation: State which subagent is handling the task and why
+For orchestration: Outline the workflow, which agents are involved, and expected outcomes
+Include next steps or decision points when appropriate
 
 **Edge Cases:**
-- **Ambiguous Request**: Use Question tool immediately, don't attempt interpretation
-- **Too Many Tasks**: Prioritize and phase work, don't overwhelm with delegation
-- **Subagent Failure**: Report issue, adjust strategy, retry with different approach
-- **Context Gaps**: Request additional information rather than making assumptions
-- **Complex Dependencies**: Reorder tasks to respect dependencies clearly
-- **No Clear Path**: Ask user for direction or preference before proceeding
+- **Ambiguous requests**: Use Question tool to clarify intent, scope, and preferred approach before proceeding
+- **Cross-domain requests**: Analyze which subagents are needed and delegate in sequence or parallel as appropriate
+- **Personal vs work overlap**: Explicitly maintain boundaries, route personal tasks to Apollo, work tasks to Hermes/Athena
+- **Execution required tasks**: Explain that Chiron-Forge handles execution and offer to delegate
+- **Multiple possible approaches**: Present options with trade-offs and ask for user preference
 
-**Critical Constraints:**
-- NEVER use write, edit, or any modification tools
-- Maintain read-only access at all times
-- Never delegate trivial single-step work
-- Always verify results before considering work complete
-- Never proceed without clarifying ambiguous requirements
-- Question tool is your primary tool for uncertainty resolution
+**Tool Usage:**
+- Question tool: REQUIRED when requests are ambiguous, lack context, or require clarification before delegation or analysis
+- Task tool: Use to delegate to subagents (hermes, athena, apollo, calliope) with clear context and objectives
+- Read/analysis tools: Available for gathering context and providing read-only guidance
 
-Your role is to think deeply, plan thoroughly, delegate intelligently, and guide execution without directly modifying files. You are the strategic mind that ensures work is done correctly, not the hands that do the work.
+**Boundaries:**
+- Do NOT modify files directly (read-only orchestrator mode)
+- Do NOT execute commands or make system changes (delegate to Chiron-Forge)
+- Do NOT handle communication drafting directly (Hermes's domain)
+- Do NOT access work documentation repositories (Athena's domain)
+- Do NOT access private vaults or personal notes (Apollo's domain)
+- Do NOT write long-form content (Calliope's domain)
+- Do NOT execute build or deployment tasks (Chiron-Forge's domain)

prompts/hermes.txt

@@ -0,0 +1,48 @@
+You are Hermes, the Greek god of communication, messengers, and swift transactions, specializing in work communication across Basecamp, Outlook, and Microsoft Teams.
+
+**Your Core Responsibilities:**
+1. Manage Basecamp tasks, projects, and todo items for collaborative work
+2. Draft and send professional emails via Outlook for work-related communication
+3. Schedule and manage Microsoft Teams meetings and channel conversations
+4. Provide quick status updates and task progress reports
+5. Coordinate communication between team members across platforms
+
+**Process:**
+1. **Identify Platform**: Determine which communication tool matches the user's request (Basecamp for tasks/projects, Outlook for email, Teams for meetings/chat)
+2. **Clarify Scope**: Use the Question tool to confirm recipients, project context, or meeting details when ambiguous
+3. **Execute Communication**: Use the appropriate MCP integration (Basecamp, Outlook, or Teams) to perform the action
+4. **Confirm Action**: Provide brief confirmation of what was sent, scheduled, or updated
+5. **Maintain Professionalism**: Ensure all communication adheres to workplace norms and etiquette
+
+**Quality Standards:**
+- Clear and concise messages that respect recipient time
+- Proper platform usage: use the right tool for the right task
+- Professional tone appropriate for workplace communication
+- Accurate meeting details with correct times and participants
+- Consistent follow-up tracking for tasks requiring action
+
+**Output Format:**
+- For Basecamp: Confirm todo created/updated, message posted, or card moved
+- For Outlook: Confirm email sent with subject line and recipient count
+- For Teams: Confirm meeting scheduled with date/time or message posted in channel
+- Brief status updates without unnecessary elaboration
+
+**Edge Cases:**
+- **Multiple platforms referenced**: Use Question to confirm which platform to use
+- **Unclear recipient**: Ask for specific names, email addresses, or team details
+- **Urgent communication**: Flag high-priority items appropriately
+- **Conflicting schedules**: Propose alternative meeting times when conflicts arise
+- **Sensitive content**: Verify appropriateness before sending to broader audiences
+
+**Tool Usage:**
+- Question tool: Required when platform choice is ambiguous or recipients are unclear
+- Basecamp MCP: For project tasks, todos, message board posts, campfire messages
+- Outlook MCP: For email drafting, sending, inbox management
+- Teams MCP: For meeting scheduling, channel messages, chat conversations
+
+**Boundaries:**
+- Do NOT handle documentation repositories or wiki knowledge (Athena's domain)
+- Do NOT access personal tools or private knowledge systems (Apollo's domain)
+- Do NOT write long-form content like reports or detailed documentation (Calliope's domain)
+- Do NOT execute code or perform technical tasks outside communication workflows
+- Do NOT share sensitive information inappropriately across platforms

rules/USAGE.md

@@ -0,0 +1,62 @@
+# Opencode Rules Usage
+
+Add AI coding rules to your project via `mkOpencodeRules`.
+
+## flake.nix Setup
+
+```nix
+{
+  inputs = {
+    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
+    m3ta-nixpkgs.url = "git+https://code.m3ta.dev/m3tam3re/nixpkgs";
+    agents = {
+      url = "git+https://code.m3ta.dev/m3tam3re/AGENTS";
+      flake = false;
+    };
+  };
+
+  outputs = { self, nixpkgs, m3ta-nixpkgs, agents, ... }:
+    let
+      system = "x86_64-linux";
+      pkgs = nixpkgs.legacyPackages.${system};
+      m3taLib = m3ta-nixpkgs.lib.${system};
+    in {
+      devShells.${system}.default = let
+        rules = m3taLib.opencode-rules.mkOpencodeRules {
+          inherit agents;
+          languages = [ "python" "typescript" ];
+          frameworks = [ "n8n" ];
+        };
+      in pkgs.mkShell {
+        shellHook = rules.shellHook;
+      };
+    };
+}
+```
+
+## Parameters
+
+- `agents` (required): Path to AGENTS repo flake input
+- `languages` (optional): List of language names (e.g., `["python" "typescript"]`)
+- `concerns` (optional): Rule categories (default: all standard concerns)
+- `frameworks` (optional): List of framework names (e.g., `["n8n" "django"]`)
+- `extraInstructions` (optional): Additional instruction file paths
+
+## .gitignore
+
+Add to your project's `.gitignore`:
+```
+.opencode-rules
+opencode.json
+```
+
+## Project Overrides
+
+Create `AGENTS.md` in your project root to override central rules. OpenCode applies project-level rules with precedence over central ones.
+
+## Updating Rules
+
+When central rules are updated:
+```bash
+nix flake update agents
+```

rules/concerns/coding-style.md

@@ -0,0 +1,163 @@
+# Coding Style
+
+## Critical Rules (MUST follow)
+
+Always prioritize readability over cleverness. Never write code that requires mental gymnastics to understand.
+Always fail fast and explicitly. Never silently swallow errors or hide exceptions.
+Always keep functions under 20 lines. Never create monolithic functions that do multiple things.
+Always validate inputs at function boundaries. Never trust external data implicitly.
+
+## Formatting
+
+Prefer consistent indentation throughout the codebase. Never mix tabs and spaces.
+Prefer meaningful variable names over short abbreviations. Never use single letters except for loop counters.
+
+### Correct:
+```lang
+const maxRetryAttempts = 3;
+const connectionTimeout = 5000;
+
+for (let attempt = 1; attempt <= maxRetryAttempts; attempt++) {
+    // process attempt
+}
+```
+
+### Incorrect:
+```lang
+const m = 3;
+const t = 5000;
+
+for (let i = 1; i <= m; i++) {
+    // process attempt
+}
+```
+
+## Patterns and Anti-Patterns
+
+Never repeat yourself. Always extract duplicated logic into reusable functions.
+Prefer composition over inheritance. Never create deep inheritance hierarchies.
+Always use guard clauses to reduce nesting. Never write arrow-shaped code.
+
+### Correct:
+```lang
+def process_user(user):
+    if not user:
+        return None
+    if not user.is_active:
+        return None
+    return user.calculate_score()
+```
+
+### Incorrect:
+```lang
+def process_user(user):
+    if user:
+        if user.is_active:
+            return user.calculate_score()
+        else:
+            return None
+    else:
+        return None
+```
+
+## Error Handling
+
+Always handle specific exceptions. Never use broad catch-all exception handlers.
+Always log error context, not just the error message. Never let errors vanish without trace.
+
+### Correct:
+```lang
+try:
+    data = fetch_resource(url)
+    return parse_data(data)
+except NetworkError as e:
+    log_error(f"Network failed for {url}: {e}")
+    raise
+except ParseError as e:
+    log_error(f"Parse failed for {url}: {e}")
+    return fallback_data
+```
+
+### Incorrect:
+```lang
+try:
+    data = fetch_resource(url)
+    return parse_data(data)
+except Exception:
+    pass
+```
+
+## Type Safety
+
+Always use type annotations where supported. Never rely on implicit type coercion.
+Prefer explicit type checks over duck typing for public APIs. Never assume type behavior.
+
+### Correct:
+```lang
+function calculateTotal(price: number, quantity: number): number {
+    return price * quantity;
+}
+```
+
+### Incorrect:
+```lang
+function calculateTotal(price, quantity) {
+    return price * quantity;
+}
+```
+
+## Function Design
+
+Always write pure functions when possible. Never mutate arguments unless required.
+Always limit function parameters to 3 or fewer. Never pass objects to hide parameter complexity.
+
+### Correct:
+```lang
+def create_user(name: str, email: str) -> User:
+    return User(name=name, email=email, created_at=now())
+```
+
+### Incorrect:
+```lang
+def create_user(config: dict) -> User:
+    return User(
+        name=config['name'],
+        email=config['email'],
+        created_at=config['timestamp']
+    )
+```
+
+## SOLID Principles
+
+Never let classes depend on concrete implementations. Always depend on abstractions.
+Always ensure classes are open for extension but closed for modification. Never change working code to add features.
+Prefer many small interfaces over one large interface. Never force clients to depend on methods they don't use.
+
+### Correct:
+```lang
+class EmailSender {
+    send(message: Message): void {
+        // implementation
+    }
+}
+
+class NotificationService {
+    constructor(private sender: EmailSender) {}
+}
+```
+
+### Incorrect:
+```lang
+class NotificationService {
+    sendEmail(message: Message): void { }
+    sendSMS(message: Message): void { }
+    sendPush(message: Message): void { }
+}
+```
+
+## Critical Rules (REPEAT)
+
+Always write self-documenting code. Never rely on comments to explain complex logic.
+Always refactor when you see code smells. Never let technical debt accumulate.
+Always test edge cases explicitly. Never assume happy path only behavior.
+Never commit commented-out code. Always remove it or restore it.

rules/concerns/documentation.md

@@ -0,0 +1,149 @@
+# Documentation Rules
+
+## When to Document
+
+**Document public APIs**. Every public function, class, method, and module needs documentation. Users need to know how to use your code.
+**Document complex logic**. Algorithms, state machines, and non-obvious implementations need explanations. Future readers will thank you.
+**Document business rules**. Encode domain knowledge directly in comments. Don't make anyone reverse-engineer requirements from code.
+**Document trade-offs**. When you choose between alternatives, explain why. Help future maintainers understand the decision context.
+**Do NOT document obvious code**. Comments like `// get user` add noise. Delete them.
+
+## Docstring Formats
+
+### Python (Google Style)
+
+```python
+def calculate_price(quantity: int, unit_price: float, discount: float = 0.0) -> float:
+    """Calculate total price after discount.
+    Args:
+        quantity: Number of items ordered.
+        unit_price: Price per item in USD.
+        discount: Decimal discount rate (0.0 to 1.0).
+    Returns:
+        Final price in USD.
+    Raises:
+        ValueError: If quantity is negative.
+    """
+```
+
+### JavaScript/TypeScript (JSDoc)
+
+```javascript
+/**
+ * Validates user input against security rules.
+ * @param {string} input - Raw user input from form.
+ * @param {Object} rules - Validation constraints.
+ * @param {number} rules.maxLength - Maximum allowed length.
+ * @returns {boolean} True if input passes all rules.
+ * @throws {ValidationError} If input violates security constraints.
+ */
+function validateInput(input, rules) {
+```
+
+### Bash
+
+```bash
+#!/usr/bin/env bash
+# Deploy application to production environment.
+#
+# Usage: ./deploy.sh [environment]
+#
+# Args:
+#   environment: Target environment (staging|production). Default: staging.
+#
+# Exits:
+#   0 on success, 1 on deployment failure.
+```
+
+## Inline Comments: WHY Not WHAT
+
+**Incorrect:**
+```python
+# Iterate through all users
+for user in users:
+    # Check if user is active
+    if user.active:
+        # Increment counter
+        count += 1
+```
+
+**Correct:**
+```python
+# Count only active users to calculate monthly revenue
+for user in users:
+    if user.active:
+        count += 1
+```
+
+**Incorrect:**
+```javascript
+// Set timeout to 5000
+setTimeout(() => {
+  // Show error message
+  alert('Error');
+}, 5000);
+```
+
+**Correct:**
+```javascript
+// 5000ms delay prevents duplicate alerts during rapid retries
+setTimeout(() => {
+  alert('Error');
+}, 5000);
+```
+
+**Incorrect:**
+```bash
+# Remove temporary files
+rm -rf /tmp/app/*
+```
+
+**Correct:**
+```bash
+# Clear temp directory before batch import to prevent partial state
+rm -rf /tmp/app/*
+```
+
+**Rule:** Describe the intent and context. Never describe what the code obviously does.
+
+## README Standards
+
+Every project needs a README at the top level.
+
+**Required sections:**
+1. **What it does** - One sentence summary
+2. **Installation** - Setup commands
+3. **Usage** - Basic example
+4. **Configuration** - Environment variables and settings
+5. **Contributing** - How to contribute
+
+**Example structure:**
+
+```markdown
+# Project Name
+
+One-line description of what this project does.
+
+## Installation
+```bash
+npm install
+```
+
+## Usage
+```bash
+npm start
+```
+
+## Configuration
+
+Create `.env` file:
+```
+API_KEY=your_key_here
+```
+
+## Contributing
+
+See [CONTRIBUTING.md](./CONTRIBUTING.md).
+```
+
+**Keep READMEs focused**. Link to separate docs for complex topics. Don't make the README a tutorial.

rules/concerns/git-workflow.md

@@ -0,0 +1,118 @@
+# Git Workflow Rules
+
+## Conventional Commits
+
+Format: `<type>(<scope>): <subject>`
+
+### Commit Types
+
+- **feat**: New feature
+  - `feat(auth): add OAuth2 login flow`
+  - `feat(api): expose user endpoints`
+
+- **fix**: Bug fix
+  - `fix(payment): resolve timeout on Stripe calls`
+  - `fix(ui): button not clickable on mobile`
+
+- **refactor**: Code refactoring (no behavior change)
+  - `refactor(utils): extract date helpers`
+  - `refactor(api): simplify error handling`
+
+- **docs**: Documentation only
+  - `docs(readme): update installation steps`
+  - `docs(api): add endpoint examples`
+
+- **chore**: Maintenance tasks
+  - `chore(deps): update Node to 20`
+  - `chore(ci): add GitHub actions workflow`
+
+- **test**: Tests only
+  - `test(auth): add unit tests for login`
+  - `test(e2e): add checkout flow tests`
+
+- **style**: Formatting, no logic change
+  - `style: sort imports alphabetically`
+
+### Commit Rules
+
+- Subject max 72 chars
+- Imperative mood ("add", not "added")
+- No period at end
+- Reference issues: `Closes #123`
+
+## Branch Naming
+
+Pattern: `<type>/<short-description>`
+
+### Branch Types
+
+- `feature/add-user-dashboard`
+- `feature/enable-dark-mode`
+- `fix/login-redirect-loop`
+- `fix/payment-timeout-error`
+- `refactor/extract-user-service`
+- `refactor/simplify-auth-flow`
+- `hotfix/security-vulnerability`
+
+### Branch Rules
+
+- Lowercase and hyphens
+- Max 50 chars
+- Delete after merge
+
+## Pull Requests
+
+### PR Title
+
+Follow Conventional Commit format:
+- `feat: add user dashboard`
+- `fix: resolve login redirect loop`
+
+### PR Description
+
+```markdown
+## What
+Brief description
+
+## Why
+Reason for change
+
+## How
+Implementation approach
+
+## Testing
+Steps performed
+
+## Checklist
+- [ ] Tests pass
+- [ ] Code reviewed
+- [ ] Docs updated
+```
+
+## Merge Strategy
+
+### Squash Merge
+
+- Many small commits
+- One cohesive feature
+- Clean history
+
+### Merge Commit
+
+- Preserve commit history
+- Distinct milestones
+- Detailed history preferred
+
+### When to Rebase
+
+- Before opening PR
+- Resolving conflicts
+- Keeping current with main
+
+## General Rules
+
+- Pull latest from main before starting
+- Write atomic commits
+- Run tests before pushing
+- Request peer review before merge
+- Never force push to main/master

rules/concerns/naming.md

@@ -0,0 +1,105 @@
+# Naming Conventions
+
+Use consistent naming across all code. Follow language-specific conventions.
+
+## Language Reference
+
+| Type | Python | TypeScript | Nix | Shell |
+|------|--------|------------|-----|-------|
+| Variables | snake_case | camelCase | camelCase | UPPER_SNAKE |
+| Functions | snake_case | camelCase | camelCase | lower_case |
+| Classes | PascalCase | PascalCase | - | - |
+| Constants | UPPER_SNAKE | UPPER_SNAKE | camelCase | UPPER_SNAKE |
+| Files | snake_case | camelCase | hyphen-case | hyphen-case |
+| Modules | snake_case | camelCase | - | - |
+
+## General Rules
+
+**Files**: Use hyphen-case for documentation, snake_case for Python, camelCase for TypeScript. Names should describe content.
+
+**Variables**: Use descriptive names. Avoid single letters except loop counters. No Hungarian notation.
+
+**Functions**: Use verb-noun pattern. Name describes what it does, not how it does it.
+
+**Classes**: Use PascalCase with descriptive nouns. Avoid abbreviations.
+
+**Constants**: Use UPPER_SNAKE with descriptive names. Group related constants.
+
+## Examples
+
+Python:
+```python
+# Variables
+user_name = "alice"
+is_authenticated = True
+
+# Functions
+def get_user_data(user_id):
+    pass
+
+# Classes
+class UserProfile:
+    pass
+
+# Constants
+MAX_RETRIES = 3
+API_ENDPOINT = "https://api.example.com"
+```
+
+TypeScript:
+```typescript
+// Variables
+const userName = "alice";
+const isAuthenticated = true;
+
+// Functions
+function getUserData(userId: string): User {
+    return null;
+}
+
+// Classes
+class UserProfile {
+    private name: string;
+}
+
+// Constants
+const MAX_RETRIES = 3;
+const API_ENDPOINT = "https://api.example.com";
+```
+
+Nix:
+```nix
+# Variables
+let
+  userName = "alice";
+  isAuthenticated = true;
+in
+# ...
+```
+
+Shell:
+```bash
+# Variables
+USER_NAME="alice"
+IS_AUTHENTICATED=true
+
+# Functions
+get_user_data() {
+    echo "Getting data"
+}
+
+# Constants
+MAX_RETRIES=3
+API_ENDPOINT="https://api.example.com"
+```
+
+## File Naming
+
+Use these patterns consistently. No exceptions.
+
+- Skills: `hyphen-case`
+- Python: `snake_case.py`
+- TypeScript: `camelCase.ts` or `hyphen-case.ts`
+- Nix: `hyphen-case.nix`
+- Shell: `hyphen-case.sh`
+- Markdown: `UPPERCASE.md` or `sentence-case.md`

rules/concerns/project-structure.md

@@ -0,0 +1,82 @@
+# Project Structure
+
+## Python
+
+Use src layout for all projects. Place application code in `src/<project>/`, tests in `tests/`.
+
+```
+project/
+├── src/myproject/
+│   ├── __init__.py
+│   ├── main.py          # Entry point
+│   └── core/
+│       └── module.py
+├── tests/
+│   ├── __init__.py
+│   └── test_module.py
+├── pyproject.toml       # Config
+├── README.md
+└── .gitignore
+```
+
+**Rules:**
+- One module per directory file
+- `__init__.py` in every package
+- Entry point in `src/myproject/main.py`
+- Config in root: `pyproject.toml`, `requirements.txt`
+
+## TypeScript
+
+Use `src/` for source, `dist/` for build output.
+
+```
+project/
+├── src/
+│   ├── index.ts         # Entry point
+│   ├── core/
+│   │   └── module.ts
+│   └── types.ts
+├── tests/
+│   └── module.test.ts
+├── package.json         # Config
+├── tsconfig.json
+└── README.md
+```
+
+**Rules:**
+- One module per file
+- Index exports from `src/index.ts`
+- Entry point in `src/index.ts`
+- Config in root: `package.json`, `tsconfig.json`
+
+## Nix
+
+Use `modules/` for NixOS modules, `pkgs/` for packages.
+
+```
+nix-config/
+├── modules/
+│   ├── default.nix      # Module list
+│   └── my-service.nix
+├── pkgs/
+│   └── my-package/
+│       └── default.nix
+├── flake.nix            # Entry point
+├── flake.lock
+└── README.md
+```
+
+**Rules:**
+- One module per file in `modules/`
+- One package per directory in `pkgs/`
+- Entry point in `flake.nix`
+- Config in root: `flake.nix`, shell.nix
+
+## General
+
+- Use hyphen-case for directories
+- Use kebab-case for file names
+- Config files in project root
+- Tests separate from source
+- Docs in root: README.md, CHANGELOG.md
+- Hidden configs: .env, .gitignore

rules/concerns/tdd.md

@@ -0,0 +1,476 @@
+# Test-Driven Development (Strict Enforcement)
+
+## Critical Rules (MUST follow)
+
+**NEVER write production code without a failing test first.**
+**ALWAYS follow the red-green-refactor cycle. No exceptions.**
+**NEVER skip the refactor step. Code quality is mandatory.**
+**ALWAYS commit after green, never commit red tests.**
+
+---
+
+## The Red-Green-Refactor Cycle
+
+### Phase 1: Red (Write Failing Test)
+
+The test MUST fail for the right reason—not a syntax error or missing import.
+
+```python
+# CORRECT: Test fails because behavior doesn't exist yet
+def test_calculate_discount_for_premium_members():
+    user = User(tier="premium")
+    cart = Cart(items=[Item(price=100)])
+    
+    discount = calculate_discount(user, cart)
+    
+    assert discount == 10  # Fails: calculate_discount not implemented
+
+# INCORRECT: Test fails for wrong reason (will pass accidentally)
+def test_calculate_discount():
+    discount = calculate_discount()  # Fails: missing required args
+    assert discount is not None
+```
+
+**Red Phase Checklist:**
+- [ ] Test describes ONE behavior
+- [ ] Test name clearly states expected outcome
+- [ ] Test fails for the intended reason
+- [ ] Error message is meaningful
+
+### Phase 2: Green (Write Minimum Code)
+
+Write the MINIMUM code to make the test pass. Do not implement future features.
+
+```python
+# CORRECT: Minimum implementation
+def calculate_discount(user, cart):
+    if user.tier == "premium":
+        return 10
+    return 0
+
+# INCORRECT: Over-engineering for future needs
+def calculate_discount(user, cart):
+    discounts = {
+        "premium": 10,
+        "gold": 15,      # Not tested
+        "silver": 5,     # Not tested
+        "basic": 0       # Not tested
+    }
+    return discounts.get(user.tier, 0)
+```
+
+**Green Phase Checklist:**
+- [ ] Code makes the test pass
+- [ ] No extra functionality added
+- [ ] Code may be ugly (refactor comes next)
+- [ ] All existing tests still pass
+
+### Phase 3: Refactor (Improve Code Quality)
+
+Refactor ONLY when all tests are green. Make small, incremental changes.
+
+```python
+# BEFORE (Green but messy)
+def calculate_discount(user, cart):
+    if user.tier == "premium":
+        return 10
+    return 0
+
+# AFTER (Refactored)
+DISCOUNT_RATES = {"premium": 0.10}
+
+def calculate_discount(user, cart):
+    rate = DISCOUNT_RATES.get(user.tier, 0)
+    return int(cart.total * rate)
+```
+
+**Refactor Phase Checklist:**
+- [ ] All tests still pass after each change
+- [ ] One refactoring at a time
+- [ ] Commit if significant improvement made
+- [ ] No behavior changes (tests remain green)
+
+---
+
+## Enforcement Rules
+
+### 1. Test-First Always
+
+```python
+# WRONG: Code first, test later
+class PaymentProcessor:
+    def process(self, amount):
+        return self.gateway.charge(amount)
+
+# Then write test... (TOO LATE!)
+
+# CORRECT: Test first
+def test_process_payment_charges_gateway():
+    mock_gateway = MockGateway()
+    processor = PaymentProcessor(gateway=mock_gateway)
+    
+    processor.process(100)
+    
+    assert mock_gateway.charged_amount == 100
+```
+
+### 2. No Commented-Out Tests
+
+```python
+# WRONG: Commented test hides failing behavior
+# def test_refund_processing():
+#     # TODO: fix this later
+#     assert False
+
+# CORRECT: Use skip with reason
+@pytest.mark.skip(reason="Refund flow not yet implemented")
+def test_refund_processing():
+    assert False
+```
+
+### 3. Commit Hygiene
+
+```bash
+# WRONG: Committing with failing tests
+git commit -m "WIP: adding payment"
+# Tests fail in CI
+
+# CORRECT: Only commit green
+git commit -m "Add payment processing"
+# All tests pass locally and in CI
+```
+
+---
+
+## AI-Assisted TDD Patterns
+
+### Pattern 1: Explicit Test Request
+
+When working with AI assistants, request tests explicitly:
+
+```
+CORRECT PROMPT:
+"Write a failing test for calculating user discounts based on tier.
+Then implement the minimum code to make it pass."
+
+INCORRECT PROMPT:
+"Implement a discount calculator with tier support."
+```
+
+### Pattern 2: Verification Request
+
+After AI generates code, verify test coverage:
+
+```
+PROMPT:
+"The code you wrote for calculate_discount is missing tests.
+First, show me a failing test for the edge case where cart is empty.
+Then make it pass with minimum code."
+```
+
+### Pattern 3: Refactor Request
+
+Request refactoring as a separate step:
+
+```
+CORRECT:
+"Refactor calculate_discount to use a lookup table.
+Run tests after each change."
+
+INCORRECT:
+"Refactor and add new features at the same time."
+```
+
+### Pattern 4: Red-Green-Refactor in Prompts
+
+Structure AI prompts to follow the cycle:
+
+```
+PROMPT TEMPLATE:
+"Phase 1 (Red): Write a test that [describes behavior]. 
+The test should fail because [reason].
+Show me the failing test output.
+
+Phase 2 (Green): Write the minimum code to pass this test.
+No extra features.
+
+Phase 3 (Refactor): Review the code. Suggest improvements.
+I'll approve before you apply changes."
+```
+
+### AI Anti-Patterns to Avoid
+
+```python
+# ANTI-PATTERN: AI generates code without tests
+# User: "Create a user authentication system"
+# AI generates 200 lines of code with no tests
+
+# CORRECT APPROACH:
+# User: "Let's build authentication with TDD.
+# First, write a failing test for successful login."
+
+# ANTI-PATTERN: AI generates tests after implementation
+# User: "Write tests for this code"
+# AI writes tests that pass trivially (not TDD)
+
+# CORRECT APPROACH:
+# User: "I need a new feature. Write the failing test first."
+```
+
+---
+
+## Legacy Code Strategy
+
+### 1. Characterization Tests First
+
+Before modifying legacy code, capture existing behavior:
+
+```python
+def test_legacy_calculate_price_characterization():
+    """
+    This test documents existing behavior, not desired behavior.
+    Do not change expected values without understanding impact.
+    """
+    # Given: Current production inputs
+    order = Order(items=[Item(price=100, quantity=2)])
+    
+    # When: Execute legacy code
+    result = legacy_calculate_price(order)
+    
+    # Then: Capture ACTUAL output (even if wrong)
+    assert result == 215  # Includes mystery 7.5% surcharge
+```
+
+### 2. Strangler Fig Pattern
+
+```python
+# Step 1: Write test for new behavior
+def test_calculate_price_with_new_algorithm():
+    order = Order(items=[Item(price=100, quantity=2)])
+    result = calculate_price_v2(order)
+    assert result == 200  # No mystery surcharge
+
+# Step 2: Implement new code with TDD
+def calculate_price_v2(order):
+    return sum(item.price * item.quantity for item in order.items)
+
+# Step 3: Route new requests to new code
+def calculate_price(order):
+    if order.use_new_pricing:
+        return calculate_price_v2(order)
+    return legacy_calculate_price(order)
+
+# Step 4: Gradually migrate, removing legacy path
+```
+
+### 3. Safe Refactoring Sequence
+
+```python
+# 1. Add characterization tests
+# 2. Extract method (tests stay green)
+# 3. Add unit tests for extracted method
+# 4. Refactor extracted method with TDD
+# 5. Inline or delete old method
+```
+
+---
+
+## Integration Test TDD
+
+### Outside-In (London School)
+
+```python
+# 1. Write acceptance test (fails end-to-end)
+def test_user_can_complete_purchase():
+    user = create_user()
+    add_item_to_cart(user, item)
+    
+    result = complete_purchase(user)
+    
+    assert result.status == "success"
+    assert user.has_receipt()
+
+# 2. Drop down to unit test for first component
+def test_cart_calculates_total():
+    cart = Cart()
+    cart.add(Item(price=100))
+    
+    assert cart.total == 100
+
+# 3. Implement with TDD, working inward
+```
+
+### Contract Testing
+
+```python
+# Provider contract test
+def test_payment_api_contract():
+    """External services must match this contract."""
+    response = client.post("/payments", json={
+        "amount": 100,
+        "currency": "USD"
+    })
+    
+    assert response.status_code == 201
+    assert "transaction_id" in response.json()
+
+# Consumer contract test
+def test_payment_gateway_contract():
+    """We expect the gateway to return transaction IDs."""
+    mock_gateway = MockPaymentGateway()
+    mock_gateway.expect_charge(amount=100).and_return(
+        transaction_id="tx_123"
+    )
+    
+    result = process_payment(mock_gateway, amount=100)
+    
+    assert result.transaction_id == "tx_123"
+```
+
+---
+
+## Refactoring Rules
+
+### Rule 1: Refactor Only When Green
+
+```python
+# WRONG: Refactoring with failing test
+def test_new_feature():
+    assert False  # Failing
+
+def existing_code():
+    # Refactoring here is DANGEROUS
+    pass
+
+# CORRECT: All tests pass before refactoring
+def existing_code():
+    # Safe to refactor now
+    pass
+```
+
+### Rule 2: One Refactoring at a Time
+
+```python
+# WRONG: Multiple refactorings at once
+def process_order(order):
+    # Changed: variable name
+    # Changed: extracted method
+    # Changed: added caching
+    # Which broke it? Who knows.
+    pass
+
+# CORRECT: One change, test, commit
+# Commit 1: Rename variable
+# Commit 2: Extract method  
+# Commit 3: Add caching
+```
+
+### Rule 3: Baby Steps
+
+```python
+# WRONG: Large refactoring
+# Before: 500-line monolith
+# After: 10 new classes
+# Risk: Too high
+
+# CORRECT: Extract one method at a time
+# Step 1: Extract calculate_total (commit)
+# Step 2: Extract validate_items (commit)
+# Step 3: Extract apply_discounts (commit)
+```
+
+---
+
+## Test Quality Gates
+
+### Pre-Commit Hooks
+
+```bash
+#!/bin/bash
+# .git/hooks/pre-commit
+
+# Run fast unit tests
+uv run pytest tests/unit -x -q || exit 1
+
+# Check test coverage threshold
+uv run pytest --cov=src --cov-fail-under=80 || exit 1
+```
+
+### CI/CD Requirements
+
+```yaml
+# .github/workflows/test.yml
+- name: Run Tests
+  run: |
+    pytest --cov=src --cov-report=xml --cov-fail-under=80
+    
+- name: Check Test Quality
+  run: |
+    # Fail if new code lacks tests
+    diff-cover coverage.xml --fail-under=80
+```
+
+### Code Review Checklist
+
+```markdown
+## TDD Verification
+- [ ] New code has corresponding tests
+- [ ] Tests were written FIRST (check commit order)
+- [ ] Each test tests ONE behavior
+- [ ] Test names describe the scenario
+- [ ] No commented-out or skipped tests without reason
+- [ ] Coverage maintained or improved
+```
+
+---
+
+## When TDD Is Not Appropriate
+
+TDD may be skipped ONLY for:
+
+### 1. Exploratory Prototypes
+
+```python
+# prototype.py - Delete after learning
+# No tests needed for throwaway exploration
+def quick_test_api():
+    response = requests.get("https://api.example.com")
+    print(response.json())
+```
+
+### 2. One-Time Scripts
+
+```python
+# migrate_data.py - Run once, discard
+# Tests would cost more than value provided
+```
+
+### 3. Trivial Changes
+
+```python
+# Typo fix or comment change
+# No behavior change = no new test needed
+```
+
+**If unsure, write the test.**
+
+---
+
+## Quick Reference
+
+| Phase   | Rule                                    | Check                              |
+|---------|-----------------------------------------|-------------------------------------|
+| Red     | Write failing test first                | Test fails for right reason        |
+| Green   | Write minimum code to pass              | No extra features                  |
+| Refactor| Improve code while tests green          | Run tests after each change        |
+| Commit  | Only commit green tests                 | All tests pass in CI               |
+
+## TDD Mantra
+
+```
+Red. Green. Refactor. Commit. Repeat.
+
+No test = No code.
+No green = No commit.
+No refactor = Technical debt.
+```

rules/concerns/testing.md

@@ -0,0 +1,134 @@
+# Testing Rules
+
+## Arrange-Act-Assert Pattern
+
+Structure every test in three distinct phases:
+
+```python
+# Arrange: Set up the test data and conditions
+user = User(name="Alice", role="admin")
+session = create_test_session(user.id)
+
+# Act: Execute the behavior under test
+result = grant_permission(session, "read_documents")
+
+# Assert: Verify the expected outcome
+assert result.granted is True
+assert result.permissions == ["read_documents"]
+```
+
+Never mix phases. Comment each phase clearly for complex setups. Keep Act phase to one line if possible.
+
+## Behavior vs Implementation Testing
+
+Test behavior, not implementation details:
+
+```python
+# GOOD: Tests the observable behavior
+def test_user_can_login():
+    response = login("alice@example.com", "password123")
+    assert response.status_code == 200
+    assert "session_token" in response.cookies
+
+# BAD: Tests internal implementation
+def test_login_sets_database_flag():
+    login("alice@example.com", "password123")
+    user = User.get(email="alice@example.com")
+    assert user._logged_in_flag is True  # Private field
+```
+
+Focus on inputs and outputs. Test public contracts. Refactor internals freely without breaking tests.
+
+## Mocking Philosophy
+
+Mock external dependencies, not internal code:
+
+```python
+# GOOD: Mock external services
+@patch("requests.post")
+def test_sends_notification_to_slack(mock_post):
+    send_notification("Build complete!")
+    mock_post.assert_called_once_with(
+        "https://slack.com/api/chat.postMessage",
+        json={"text": "Build complete!"}
+    )
+
+# BAD: Mock internal methods
+@patch("NotificationService._format_message")
+def test_notification_formatting(mock_format):
+    # Don't mock private methods
+    send_notification("Build complete!")
+```
+
+Mock when:
+- Dependency is slow (database, network, file system)
+- Dependency is unreliable (external APIs)
+- Dependency is expensive (third-party services)
+
+Don't mock when:
+- Testing the dependency itself
+- The dependency is fast and stable
+- The mock becomes more complex than real implementation
+
+## Coverage Expectations
+
+Write tests for:
+- Critical business logic (aim for 90%+)
+- Edge cases and error paths (aim for 80%+)
+- Public APIs and contracts (aim for 100%)
+
+Don't obsess over:
+- Trivial getters/setters
+- Generated code
+- One-line wrappers
+
+Coverage is a floor, not a ceiling. A test suite at 100% coverage that doesn't verify behavior is worthless.
+
+## Test-Driven Development
+
+Follow the red-green-refactor cycle:
+1. Red: Write failing test for new behavior
+2. Green: Write minimum code to pass
+3. Refactor: improve code while tests stay green
+
+Write tests first for new features. Write tests after for bug fixes. Never refactor without tests.
+
+## Test Organization
+
+Group tests by feature or behavior, not by file structure. Name tests to describe the scenario:
+
+```python
+class TestUserAuthentication:
+    def test_valid_credentials_succeeds(self):
+        pass
+
+    def test_invalid_credentials_fails(self):
+        pass
+
+    def test_locked_account_fails(self):
+        pass
+```
+
+Each test should stand alone. Avoid shared state between tests. Use fixtures or setup methods to reduce duplication.
+
+## Test Data
+
+Use realistic test data that reflects production scenarios:
+
+```python
+# GOOD: Realistic values
+user = User(
+    email="alice@example.com",
+    name="Alice Smith",
+    age=28
+)
+
+# BAD: Placeholder values
+user = User(
+    email="test@test.com",
+    name="Test User",
+    age=999
+)
+```
+
+Avoid magic strings and numbers. Use named constants for expected values that change often.

rules/frameworks/n8n.md

@@ -0,0 +1,42 @@
+# n8n Workflow Automation Rules
+
+## Workflow Design
+- Start with a clear trigger: Webhook, Schedule, or Event source
+- Keep workflows under 20 nodes for maintainability
+- Group related logic with sub-workflows
+- Use the "Switch" node for conditional branching
+- Add "Wait" nodes between rate-limited API calls
+
+## Node Naming
+- Use verb-based names: `Fetch Users`, `Transform Data`, `Send Email`
+- Prefix data nodes: `Get_`, `Set_`, `Update_`
+- Prefix conditionals: `Check_`, `If_`, `When_`
+- Prefix actions: `Send_`, `Create_`, `Delete_`
+- Add version suffix to API nodes: `API_v1_Users`
+
+## Error Handling
+- Always add an Error Trigger node
+- Route errors to a "Notify Failure" branch
+- Log error details: `$json.error.message`, `$json.node.name`
+- Send alerts on critical failures
+- Add "Continue On Fail" for non-essential nodes
+
+## Data Flow
+- Use "Set" nodes to normalize output structure
+- Reference previous nodes: `{{ $json.field }}`
+- Use "Merge" node to combine multiple data sources
+- Apply "Code" node for complex transformations
+- Clean data before sending to external APIs
+
+## Credential Security
+- Store all secrets in n8n credentials manager
+- Never hardcode API keys or tokens
+- Use environment-specific credential sets
+- Rotate credentials regularly
+- Limit credential scope to minimum required permissions
+
+## Testing
+- Test each node independently with "Execute Node"
+- Verify data structure at each step
+- Mock external dependencies during development
+- Log workflow execution for debugging

rules/languages/nix.md

@@ -0,0 +1,129 @@
+# Nix Code Conventions
+
+## Formatting
+
+- Use `alejandra` for formatting
+- camelCase for variables, `PascalCase` for types
+- 2 space indentation (alejandra default)
+- No trailing whitespace
+
+## Flake Structure
+
+```nix
+{
+  description = "Description here";
+  inputs = {
+    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+    flake-utils.url = "github:numtide/flake-utils";
+  };
+  outputs = { self, nixpkgs, flake-utils, ... }:
+    flake-utils.lib.eachDefaultSystem (system:
+      let
+        pkgs = nixpkgs.legacyPackages.${system};
+      in {
+        packages.default = pkgs.hello;
+        devShells.default = pkgs.mkShell {
+          buildInputs = [ pkgs.hello ];
+        };
+      }
+    );
+}
+```
+
+## Module Patterns
+
+Standard module function signature:
+
+```nix
+{ config, lib, pkgs, ... }:
+{
+  options.myService.enable = lib.mkEnableOption "my service";
+  config = lib.mkIf config.myService.enable {
+    services.myService.enable = true;
+  };
+}
+```
+
+## Conditionals and Merging
+
+- Use `mkIf` for conditional config
+- Use `mkMerge` to combine multiple config sets
+- Use `mkOptionDefault` for defaults that can be overridden
+
+```nix
+config = lib.mkMerge [
+  (lib.mkIf cfg.enable { ... })
+  (lib.mkIf cfg.extraConfig { ... })
+];
+```
+
+## Anti-Patterns (AVOID)
+
+### `with pkgs;`
+Bad: Pollutes namespace, hard to trace origins
+```nix
+{ pkgs, ... }:
+{
+  packages = with pkgs; [ vim git ];
+}
+```
+
+Good: Explicit references
+```nix
+{ pkgs, ... }:
+{
+  packages = [ pkgs.vim pkgs.git ];
+}
+```
+
+### `builtins.fetchTarball`
+Use flake inputs instead. `fetchTarball` is non-reproducible.
+
+### Impure operations
+Avoid `import <nixpkgs>` in flakes. Always use inputs.
+
+### `builtins.getAttr` / `builtins.hasAttr`
+Use `lib.attrByPath` or `lib.optionalAttrs` instead.
+
+## Home Manager Patterns
+
+```nix
+{ config, pkgs, lib, ... }:
+{
+  home.packages = with pkgs; [ ripgrep fd ];
+  programs.zsh.enable = true;
+  xdg.configFile."myapp/config".text = "...";
+}
+```
+
+## Overlays
+
+```nix
+{ config, lib, pkgs, ... }:
+let
+  myOverlay = final: prev: {
+    myPackage = prev.myPackage.overrideAttrs (old: { ... });
+  };
+in
+{
+  nixpkgs.overlays = [ myOverlay ];
+}
+```
+
+## Imports and References
+
+- Use flake inputs for dependencies
+- `lib` is always available in modules
+- Reference packages via `pkgs.packageName`
+- Use `callPackage` for complex package definitions
+
+## File Organization
+
+```
+flake.nix              # Entry point
+modules/               # NixOS modules
+  services/
+    my-service.nix
+overlays/              # Package overrides
+  default.nix
+```

rules/languages/python.md

@@ -0,0 +1,224 @@
+# Python Language Rules
+
+## Toolchain
+
+### Package Management (uv)
+```bash
+uv init my-project --package
+uv add numpy pandas
+uv add --dev pytest ruff pyright hypothesis
+uv run python -m pytest
+uv lock --upgrade-package numpy
+```
+
+### Linting & Formatting (ruff)
+```toml
+[tool.ruff]
+line-length = 100
+target-version = "py311"
+
+[tool.ruff.lint]
+select = ["E", "F", "W", "I", "N", "UP"]
+ignore = ["E501"]
+
+[tool.ruff.format]
+quote-style = "double"
+```
+
+### Type Checking (pyright)
+```toml
+[tool.pyright]
+typeCheckingMode = "strict"
+reportMissingTypeStubs = true
+reportUnknownMemberType = true
+```
+
+### Testing (pytest + hypothesis)
+```python
+import pytest
+from hypothesis import given, strategies as st
+
+@given(st.integers(), st.integers())
+def test_addition_commutative(a, b):
+    assert a + b == b + a
+
+@pytest.fixture
+def user_data():
+    return {"name": "Alice", "age": 30}
+
+def test_user_creation(user_data):
+    user = User(**user_data)
+    assert user.name == "Alice"
+```
+
+### Data Validation (Pydantic)
+```python
+from pydantic import BaseModel, Field, validator
+
+class User(BaseModel):
+    name: str = Field(min_length=1, max_length=100)
+    age: int = Field(ge=0, le=150)
+    email: str
+
+    @validator('email')
+    def email_must_contain_at(cls, v):
+        if '@' not in v:
+            raise ValueError('must contain @')
+        return v
+```
+
+## Idioms
+
+### Comprehensions
+```python
+# List comprehension
+squares = [x**2 for x in range(10) if x % 2 == 0]
+
+# Dict comprehension
+word_counts = {word: text.count(word) for word in unique_words}
+
+# Set comprehension
+unique_chars = {char for char in text if char.isalpha()}
+```
+
+### Context Managers
+```python
+# Built-in context managers
+with open('file.txt', 'r') as f:
+    content = f.read()
+
+# Custom context manager
+from contextlib import contextmanager
+
+@contextmanager
+def timer():
+    start = time.time()
+    yield
+    print(f"Elapsed: {time.time() - start:.2f}s")
+```
+
+### Generators
+```python
+def fibonacci():
+    a, b = 0, 1
+    while True:
+        yield a
+        a, b = b, a + b
+
+def read_lines(file_path):
+    with open(file_path) as f:
+        for line in f:
+            yield line.strip()
+```
+
+### F-strings
+```python
+name = "Alice"
+age = 30
+
+# Basic interpolation
+msg = f"Name: {name}, Age: {age}"
+
+# Expression evaluation
+msg = f"Next year: {age + 1}"
+
+# Format specs
+msg = f"Price: ${price:.2f}"
+msg = f"Hex: {0xFF:X}"
+```
+
+## Anti-Patterns
+
+### Bare Except
+```python
+# AVOID: Catches all exceptions including SystemExit
+try:
+    risky_operation()
+except:
+    pass
+
+# USE: Catch specific exceptions
+try:
+    risky_operation()
+except ValueError as e:
+    log_error(e)
+except KeyError as e:
+    log_error(e)
+```
+
+### Mutable Defaults
+```python
+# AVOID: Default argument created once
+def append_item(item, items=[]):
+    items.append(item)
+    return items
+
+# USE: None as sentinel
+def append_item(item, items=None):
+    if items is None:
+        items = []
+    items.append(item)
+    return items
+```
+
+### Global State
+```python
+# AVOID: Global mutable state
+counter = 0
+
+def increment():
+    global counter
+    counter += 1
+
+# USE: Class-based state
+class Counter:
+    def __init__(self):
+        self.count = 0
+
+    def increment(self):
+        self.count += 1
+```
+
+### Star Imports
+```python
+# AVOID: Pollutes namespace, unclear origins
+from module import *
+
+# USE: Explicit imports
+from module import specific_function, MyClass
+import module as m
+```
+
+## Project Setup
+
+### pyproject.toml Structure
+```toml
+[project]
+name = "my-project"
+version = "0.1.0"
+requires-python = ">=3.11"
+dependencies = [
+    "pydantic>=2.0",
+    "httpx>=0.25",
+]
+
+[project.optional-dependencies]
+dev = ["pytest", "ruff", "pyright", "hypothesis"]
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+```
+
+### src Layout
+```
+my-project/
+├── pyproject.toml
+└── src/
+    └── my_project/
+        ├── __init__.py
+        ├── main.py
+        └── utils/
+            ├── __init__.py
+            └── helpers.py
+```

rules/languages/shell.md

@@ -0,0 +1,100 @@
+# Shell Scripting Rules
+
+## Shebang
+
+Always use `#!/usr/bin/env bash` for portability. Never hardcode `/bin/bash`.
+
+```bash
+#!/usr/bin/env bash
+```
+
+## Strict Mode
+
+Enable strict mode in every script.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+```
+
+- `-e`: Exit on error
+- `-u`: Error on unset variables
+- `-o pipefail`: Return exit status of last failed pipe command
+
+## Shellcheck
+
+Run shellcheck on all scripts before committing.
+
+```bash
+shellcheck script.sh
+```
+
+## Quoting
+
+Quote all variable expansions and command substitutions. Use arrays instead of word-splitting strings.
+
+```bash
+# Good
+"${var}"
+files=("file1.txt" "file2.txt")
+for f in "${files[@]}"; do
+  process "$f"
+done
+
+# Bad
+$var
+files="file1.txt file2.txt"
+for f in $files; do
+  process $f
+done
+```
+
+## Functions
+
+Define with parentheses, use `local` for variables.
+
+```bash
+my_function() {
+  local result
+  result=$(some_command)
+  echo "$result"
+}
+```
+
+## Command Substitution
+
+Use `$()` not backticks. Nests cleanly.
+
+```bash
+# Good
+output=$(ls "$dir")
+
+# Bad
+output=`ls $dir`
+```
+
+## POSIX Portability
+
+Write POSIX-compliant scripts when targeting `/bin/sh`.
+
+- Use `[[` only for bash scripts
+- Use `printf` instead of `echo -e`
+- Avoid `[[`, `((`, `&>` in sh scripts
+
+## Error Handling
+
+Use `trap` for cleanup.
+
+```bash
+cleanup() {
+  rm -f /tmp/lockfile
+}
+trap cleanup EXIT
+```
+
+## Readability
+
+- Use 2-space indentation
+- Limit lines to 80 characters
+- Add comments for non-obvious logic
+- Separate sections with blank lines

rules/languages/typescript.md

@@ -0,0 +1,150 @@
+# TypeScript Patterns
+
+## Strict tsconfig
+
+Always enable strict mode and key safety options:
+
+```json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUnusedLocals": true,
+    "noUnusedParameters": true
+  }
+}
+```
+
+## Discriminated Unions
+
+Use discriminated unions for exhaustive type safety:
+
+```ts
+type Result =
+  | { success: true; data: string }
+  | { success: false; error: Error };
+
+function handleResult(result: Result): string {
+  if (result.success) {
+    return result.data;
+  }
+  throw result.error;
+}
+```
+
+## Branded Types
+
+Prevent type confusion with nominal branding:
+
+```ts
+type UserId = string & { readonly __brand: unique symbol };
+type Email = string & { readonly __brand: unique symbol };
+
+function createUserId(id: string): UserId {
+  return id as UserId;
+}
+
+function sendEmail(email: Email, userId: UserId) {}
+```
+
+## satisfies Operator
+
+Use `satisfies` for type-safe object literal inference:
+
+```ts
+const config = {
+  port: 3000,
+  host: "localhost",
+} satisfies {
+  port: number;
+  host: string;
+  debug?: boolean;
+};
+
+config.port; // number
+config.host; // string
+```
+
+## as const Assertions
+
+Freeze literal types with `as const`:
+
+```ts
+const routes = {
+  home: "/",
+  about: "/about",
+  contact: "/contact",
+} as const;
+
+type Route = typeof routes[keyof typeof routes];
+```
+
+## Modern Features
+
+```ts
+// Promise.withResolvers()
+const { promise, resolve, reject } = Promise.withResolvers<string>();
+
+// Object.groupBy()
+const users = [
+  { name: "Alice", role: "admin" },
+  { name: "Bob", role: "user" },
+];
+const grouped = Object.groupBy(users, u => u.role);
+
+// using statement for disposables
+class Resource implements Disposable {
+  async [Symbol.asyncDispose]() {
+    await this.cleanup();
+  }
+}
+async function withResource() {
+  using r = new Resource();
+}
+```
+
+## Toolchain
+
+Prefer modern tooling:
+- Runtime: `bun` or `tsx` (no `tsc` for execution)
+- Linting: `biome` (preferred) or `eslint`
+- Formatting: `biome` (built-in) or `prettier`
+
+## Anti-Patterns
+
+Avoid these TypeScript patterns:
+
+```ts
+// NEVER use as any
+const data = response as any;
+
+// NEVER use @ts-ignore
+// @ts-ignore
+const value = unknownFunction();
+
+// NEVER use ! assertion (non-null)
+const element = document.querySelector("#foo")!;
+
+// NEVER use enum (prefer union)
+enum Status { Active, Inactive } // ❌
+
+// Prefer const object or union
+type Status = "Active" | "Inactive"; // ✅
+const Status = { Active: "Active", Inactive: "Inactive" } as const; // ✅
+```
+
+## Indexed Access Safety
+
+With `noUncheckedIndexedAccess`, handle undefined:
+
+```ts
+const arr: string[] = ["a", "b"];
+const item = arr[0]; // string | undefined
+
+const item2 = arr.at(0); // string | undefined
+
+const map = new Map<string, number>();
+const value = map.get("key"); // number | undefined
+```

scripts/test-skill.sh

@@ -8,7 +8,7 @@
 #   ./scripts/test-skill.sh --run        # Launch interactive opencode session
 #
 # This script creates a temporary XDG_CONFIG_HOME with symlinks to this
-# repository's skill/, context/, command/, and prompts/ directories,
+# repository's skills/, context/, command/, and prompts/ directories,
 # allowing you to test skill changes before deploying via home-manager.
 
 set -euo pipefail
@@ -72,17 +72,17 @@ list_skills() {
 
 validate_skill() {
     local skill_name="$1"
-    local skill_path="$REPO_ROOT/skill/$skill_name"
+    local skill_path="$REPO_ROOT/skills/$skill_name"
 
     if [[ ! -d "$skill_path" ]]; then
         echo -e "${RED}❌ Skill not found: $skill_name${NC}"
         echo "Available skills:"
-        ls -1 "$REPO_ROOT/skill/"
+        ls -1 "$REPO_ROOT/skills/"
         exit 1
     fi
 
     echo -e "${YELLOW}Validating skill: $skill_name${NC}"
-    if python3 "$REPO_ROOT/skill/skill-creator/scripts/quick_validate.py" "$skill_path"; then
+    if python3 "$REPO_ROOT/skills/skill-creator/scripts/quick_validate.py" "$skill_path"; then
         echo -e "${GREEN}✅ Skill '$skill_name' is valid${NC}"
     else
         echo -e "${RED}❌ Skill '$skill_name' has validation errors${NC}"
@@ -95,14 +95,14 @@ validate_all() {
     echo ""
 
     local failed=0
-    for skill_dir in "$REPO_ROOT/skill/"*/; do
+    for skill_dir in "$REPO_ROOT/skills/"*/; do
         local skill_name=$(basename "$skill_dir")
         echo -n "  $skill_name: "
-        if python3 "$REPO_ROOT/skill/skill-creator/scripts/quick_validate.py" "$skill_dir" > /dev/null 2>&1; then
+        if python3 "$REPO_ROOT/skills/skill-creator/scripts/quick_validate.py" "$skill_dir" > /dev/null 2>&1; then
             echo -e "${GREEN}✅${NC}"
         else
             echo -e "${RED}❌${NC}"
-            python3 "$REPO_ROOT/skill/skill-creator/scripts/quick_validate.py" "$skill_dir" 2>&1 | sed 's/^/    /'
+            python3 "$REPO_ROOT/skills/skill-creator/scripts/quick_validate.py" "$skill_dir" 2>&1 | sed 's/^/    /'
             ((failed++)) || true
         fi
     done

scripts/validate-agents.sh

@@ -0,0 +1,182 @@
+#!/usr/bin/env bash
+#
+# Validate agents.json structure and referenced prompt files
+#
+# Usage:
+#   ./scripts/validate-agents.sh
+#
+# This script validates the agent configuration by:
+# - Parsing agents.json as valid JSON
+# - Checking all 6 required agents are present
+# - Verifying each agent has required fields
+# - Validating agent modes (primary vs subagent)
+# - Verifying all referenced prompt files exist and are non-empty
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+REPO_ROOT="$(dirname "$SCRIPT_DIR")"
+
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+NC='\033[0m'
+
+AGENTS_FILE="$REPO_ROOT/agents/agents.json"
+PROMPTS_DIR="$REPO_ROOT/prompts"
+
+# Expected agent list
+EXPECTED_AGENTS=("chiron" "chiron-forge" "hermes" "athena" "apollo" "calliope")
+# Expected primary agents
+PRIMARY_AGENTS=("chiron" "chiron-forge")
+# Expected subagents
+SUBAGENTS=("hermes" "athena" "apollo" "calliope")
+# Required fields for each agent
+REQUIRED_FIELDS=("description" "mode" "model" "prompt")
+
+echo -e "${YELLOW}Validating agent configuration...${NC}"
+echo ""
+
+# Track errors
+error_count=0
+warning_count=0
+
+# Function to print error
+error() {
+    echo -e "${RED}❌ $1${NC}" >&2
+    ((error_count++)) || true
+}
+
+# Function to print warning
+warning() {
+    echo -e "${YELLOW}⚠️  $1${NC}"
+    ((warning_count++)) || true
+}
+
+# Function to print success
+success() {
+    echo -e "${GREEN}✅ $1${NC}"
+}
+
+# Check if agents.json exists
+if [[ ! -f "$AGENTS_FILE" ]]; then
+    error "agents.json not found at $AGENTS_FILE"
+    exit 1
+fi
+
+# Validate JSON syntax
+if ! python3 -c "import json; json.load(open('$AGENTS_FILE'))" 2>/dev/null; then
+    error "agents.json is not valid JSON"
+    exit 1
+fi
+
+success "agents.json is valid JSON"
+echo ""
+
+# Parse agents.json
+AGENT_COUNT=$(python3 -c "import json; print(len(json.load(open('$AGENTS_FILE'))))")
+success "Found $AGENT_COUNT agents in agents.json"
+
+# Check agent count
+if [[ $AGENT_COUNT -ne ${#EXPECTED_AGENTS[@]} ]]; then
+    error "Expected ${#EXPECTED_AGENTS[@]} agents, found $AGENT_COUNT"
+fi
+
+# Get list of agent names
+AGENT_NAMES=$(python3 -c "import json; print(' '.join(sorted(json.load(open('$AGENTS_FILE')).keys())))")
+
+echo ""
+echo "Checking agent list..."
+
+# Check for missing agents
+for expected_agent in "${EXPECTED_AGENTS[@]}"; do
+    if echo "$AGENT_NAMES" | grep -qw "$expected_agent"; then
+        success "Agent '$expected_agent' found"
+    else
+        error "Required agent '$expected_agent' not found"
+    fi
+done
+
+# Check for unexpected agents
+for agent_name in $AGENT_NAMES; do
+    if [[ ! " ${EXPECTED_AGENTS[@]} " =~ " ${agent_name} " ]]; then
+        warning "Unexpected agent '$agent_name' found (not in expected list)"
+    fi
+done
+
+echo ""
+echo "Checking agent fields and modes..."
+
+# Validate each agent
+for agent_name in "${EXPECTED_AGENTS[@]}"; do
+    echo -n "  $agent_name: "
+
+    # Check required fields
+    missing_fields=()
+    for field in "${REQUIRED_FIELDS[@]}"; do
+        if ! python3 -c "import json; data=json.load(open('$AGENTS_FILE')); print(data.get('$agent_name').get('$field', ''))" 2>/dev/null | grep -q .; then
+            missing_fields+=("$field")
+        fi
+    done
+
+    if [[ ${#missing_fields[@]} -gt 0 ]]; then
+        error "Missing required fields: ${missing_fields[*]}"
+        continue
+    fi
+
+    # Get mode value
+    mode=$(python3 -c "import json; print(json.load(open('$AGENTS_FILE'))['$agent_name']['mode'])")
+
+    # Validate mode
+    if [[ " ${PRIMARY_AGENTS[@]} " =~ " ${agent_name} " ]]; then
+        if [[ "$mode" == "primary" ]]; then
+            success "Mode: $mode (valid)"
+        else
+            error "Expected mode 'primary' for agent '$agent_name', found '$mode'"
+        fi
+    elif [[ " ${SUBAGENTS[@]} " =~ " ${agent_name} " ]]; then
+        if [[ "$mode" == "subagent" ]]; then
+            success "Mode: $mode (valid)"
+        else
+            error "Expected mode 'subagent' for agent '$agent_name', found '$mode'"
+        fi
+    fi
+done
+
+echo ""
+echo "Checking prompt files..."
+
+# Validate prompt file references
+for agent_name in "${EXPECTED_AGENTS[@]}"; do
+    # Extract prompt file path from agent config
+    prompt_ref=$(python3 -c "import json; print(json.load(open('$AGENTS_FILE'))['$agent_name']['prompt'])")
+
+    # Parse prompt reference: {file:./prompts/<name>.txt}
+    if [[ "$prompt_ref" =~ \{file:(\./prompts/[^}]+)\} ]]; then
+        prompt_file="${BASH_REMATCH[1]}"
+        prompt_path="$REPO_ROOT/${prompt_file#./}"
+
+        # Check if prompt file exists
+        if [[ -f "$prompt_path" ]]; then
+            # Check if prompt file is non-empty
+            if [[ -s "$prompt_path" ]]; then
+                success "Prompt file exists and non-empty: $prompt_file"
+            else
+                error "Prompt file is empty: $prompt_file"
+            fi
+        else
+            error "Prompt file not found: $prompt_file"
+        fi
+    else
+        error "Invalid prompt reference format for agent '$agent_name': $prompt_ref"
+    fi
+done
+
+echo ""
+if [[ $error_count -eq 0 ]]; then
+    echo -e "${GREEN}All validations passed!${NC}"
+    exit 0
+else
+    echo -e "${RED}$error_count validation error(s) found${NC}"
+    exit 1
+fi

skills/basecamp/SKILL.md

@@ -1,341 +1,315 @@
 ---
 name: basecamp
-description: "Manage work projects in Basecamp via MCP. Use when: (1) creating or viewing Basecamp projects, (2) managing todos or todo lists, (3) working with card tables (kanban boards), (4) searching Basecamp content, (5) syncing project plans to Basecamp. Triggers: basecamp, create todos, show my projects, card table, move card, basecamp search, sync to basecamp, what's in basecamp."
+description: "Use when: (1) Managing Basecamp projects, (2) Working with Basecamp todos and tasks, (3) Reading/updating message boards and campfire, (4) Managing card tables (kanban), (5) Handling email forwards/inbox, (6) Setting up webhooks for automation. Triggers: 'Basecamp', 'project', 'todo', 'card table', 'campfire', 'message board', 'webhook', 'inbox', 'email forwards'."
 compatibility: opencode
 ---
 
 # Basecamp
 
-Manage work projects in Basecamp via MCP server. Provides workflows for project overview, todo management, kanban boards, and syncing from plan-writing skill.
-
-## Quick Reference
-
-| Action          | Command Pattern                        |
-| --------------- | -------------------------------------- |
-| List projects   | "Show my Basecamp projects"            |
-| View project    | "What's in [project name]?"            |
-| Create todos    | "Add todos to [project]"               |
-| View card table | "Show kanban for [project]"            |
-| Move card       | "Move [card] to [column]"              |
-| Search          | "Search Basecamp for [query]"          |
-| Sync plan       | "Create Basecamp todos from this plan" |
+Basecamp 3 project management integration via MCP server. Provides comprehensive access to projects, todos, messages, card tables (kanban), campfire, inbox, documents, and webhooks.
 
 ## Core Workflows
 
-### 1. Project Overview
+### Finding Projects and Todos
 
-List and explore projects:
-
-```
-1. get_projects → list all projects
-2. Present summary: name, last activity
-3. User selects project
-4. get_project(id) → show dock items (todosets, card tables, message boards)
+**List all projects:**
+```bash
+# Get all accessible Basecamp projects
+get_projects
 ```
 
-**Example output:**
-
-```
-Your Basecamp Projects:
-1. Q2 Training Program (last activity: 2 hours ago)
-2. Website Redesign (last activity: yesterday)
-3. Product Launch (last activity: 3 days ago)
-
-Which project would you like to explore?
+**Get project details:**
+```bash
+# Get specific project information including status, tools, and access level
+get_project --project_id <id>
 ```
 
-### 2. Todo Management
+**Explore todos:**
+```bash
+# Get all todo lists in a project
+get_todolists --project_id <id>
 
-**View todos:**
+# Get all todos from a specific todo list (handles pagination automatically)
+get_todos --recording_id <todo_list_id>
 
-```
-1. get_project(id) → find todoset from dock
-2. get_todolists(project_id) → list all todo lists
-3. get_todos(project_id, todolist_id) → show todos with status
+# Search across projects for todos/messages containing keywords
+search_basecamp --query <search_term>
 ```
 
-**Create todos:**
+### Managing Card Tables (Kanban)
 
-```
-1. Identify target project and todo list
-2. For each todo:
-   create_todo(
-     project_id,
-     todolist_id,
-     content,
-     due_on?,        # YYYY-MM-DD format
-     assignee_ids?,  # array of person IDs
-     notify?         # boolean
-   )
-3. Confirm creation with links
-```
+**Card tables** are Basecamp's kanban-style workflow management tool.
 
-**Complete/update todos:**
+**Explore card table:**
+```bash
+# Get card table for a project
+get_card_table --project_id <id>
 
-```
-- complete_todo(project_id, todo_id) → mark done
-- uncomplete_todo(project_id, todo_id) → reopen
-- update_todo(project_id, todo_id, content?, due_on?, assignee_ids?)
-- delete_todo(project_id, todo_id) → remove
-```
+# Get all columns in a card table
+get_columns --card_table_id <id>
 
-### 3. Card Table (Kanban) Management
-
-**View board:**
-
-```
-1. get_card_table(project_id) → get card table details
-2. get_columns(project_id, card_table_id) → list columns
-3. For each column: get_cards(project_id, column_id)
-4. Present as kanban view
-```
-
-**Example output:**
-
-```
-Card Table: Development Pipeline
-
-| Backlog (3) | In Progress (2) | Review (1) | Done (5) |
-|-------------|-----------------|------------|----------|
-| Feature A   | Feature B       | Bug fix    | ...      |
-| Feature C   | Feature D       |            |          |
-| Refactor    |                 |            |          |
+# Get all cards in a specific column
+get_cards --column_id <id>
 ```
 
 **Manage columns:**
+```bash
+# Create new column (e.g., "In Progress", "Done")
+create_column --card_table_id <id> --title "Column Name"
 
-```
-- create_column(project_id, card_table_id, title)
-- update_column(project_id, column_id, title) → rename
-- move_column(project_id, card_table_id, column_id, position)
-- update_column_color(project_id, column_id, color)
-- put_column_on_hold(project_id, column_id) → freeze work
-- remove_column_hold(project_id, column_id) → unfreeze
+# Update column title
+update_column --column_id <id> --title "New Title"
+
+# Move column to different position
+move_column --column_id <id> --position 3
+
+# Update column color
+update_column_color --column_id <id> --color "red"
+
+# Put column on hold (freeze work)
+put_column_on_hold --column_id <id>
+
+# Remove hold from column (unfreeze work)
+remove_column_hold --column_id <id>
 ```
 
 **Manage cards:**
+```bash
+# Create new card in a column
+create_card --column_id <id> --title "Task Name" --content "Description"
 
-```
-- create_card(project_id, column_id, title, content?, due_on?, notify?)
-- update_card(project_id, card_id, title?, content?, due_on?, assignee_ids?)
-- move_card(project_id, card_id, column_id) → move to different column
-- complete_card(project_id, card_id)
-- uncomplete_card(project_id, card_id)
+# Update card details
+update_card --card_id <id> --title "Updated Title" --content "New content"
+
+# Move card to different column
+move_card --card_id <id> --to_column_id <new_column_id>
+
+# Mark card as complete
+complete_card --card_id <id>
+
+# Mark card as incomplete
+uncomplete_card --card_id <id>
 ```
 
-**Card steps (subtasks):**
+**Manage card steps (sub-tasks):**
+```bash
+# Get all steps for a card
+get_card_steps --card_id <id>
 
-```
-- get_card_steps(project_id, card_id) → list subtasks
-- create_card_step(project_id, card_id, title, due_on?, assignee_ids?)
-- complete_card_step(project_id, step_id)
-- update_card_step(project_id, step_id, title?, due_on?, assignee_ids?)
-- delete_card_step(project_id, step_id)
+# Create new step
+create_card_step --card_id <id> --content "Sub-task description"
+
+# Update step
+update_card_step --step_id <id> --content "Updated description"
+
+# Delete step
+delete_card_step --step_id <id>
+
+# Mark step as complete
+complete_card_step --step_id <id>
+
+# Mark step as incomplete
+uncomplete_card_step --step_id <id>
 ```
 
-### 4. Search
+### Working with Messages and Campfire
 
-```
-search_basecamp(query, project_id?)
-- Omit project_id → search all projects
-- Include project_id → scope to specific project
+**Message board:**
+```bash
+# Get message board for a project
+get_message_board --project_id <id>
+
+# Get all messages from a project
+get_messages --project_id <id>
+
+# Get specific message
+get_message --message_id <id>
 ```
 
-Results include todos, messages, and other content matching the query.
-
-### 5. Sync from Plan-Writing
-
-When user has a project plan from plan-writing skill:
-
-```
-1. Parse todo-structure.md or tasks.md for task hierarchy
-2. Ask: "Which Basecamp project should I add these to?"
-   - List existing projects via get_projects
-   - Note: New projects must be created manually in Basecamp
-3. Ask: "Use todo lists or card table?"
-4. If todo lists:
-   - Create todo list per phase/milestone if needed
-   - Create todos with due dates and assignees
-5. If card table:
-   - Create columns for phases/statuses
-   - Create cards from tasks
-   - Add card steps for subtasks
-6. Confirm: "Created X todos/cards in [project]. View in Basecamp."
+**Campfire (team chat):**
+```bash
+# Get recent campfire lines (messages)
+get_campfire_lines --campfire_id <id>
 ```
 
-### 6. Status Check
+**Comments:**
+```bash
+# Get comments for any Basecamp item (message, todo, card, etc.)
+get_comments --recording_id <id>
 
-```
-User: "What's the status of [project]?"
-
-1. get_project(id)
-2. For each todo list: get_todos, count complete/incomplete
-3. If card table exists: get columns and card counts
-4. Calculate summary:
-   - X todos complete, Y incomplete, Z overdue
-   - Card distribution across columns
-5. Highlight: overdue items, blocked items
+# Create a comment
+create_comment --recording_id <id> --content "Your comment"
 ```
 
-**Example output:**
+### Managing Inbox (Email Forwards)
 
-```
-Project: Q2 Training Program
+**Inbox** handles email forwarding to Basecamp projects.
 
-Todos: 12/20 complete (60%)
-- 3 overdue items
-- 5 due this week
+**Explore inbox:**
+```bash
+# Get inbox for a project (email forwards container)
+get_inbox --project_id <id>
 
-Card Table: Development
-| Backlog | In Progress | Review | Done |
-|    3    |      2      |   1    |  8   |
+# Get all forwarded emails from a project's inbox
+get_forwards --project_id <id>
 
-Attention needed:
-- "Create training materials" (overdue by 2 days)
-- "Review curriculum" (due tomorrow)
+# Get specific forwarded email
+get_forward --forward_id <id>
+
+# Get all replies to a forwarded email
+get_inbox_replies --forward_id <id>
+
+# Get specific reply
+get_inbox_reply --reply_id <id>
 ```
 
-## Tool Categories
-
-For complete tool reference with parameters, see [references/mcp-tools.md](references/mcp-tools.md).
-
-| Category   | Key Tools                                                      |
-| ---------- | -------------------------------------------------------------- |
-| Projects   | get_projects, get_project                                      |
-| Todos      | get_todolists, get_todos, create_todo, complete_todo           |
-| Cards      | get_card_table, get_columns, get_cards, create_card, move_card |
-| Card Steps | get_card_steps, create_card_step, complete_card_step           |
-| Search     | search_basecamp                                                |
-| Comments   | get_comments, create_comment                                   |
-| Documents  | get_documents, create_document, update_document                |
-
-## Limitations
-
-- **No create_project tool**: Projects must be created manually in Basecamp UI
-- **Work projects only**: This skill is for professional/team projects
-- **Pagination handled**: MCP server handles pagination transparently
-
-## Project Mapping Configuration
-
-### Map Basecamp Projects to PARA
-
-When setting up the integration, create a mapping between Basecamp projects and Obsidian project folders:
-
-**Example configuration** (to be customized):
-```json
-{
-  "basecamp_projects": {
-    "project_123": {
-      "name": "API Integration Platform",
-      "para_path": "01-projects/work/api-integration-platform",
-      "area": "technical-excellence",
-      "type": "engineering"
-    },
-    "project_456": {
-      "name": "Customer Portal Redesign",
-      "para_path": "01-projects/work/customer-portal-redesign",
-      "area": "technical-excellence",
-      "type": "product-design"
-    }
-    // ... add all projects
-  }
-}
+**Manage forwards:**
+```bash
+# Move forwarded email to trash
+trash_forward --forward_id <id>
 ```
 
-**Where to store**:
-- Obsidian: `~/CODEX/_chiron/context/basecamp-projects.md`
-- Or in skill: `references/basecamp-project-map.md`
+### Documents
 
-### Usage in Workflows
+**Manage documents:**
+```bash
+# List documents in a vault
+get_documents --vault_id <id>
 
-When creating/syncing to Basecamp:
+# Get specific document
+get_document --document_id <id>
 
-```
-1. User mentions: "API Integration Platform"
-2. Look up in project map:
-   - Get: project_id = "project_123"
-   - Get: para_path = "01-projects/work/api-integration-platform"
-3. Use project_id for Basecamp operations
-4. Use para_path for Obsidian operations
+# Create new document
+create_document --vault_id <id> --title "Document Title" --content "Document content"
+
+# Update document
+update_document --document_id <id> --title "Updated Title" --content "New content"
+
+# Move document to trash
+trash_document --document_id <id>
 ```
 
-### Fetching Real Projects
+### Webhooks and Automation
 
-**When first setting up**:
+**Webhooks** enable automation by triggering external services on Basecamp events.
 
-```
-User: "Fetch my Basecamp projects and set up PARA structure"
+**Manage webhooks:**
+```bash
+# List webhooks for a project
+get_webhooks --project_id <id>
 
-Steps:
-1. get_projects() → Get all Basecamp projects
-2. For each project:
-   - Extract: id, name, status, last_activity
-   - Determine PARA path (kebab-case from name)
-   - Create project folder with _index.md
-   - Add frontmatter: basecamp_id, project_link
-3. Create mapping in basecamp-projects.md
-4. Confirm: "Mapped 10 Basecamp projects to PARA structure"
+# Create webhook
+create_webhook --project_id <id> --callback_url "https://your-service.com/webhook" --types "TodoCreated,TodoCompleted"
+
+# Delete webhook
+delete_webhook --webhook_id <id>
 ```
 
-**Example project _index.md frontmatter**:
-```yaml
----
-title: "[Project Name]"
-basecamp_id: "project_123"
-basecamp_url: "https://3.basecampapi.com/123456/projects/project_123"
-status: active
-deadline: YYYY-MM-DD
-source: basecamp
-tags: [work, project, engineering]
----
+### Daily Check-ins
+
+**Project check-ins:**
+```bash
+# Get daily check-in questions for a project
+get_daily_check_ins --project_id <id>
+
+# Get answers to daily check-in questions
+get_question_answers --question_id <id>
 ```
 
----
+### Attachments and Events
+
+**Upload and track:**
+```bash
+# Upload file as attachment
+create_attachment --recording_id <id> --file_path "/path/to/file"
+
+# Get events for a recording
+get_events --recording_id <id>
+```
 
 ## Integration with Other Skills
 
-| From Skill      | To Basecamp                                       |
-| --------------- | ------------------------------------------------- |
-| brainstorming   | Save decision → reference in project docs         |
-| plan-writing    | todo-structure.md → Basecamp todos or cards       |
-| task-management | Obsidian tasks ↔ Basecamp todos (manual reference) |
-| daily-routines  | Morning planning with Basecamp todos, evening review   |
-| meeting-notes  | Sync action items from meetings to Basecamp          |
+### Hermes (Work Communication)
 
-## Common Patterns
+Hermes loads this skill when working with Basecamp projects. Common workflows:
 
-### Create todos from a list
+| User Request | Hermes Action | Basecamp Tools Used |
+|--------------|---------------|---------------------|
+| "Create a task in Marketing project" | Create card/todo | `create_card`, `get_columns`, `create_column` |
+| "Check project updates" | Read messages/campfire | `get_messages`, `get_campfire_lines`, `get_comments` |
+| "Update my tasks" | Move cards, update status | `move_card`, `complete_card`, `update_card` |
+| "Add comment to discussion" | Post comment | `create_comment`, `get_comments` |
+| "Review project inbox" | Check email forwards | `get_inbox`, `get_forwards`, `get_inbox_replies` |
 
-```
-User provides list:
-- Task 1 (due Friday)
-- Task 2 (due next week)
-- Task 3
+### Workflow Patterns
 
-1. Identify or confirm project and todo list
-2. Parse due dates (Friday → YYYY-MM-DD)
-3. Create each todo via create_todo
-4. Report: "Created 3 todos in [list name]"
+**Project setup:**
+1. Use `get_projects` to find existing projects
+2. Use `get_project` to verify project details
+3. Use `get_todolists` or `get_card_table` to understand project structure
+
+**Task management:**
+1. Use `get_todolists` or `get_columns` to find appropriate location
+2. Use `create_card` or todo creation to add work
+3. Use `move_card`, `complete_card` to update status
+4. Use `get_card_steps` and `create_card_step` for sub-task breakdown
+
+**Communication:**
+1. Use `get_messages` or `get_campfire_lines` to read discussions
+2. Use `create_comment` to contribute to existing items
+3. Use `search_basecamp` to find relevant content
+
+**Automation:**
+1. Use `get_webhooks` to check existing integrations
+2. Use `create_webhook` to set up external notifications
+
+## Tool Organization by Category
+
+**Projects & Lists:**
+- `get_projects`, `get_project`, `get_todolists`, `get_todos`, `search_basecamp`
+
+**Card Table (Kanban):**
+- `get_card_table`, `get_columns`, `get_column`, `create_column`, `update_column`, `move_column`, `update_column_color`, `put_column_on_hold`, `remove_column_hold`, `watch_column`, `unwatch_column`, `get_cards`, `get_card`, `create_card`, `update_card`, `move_card`, `complete_card`, `uncomplete_card`, `get_card_steps`, `create_card_step`, `get_card_step`, `update_card_step`, `delete_card_step`, `complete_card_step`, `uncomplete_card_step`
+
+**Messages & Communication:**
+- `get_message_board`, `get_messages`, `get_message`, `get_campfire_lines`, `get_comments`, `create_comment`
+
+**Inbox (Email Forwards):**
+- `get_inbox`, `get_forwards`, `get_forward`, `get_inbox_replies`, `get_inbox_reply`, `trash_forward`
+
+**Documents:**
+- `get_documents`, `get_document`, `create_document`, `update_document`, `trash_document`
+
+**Webhooks:**
+- `get_webhooks`, `create_webhook`, `delete_webhook`
+
+**Other:**
+- `get_daily_check_ins`, `get_question_answers`, `create_attachment`, `get_events`
+
+## Common Queries
+
+**Finding the right project:**
+```bash
+# Use search to find projects by keyword
+search_basecamp --query "marketing"
+# Then inspect specific project
+get_project --project_id <id>
 ```
 
-### Move cards through workflow
-
-```
-User: "Move Feature A to In Progress"
-
-1. search_basecamp("Feature A") or get_cards to find card_id
-2. get_columns to find target column_id
-3. move_card(project_id, card_id, column_id)
-4. Confirm: "Moved 'Feature A' to 'In Progress'"
+**Understanding project structure:**
+```bash
+# Check which tools are available in a project
+get_project --project_id <id>
+# Project response includes tools: message_board, campfire, card_table, todolists, etc.
 ```
 
-### Add subtasks to a card
+**Bulk operations:**
+```bash
+# Get all todos across a project (pagination handled automatically)
+get_todos --recording_id <todo_list_id>
+# Returns all pages of results
 
-```
-User: "Add subtasks to the Feature B card"
-
-1. Find card via search or get_cards
-2. For each subtask:
-   create_card_step(project_id, card_id, title)
-3. Report: "Added X steps to 'Feature B'"
+# Get all cards across all columns
+get_columns --card_table_id <id>
+get_cards --column_id <id>  # Repeat for each column
 ```

skills/basecamp/references/mcp-tools.md

@@ -1,198 +0,0 @@
-# Basecamp MCP Tools Reference
-
-Complete reference for all 46 available Basecamp MCP tools.
-
-## Projects
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_projects` | none | List of all projects with id, name, description |
-| `get_project` | project_id | Project details including dock (todosets, card tables, etc.) |
-
-## Todo Lists
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_todolists` | project_id | All todo lists in project |
-
-## Todos
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_todos` | project_id, todolist_id | All todos (pagination handled) |
-| `create_todo` | project_id, todolist_id, content, due_on?, assignee_ids?, notify? | Created todo |
-| `update_todo` | project_id, todo_id, content?, due_on?, assignee_ids? | Updated todo |
-| `delete_todo` | project_id, todo_id | Success confirmation |
-| `complete_todo` | project_id, todo_id | Completed todo |
-| `uncomplete_todo` | project_id, todo_id | Reopened todo |
-
-### Todo Parameters
-
-- `content`: String - The todo text
-- `due_on`: String - Date in YYYY-MM-DD format
-- `assignee_ids`: Array of integers - Person IDs to assign
-- `notify`: Boolean - Whether to notify assignees
-
-## Card Tables
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_card_tables` | project_id | All card tables in project |
-| `get_card_table` | project_id | Primary card table details |
-
-## Columns
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_columns` | project_id, card_table_id | All columns in card table |
-| `get_column` | project_id, column_id | Column details |
-| `create_column` | project_id, card_table_id, title | New column |
-| `update_column` | project_id, column_id, title | Updated column |
-| `move_column` | project_id, card_table_id, column_id, position | Moved column |
-| `update_column_color` | project_id, column_id, color | Updated color |
-| `put_column_on_hold` | project_id, column_id | Column frozen |
-| `remove_column_hold` | project_id, column_id | Column unfrozen |
-| `watch_column` | project_id, column_id | Subscribed to notifications |
-| `unwatch_column` | project_id, column_id | Unsubscribed |
-
-### Column Colors
-
-Available colors for `update_column_color`:
-- white, grey, pink, red, orange, yellow, green, teal, blue, purple
-
-## Cards
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_cards` | project_id, column_id | All cards in column |
-| `get_card` | project_id, card_id | Card details |
-| `create_card` | project_id, column_id, title, content?, due_on?, notify? | New card |
-| `update_card` | project_id, card_id, title?, content?, due_on?, assignee_ids? | Updated card |
-| `move_card` | project_id, card_id, column_id | Card moved to column |
-| `complete_card` | project_id, card_id | Card marked complete |
-| `uncomplete_card` | project_id, card_id | Card reopened |
-
-### Card Parameters
-
-- `title`: String - Card title
-- `content`: String - Card description/body (supports HTML)
-- `due_on`: String - Date in YYYY-MM-DD format
-- `assignee_ids`: Array of integers - Person IDs
-- `notify`: Boolean - Notify assignees on creation
-
-## Card Steps (Subtasks)
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_card_steps` | project_id, card_id | All steps on card |
-| `create_card_step` | project_id, card_id, title, due_on?, assignee_ids? | New step |
-| `get_card_step` | project_id, step_id | Step details |
-| `update_card_step` | project_id, step_id, title?, due_on?, assignee_ids? | Updated step |
-| `delete_card_step` | project_id, step_id | Step deleted |
-| `complete_card_step` | project_id, step_id | Step completed |
-| `uncomplete_card_step` | project_id, step_id | Step reopened |
-
-## Search
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `search_basecamp` | query, project_id? | Matching todos, messages, etc. |
-
-- Omit `project_id` for global search across all projects
-- Include `project_id` to scope search to specific project
-
-## Communication
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_campfire_lines` | project_id, campfire_id | Recent chat messages |
-| `get_comments` | project_id, recording_id | Comments on any item |
-| `create_comment` | project_id, recording_id, content | New comment |
-
-### Comment Parameters
-
-- `recording_id`: The ID of the item (todo, card, document, etc.)
-- `content`: String - Comment text (supports HTML)
-
-## Daily Check-ins
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_daily_check_ins` | project_id, page? | Check-in questions |
-| `get_question_answers` | project_id, question_id, page? | Answers to question |
-
-## Documents
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_documents` | project_id, vault_id | Documents in vault |
-| `get_document` | project_id, document_id | Document content |
-| `create_document` | project_id, vault_id, title, content, status? | New document |
-| `update_document` | project_id, document_id, title?, content? | Updated document |
-| `trash_document` | project_id, document_id | Document trashed |
-
-### Document Parameters
-
-- `vault_id`: Found in project dock as the docs/files container
-- `content`: String - Document body (supports HTML)
-- `status`: "active" or "archived"
-
-## Attachments
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `create_attachment` | file_path, name, content_type? | Uploaded attachment |
-
-## Events
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_events` | project_id, recording_id | Activity events on item |
-
-## Webhooks
-
-| Tool | Parameters | Returns |
-|------|------------|---------|
-| `get_webhooks` | project_id | Project webhooks |
-| `create_webhook` | project_id, payload_url, types? | New webhook |
-| `delete_webhook` | project_id, webhook_id | Webhook deleted |
-
-### Webhook Types
-
-Available types for `create_webhook`:
-- Comment, Document, GoogleDocument, Message, Question::Answer
-- Schedule::Entry, Todo, Todolist, Upload, Vault, Card, CardTable::Column
-
-## Common Patterns
-
-### Find project by name
-
-```
-1. get_projects → list all
-2. Match name (case-insensitive partial match)
-3. Return project_id
-```
-
-### Find todoset ID for a project
-
-```
-1. get_project(project_id)
-2. Look in dock array for item with name "todoset"
-3. Extract id from dock item URL
-```
-
-### Find card table ID
-
-```
-1. get_project(project_id)
-2. Look in dock for "kanban_board" or use get_card_tables
-3. Extract card_table_id
-```
-
-### Get all todos across all lists
-
-```
-1. get_todolists(project_id)
-2. For each todolist: get_todos(project_id, todolist_id)
-3. Aggregate results
-```

skills/calendar-scheduling/SKILL.md

@@ -1,69 +0,0 @@
----
-name: calendar-scheduling
-description: "Calendar and time management with Proton Calendar integration. Use when: (1) checking schedule, (2) blocking focus time, (3) scheduling meetings, (4) time-based planning, (5) managing availability. Triggers: calendar, schedule, when am I free, block time, meeting, availability, what's my day look like."
-compatibility: opencode
----
-
-# Calendar & Scheduling
-
-Time management and calendar integration for Proton Calendar.
-
-## Status: Stub
-
-This skill is a placeholder for future development. Core functionality to be added:
-
-## Planned Features
-
-### Schedule Overview
-- Daily/weekly calendar view
-- Meeting summaries
-- Free time identification
-
-### Time Blocking
-- Deep work blocks
-- Focus time protection
-- Buffer time between meetings
-
-### Meeting Management
-- Quick meeting creation
-- Availability checking
-- Meeting prep reminders
-
-### Time-Based Planning
-- Energy-matched scheduling
-- Context-based time allocation
-- Review time protection
-
-## Integration Points
-
-- **Proton Calendar**: Primary calendar backend
-- **task-management**: Align tasks with available time
-- **ntfy**: Meeting reminders and alerts
-
-## Quick Commands (Future)
-
-| Command | Description |
-|---------|-------------|
-| `what's my day` | Today's schedule overview |
-| `block [duration] for [activity]` | Create focus block |
-| `when am I free [day]` | Check availability |
-| `schedule meeting [details]` | Create calendar event |
-
-## Proton Calendar Integration
-
-API integration pending. Requires:
-- Proton Bridge or API access
-- CalDAV sync configuration
-- Authentication setup
-
-## Time Blocking Philosophy
-
-Based on Sascha's preferences:
-- **Early mornings**: Deep work (protect fiercely)
-- **Mid-day**: Meetings and collaboration
-- **Late afternoon**: Admin and email
-- **Evening**: Review and planning
-
-## Notes
-
-Proton Calendar API access needs to be configured. Consider CalDAV integration or n8n workflow as bridge.

skills/chiron-core/SKILL.md

@@ -1,223 +0,0 @@
----
-name: chiron-core
-description: "Chiron productivity mentor with PARA methodology for Obsidian vaults. Use when: (1) guiding daily/weekly planning workflows, (2) prioritizing work using PARA principles, (3) structuring knowledge organization, (4) providing productivity advice, (5) coordinating between productivity skills. Triggers: chiron, mentor, productivity, para, planning, review, organize, prioritize, focus."
-compatibility: opencode
----
-
-# Chiron Core
-
-**Chiron** is the AI productivity mentor - a wise guide named after the centaur who trained Greek heroes. This skill provides the foundational PARA methodology and mentorship persona for the Chiron productivity system.
-
-## Role & Personality
-
-**Mentor, not commander** - Guide the user toward their own insights and decisions.
-
-**Personality traits:**
-- Wise but not condescending
-- Direct but supportive
-- Encourage reflection and self-improvement
-- Use Greek mythology references sparingly
-- Sign important interactions with 🏛️
-
-## PARA Methodology
-
-The organizing framework for your Obsidian vault at `~/CODEX/`.
-
-### PARA Structure
-
-| Category | Folder | Purpose | Examples |
-|----------|---------|---------|----------|
-| **Projects** | `01-projects/` | Active outcomes with deadlines | "Website relaunch", "NixOS setup" |
-| **Areas** | `02-areas/` | Ongoing responsibilities | "Health", "Finances", "Team" |
-| **Resources** | `03-resources/` | Reference material by topic | "Python", "Productivity", "Recipes" |
-| **Archive** | `04-archive/` | Completed/inactive items | Old projects, outdated resources |
-
-### Decision Rules
-
-**Use when deciding where to put information:**
-
-1. **Is it actionable with a deadline?** → `01-projects/`
-2. **Is it an ongoing responsibility?** → `02-areas/`
-3. **Is it reference material?** → `03-resources/`
-4. **Is it completed or inactive?** → `04-archive/`
-
-## Workflows
-
-### Morning Planning (/chiron-start)
-
-**When user says**: "Start day", "Morning planning", "What's today?"
-
-**Steps:**
-1. Read yesterday's daily note from `daily/YYYY/MM/DD/YYYY-MM-DD.md`
-2. Check today's tasks in `tasks/inbox.md` and project files
-3. Prioritize using energy levels and deadlines
-4. Generate today's focus (3-5 top priorities)
-5. Ask: "Ready to start, or need to adjust?"
-
-**Output format:**
-```markdown
-# 🌅 Morning Plan - YYYY-MM-DD
-
-## Focus Areas
-- [Priority 1]
-- [Priority 2]
-- [Priority 3]
-
-## Quick Wins (<15min)
-- [Task]
-
-## Deep Work Blocks
-- [Block 1: 9-11am]
-- [Block 2: 2-4pm]
-
-## Inbox to Process
-- Count items in `00-inbox/`
-```
-
-### Evening Reflection (/chiron-end)
-
-**When user says**: "End day", "Evening review", "How was today?"
-
-**Steps:**
-1. Review completed tasks
-2. Capture key wins and learnings
-3. Identify blockers
-4. Plan tomorrow's focus
-5. Ask for reflection question
-
-**Output format:**
-```markdown
-# 🌙 Evening Reflection - YYYY-MM-DD
-
-## Wins
-- Win 1
-- Win 2
-- Win 3
-
-## Challenges
-- Blocker 1
-
-## Learnings
-- Learning 1
-
-## Tomorrow's Focus
-- Top 3 priorities
-```
-
-### Weekly Review (/chiron-review)
-
-**When user says**: "Weekly review", "Week planning"
-
-**Steps:**
-1. Collect completed tasks from daily notes
-2. Review project status across all projects
-3. Process inbox items
-4. Identify patterns and trends
-5. Plan next week's priorities
-6. Review area health (2-4 weeks review cycle)
-
-**Output format:**
-```markdown
-# 📊 Weekly Review - W#N
-
-## Metrics
-- Tasks completed: N
-- Deep work hours: N
-- Focus score: N/10
-
-## Top 3 Wins
-1. Win 1
-2. Win 2
-3. Win 3
-
-## Key Learnings
-- Learning 1
-
-## Next Week Priorities
-1. Priority 1
-2. Priority 2
-3. Priority 3
-
-## Inbox Status
-- Processed N items
-- Remaining: N
-```
-
-## Task Management
-
-**Use Obsidian Tasks plugin format:**
-
-```markdown
-- [ ] Task description #tag ⏫ 📅 YYYY-MM-DD
-```
-
-**Priority indicators:**
-- ⏫ = Critical (urgent AND important)
-- 🔼 = High (important, not urgent)
-- 🔽 = Low (nice to have)
-
-**Common tags:**
-- `#work` - Work task
-- `#personal` - Personal task
-- `#quick` - <15 minutes
-- `#deep` - Requires focus
-- `#waiting` - Blocked/delegated
-
-## File Paths
-
-```
-~/CODEX/
-├── _chiron/
-│   ├── context.md          # Primary context (read first)
-│   └── templates/         # Note templates
-├── 00-inbox/             # Quick captures
-├── 01-projects/          # Active projects
-├── 02-areas/             # Ongoing responsibilities
-├── 03-resources/         # Reference material
-├── 04-archive/           # Completed items
-├── daily/                # Daily notes
-└── tasks/                # Task management
-```
-
-## Integration with Other Skills
-
-**chiron-core delegates to:**
-- `obsidian-management` - File operations and template usage
-- `daily-routines` - Detailed workflow execution
-- `task-management` - Task operations
-- `quick-capture` - Inbox processing
-- `meeting-notes` - Meeting workflows
-
-**Delegation triggers:**
-- "Create a project note" → `project-structures` skill
-- "Capture this quickly" → `quick-capture` skill
-- "Take meeting notes" → `meeting-notes` skill
-- "Find all X tasks" → `task-management` skill
-
-## Core Principles
-
-1. **Context first** - Always read `_chiron/context.md` before acting
-2. **Minimal friction** - Quick capture should be instant
-3. **Trust the system** - Regular reviews keep it useful
-4. **Progressive disclosure** - Show what's needed, not everything
-5. **Reflect and improve** - Weekly reviews drive system refinement
-
-## When NOT to Use This Skill
-
-- For specific file operations → `obsidian-management`
-- For detailed workflow execution → `daily-routines`
-- For Basecamp integration → `basecamp`
-- For calendar operations → `calendar-scheduling`
-- For n8n workflows → `n8n-automation`
-
-## References
-
-- `references/para-guide.md` - Detailed PARA methodology
-- `references/priority-matrix.md` - Eisenhower matrix for prioritization
-- `references/reflection-questions.md` - Weekly reflection prompts
-
-**Load these references when:**
-- User asks about PARA methodology
-- Prioritization questions arise
-- Weekly review preparation needed
-- System improvement suggestions requested

skills/chiron-core/references/para-guide.md

@@ -1,272 +0,0 @@
-# PARA Methodology Guide
-
-## What is PARA?
-
-PARA is a productivity framework for organizing digital information:
-
-- **P**rojects - Short-term efforts with deadlines
-- **A**reas - Long-term responsibilities (no deadline)
-- **R**esources - Topics of interest (reference material)
-- **A**rchive - Inactive items (completed, cancelled, on hold)
-
-## Why PARA Works
-
-**Traditional problem**: Information scattered across multiple systems with no clear organization.
-
-**PARA solution**: Single organizing principle based on **actionability** and **time horizon**.
-
-## Detailed Definitions
-
-### Projects (01-projects/)
-
-**Definition**: Short-term efforts that you're working on now with clear goals and deadlines.
-
-**Criteria for a project:**
-- Has a clear goal or outcome
-- Has a deadline or target date
-- Takes effort to complete (not a single task)
-- Active - you're working on it now
-
-**Examples**:
-- "Launch new website" (deadline: March 15)
-- "Complete Q1 budget review" (deadline: Feb 28)
-- "Learn Python basics" (deadline: End of month)
-- "Organize home office" (deadline: This weekend)
-
-**Project structure**:
-```
-01-projects/[work|personal]/[project-name]/
-├── _index.md          # Main project file (MOC)
-├── meetings/          # Meeting notes
-├── decisions/         # Decision records
-└── notes/            # General notes
-```
-
-**Project frontmatter**:
-```yaml
----
-status: active | on-hold | completed
-deadline: YYYY-MM-DD
-priority: critical | high | medium | low
-tags: [work, personal]
----
-```
-
-### Areas (02-areas/)
-
-**Definition**: Ongoing responsibilities with no end date. These define your roles in life.
-
-**Criteria for an area:**
-- No deadline - ongoing indefinitely
-- Represents a responsibility or role
-- Requires regular attention
-- Contains multiple projects over time
-
-**Examples**:
-- "Health" (ongoing, has projects: "Run marathon", "Eat better")
-- "Finances" (ongoing, has projects: "Tax preparation", "Investment plan")
-- "Professional Development" (ongoing, has projects: "Learn AI", "Get certification")
-- "Home & Family" (ongoing, has projects: "Plan vacation", "Renovate kitchen")
-
-**Area structure**:
-```
-02-areas/[work|personal]/
-├── health.md
-├── finances.md
-├── professional-development.md
-└── home.md
-```
-
-**Area frontmatter**:
-```yaml
----
-review-frequency: weekly | biweekly | monthly
-last_reviewed: YYYY-MM-DD
-health: good | needs-attention | critical
----
-```
-
-### Resources (03-resources/)
-
-**Definition**: Topics or themes of ongoing interest. Material you reference repeatedly.
-
-**Criteria for a resource:**
-- Reference material, not actionable
-- Topic-based organization
-- Used across multiple projects/areas
-- Has long-term value
-
-**Examples**:
-- "Python Programming" (referenced for multiple coding projects)
-- "Productivity Systems" (used across work and personal)
-- "Cooking Recipes" (referenced repeatedly)
-- "Productivity Tools" (knowledge about tools)
-
-**Resource structure**:
-```
-03-resources/
-├── programming/
-│   ├── python/
-│   ├── nix/
-│   └── typescript/
-├── tools/
-│   ├── obsidian.md
-│   ├── n8n.md
-│   └── nixos.md
-├── productivity/
-└── cooking/
-```
-
-**Resource frontmatter**:
-```yaml
----
-type: reference | guide | documentation
-tags: [programming, tools]
-last_updated: YYYY-MM-DD
----
-```
-
-### Archive (04-archive/)
-
-**Definition**: Completed or inactive items. Moved here when no longer active.
-
-**When to archive:**
-- Projects completed
-- Areas no longer relevant (life change)
-- Resources outdated
-- Items on hold indefinitely
-
-**Archive structure**:
-```
-04-archive/
-├── projects/
-├── areas/
-└── resources/
-```
-
-## Decision Tree
-
-**When deciding where to put something:**
-
-```
-Is it actionable?
-├─ Yes → Has a deadline?
-│  ├─ Yes → PROJECT (01-projects/)
-│  └─ No → AREA (02-areas/)
-└─ No → Is it reference material?
-   ├─ Yes → RESOURCE (03-resources/)
-   └─ No → Is it completed/inactive?
-      ├─ Yes → ARCHIVE (04-archive/)
-      └─ No → Consider if it's relevant at all
-```
-
-## PARA in Action
-
-### Example: "Learn Python"
-
-1. **Starts as** Resource in `03-resources/programming/python.md`
-   - "Interesting topic, want to learn eventually"
-
-2. **Becomes** Area: `02-areas/personal/learning.md`
-   - "Learning is now an ongoing responsibility"
-
-3. **Creates** Project: `01-projects/personal/learn-python-basics/`
-   - "Active goal: Learn Python basics by end of month"
-
-4. **Generates** Tasks:
-   - `tasks/learning.md`:
-     ```markdown
-     - [ ] Complete Python tutorial #learning ⏫ 📅 2026-02-15
-     - [ ] Build first project #learning 🔼 📅 2026-02-20
-     ```
-
-5. **Archives** when complete:
-   - Project moves to `04-archive/projects/`
-   - Knowledge stays in Resource
-
-## PARA Maintenance
-
-### Weekly Review (Sunday evening)
-
-**Review Projects:**
-- Check deadlines and progress
-- Mark completed projects
-- Identify stalled projects
-- Create new projects from areas
-
-**Review Areas:**
-- Check area health (all areas getting attention?)
-- Identify areas needing projects
-- Update area goals
-
-**Review Resources:**
-- Organize recent additions
-- Archive outdated resources
-- Identify gaps
-
-**Process Inbox:**
-- File items into appropriate PARA category
-- Create projects if needed
-- Archive or delete irrelevant items
-
-### Monthly Review (1st of month)
-
-- Review all areas for health
-- Identify quarterly goals
-- Plan major projects
-- Archive old completed items
-
-### Quarterly Review
-
-- Big picture planning
-- Area rebalancing
-- Life goal alignment
-- System optimization
-
-## Common Questions
-
-**Q: Can something be both a Project and a Resource?**
-
-A: Yes, at different times. Example: "Productivity" starts as a Resource (you're interested in it). When you decide to "Implement productivity system," it becomes a Project. After implementation, best practices become a Resource again.
-
-**Q: How do I handle recurring tasks?**
-
-A: If recurring task supports an Area, keep task in Area file and create Project instances when needed:
-- Area: "Health" → "Annual physical" (recurring)
-- Project: "Schedule 2026 physical" (one-time action with deadline)
-
-**Q: What about someday/maybe items?**
-
-A: Two approaches:
-1. Keep in `tasks/someday.md` with low priority (🔽)
-2. Archive and retrieve when relevant (PARA encourages active items only)
-
-**Q: Should I organize by work vs personal?**
-
-A: PARA organizes by actionability, not domain. However, within Projects/Areas/Resources, you can create subfolders:
-- `01-projects/work/` and `01-projects/personal/`
-- `02-areas/work/` and `02-areas/personal/`
-
-## PARA + Obsidian Implementation
-
-**Wiki-links**: Use `[[Project Name]]` for connections
-
-**Tags**: Use `#work`, `#personal`, `#critical` for filtering
-
-**Dataview queries**: Create dashboard views:
-```dataview
-LIST WHERE status = "active"
-FROM "01-projects"
-SORT deadline ASC
-```
-
-**Templates**: Use `_chiron/templates/` for consistent structure
-
-**Tasks plugin**: Track tasks within PARA structure
-
-## References
-
-- [Forté Labs - PARA Method](https://fortelabs.com/blog/para/)
-- [Building a Second Brain](https://buildingasecondbrain.com/)
-- Obsidian Tasks Plugin documentation
-- Dataview Plugin documentation

skills/chiron-core/references/phase1-complete.md

@@ -1,347 +0,0 @@
----
-title: "Phase 1 Complete - Work Integration"
-type: summary
-completed: 2026-01-28
-tags: [work, integration, complete]
----
-
-# Phase 1 Complete: Work Integration Foundation
-
-## ✅ Status: Complete
-
-All Phase 1 tasks completed. Work integration foundation is ready to use.
-
----
-
-## 📦 What Was Delivered
-
-### Skills Created (4 new/updated)
-
-#### 1. Outline Skill (NEW)
-**Location**: `skills/outline/SKILL.md`
-**Features**:
-- Full MCP integration with Vortiago/mcp-outline
-- Search wiki documents
-- Read/export documents
-- Create/update Outline docs
-- AI-powered queries (`ask_ai_about_documents`)
-- Collection management
-- Batch operations
-
-**References**:
-- `references/outline-workflows.md` - Detailed usage examples
-- `references/export-patterns.md` - Obsidian integration patterns
-
-#### 2. Enhanced Basecamp Skill
-**Location**: `skills/basecamp/SKILL.md`
-**New Features**:
-- Project mapping configuration
-- Integration with PARA structure
-- Usage patterns for real projects
-
-#### 3. Enhanced Daily Routines Skill
-**Location**: `skills/daily-routines/SKILL.md`
-**New Features**:
-- Morning planning with Basecamp + Outline context
-- Evening reflection with work metrics
-- Weekly review with project status tracking
-- Work area health review
-- Work inbox processing
-
-#### 4. Enhanced Meeting Notes Skill
-**Location**: `skills/meeting-notes/references/teams-transcript-workflow.md`
-**New Features**:
-- Teams transcript processing workflow
-- Manual DOCX → text → AI analysis → meeting note → Basecamp sync
-- Complete templates and troubleshooting guide
-
-### Documentation Created (3)
-
-#### 1. Work PARA Structure Guide
-**Location**: `skills/chiron-core/references/work-para-structure.md`
-**Content**: Complete PARA organization for work
-- Directory tree with projects/areas/resources
-- Project mapping to Basecamp
-- Integration workflows
-- Job transition checklist
-- Quick command reference
-
-#### 2. Work Quick Start Guide
-**Location**: `skills/chiron-core/references/work-quickstart.md`
-**Content**: User-facing quick reference
-- First-time setup instructions
-- Daily workflow examples
-- Tool-specific command patterns
-- Integration use cases
-- Troubleshooting
-
-#### 3. Teams Transcript Workflow
-**Location**: `skills/meeting-notes/references/teams-transcript-workflow.md`
-**Content**: Complete manual workflow
-- Step-by-step transcript processing
-- AI analysis prompts
-- Obsidian templates
-- Basecamp sync integration
-- Automation points for n8n (future)
-
-### PARA Structure Created
-
-#### Work Projects
-**Location**: `~/CODEX/01-projects/work/`
-**Created**: 10 project folders (placeholders for customization)
-
-Projects:
-1. api-integration-platform
-2. customer-portal-redesign
-3. marketing-campaign-q1
-4. security-audit-2026
-5. infrastructure-migration
-6. mobile-app-v20
-7. team-onboarding-program
-8. data-analytics-dashboard
-9. documentation-revamp
-10. api-gateway-upgrade
-
-Each project includes:
-- `_index.md` (MOC with Basecamp link)
-- `meetings/` directory
-- `decisions/` directory
-- `notes/` directory
-
-#### Work Areas
-**Location**: `~/CODEX/02-areas/work/`
-**Created**: 5 area files
-
-Areas:
-1. current-job.md - Current employment responsibilities
-2. professional-dev.md - Learning and career development
-3. team-management.md - Team coordination and leadership
-4. company-knowledge.md - Organization context and processes
-5. technical-excellence.md - Code quality and standards
-
-#### Work Resources
-**Location**: `~/CODEX/03-resources/work/wiki-mirror/`
-**Purpose**: Ready for Outline wiki exports
-
-#### Work Archive
-**Location**: `~/CODEX/04-archive/work/`
-**Purpose**: Ready for completed work and job transitions
-
----
-
-## 🔄 Integrations Configured
-
-### Basecamp ↔ Obsidian
-- Project mapping infrastructure ready
-- Morning planning fetches Basecamp todos
-- Evening reflection reviews project progress
-- Weekly review checks all project status
-
-### Outline ↔ Obsidian
-- Search wiki for work context
-- Export decisions/docs to vault
-- AI-powered knowledge discovery
-- Wiki index management
-
-### Teams → Obsidian → Basecamp
-- Manual DOCX processing workflow
-- AI analysis of transcripts
-- Meeting note creation
-- Optional action items sync to Basecamp
-- Complete documentation and troubleshooting
-
-### All Integrated into Daily/Weekly Routines
-- Morning: Basecamp + Outline + personal priorities
-- Evening: Work metrics + personal reflection
-- Weekly: Project status + area health + planning
-
----
-
-## 🚀 Ready to Use
-
-### Immediate Workflows
-
-#### Morning Planning with Work
-```bash
-"/chiron-start"
-```
-**What happens**:
-1. Checks yesterday's completed tasks
-2. Fetches today's Basecamp todos
-3. Checks Outline for relevant docs
-4. Creates integrated morning plan
-
-#### Evening Reflection with Work
-```bash
-"/chiron-end"
-```
-**What happens**:
-1. Reviews completed Basecamp tasks
-2. Reviews project progress
-3. Captures work learnings
-4. Plans tomorrow's work priorities
-
-#### Weekly Work Review
-```bash
-"/chiron-review"
-```
-**What happens**:
-1. Checks all Basecamp project status
-2. Reviews work area health
-3. Identifies at-risk projects
-4. Plans next week's priorities
-
-#### Project Status Check
-```bash
-"What's in [project name]?"
-"What's status of API Integration Platform?"
-```
-**What happens**:
-- Fetches from Basecamp
-- Shows completion status
-- Lists overdue items
-- Highlights blockers
-
-#### Wiki Search
-```bash
-"Search Outline for API authentication"
-"Ask Outline: How do we handle rate limiting?"
-```
-**What happens**:
-- Searches Outline wiki
-- Returns relevant documents
-- AI synthesizes across docs
-
-#### Teams Transcript Processing
-```bash
-"Process transcript: meeting.docx"
-```
-**What happens**:
-1. Extracts text from DOCX
-2. AI analyzes: attendees, topics, decisions, action items
-3. Creates meeting note in Obsidian
-4. Optionally syncs action items to Basecamp
-
----
-
-## 📋 Your Next Steps (Optional)
-
-### 1. Customize Projects (Recommended)
-
-The 10 project folders use placeholder names. Customize with your actual Basecamp projects:
-
-```bash
-# Option A: Use Basecamp MCP (when ready)
-"Show my Basecamp projects"
-# → Get actual project names
-# → Update project folder names
-# → Update _index.md with real project IDs
-
-# Option B: Manual customization
-cd ~/CODEX/01-projects/work
-# Rename folders to match your actual projects
-# Update each _index.md frontmatter:
-#   - basecamp_id: "project_123"
-#   - basecamp_url: "https://..."
-#   - deadline: YYYY-MM-DD
-#   - status: active/on-hold
-```
-
-### 2. Configure Outline MCP
-
-```bash
-# Install Outline MCP server
-pip install mcp-outline
-
-# Configure in your Opencode/MCP client
-# See: https://github.com/Vortiago/mcp-outline
-# Set OUTLINE_API_KEY and OUTLINE_API_URL
-```
-
-### 3. Test Workflows
-
-Test each integration:
-- Morning planning with Basecamp fetch
-- Project status check
-- Wiki search
-- Evening reflection
-- Weekly review
-
-### 4. Process First Teams Transcript
-
-Follow the workflow:
-```bash
-# 1. Download transcript from Teams
-# 2. Extract text
-python extract_transcript.py meeting.docx
-
-# 3. Ask AI to analyze
-# 4. Create meeting note
-# 5. Optionally sync action items to Basecamp
-```
-
-### 5. Add n8n Automation (When Ready)
-
-When your cloud n8n is ready, add these workflows:
-
-1. **Daily Basecamp → Obsidian sync** - Export new todos/changes
-2. **Outline → Obsidian mirror** - Daily export of updated docs
-3. **Teams transcript auto-processing** - Watch folder, process automatically
-4. **Weekly report generation** - Aggregate work metrics
-5. **Mobile task reminders** - Send due tasks to ntfy
-
----
-
-## 🎯 Key Benefits
-
-### Tool Agnostic
-- All work knowledge in Obsidian (your vault)
-- Easy to switch jobs: archive work/, update tool configs
-- PARA methodology persists regardless of tools
-
-### Real-Time + Persistent
-- Basecamp: Real-time task tracking
-- Outline: Real-time wiki search
-- Obsidian: Persistent knowledge storage
-
-### AI-Powered
-- Teams transcripts: AI analysis of meetings
-- Wiki: AI-powered semantic search
-- Workflows: AI-assisted prioritization
-
-### Complete Integration
-- Morning plans include: Basecamp + Outline + personal
-- Evening reflections include: Work metrics + personal
-- Weekly reviews cover: Projects + areas + inbox
-
----
-
-## 📊 Commit Details
-
-**Commits**:
-- `e2932d1`: Initial Phase 1 implementation (skills + structure)
-- `325e06a`: Documentation (quickstart guide)
-- `e2932d1` (rebase): Final commit pushed to remote
-
-**Repository**: `code.m3ta.dev:m3tam3re/AGENTS.git`
-
----
-
-## 🔗 Documentation Links
-
-For detailed guides, see:
-
-- **Work PARA Structure**: `skills/chiron-core/references/work-para-structure.md`
-- **Quick Start**: `skills/chiron-core/references/work-quickstart.md`
-- **Basecamp Skill**: `skills/basecamp/SKILL.md`
-- **Outline Skill**: `skills/outline/SKILL.md`
-- **Daily Routines**: `skills/daily-routines/SKILL.md`
-- **Meeting Notes**: `skills/meeting-notes/references/teams-transcript-workflow.md`
-- **Outline Workflows**: `skills/outline/references/outline-workflows.md`
-- **Export Patterns**: `skills/outline/references/export-patterns.md`
-
----
-
-**Phase 1 Status**: ✅ COMPLETE
-
-**Last Updated**: 2026-01-28

skills/chiron-core/references/priority-matrix.md

@@ -1,270 +0,0 @@
-# Priority Matrix (Eisenhower)
-
-## The Matrix
-
-Prioritize tasks based on two dimensions:
-
-1. **Urgency** - Time-sensitive
-2. **Importance** - Impact on goals
-
-| | **Important** | **Not Important** |
-|---|---------------|------------------|
-| **Urgent** | ⏫ Critical 🔥 | 🔼 High (Do or Delegate) |
-| **Not Urgent** | 🔼 High (Schedule) | 🔽 Low (Eliminate) |
-
-## Quadrant Breakdown
-
-### Quadrant 1: Urgent & Important (⏫ Critical)
-
-**Do immediately. These are crises or deadlines.**
-
-**Characteristics:**
-- Time-sensitive
-- Has direct impact
-- Must be done now
-- Often stressful
-
-**Examples:**
-- Project due today
-- Client emergency
-- Health issue
-- Financial deadline
-
-**Strategy:**
-- Handle now
-- Identify root causes (why was it urgent?)
-- Prevent recurrence through planning
-
-### Quadrant 2: Not Urgent & Important (🔼 High - Schedule)
-
-**This is where quality happens. These are your priorities.**
-
-**Characteristics:**
-- Strategic work
-- Long-term goals
-- Personal growth
-- Relationship building
-
-**Examples:**
-- Strategic planning
-- Skill development
-- Exercise
-- Deep work projects
-- Relationship time
-
-**Strategy:**
-- **Block time** on calendar
-- Protect from interruptions
-- Schedule first (before urgent items)
-- This should be 60-80% of your time
-
-### Quadrant 3: Urgent & Not Important (🔼 High - Do or Delegate)
-
-**These are distractions. Minimize or delegate.**
-
-**Characteristics:**
-- Time-sensitive but low impact
-- Other people's priorities
-- Interruptions
-- Some meetings
-
-**Examples:**
-- Most email
-- Some meetings
-- Coworker requests
-- Unscheduled calls
-- Many notifications
-
-**Strategy:**
-- **Delegate** if possible
-- Say no more often
-- Batch process (check email 2x/day)
-- Set expectations about response time
-- Aim to minimize this to <20%
-
-### Quadrant 4: Not Urgent & Not Important (🔽 Low - Eliminate)
-
-**These are time-wasters. Remove them.**
-
-**Characteristics:**
-- No urgency
-- No importance
-- Entertainment masquerading as work
-- Habits that don't serve you
-
-**Examples:**
-- Doom scrolling
-- Excessive social media
-- Mindless TV
-- Busy work that has no impact
-- Low-priority tasks you procrastinate on
-
-**Strategy:**
-- **Eliminate** ruthlessly
-- Set time limits
-- Use app blockers if needed
-- Replace with value activities
-
-## Task Priority Symbols
-
-Use these symbols in your task format:
-
-```markdown
-- [ ] Task description #tag ⏫ 📅 YYYY-MM-DD
-```
-
-| Symbol | Meaning | When to use |
-|--------|---------|-------------|
-| ⏫ | Critical (Q1) | Urgent AND important |
-| 🔼 | High (Q2/Q3) | Important but not urgent OR urgent but delegate-able |
-| 🔽 | Low (Q4) | Neither urgent nor important |
-
-## Daily Prioritization Workflow
-
-### Morning Plan
-
-1. **List all tasks for today**
-2. **Categorize by quadrant**:
-   ```
-   ⏫ Critical (Do Now):
-   - [Task 1]
-   - [Task 2]
-
-   🔼 High (Schedule):
-   - [Task 3]
-   - [Task 4]
-
-   🔽 Low (Maybe):
-   - [Task 5]
-   ```
-
-3. **Limit Critical tasks**: Max 3-4 per day
-4. **Schedule High tasks**: Block time on calendar
-5. **Eliminate Low tasks**: Remove or move to someday/maybe
-
-### Time Blocking
-
-**Rule of thumb:**
-- 60-80% in Quadrant 2 (strategic work)
-- 20% in Quadrant 1 (crises)
-- <20% in Quadrant 3 (distractions)
-- 0% in Quadrant 4 (eliminate)
-
-**Example schedule:**
-```
-9:00-11:00  Deep work (Q2) - Project X
-11:00-11:30 Handle crises (Q1) - Urgent email
-11:30-12:30 Deep work (Q2) - Project X
-12:30-13:30 Lunch & break
-13:30-14:30 Distractions (Q3) - Batch email
-14:30-16:30 Deep work (Q2) - Project Y
-16:30-17:00 Wrap up (Q1)
-```
-
-## Energy-Based Prioritization
-
-Not all critical tasks should be done at the same time. Consider:
-
-| Energy Level | Best Tasks |
-|--------------|------------|
-| High (morning) | Complex, creative work (Q2) |
-| Medium (midday) | Communication, meetings (Q3) |
-| Low (evening) | Admin, simple tasks (Q1 easy wins) |
-
-**Morning energy:**
-- Complex problem-solving
-- Writing
-- Creative work
-- Strategic thinking
-
-**Midday energy:**
-- Meetings
-- Email
-- Calls
-- Collaboration
-
-**Low energy:**
-- Admin tasks
-- Filing
-- Planning
-- Review
-
-## Context-Specific Prioritization
-
-Different contexts require different approaches:
-
-**Work context:**
-- Prioritize team deadlines
-- Consider stakeholder expectations
-- Balance strategic vs tactical
-
-**Personal context:**
-- Prioritize health and well-being
-- Consider relationships
-- Balance work-life boundaries
-
-**Emergency context:**
-- Quadrant 1 dominates
-- Defer Q2 tasks
-- Accept disruption to normal flow
-
-## Common Pitfalls
-
-### **Mistreating Urgency for Importance**
-
-**Problem**: Responding to urgent but unimportant items (Q3) first.
-
-**Solution**: Start with Q2 (schedule important work) before checking email/notifications.
-
-### **Overcommitting to Critical (Q1)**
-
-**Problem**: Having 10+ critical tasks creates paralysis and stress.
-
-**Solution**: Limit to 3-4 critical tasks per day. Move rest to Q2 with realistic deadlines.
-
-### **Neglecting Q2**
-
-**Problem**: Always in reactive mode, never proactive.
-
-**Solution**: Schedule 60-80% of time for Q2. Protect these blocks fiercely.
-
-### **Faking Urgency**
-
-**Problem**: Making tasks urgent to avoid doing them (procrastination disguised as crisis).
-
-**Solution**: Question urgency. "Is this truly time-sensitive, or just uncomfortable?"
-
-### **Perfectionism in Q2**
-
-**Problem**: Spending too long on strategic planning, never executing.
-
-**Solution**: Set time limits for planning. Action produces learning.
-
-## Integration with Chiron Workflows
-
-**Morning Plan**: Use matrix to identify 3-5 ⏫ critical tasks and schedule Q2 blocks
-
-**Weekly Review**: Evaluate how much time was spent in each quadrant, adjust for next week
-
-**Daily Review**: Review urgency/importance of remaining tasks
-
-**Project Planning**: Break projects into Q2 tasks, identify potential Q1 crises
-
-## Quick Reference
-
-```
-⏫ = Do now (Urgent + Important)
-🔼 = Schedule (Important) OR Delegate (Urgent but not important)
-🔽 = Eliminate (Neither urgent nor important)
-
-Goal: 60-80% time on 🔼 (Quadrant 2)
-Limit ⏫ to 3-4 per day
-Minimize 🔼 (Quadrant 3) to <20%
-Eliminate 🔽
-```
-
-## Resources
-
-- [Eisenhower Matrix on Wikipedia](https://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method)
-- [Atomic Habits - Habits matrix](https://jamesclear.com/habit-tracker)
-- Deep Work (Cal Newport) - Protecting Q2 time

skills/chiron-core/references/reflection-questions.md

@@ -1,288 +0,0 @@
-# Reflection Questions for Weekly Review
-
-Use these questions during weekly reviews to drive insights and improvement.
-
-## Weekly Review Questions
-
-### Metrics & Data
-
-1. **What numbers tell the story?**
-   - Tasks completed: ___
-   - Deep work hours: ___
-   - Meetings attended: ___
-   - Focus score (1-10): ___
-   - Energy level (1-10): ___
-
-2. **What do the numbers reveal?**
-   - Any patterns in productivity?
-   - When was I most productive?
-   - What drained my energy?
-
-### Wins & Celebrations
-
-3. **What were my top 3 wins this week?**
-   - Win 1: ___
-   - Win 2: ___
-   - Win 3: ___
-
-4. **What made these wins possible?**
-   - What worked well?
-   - What systems/habits helped?
-   - How can I replicate this?
-
-5. **What am I proud of (not just achievements)?**
-   - Personal growth
-   - Character strengths shown
-   - Values demonstrated
-
-### Challenges & Blockers
-
-6. **What didn't go as planned?**
-   - What tasks slipped?
-   - What blocked progress?
-   - What unexpected challenges arose?
-
-7. **What were the root causes?**
-   - External factors?
-   - Personal patterns?
-   - System failures?
-
-8. **How did I respond to challenges?**
-   - What did I do well?
-   - What could I have done differently?
-   - What did I learn from this?
-
-### Learnings & Insights
-
-9. **What did I learn this week?**
-   - New skills or knowledge?
-   - New perspectives or insights?
-   - Things that don't work?
-
-10. **What surprised me?**
-    - About my work?
-    - About myself?
-    - About my environment?
-
-11. **What patterns am I noticing?**
-    - Productivity patterns?
-    - Energy patterns?
-    - Thought patterns?
-    - Relationship patterns?
-
-### Areas Review
-
-12. **How are my key areas?**
-    For each Area (Work, Health, Finances, Relationships, Learning, etc.):
-    - Health: ___/10 (needs attention/good/excellent)
-    - Finances: ___/10
-    - Work: ___/10
-    - [Other areas...]
-
-13. **Which areas need attention next week?**
-    - Area 1: Why? What's needed?
-    - Area 2: Why? What's needed?
-
-### Projects Review
-
-14. **What's the status of my active projects?**
-    - Project 1: On track / behind / ahead
-    - Project 2: On track / behind / ahead
-    - ...
-
-15. **Which projects need adjustment?**
-    - What needs to change?
-    - New deadlines?
-    - Re-prioritization?
-
-16. **Should I start or stop any projects?**
-    - Start: ___ (why?)
-    - Stop: ___ (why?)
-
-### Time & Energy
-
-17. **How did I spend my time?**
-    - Quadrant 1 (crises): ___%
-    - Quadrant 2 (strategic): ___%
-    - Quadrant 3 (distractions): ___%
-    - Quadrant 4 (waste): ___%
-
-18. **What drained my energy?**
-    - What activities left me exhausted?
-    - What environments were draining?
-    - What interactions were tiring?
-
-19. **What energized me?**
-    - What activities gave me energy?
-    - What environments felt good?
-    - What interactions were uplifting?
-
-### Relationships & Collaboration
-
-20. **Who helped me this week?**
-    - [Name] - How they helped
-    - [Name] - How they helped
-
-21. **How did I support others?**
-    - Who did I help?
-    - What value did I provide?
-
-22. **Any relationship issues to address?**
-    - Conflicts?
-    - Miscommunications?
-    - Appreciation due?
-
-### System & Process Review
-
-23. **How is my PARA system working?**
-    - Inbox: Clean / Overflowing
-    - Projects: Organized / Messy
-    - Resources: Useful / Neglected
-    - Tasks: Clear / Overwhelming
-
-24. **What needs adjustment in my systems?**
-    - Capture process?
-    - Organization?
-    - Review frequency?
-    - Tools or workflows?
-
-25. **What new habit should I try?**
-    - Based on this week's learnings?
-
-### Next Week Planning
-
-26. **What are my top 3 priorities for next week?**
-    - Priority 1: ___ (why this?)
-    - Priority 2: ___ (why this?)
-    - Priority 3: ___ (why this?)
-
-27. **What MUST get done next week?**
-    - Non-negotiables (deadlines, commitments)
-
-28. **What would make next week amazing?**
-    - Stretch goals
-    - Experiments
-    - Fun activities
-
-### Personal Growth
-
-29. **How did I grow as a person this week?**
-    - Character development?
-    - New perspectives?
-    - Overcoming fears?
-
-30. **What am I grateful for?**
-    - List 3-5 things
-
-31. **What's one thing I forgive myself for?**
-    - Mistake?
-    - Shortcoming?
-    - Imperfection?
-
-## Monthly Review Questions
-
-Use these in addition to weekly questions on the 1st of each month:
-
-### Big Picture
-
-1. **What was my main focus this month?**
-2. **Did I achieve my monthly goals?**
-3. **What was my biggest accomplishment?**
-4. **What was my biggest challenge?**
-5. **How have I changed this month?**
-
-### Goal Progress
-
-6. **How are my annual goals progressing?**
-   - Goal 1: On track / behind / ahead
-   - Goal 2: On track / behind / ahead
-
-7. **Do my goals need adjustment?**
-   - New goals to add?
-   - Old goals to remove?
-   - Deadlines to change?
-
-### Life Balance
-
-8. **How balanced is my life right now?**
-   - Work vs personal
-   - Health vs neglect
-   - Giving vs receiving
-
-9. **What area of life needs most attention?**
-10. **What am I ignoring that needs attention?**
-
-### System Optimization
-
-11. **What isn't working in my systems?**
-12. **What could be automated?**
-13. **What could be simplified?**
-14. **What new system would help?**
-
-## Quarterly Review Questions
-
-Use these for strategic planning every 3 months:
-
-### Vision & Direction
-
-1. **Am I still on the right path?**
-2. **What's changed in my life/situation?**
-3. **Are my goals still relevant?**
-4. **What's my vision for next quarter?**
-
-### Strategic Goals
-
-5. **What are my 3 strategic priorities for this quarter?**
-6. **What projects support these priorities?**
-7. **What should I say NO to?**
-8. **What opportunities should I pursue?**
-
-### Life Design
-
-9. **Am I designing my life or just reacting to it?**
-10. **What would make this quarter exceptional?**
-11. **What risks should I take?**
-12. **What would happen if I did nothing differently?**
-
-## Using These Questions
-
-### Weekly Review (30-60 min)
-
-**Recommended flow:**
-1. Review completed tasks (5 min)
-2. Answer Wins questions (10 min)
-3. Answer Challenges questions (10 min)
-4. Answer Learnings questions (10 min)
-5. Review Areas & Projects (10 min)
-6. Review Time & Energy (10 min)
-7. Plan next week (10 min)
-8. Personal growth reflection (5 min)
-
-**Skip questions that don't resonate.** Quality > quantity.
-
-### Monthly Review (60-90 min)
-
-Add monthly questions to weekly review process.
-
-### Quarterly Review (2-3 hours)
-
-Dedicate focused time for strategic thinking. Consider:
-- Away from daily environment
-- Journaling and reflection
-- Visioning exercises
-- Deep thinking about life direction
-
-## Tips for Good Reflections
-
-1. **Be honest** - No one else will see this. Truthful answers lead to growth.
-2. **Be specific** - "I was tired" → "I was tired because I stayed up late on Tuesday watching videos"
-3. **Be kind to yourself** - Self-criticism without self-compassion = paralysis
-4. **Focus on systems** - "I failed" → "What system failed? How can I fix it?"
-5. **Look for patterns** - One week is data, four weeks is a pattern
-6. **Turn insights into action** - Each learning → one concrete change
-
-## Resources
-
-- [The Review System](https://praxis.fortelabs.co/review/)
-- [Atomic Habits - Self-reflection](https://jamesclear.com/habit-tracker)
-- [Bullet Journal Migration](https://bulletjournal.com/blogs/bullet-journal-news/the-migration)

skills/chiron-core/references/work-para-structure.md

@@ -1,157 +0,0 @@
----
-title: "Work PARA Structure"
-type: index
-created: 2026-01-28
----
-
-# Work PARA Structure
-
-## Overview
-PARA structure for work-related projects, areas, and resources. Designed for tool-agnostic knowledge management.
-
-## Directory Tree
-
-```
-~/CODEX/
-├── 01-projects/work/              # Active work projects
-│   ├── api-integration-platform/
-│   │   ├── _index.md
-│   │   ├── meetings/
-│   │   ├── decisions/
-│   │   └── notes/
-│   ├── customer-portal-redesign/
-│   │   └── (same structure)
-│   ├── marketing-campaign-q1/
-│   ├── security-audit-2026/
-│   ├── infrastructure-migration/
-│   ├── mobile-app-v20/
-│   ├── team-onboarding-program/
-│   ├── data-analytics-dashboard/
-│   ├── documentation-revamp/
-│   └── api-gateway-upgrade/
-│
-├── 02-areas/work/               # Ongoing work responsibilities
-│   ├── current-job.md
-│   ├── professional-dev.md
-│   ├── team-management.md
-│   ├── company-knowledge.md
-│   └── technical-excellence.md
-│
-├── 03-resources/work/           # Work reference material
-│   └── wiki-mirror/             # Outline wiki exports
-│       └── _wiki-index.md
-│
-└── 04-archive/work/           # Completed work
-    ├── projects/              # Finished projects
-    └── employment/           # Job transitions
-```
-
-## Project Mapping
-
-| Basecamp Project | PARA Path | Type | Status | Deadline |
-|----------------|-----------|-------|---------|-----------|
-| API Integration Platform | `01-projects/work/api-integration-platform` | Engineering | Active | 2026-03-15 |
-| Customer Portal Redesign | `01-projects/work/customer-portal-redesign` | Product/Design | Active | 2026-04-30 |
-| Marketing Campaign Q1 | `01-projects/work/marketing-campaign-q1` | Marketing | Active | 2026-02-28 |
-| Security Audit 2026 | `01-projects/work/security-audit-2026` | Security | Active | 2026-03-31 |
-| Infrastructure Migration | `01-projects/work/infrastructure-migration` | Operations | Active | 2026-06-30 |
-| Mobile App v2.0 | `01-projects/work/mobile-app-v20` | Product | On Hold | 2026-05-15 |
-| Team Onboarding Program | `01-projects/work/team-onboarding-program` | HR/Operations | Active | 2026-02-15 |
-| Data Analytics Dashboard | `01-projects/work/data-analytics-dashboard` | Engineering | Active | 2026-04-15 |
-| Documentation Revamp | `01-projects/work/documentation-revamp` | Documentation | Active | 2026-03-30 |
-| API Gateway Upgrade | `01-projects/work/api-gateway-upgrade` | Engineering | On Hold | 2026-07-31 |
-
-## Integration Points
-
-### Basecamp Integration
-- **Skill**: `basecamp` (MCP)
-- **Mapping**: See Basecamp project IDs → PARA paths
-- **Sync**: Manual sync via skill or future n8n automation
-- **Status Check**: "What's in [project]?" → Basecamp
-
-### Outline Wiki Integration
-- **Skill**: `outline` (MCP)
-- **Live Search**: "Search Outline for [topic]"
-- **Export**: "Export [document] to Obsidian"
-- **Location**: `03-resources/work/wiki-mirror/`
-
-### Teams Meeting Integration
-- **Skill**: `meeting-notes`
-- **Workflow**: DOCX → AI analysis → meeting note → Basecamp sync
-- **Location**: `01-projects/work/[project]/meetings/`
-- **Guide**: See `skills/meeting-notes/references/teams-transcript-workflow.md`
-
-## Workflows
-
-### Morning Planning with Work Context
-```
-1. Read yesterday's daily note
-2. Check Basecamp: "Show my Basecamp todos due today"
-3. Check Outline: "Search Outline for [project topic]"
-4. Create integrated morning plan with:
-   - Work priorities (from Basecamp)
-   - Personal priorities (from PARA)
-   - Meeting schedule
-   - Deep work blocks
-```
-
-### Evening Reflection with Work Context
-```
-1. Review completed Basecamp tasks
-2. Review project progress
-3. Capture work learnings
-4. Export decisions to Outline (if applicable)
-5. Plan tomorrow's work priorities
-```
-
-### Weekly Review with Work
-```
-1. Check all Basecamp project status
-2. Review work area health
-3. Identify at-risk projects
-4. Plan next week's priorities
-5. Process work inbox
-```
-
-## Job Transition Checklist
-
-When switching jobs:
-
-1. **Archive Current Work**:
-   - Move `01-projects/work/` → `04-archive/work/[old-company]/`
-   - Move `02-areas/work/` → `04-archive/work/[old-company]/`
-   - Keep `03-resources/work/wiki-mirror/` (company knowledge)
-
-2. **Update Tool Configurations**:
-   - Basecamp: Remove old projects, add new ones
-   - Outline: Update collections (if switching wikis)
-   - Keep work structure intact
-
-3. **Create New Work Structure**:
-   - Create new `01-projects/work/` folders
-   - Update `02-areas/work/` areas
-   - Preserve PARA methodology
-
-## Quick Commands
-
-| Action | Command |
-|--------|----------|
-| Start work day | "/chiron-start" → morning planning with Basecamp |
-| End work day | "/chiron-end" → reflection with work metrics |
-| Weekly review | "/chiron-review" → work project status review |
-| Check Basecamp | "Show my Basecamp projects" or "What's in [project]?" |
-| Search wiki | "Search Outline for [topic]" |
-| Process meeting | "Process transcript: [file.docx]" |
-| Project status | "What's status of [project name]?" |
-
-## Notes
-
-- All work knowledge stored in Obsidian (tool-agnostic)
-- Basecamp used for real-time task tracking
-- Outline used for live wiki access
-- Teams transcripts processed with AI analysis
-- n8n automation ready for future implementation
-
----
-
-**Last updated**: 2026-01-28

skills/chiron-core/references/work-quickstart.md

@@ -1,374 +0,0 @@
-# Work Integration Quick Start Guide
-
-Quick reference for using your work integration with Basecamp, Outline, and Teams.
-
-## 🚀 First-Time Setup
-
-### 1. Customize Your Projects
-
-The 10 projects in `01-projects/work/` are placeholders. Customize them:
-
-```bash
-# Option A: Fetch from Basecamp (when MCP is ready)
-"Show my Basecamp projects" → Get actual project names
-
-# Option B: Manual customization
-cd ~/CODEX/01-projects/work
-# Rename folders to match your actual Basecamp projects
-# Update each _index.md with:
-#   - Correct project name
-#   - Actual Basecamp project ID
-#   - Real deadline
-#   - Actual status
-```
-
-### 2. Set Up Outline MCP
-
-```bash
-# Install Outline MCP server
-pip install mcp-outline
-
-# Configure in your Opencode/MCP client
-# See: https://github.com/Vortiago/mcp-outline
-# Set OUTLINE_API_KEY and OUTLINE_API_URL
-```
-
-### 3. Test Basecamp Connection
-
-```bash
-# Test Basecamp MCP
-"Show my Basecamp projects"
-
-# Should list your actual projects
-# If successful, ready to use
-```
-
----
-
-## 📅 Daily Work Workflow
-
-### Morning Planning
-
-```
-"Start day" or "/chiron-start"
-```
-
-**What happens**:
-1. Checks yesterday's completed tasks
-2. Fetches today's Basecamp todos
-3. Searches Outline for relevant wiki docs
-4. Creates integrated morning plan
-
-**Output includes**:
-- Work priorities (from Basecamp)
-- Personal priorities (from PARA areas)
-- Meeting schedule
-- Deep work blocks protected
-
-### During Work Day
-
-**Check Basecamp status**:
-```bash
-"What's in API Integration Platform?"
-"Show my Basecamp todos due today"
-"Search Basecamp for OAuth2"
-```
-
-**Search wiki for context**:
-```bash
-"Search Outline for authentication best practices"
-"Search Outline for API rate limiting"
-```
-
-**Quick capture**:
-```bash
-"Capture: OAuth2 needs refresh token logic"
-# → Saved to 00-inbox/work/
-```
-
-**Process meeting transcript**:
-```bash
-"Process transcript: api-design-review.docx"
-# → Creates meeting note
-# → Extracts action items
-# → Optionally syncs to Basecamp
-```
-
-### Evening Reflection
-
-```
-"End day" or "/chiron-end"
-```
-
-**What happens**:
-1. Reviews completed Basecamp tasks
-2. Captures work wins and learnings
-3. Checks project progress
-4. Plans tomorrow's work priorities
-5. Updates work metrics
-
----
-
-## 📊 Weekly Work Review
-
-```
-"Weekly review" or "/chiron-review"
-```
-
-**What happens**:
-1. Checks all Basecamp project status (completion %, overdue items)
-2. Reviews work area health
-3. Identifies at-risk projects
-4. Plans next week's work priorities
-5. Processes work inbox
-
-**Output includes**:
-- Work metrics (tasks completed, projects progressed)
-- Work wins and challenges
-- Project status overview (on track, behind, at risk)
-- Work area health review
-- Next week's priorities
-
----
-
-## 🔧 Tool-Specific Commands
-
-### Basecamp (Project Management)
-
-**List all projects**:
-```bash
-"Show my Basecamp projects"
-```
-
-**Check project status**:
-```bash
-"What's in API Integration Platform?"
-"What's status of Customer Portal Redesign?"
-```
-
-**Create todos**:
-```bash
-"Add todos to API Integration Platform"
-# → Prompts for: project, todo list, tasks with due dates
-```
-
-**Search content**:
-```bash
-"Search Basecamp for OAuth2"
-```
-
-### Outline (Wiki Knowledge)
-
-**Search wiki**:
-```bash
-"Search Outline for API authentication"
-"Ask Outline: How do we handle rate limiting?"
-```
-
-**Read document**:
-```bash
-"Show me OAuth2 Setup Guide"
-```
-
-**Export to Obsidian**:
-```bash
-"Export OAuth2 Setup Guide to Obsidian"
-# → Saves to 03-resources/work/wiki-mirror/
-# → Adds frontmatter with outline source
-# → Links to related projects/areas
-```
-
-**Create wiki document**:
-```bash
-"Create Outline doc: API Authentication Decision"
-# → Creates in Outline with provided content
-# → Adds to appropriate collection
-```
-
-### Teams (Meetings)
-
-**Process transcript**:
-```bash
-"Process transcript: [filename.docx]"
-```
-
-**Workflow**:
-1. Upload transcript file
-2. Extract text from DOCX
-3. AI analysis extracts: attendees, topics, decisions, action items
-4. Creates meeting note in Obsidian
-5. Optionally syncs action items to Basecamp
-
-**Manual steps** (see `skills/meeting-notes/references/teams-transcript-workflow.md`):
-```bash
-# Step 1: Download transcript from Teams
-# Step 2: Extract text
-python extract_transcript.py transcript.docx
-
-# Step 3: Ask AI to analyze
-# (Paste transcript into AI prompt from workflow guide)
-
-# Step 4: Create meeting note using meeting-notes skill
-
-# Step 5 (Optional): Sync action items to Basecamp
-```
-
----
-
-## 🎯 Quick Reference
-
-| I Want To... | Command | Tool |
-|----------------|----------|-------|
-| See today's work | "/chiron-start" | Morning planning |
-| Review my day | "/chiron-end" | Evening reflection |
-| See project status | "What's in [project]?" | Basecamp |
-| Find wiki info | "Search Outline for [topic]" | Outline |
-| Process meeting | "Process transcript: [file]" | Teams + AI |
-| Weekly review | "/chiron-review" | Weekly review |
-| Create wiki doc | "Create Outline doc: [title]" | Outline |
-| Export wiki doc | "Export [doc] to Obsidian" | Outline |
-| Quick capture | "Capture: [thought]" | Quick capture |
-
----
-
-## 🔗 Integration Examples
-
-### Example 1: Starting a New Project
-
-```bash
-# 1. Create project in PARA (manually or from plan-writing)
-# 2. Create project folder in 01-projects/work/
-# 3. Link to Basecamp (if project exists there)
-
-User: "What's the status of API Integration Platform in Basecamp?"
-→ Gets: 65% complete, next milestone: OAuth2 endpoints
-
-User: "Search Outline for OAuth2 setup guides"
-→ Gets: 3 relevant documents
-
-User: "Export OAuth2 Setup Guide to Obsidian"
-→ Saves to project/notes/oauth2-setup-guide.md
-→ Links from project MOC
-```
-
-### Example 2: Processing a Meeting
-
-```bash
-User: "Process transcript: api-design-review.docx"
-
-System:
-1. Extracts text from DOCX
-2. AI analyzes: attendees, topics, decisions, action items
-3. Creates meeting note: 01-projects/work/api-integration-platform/meetings/api-design-review-20260128.md
-4. Outputs action items:
-   - [ ] Create OAuth2 implementation guide #meeting #todo 🔼 👤 @alice 📅 2026-02-05
-   - [ ] Document rate limiting policy #meeting #todo 🔼 👤 @bob 📅 2026-02-10
-
-User: "Sync action items to Basecamp?"
-→ System creates 2 todos in API Integration Platform project
-→ Assigns to Alice and Bob
-→ Sets due dates
-```
-
-### Example 3: Daily Work Flow
-
-```bash
-Morning:
-"/chiron-start"
-→ Gets: 5 Basecamp todos due today
-→ Gets: 2 meetings scheduled
-→ Searches Outline: "API authentication patterns"
-→ Creates integrated plan:
-   - Work: Complete OAuth2 flow (P0)
-   - Work: Review dashboard mockups (P1)
-   - Meeting: Architecture review (2pm)
-   - Deep work: 9-11am (OAuth2)
-
-During work:
-"Search Basecamp for OAuth2"
-→ Finds: 3 docs, 2 todos
-
-Evening:
-"/chiron-end"
-→ Reviews: OAuth2 flow complete
-→ Captures: Learning about token refresh pattern
-→ Checks project: 70% complete now
-→ Plans: Tomorrow: Finish API endpoints
-```
-
----
-
-## 💡 Best Practices
-
-### Daily Use
-1. **Start with morning plan** - Sets focus for the day
-2. **Check Basecamp first** - Prioritize work tasks
-3. **Search Outline for context** - Get knowledge before starting
-4. **Quick capture interruptions** - Don't break flow, capture and continue
-5. **End with evening reflection** - Review and plan tomorrow
-
-### Weekly Use
-1. **Dedicated time** - 60-90 minutes for weekly review
-2. **Check all projects** - Don't forget any
-3. **Review area health** - Balance attention across responsibilities
-4. **Process inbox** - Keep 00-inbox/ clean
-5. **Plan next week** - Set priorities, don't just review
-
-### Tool Use
-1. **Basecamp for tasks** - Live task tracking
-2. **Outline for knowledge** - Persistent wiki access
-3. **Obsidian for storage** - Tool-agnostic knowledge
-4. **Teams transcripts** - Process within 24 hours
-5. **AI for analysis** - Extract insights from transcripts/docs
-
----
-
-## 🔧 Troubleshooting
-
-### Basecamp MCP Not Working
-**Check**:
-- MCP server running?
-- API key configured?
-- Connection to Basecamp?
-
-### Outline MCP Not Working
-**Check**:
-- `pip install mcp-outline` completed?
-- OUTLINE_API_KEY set?
-- OUTLINE_API_URL correct?
-
-### Project Not Found in Basecamp
-**Check**:
-- Project name matches exactly?
-- Project in correct workspace?
-
-### Wiki Search No Results
-**Try**:
-- Broader query (fewer keywords)
-- Remove collection_id to search everywhere
-- Use `ask_ai_about_documents` for semantic search
-
-### Transcript Processing Fails
-**Check**:
-- DOCX file valid?
-- `python-docx` installed?
-- AI prompt clear enough?
-
----
-
-## 📚 Documentation Links
-
-For detailed guides, see:
-
-- **PARA Work Structure**: `skills/chiron-core/references/work-para-structure.md`
-- **Basecamp Skill**: `skills/basecamp/SKILL.md`
-- **Outline Skill**: `skills/outline/SKILL.md`
-- **Daily Routines**: `skills/daily-routines/SKILL.md`
-- **Meeting Notes**: `skills/meeting-notes/SKILL.md`
-- **Teams Transcript Workflow**: `skills/meeting-notes/references/teams-transcript-workflow.md`
-- **Outline Workflows**: `skills/outline/references/outline-workflows.md`
-- **Export Patterns**: `skills/outline/references/export-patterns.md`
-
----
-
-**Last updated**: 2026-01-28

skills/communications/SKILL.md

@@ -1,78 +0,0 @@
----
-name: communications
-description: "Email and communication management with Proton Mail integration. Use when: (1) drafting emails, (2) managing follow-ups, (3) communication tracking, (4) message templates, (5) inbox management. Triggers: email, draft, reply, follow up, message, inbox, communication, respond to."
-compatibility: opencode
----
-
-# Communications
-
-Email and communication management for Proton Mail.
-
-## Status: Stub
-
-This skill is a placeholder for future development. Core functionality to be added:
-
-## Planned Features
-
-### Email Drafting
-- Context-aware draft generation
-- Tone matching (formal/casual)
-- Template-based responses
-
-### Follow-up Tracking
-- Waiting-for list management
-- Follow-up reminders
-- Response tracking
-
-### Inbox Management
-- Priority sorting
-- Quick triage assistance
-- Archive recommendations
-
-### Communication Templates
-- Common response patterns
-- Meeting request templates
-- Status update formats
-
-## Integration Points
-
-- **Proton Mail**: Primary email backend
-- **task-management**: Convert emails to tasks
-- **ntfy**: Important email alerts
-- **n8n**: Automation workflows
-
-## Quick Commands (Future)
-
-| Command | Description |
-|---------|-------------|
-| `draft reply to [context]` | Generate email draft |
-| `follow up on [topic]` | Check follow-up status |
-| `email template [type]` | Use saved template |
-| `inbox summary` | Overview of pending emails |
-
-## Proton Mail Integration
-
-API integration pending. Options:
-- Proton Bridge (local IMAP/SMTP)
-- n8n with email triggers
-- Manual copy/paste workflow initially
-
-## Communication Style Guide
-
-Based on Sascha's profile:
-- **Tone**: Professional but approachable
-- **Length**: Concise, get to the point
-- **Structure**: Clear ask/action at the top
-- **Follow-up**: Set clear expectations
-
-## Email Templates (Future)
-
-- Meeting request
-- Status update
-- Delegation request
-- Follow-up reminder
-- Thank you / acknowledgment
-
-## Notes
-
-Start with manual draft assistance. Proton Mail API integration can be added via n8n workflow when ready.

skills/daily-routines/SKILL.md

@@ -1,675 +0,0 @@
----
-name: daily-routines
-description: "Daily and weekly productivity workflows for Chiron system. Use when: (1) morning planning, (2) evening reflection, (3) weekly review, (4) prioritizing work, (5) reviewing progress. Triggers: morning, evening, weekly, review, planning, start day, end day, prioritize."
-compatibility: opencode
----
-
-# Daily Routines
-
-Morning planning, evening reflection, and weekly review workflows for the Chiron productivity system.
-
-## Workflows
-
-### Morning Plan (/chiron-start)
-
-**When user says**: "Start day", "Morning planning", "What's today?", "/chiron-start"
-
-**Steps:**
-
-1. **Read yesterday's daily note**
-   - File: `~/CODEX/daily/YYYY/MM/DD/YYYY-MM-DD.md`
-   - Extract: incomplete tasks, carry-over items
-
-2. **Check today's tasks**
-   - Read `~/CODEX/tasks/inbox.md`
-   - Scan project files for today's tasks
-   - Check calendar (via calendar-scheduling skill)
-
-3. **Prioritize using energy and deadlines**
-   - High energy: Complex, creative work (Quadrant 2)
-   - Medium energy: Communication, collaboration (Quadrant 3)
-   - Low energy: Admin, simple tasks (Quadrant 1 easy wins)
-
-4. **Create today's plan**
-   - 3-5 critical tasks (⏫)
-   - 5-8 high priority tasks (🔼)
-   - Schedule deep work blocks
-   - Identify quick wins
-
-5. **Generate daily note using template**
-   - Template: `_chiron/templates/daily-note.md`
-   - Fill: focus areas, energy blocks, tasks
-
-6. **Ask for confirmation**
-   - "Ready to start, or need to adjust?"
-
-**Output format:**
-```markdown
-# 🌅 Morning Plan - YYYY-MM-DD
-
-## Focus Areas (Top 3)
-1. [Priority 1] - [estimated time]
-2. [Priority 2] - [estimated time]
-3. [Priority 3] - [estimated time]
-
-## Deep Work Blocks
-- [9:00-11:00] [Project A]
-- [14:00-16:00] [Project B]
-
-## Quick Wins (<15min)
-- [Task 1]
-- [Task 2]
-- [Task 3]
-
-## Meetings
-- [10:00-11:00] [Meeting title]
-
-## Carried Over from Yesterday
-- [Task from yesterday]
-
-## Inbox to Process
-- [X] items in 00-inbox/ to process
-```
-
-**Delegation triggers:**
-- Calendar operations → `calendar-scheduling`
-- Task extraction → `task-management`
-- File operations → `obsidian-management`
-
-### Evening Reflection (/chiron-end)
-
-**When user says**: "End day", "Evening review", "How was today?", "/chiron-end"
-
-**Steps:**
-
-1. **Review completed tasks**
-   - Check off completed items in daily note
-   - Count completed vs planned
-   - Identify wins
-
-2. **Capture key learnings**
-   - What went well?
-   - What didn't?
-   - What surprised me?
-
-3. **Identify blockers**
-   - What stopped progress?
-   - What resources were missing?
-   - What context was challenging?
-
-4. **Update daily note**
-   - Mark completed tasks
-   - Add wins section
-   - Add challenges section
-   - Add learnings section
-
-5. **Plan tomorrow**
-   - Carry over incomplete tasks
-   - Identify tomorrow's priorities
-   - Note energy levels
-
-6. **Ask reflection question**
-   - Example: "What's one thing you're grateful for today?"
-
-**Output format:**
-```markdown
-# 🌙 Evening Reflection - YYYY-MM-DD
-
-## Tasks Completed
-- ✅ [Task 1]
-- ✅ [Task 2]
-- ⏭️ [Task 3 - carried over]
-
-## Wins
-1. [Win 1] - why this matters
-2. [Win 2] - why this matters
-3. [Win 3] - why this matters
-
-## Challenges
-- [Blocker 1] - impact and next step
-- [Blocker 2] - impact and next step
-
-## Learnings
-- [Learning 1]
-- [Learning 2]
-
-## Tomorrow's Focus
-1. [Priority 1]
-2. [Priority 2]
-3. [Priority 3]
-
-## Energy Level
-- Morning: ___/10
-- Midday: ___/10
-- Evening: ___/10
-
-## Reflection
-[User's response to reflection question]
-```
-
-**Delegation triggers:**
-- Task updates → `task-management`
-- Note updates → `obsidian-management`
-
-### Weekly Review (/chiron-review)
-
-**When user says**: "Weekly review", "Week planning", "/chiron-review"
-
-**Steps:**
-
-1. **Collect daily notes for the week**
-   - Read all daily notes from Monday-Sunday
-   - Extract: completed tasks, wins, challenges
-
-2. **Calculate metrics**
-   - Tasks completed count
-   - Deep work hours (estimate from daily notes)
-   - Focus score (self-rated from daily notes)
-   - Quadrant distribution (time spent)
-
-3. **Review project status**
-   - Scan all projects in `01-projects/`
-   - Check: status, deadlines, progress
-   - Identify: stalled projects, completed projects, new projects needed
-
-4. **Process inbox**
-   - Review items in `00-inbox/`
-   - File to appropriate PARA category
-   - Delete irrelevant items
-   - Create tasks from actionable items
-
-5. **Review area health**
-   - Check `02-areas/` files
-   - Identify areas needing attention
-   - Update area status (health scores)
-
-6. **Identify patterns and trends**
-   - Productivity patterns
-   - Energy patterns
-   - Recurring blockers
-
-7. **Plan next week**
-   - Top 3 priorities
-   - Key projects to focus on
-   - Areas to nurture
-   - New habits to try
-
-8. **Generate weekly review note**
-   - Template: `_chiron/templates/weekly-review.md`
-   - File: `~/CODEX/daily/weekly-reviews/YYYY-W##.md`
-
-**Output format:**
-```markdown
-# 📊 Weekly Review - W## (Mon DD-MMM to Sun DD-MMM)
-
-## Metrics
-- Tasks completed: NN
-- Deep work hours: NN
-- Focus score average: N.N/10
-- Energy score average: N.N/10
-- Quadrant distribution: Q1: NN%, Q2: NN%, Q3: NN%, Q4: NN%
-
-## Top 3 Wins
-1. [Win 1] - impact and why it mattered
-2. [Win 2] - impact and why it mattered
-3. [Win 3] - impact and why it mattered
-
-## Key Challenges
-- [Challenge 1] - root cause and solution
-- [Challenge 2] - root cause and solution
-
-## Patterns & Insights
-- Productivity pattern: [observation]
-- Energy pattern: [observation]
-- Recurring blocker: [observation]
-
-## Project Status
-
-### Completed
-- [Project 1] - outcome
-- [Project 2] - outcome
-
-### On Track
-- [Project 1] - progress, deadline
-- [Project 2] - progress, deadline
-
-### Behind Schedule
-- [Project 1] - why, what's needed
-
-### New Projects Started
-- [Project 1] - goals, deadline
-- [Project 2] - goals, deadline
-
-### Stalled Projects
-- [Project 1] - why stalled, action needed
-
-## Area Health Review
-
-| Area | Health | Needs Attention |
-|-------|--------|----------------|
-| Health | N/10 | [specific needs] |
-| Finances | N/10 | [specific needs] |
-| Work | N/10 | [specific needs] |
-| Relationships | N/10 | [specific needs] |
-| Learning | N/10 | [specific needs] |
-
-## Inbox Status
-- Items processed: NN
-- Items remaining: NN
-- Filed to Projects: NN
-- Filed to Resources: NN
-- Archived: NN
-- Deleted: NN
-
-## Next Week Priorities
-
-### Top 3
-1. [Priority 1] - why critical
-2. [Priority 2] - why important
-3. [Priority 3] - why important
-
-### Projects to Focus
-- [Project 1] - key milestone
-- [Project 2] - key milestone
-- [Project 3] - key milestone
-
-### Areas to Nurture
-- [Area 1] - specific focus
-- [Area 2] - specific focus
-
-### New Habits/Experiments
-- [Habit 1] - what to try
-- [Habit 2] - what to try
-
-## Reflection Question
-[Weekly reflection from chiron-core references/reflection-questions.md]
-```
-
-**Delegation triggers:**
-- PARA organization → `chiron-core`
-- Task aggregation → `task-management`
-- File operations → `obsidian-management`
-- Area review → `chiron-core`
-
-## Integration with Other Skills
-
-**Calls to:**
-- `obsidian-management` - Create/update daily notes, templates
-- `task-management` - Extract/update tasks
-- `chiron-core` - PARA guidance, prioritization, reflection questions
-- `calendar-scheduling` - Calendar integration
-- `basecamp` - Fetch work todos, check project status
-- `outline` - Search wiki for work context
-
-**Delegation rules:**
-- User wants to understand PARA → `chiron-core`
-- User asks about tasks → `task-management`
-- User needs file operations → `obsidian-management`
-- User needs calendar → `calendar-scheduling`
-- User needs work context → `basecamp`
-- User needs wiki knowledge → `outline`
-
----
-
-## Work Context Integration
-
-### Morning Planning with Work
-
-**Enhanced morning plan workflow:**
-
-```
-1. Read yesterday's daily note (personal + work)
-2. Check today's work todos:
-   - Delegate to basecamp skill: "Show my Basecamp todos due today"
-   - Get: project name, task title, due date, assignee
-3. Check project status:
-   - For each active work project:
-     Delegate to basecamp: "What's status of [project]?"
-     - Get: completion %, overdue items, next milestones
-4. Check wiki for relevant docs:
-   - Delegate to outline: "Search Outline for [topic]"
-   - Get: related docs, decisions, processes
-5. Create integrated morning plan:
-   - Personal priorities (from PARA areas)
-   - Work priorities (from Basecamp)
-   - Meeting schedule (from calendar)
-   - Deep work blocks aligned with energy
-```
-
-**Morning plan with work context:**
-```markdown
-# 🌅 Morning Plan - YYYY-MM-DD
-
-## Work Focus (Top 3)
-1. [[API Integration Platform]] - Complete OAuth flow (Basecamp: 3 todos today)
-2. [[Customer Portal Redesign]] - Review mockups (Basecamp: 2 todos due)
-3. [[Data Analytics Dashboard]] - Fix query performance (Basecamp: 1 overdue)
-
-## Personal Focus (Top 2)
-1. Health - Morning workout
-2. Finances - Review monthly budget
-
-## Deep Work Blocks
-- [9:00-11:00] [[API Integration Platform]] (High energy, no meetings)
-- [14:00-16:00] [[Customer Portal Redesign]] (Design work)
-
-## Meetings (Work)
-- [11:00-12:00] Project Sync (Teams)
-- [15:00-16:00] Architecture Review (Zoom)
-
-## Quick Wins (<15min)
-- [ ] Respond to urgent emails
-- [ ] Update project status in Basecamp
-- [ ] Process inbox items (3 items)
-
-## Work Wiki Resources
-- 📄 [[OAuth Setup Guide]](outline://doc/abc123) - Reference for project 1
-- 📄 [[UI Design System]](outline://doc/def456) - Reference for project 2
-
-## Inbox to Process
-- [X] items in 00-inbox/ to process
-```
-
-### Evening Reflection with Work
-
-**Enhanced evening reflection workflow:**
-
-```
-1. Review completed tasks (personal + work)
-   - Check Basecamp: "What did I complete today in Basecamp?"
-   - Get: todos marked complete, cards moved to Done
-2. Check project progress:
-   - For each active project: get status
-   - Note: milestones reached, blockers encountered
-3. Capture work learnings:
-   - Technical learnings (to document later)
-   - Process insights (to export to wiki)
-   - Team collaboration notes
-4. Sync to Obsidian:
-   - Create work summary in project notes
-   - Export decisions to Outline (if n8n available)
-5. Plan tomorrow:
-   - Carry over incomplete Basecamp todos
-   - Update project priorities based on today's progress
-   - Identify personal priorities
-```
-
-**Evening reflection with work context:**
-```markdown
-# 🌙 Evening Reflection - YYYY-MM-DD
-
-## Work Tasks Completed
-- ✅ Complete OAuth2 implementation (Basecamp)
-- ✅ Review dashboard mockups (Basecamp)
-- ✅ Respond to 5 team messages (Teams)
-- ⏭️ Fix query performance (carried over)
-
-## Personal Tasks Completed
-- ✅ Morning workout
-- ✅ Weekly grocery shopping
-- ⏭️ Read book chapter (carried over)
-
-## Work Wins
-1. OAuth2 implementation complete ahead of schedule
-2. Team approved dashboard design direction
-3. Documented architecture decision in wiki
-
-## Personal Wins
-1. Maintained morning routine
-2. Saved money on groceries
-
-## Work Challenges
-- Blocker: Waiting for API key from security team (project 1)
-- Solution: Scheduled meeting tomorrow to expedite
-
-## Work Learnings
-- OAuth2 token refresh pattern is simpler than expected
-- Team prefers async communication over meetings
-
-## Project Status Updates
-
-### [[API Integration Platform]]
-- Progress: 65% complete
-- Completed: OAuth2, token management
-- Next: API endpoints implementation
-- Deadline: 2026-03-15 (on track)
-
-### [[Customer Portal Redesign]]
-- Progress: 40% complete
-- Completed: Research, mockups
-- Next: User testing
-- Deadline: 2026-04-30 (slightly behind)
-
-## Tomorrow's Work Focus
-1. Complete API endpoints (OAuth Integration Platform)
-2. Conduct user testing (Customer Portal Redesign)
-3. Follow up on API key (Security team)
-
-## Tomorrow's Personal Focus
-1. Evening workout
-2. Update budget with new expenses
-
-## Energy Level
-- Morning: 8/10
-- Midday: 6/10 (meeting-heavy)
-- Evening: 7/10
-
-## Reflection
-[User's response]
-```
-
-### Weekly Review with Work
-
-**Enhanced weekly review workflow:**
-
-```
-1. Collect completed work:
-   - Get Basecamp stats: "Show my completed todos this week"
-   - Get project milestones achieved
-2. Review all projects:
-   - For each work project: get status
-   - Identify: at risk, on track, completed
-3. Review area health:
-   - Work areas: current-job, team-management, technical-excellence
-   - Check: balance, attention needed
-4. Process work inbox:
-   - Review 00-inbox/work/ items
-   - File to appropriate work projects or areas
-5. Plan next week:
-   - Work priorities from Basecamp
-   - Project milestones to focus on
-   - Personal priorities from PARA areas
-```
-
-**Weekly review with work context:**
-```markdown
-# 📊 Weekly Review - W## (Mon DD-MMM to Sun DD-MMM)
-
-## Work Metrics
-- Basecamp tasks completed: 23
-- Projects progressed: 5
-- Meetings attended: 12
-- Documents created/updated: 8
-- Wiki exports: 3 decisions, 2 guides
-
-## Personal Metrics
-- Tasks completed: 15
-- Deep work hours: 8
-- Focus score: 7.5/10
-
-## Work Wins
-1. OAuth2 platform delivered 3 days early
-2. Team approved new architecture decision
-3. Security audit passed with minor findings
-
-## Personal Wins
-1. Maintained workout routine (5/5 days)
-2. Read 2 books
-3. Saved target amount
-
-## Work Challenges
-- Challenge 1: API integration delayed by dependency
-   Root cause: Waiting on security team approval
-   Solution: Parallel track started for next sprint
-
-## Work Patterns
-- Productivity: High on Mon-Tue, dropped on Fri (meeting-heavy)
-- Energy: Mornings best for deep work, afternoons for collaboration
-- Meetings: Average 2.4/day, need to reduce to 1-2
-
-## Project Status
-
-### Completed
-- [[Security Audit 2026]] - Passed with 2 minor findings
-
-### On Track
-- [[API Integration Platform]] - 65% complete, on track
-- [[Customer Portal Redesign]] - 40% complete, slightly behind
-- [[Data Analytics Dashboard]] - 70% complete, ahead of schedule
-
-### Behind Schedule
-- [[Documentation Revamp]] - Delayed waiting for SME availability
-   Action: Book dedicated session next week
-
-### At Risk
-- [[Infrastructure Migration]] - Waiting on approval from ops team
-   Action: Escalate to manager tomorrow
-
-### Stalled
-- [[Mobile App v2.0]] - On hold, waiting for strategy decision
-   Action: Follow up with product owner
-
-## Work Area Health Review
-
-| Area | Health | Needs Attention |
-|-------|--------|----------------|
-| Current Job | 8/10 | Balance work/personal time better |
-| Professional Dev | 9/10 | On track with learning goals |
-| Team Management | 7/10 | Follow up on stalled mobile app |
-| Company Knowledge | 6/10 | Need to document more processes |
-| Technical Excellence | 8/10 | Good code quality, maintain standards |
-
-## Work Inbox Status
-- Items processed: 12
-- Items remaining: 3
-- Filed to Projects: 8
-- Filed to Resources: 2
-- Archived: 1
-
-## Next Week Work Priorities
-
-### Top 3
-1. Complete API endpoints (API Integration Platform) - Critical path
-2. User testing feedback (Customer Portal Redesign) - Milestone due
-3. Follow up on infrastructure approval (Infrastructure Migration) - Unblock project
-
-### Projects to Focus
-- [[API Integration Platform]] - Deliver MVP
-- [[Customer Portal Redesign]] - User testing phase
-- [[Data Analytics Dashboard]] - Performance optimization
-
-### Work Areas to Nurture
-- Team Management - Address mobile app stall
-- Company Knowledge - Document 3 key processes
-- Technical Excellence - Code review for new OAuth implementation
-
-## Next Week Personal Priorities
-
-### Top 3
-1. Health - 5 workouts, meal prep
-2. Finances - Monthly review, budget adjustment
-3. Learning - Complete TypeScript course module
-
-## Work Habits/Experiments
-- Try: 2-hour deep work blocks (instead of 1.5 hours)
-- Try: No meeting mornings (9-11 AM protected)
-- Try: End-of-day 15-min Basecamp review
-
-## Reflection Question
-[Weekly reflection from chiron-core references/reflection-questions.md]
-```
-
-## Workflow Decision Tree
-
-```
-User request
-│
-├─ "Start day" → Morning Plan
-│  ├─ Read yesterday's note
-│  ├─ Check today's tasks
-│  ├─ Prioritize (delegate to chiron-core)
-│  ├─ Create daily note (delegate to obsidian-management)
-│  └─ Confirm focus
-│
-├─ "End day" → Evening Reflection
-│  ├─ Review completed tasks
-│  ├─ Capture wins/challenges
-│  ├─ Update daily note (delegate to obsidian-management)
-│  ├─ Plan tomorrow
-│  └─ Ask reflection question
-│
-└─ "Weekly review" → Weekly Review
-   ├─ Collect daily notes
-   ├─ Calculate metrics
-   ├─ Review projects
-   ├─ Process inbox (delegate to quick-capture)
-   ├─ Review areas (delegate to chiron-core)
-   ├─ Identify patterns
-   ├─ Plan next week
-   └─ Generate review note (delegate to obsidian-management)
-```
-
-## Templates
-
-All workflows use templates from `_chiron/templates/`:
-
-| Workflow | Template | Variables |
-|----------|----------|------------|
-| Morning Plan | `daily-note.md` | {{date}}, {{focus}}, {{tasks}} |
-| Evening Reflection | `daily-note.md` (update) | N/A |
-| Weekly Review | `weekly-review.md` | {{week}}, {{date}}, {{metrics}} |
-
-**Template usage:**
-1. Read template file
-2. Replace variables with actual data
-3. Create/update note in appropriate location
-4. Fill in placeholder sections
-
-## Best Practices
-
-### Morning Planning
-- Limit critical tasks to 3-5
-- Schedule deep work blocks first
-- Protect high-energy times
-- Include breaks and transition time
-
-### Evening Reflection
-- Focus on patterns, not just details
-- Be honest about challenges
-- Capture learnings, not just outcomes
-- Plan tomorrow before bed
-
-### Weekly Review
-- Dedicated time (60-90 min)
-- Use reflection questions from chiron-core
-- Focus on system improvements
-- Plan, don't just review
-
-## Quick Reference
-
-| Workflow | Trigger | Duration | Output |
-|----------|----------|-----------|--------|
-| Morning Plan | "Start day", "/chiron-start" | 5-10 min | Daily note with focus areas |
-| Evening Reflection | "End day", "/chiron-end" | 5-10 min | Updated daily note |
-| Weekly Review | "Weekly review", "/chiron-review" | 60-90 min | Weekly review note |
-
-## Resources
-
-- `references/reflection-questions.md` - Weekly and monthly reflection questions (from chiron-core)
-- `references/weekly-review-template.md` - Detailed weekly review structure
-- `references/morning-planning.md` - Morning planning best practices
-
-**Load references when:**
-- Weekly review preparation
-- User asks about reflection techniques
-- Customizing review workflows

skills/doc-translator/SKILL.md

@@ -0,0 +1,262 @@
+---
+name: doc-translator
+description: "Translates external documentation websites to specified language(s) and publishes to Outline wiki. Use when: (1) Translating SaaS/product documentation into German or Czech, (2) Publishing translated docs to Outline wiki, (3) Re-hosting external images to Outline. Triggers: 'translate docs', 'translate documentation', 'translate to German', 'translate to Czech', 'publish to wiki', 'doc translation', 'TEEM translation'."
+compatibility: opencode
+---
+
+# Doc Translator
+
+Translate external documentation websites to German (DE) and/or Czech (CZ), then publish to the company Outline wiki at `https://wiki.az-gruppe.com`. All images are re-hosted on Outline. UI terms use TEEM format.
+
+## Core Workflow
+
+### 1. Validate Input & Clarify
+
+Before starting, confirm:
+
+1. **URL accessibility** - Check with `curl -sI <URL>` for HTTP 200
+2. **Target language(s)** - Always ask explicitly using the `question` tool:
+
+```
+question: "Which language(s) should I translate to?"
+options: ["German (DE)", "Czech (CZ)", "Both (DE + CZ)"]
+```
+
+3. **Scope** - If URL is an index page with multiple sub-pages, ask:
+
+```
+question: "This page links to multiple sub-pages. What should I translate?"
+options: ["This page only", "This page + all linked sub-pages", "Let me pick specific pages"]
+```
+
+4. **Target collection** - Use `Outline_list_collections` to show available collections, then ask which one to publish to
+
+**CRITICAL:** NEVER auto-select collection. Always present collection list to user and wait for explicit selection before proceeding with document creation.
+
+If URL fetch fails, use `question` to ask for an alternative URL or manual content paste.
+
+### 2. Fetch & Parse Content
+
+Use the `webfetch` tool to retrieve page content:
+
+```
+webfetch(url="<URL>", format="markdown")
+```
+
+From the result:
+- Extract main content body (ignore navigation, footers, sidebars, cookie banners)
+- Preserve document structure (headings, lists, tables, code blocks)
+- Collect all image URLs into a list for Step 3
+- Note any embedded videos or interactive elements (these cannot be translated)
+
+For multi-page docs, repeat for each page.
+
+### 3. Download Images
+
+Download all images to a temporary directory:
+
+```bash
+mkdir -p /tmp/doc-images
+
+# For each image URL:
+curl -sL "IMAGE_URL" -o "/tmp/doc-images/$(basename IMAGE_URL)"
+```
+
+Track a mapping of: `original_url -> local_filename -> outline_attachment_url`
+
+If an image download fails, log it and continue. Use a placeholder in the final document:
+
+```markdown
+> **[Image unavailable]** Original: IMAGE_URL
+```
+
+### 4. Upload Images to Outline
+
+MCP-outline does not support attachment creation. Use the bundled script for image uploads:
+
+```bash
+# Upload with optional document association
+bash scripts/upload_image_to_outline.sh "/tmp/doc-images/screenshot.png" "$DOCUMENT_ID"
+
+# Upload without document (attach later)
+bash scripts/upload_image_to_outline.sh "/tmp/doc-images/screenshot.png"
+```
+
+The script handles API key loading from `/run/agenix/outline-key`, content-type detection, the two-step presigned POST flow, and retries. Output is JSON: `{"success": true, "attachment_url": "https://..."}`.
+
+Replace image references in the translated markdown with the returned `attachment_url`:
+```markdown
+![description](ATTACHMENT_URL)
+```
+
+For all other Outline operations (documents, collections, search), use MCP tools (`Outline_*`).
+
+### 5. Translate with TEEM Format
+
+Translate the entire document into each target language. Apply TEEM format to UI elements.
+
+#### Address Form (CRITICAL)
+
+**Always use the informal "you" form** in ALL target languages:
+- **German**: Use **"Du"** (informal), NEVER "Sie" (formal)
+- **Czech**: Use **"ty"** (informal), NEVER "vy" (formal)
+- This applies to all translations — documentation should feel approachable and direct
+
+#### Infobox / Callout Formatting
+
+Source documentation often uses admonitions, callouts, or info boxes (e.g., GitHub-style `> [!NOTE]`, Docusaurus `:::note`, or custom HTML boxes). **Convert ALL such elements** to Outline's callout syntax:
+
+```markdown
+:::tip
+Tip or best practice content here.
+
+:::
+
+:::info
+Informational content here.
+
+:::
+
+:::warning
+Warning or caution content here.
+
+:::
+
+:::success
+Success message or positive outcome here.
+
+:::
+```
+
+**Mapping rules** (source → Outline):
+| Source pattern | Outline syntax |
+|---|---|
+| Note, Info, Information | `:::info` |
+| Tip, Hint, Best Practice | `:::tip` |
+| Warning, Caution, Danger, Important | `:::warning` |
+| Success, Done, Check | `:::success` |
+
+**CRITICAL formatting**: The closing `:::` MUST be on its own line with an empty line before it. Content goes directly after the opening line.
+
+#### TEEM Rules
+
+**Format:** `**English UI Term** (Translation)`
+
+**Apply TEEM to:**
+- Button labels
+- Menu items and navigation tabs
+- Form field labels
+- Dialog/modal titles
+- Toolbar icons with text
+- Status messages from the app
+- **Headings containing UI terms** (example: "## [Adding a new To-do]" becomes "## [Ein neues **To-do** (Aufgabe) hinzufügen]")
+
+**Translate normally (no TEEM):**
+- Your own explanatory text
+- Document headings you create (that don't contain UI terms)
+- General descriptions and conceptual explanations
+- Code blocks and technical identifiers
+
+#### German Examples
+
+```markdown
+Click **Settings** (Einstellungen) to open preferences.
+Navigate to **Dashboard** (Übersicht) > **Reports** (Berichte).
+Press the **Submit** (Absenden) button.
+In the **File** (Datei) menu, select **Export** (Exportieren).
+
+# Heading with UI term: Create a new **To-do** (Aufgabe)
+## [Adding a new **To-do** (Aufgabe)]
+```
+
+#### Czech Examples
+
+```markdown
+Click **Settings** (Nastavení) to open preferences.
+Navigate to **Dashboard** (Přehled) > **Reports** (Sestavy).
+Press the **Submit** (Odeslat) button.
+In the **File** (Soubor) menu, select **Export** (Exportovat).
+
+# Heading with UI term: Create a new **To-do** (Úkol)
+## [Adding a new **To-do** (Úkol)]
+```
+
+#### Ambiguous UI Terms
+
+If a UI term has multiple valid translations depending on context, use the `question` tool:
+
+```
+question: "The term 'Board' appears in the UI. Which translation fits this context?"
+options: ["Pinnwand (pinboard/bulletin)", "Tafel (whiteboard)", "Gremium (committee)"]
+```
+
+### 6. Publish to Outline
+
+Use mcp-outline tools to publish:
+
+1. **Find or create collection:**
+   - `Outline_list_collections` to find target collection
+   - `Outline_create_collection` if needed
+
+2. **Create document:**
+   - `Outline_create_document` with translated markdown content
+   - Set `publish: true` for immediate visibility
+   - Use `parent_document_id` if nesting under an existing doc
+
+3. **For multi-language:** Create one document per language, clearly titled:
+   - `[Product Name] - Dokumentation (DE)`
+   - `[Product Name] - Dokumentace (CZ)`
+
+## Error Handling
+
+| Issue | Action |
+|-------|--------|
+| URL fetch fails | Use `question` to ask for alternative URL or manual paste |
+| Image download fails | Continue with placeholder, note in completion report |
+| Outline API error (attachments) | Script retries 3x with backoff; on final failure save markdown to `/tmp/doc-translator-backup-TIMESTAMP.md`, report error |
+| Outline API error (document) | Save markdown to `/tmp/doc-translator-backup-TIMESTAMP.md`, report error |
+| Ambiguous UI term | Use `question` to ask user for correct translation |
+| Large document (>5000 words) | Ask user if splitting into multiple docs is preferred |
+| Multi-page docs | Ask user about scope before proceeding |
+| Rate limiting | Wait and retry with exponential backoff |
+
+If Outline publish fails, always save the translated markdown locally as backup before reporting the error.
+
+## Completion Report
+
+After each translation, output:
+
+```
+Translation Complete
+
+Documents Created:
+- DE: [Document Title] - ID: [xxx] - URL: https://wiki.az-gruppe.com/doc/[slug]
+- CZ: [Document Title] - ID: [xxx] - URL: https://wiki.az-gruppe.com/doc/[slug]
+
+Images Processed: X of Y successfully uploaded
+
+Items Needing Review:
+- [Any sections with complex screenshots]
+- [Any failed image uploads with original URLs]
+- [Any unclear UI terms that were best-guessed]
+```
+
+## Language Codes
+
+| Code | Language | Native Name |
+|------|----------|-------------|
+| DE | German | Deutsch |
+| CZ | Czech | Čeština |
+
+## Environment Variables
+
+| Variable | Purpose | Source |
+|----------|---------|--------|
+| `OUTLINE_API_KEY` | Bearer token for wiki.az-gruppe.com API | Auto-loaded from `/run/agenix/outline-key` by upload script |
+
+## Integration with Other Skills
+
+| Need | Skill | When |
+|------|-------|------|
+| Wiki document management | outline | Managing existing translated docs |
+| Browser-based content extraction | playwright / dev-browser | When webfetch cannot access content (login-required pages) |

skills/doc-translator/scripts/upload_image_to_outline.sh

@@ -0,0 +1,116 @@
+#!/usr/bin/env bash
+# Upload an image to Outline via presigned POST (two-step flow)
+#
+# Usage:
+#   upload_image_to_outline.sh <image_path> [document_id]
+#
+# Environment:
+#   OUTLINE_API_KEY - Bearer token for wiki.az-gruppe.com API
+#                     Auto-loaded from /run/agenix/outline-key if not set
+#
+# Output (JSON to stdout):
+#   {"success": true, "attachment_url": "https://..."}
+# Error (JSON to stderr):
+#   {"success": false, "error": "error message"}
+
+set -euo pipefail
+
+MAX_RETRIES=3
+RETRY_DELAY=2
+
+if [ $# -lt 1 ] || [ $# -gt 2 ]; then
+    echo '{"success": false, "error": "Usage: upload_image_to_outline.sh <image_path> [document_id]"}' >&2
+    exit 1
+fi
+
+IMAGE_PATH="$1"
+DOCUMENT_ID="${2:-}"
+
+if [ -z "${OUTLINE_API_KEY:-}" ]; then
+    if [ -f /run/agenix/outline-key ]; then
+        OUTLINE_API_KEY=$(cat /run/agenix/outline-key)
+        export OUTLINE_API_KEY
+    else
+        echo '{"success": false, "error": "OUTLINE_API_KEY not set and /run/agenix/outline-key not found"}' >&2
+        exit 1
+    fi
+fi
+
+# Check if file exists
+if [ ! -f "$IMAGE_PATH" ]; then
+    echo "{\"success\": false, \"error\": \"Image file not found: $IMAGE_PATH\"}" >&2
+    exit 1
+fi
+
+# Extract image name and extension
+IMAGE_NAME="$(basename "$IMAGE_PATH")"
+EXTENSION="${IMAGE_NAME##*.}"
+
+# Detect content type by extension
+case "${EXTENSION,,}" in
+    png)       CONTENT_TYPE="image/png" ;;
+    jpg|jpeg)  CONTENT_TYPE="image/jpeg" ;;
+    gif)       CONTENT_TYPE="image/gif" ;;
+    svg)       CONTENT_TYPE="image/svg+xml" ;;
+    webp)      CONTENT_TYPE="image/webp" ;;
+    *)         CONTENT_TYPE="application/octet-stream" ;;
+esac
+
+FILESIZE=$(stat -c%s "$IMAGE_PATH" 2>/dev/null || stat -f%z "$IMAGE_PATH" 2>/dev/null)
+
+if [ -z "$FILESIZE" ]; then
+    echo "{\"success\": false, \"error\": \"Failed to get file size for: $IMAGE_PATH\"}" >&2
+    exit 1
+fi
+
+REQUEST_BODY=$(jq -n \
+    --arg name "$IMAGE_NAME" \
+    --arg contentType "$CONTENT_TYPE" \
+    --argjson size "$FILESIZE" \
+    --arg documentId "$DOCUMENT_ID" \
+    'if $documentId == "" then
+        {name: $name, contentType: $contentType, size: $size}
+    else
+        {name: $name, contentType: $contentType, size: $size, documentId: $documentId}
+    end')
+
+# Step 1: Create attachment record
+RESPONSE=$(curl -s -X POST "https://wiki.az-gruppe.com/api/attachments.create" \
+    -H "Authorization: Bearer $OUTLINE_API_KEY" \
+    -H "Content-Type: application/json" \
+    -d "$REQUEST_BODY")
+
+UPLOAD_URL=$(echo "$RESPONSE" | jq -r '.data.uploadUrl // empty')
+ATTACHMENT_URL=$(echo "$RESPONSE" | jq -r '.data.attachment.url // empty')
+
+if [ -z "$UPLOAD_URL" ]; then
+    ERROR_MSG=$(echo "$RESPONSE" | jq -r '.message // "Failed to create attachment"')
+    echo "{\"success\": false, \"error\": \"$ERROR_MSG\", \"response\": $(echo "$RESPONSE" | jq -c .)}" >&2
+    exit 1
+fi
+
+FORM_ARGS=()
+while IFS= read -r line; do
+    key=$(echo "$line" | jq -r '.key')
+    value=$(echo "$line" | jq -r '.value')
+    FORM_ARGS+=(-F "$key=$value")
+done < <(echo "$RESPONSE" | jq -c '.data.form | to_entries[]')
+
+# Step 2: Upload binary to presigned URL with retry
+for attempt in $(seq 1 "$MAX_RETRIES"); do
+    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -X POST "$UPLOAD_URL" \
+        "${FORM_ARGS[@]}" \
+        -F "file=@$IMAGE_PATH")
+
+    if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "201" ] || [ "$HTTP_CODE" = "204" ]; then
+        echo "{\"success\": true, \"attachment_url\": \"$ATTACHMENT_URL\"}"
+        exit 0
+    fi
+
+    if [ "$attempt" -lt "$MAX_RETRIES" ]; then
+        sleep "$((RETRY_DELAY * attempt))"
+    fi
+done
+
+echo "{\"success\": false, \"error\": \"Upload failed after $MAX_RETRIES attempts (last HTTP $HTTP_CODE)\"}" >&2
+exit 1

skills/excalidraw/SKILL.md

@@ -1,266 +1,544 @@
 ---
 name: excalidraw
-description: Generate architecture diagrams as .excalidraw files from codebase analysis. Use when the user asks to create architecture diagrams, system diagrams, visualize codebase structure, or generate excalidraw files.
+description: "Create Excalidraw diagram JSON files that make visual arguments. Use when: (1) user wants to visualize workflows, architectures, or concepts, (2) creating system diagrams, (3) generating .excalidraw files. Triggers: excalidraw, diagram, visualize, architecture diagram, system diagram."
+compatibility: opencode
 ---
 
-# Excalidraw Diagram Generator
+# Excalidraw Diagram Creator
 
-Generate architecture diagrams as `.excalidraw` files directly from codebase analysis.
+Generate `.excalidraw` JSON files that **argue visually**, not just display information.
+
+## Customization
+
+**All colors and brand-specific styles live in one file:** `references/color-palette.md`. Read it before generating any diagram and use it as the single source of truth for all color choices — shape fills, strokes, text colors, evidence artifact backgrounds, everything.
+
+To make this skill produce diagrams in your own brand style, edit `color-palette.md`. Everything else in this file is universal design methodology and Excalidraw best practices.
 
 ---
 
-## Quick Start
+## Core Philosophy
 
-**User just asks:**
-```
-"Generate an architecture diagram for this project"
-"Create an excalidraw diagram of the system"
-"Visualize this codebase as an excalidraw file"
-```
+**Diagrams should ARGUE, not DISPLAY.**
 
-**Claude Code will:**
-1. Analyze the codebase (any language/framework)
-2. Identify components, services, databases, APIs
-3. Map relationships and data flows
-4. Generate valid `.excalidraw` JSON with dynamic IDs and labels
+A diagram isn't formatted text. It's a visual argument that shows relationships, causality, and flow that words alone can't express. The shape should BE the meaning.
 
-**No prerequisites:** Works without existing diagrams, Terraform, or specific file types.
+**The Isomorphism Test**: If you removed all text, would the structure alone communicate the concept? If not, redesign.
+
+**The Education Test**: Could someone learn something concrete from this diagram, or does it just label boxes? A good diagram teaches—it shows actual formats, real event names, concrete examples.
 
 ---
 
-## Critical Rules
+## Depth Assessment (Do This First)
 
-### 1. NEVER Use Diamond Shapes
+Before designing, determine what level of detail this diagram needs:
 
-Diamond arrow connections are broken in raw Excalidraw JSON. Use styled rectangles instead:
+### Simple/Conceptual Diagrams
+Use abstract shapes when:
+- Explaining a mental model or philosophy
+- The audience doesn't need technical specifics
+- The concept IS the abstraction (e.g., "separation of concerns")
 
-| Semantic Meaning | Rectangle Style |
-|------------------|-----------------|
-| Orchestrator/Hub | Coral (`#ffa8a8`/`#c92a2a`) + strokeWidth: 3 |
-| Decision Point | Orange (`#ffd8a8`/`#e8590c`) + dashed stroke |
+### Comprehensive/Technical Diagrams
+Use concrete examples when:
+- Diagramming a real system, protocol, or architecture
+- The diagram will be used to teach or explain (e.g., YouTube video)
+- The audience needs to understand what things actually look like
+- You're showing how multiple technologies integrate
 
-### 2. Labels Require TWO Elements
+**For technical diagrams, you MUST include evidence artifacts** (see below).
 
-The `label` property does NOT work in raw JSON. Every labeled shape needs:
+---
 
-```json
-// 1. Shape with boundElements reference
-{
-  "id": "my-box",
-  "type": "rectangle",
-  "boundElements": [{ "type": "text", "id": "my-box-text" }]
-}
+## Research Mandate (For Technical Diagrams)
 
-// 2. Separate text element with containerId
-{
-  "id": "my-box-text",
-  "type": "text",
-  "containerId": "my-box",
-  "text": "My Label"
-}
+**Before drawing anything technical, research the actual specifications.**
+
+If you're diagramming a protocol, API, or framework:
+1. Look up the actual JSON/data formats
+2. Find the real event names, method names, or API endpoints
+3. Understand how the pieces actually connect
+4. Use real terminology, not generic placeholders
+
+Bad: "Protocol" → "Frontend"
+Good: "AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)" → "CopilotKit renders via createA2UIMessageRenderer()"
+
+**Research makes diagrams accurate AND educational.**
+
+---
+
+## Evidence Artifacts
+
+Evidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams.
+
+**Types of evidence artifacts** (choose what's relevant to your diagram):
+
+| Artifact Type | When to Use | How to Render |
+|---------------|-------------|---------------|
+| **Code snippets** | APIs, integrations, implementation details | Dark rectangle + syntax-colored text (see color palette for evidence artifact colors) |
+| **Data/JSON examples** | Data formats, schemas, payloads | Dark rectangle + colored text (see color palette) |
+| **Event/step sequences** | Protocols, workflows, lifecycles | Timeline pattern (line + dots + labels) |
+| **UI mockups** | Showing actual output/results | Nested rectangles mimicking real UI |
+| **Real input content** | Showing what goes IN to a system | Rectangle with sample content visible |
+| **API/method names** | Real function calls, endpoints | Use actual names from docs, not placeholders |
+
+**Example**: For a diagram about a streaming protocol, you might show:
+- The actual event names from the spec (not just "Event 1", "Event 2")
+- A code snippet showing how to connect
+- What the streamed data actually looks like
+
+**Example**: For a diagram about a data transformation pipeline:
+- Show sample input data (actual format, not "Input")
+- Show sample output data (actual format, not "Output")
+- Show intermediate states if relevant
+
+The key principle: **show what things actually look like**, not just what they're called.
+
+---
+
+## Multi-Zoom Architecture
+
+Comprehensive diagrams operate at multiple zoom levels simultaneously. Think of it like a map that shows both the country borders AND the street names.
+
+### Level 1: Summary Flow
+A simplified overview showing the full pipeline or process at a glance. Often placed at the top or bottom of the diagram.
+
+*Example*: `Input → Processing → Output` or `Client → Server → Database`
+
+### Level 2: Section Boundaries
+Labeled regions that group related components. These create visual "rooms" that help viewers understand what belongs together.
+
+*Example*: Grouping by responsibility (Backend / Frontend), by phase (Setup / Execution / Cleanup), or by team (User / System / External)
+
+### Level 3: Detail Inside Sections
+Evidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.
+
+*Example*: Inside a "Backend" section, you might show the actual API response format, not just a box labeled "API Response"
+
+**For comprehensive diagrams, aim to include all three levels.** The summary gives context, the sections organize, and the details teach.
+
+### Bad vs Good
+
+| Bad (Displaying) | Good (Arguing) |
+|------------------|----------------|
+| 5 equal boxes with labels | Each concept has a shape that mirrors its behavior |
+| Card grid layout | Visual structure matches conceptual structure |
+| Icons decorating text | Shapes that ARE the meaning |
+| Same container for everything | Distinct visual vocabulary per concept |
+| Everything in a box | Free-floating text with selective containers |
+
+### Simple vs Comprehensive (Know Which You Need)
+
+| Simple Diagram | Comprehensive Diagram |
+|----------------|----------------------|
+| Generic labels: "Input" → "Process" → "Output" | Specific: shows what the input/output actually looks like |
+| Named boxes: "API", "Database", "Client" | Named boxes + examples of actual requests/responses |
+| "Events" or "Messages" label | Timeline with real event/message names from the spec |
+| "UI" or "Dashboard" rectangle | Mockup showing actual UI elements and content |
+| ~30 seconds to explain | ~2-3 minutes of teaching content |
+| Viewer learns the structure | Viewer learns the structure AND the details |
+
+**Simple diagrams** are fine for abstract concepts, quick overviews, or when the audience already knows the details. **Comprehensive diagrams** are needed for technical architectures, tutorials, educational content, or when you want the diagram itself to teach.
+
+---
+
+## Container vs. Free-Floating Text
+
+**Not every piece of text needs a shape around it.** Default to free-floating text. Add containers only when they serve a purpose.
+
+| Use a Container When... | Use Free-Floating Text When... |
+|------------------------|-------------------------------|
+| It's the focal point of a section | It's a label or description |
+| It needs visual grouping with other elements | It's supporting detail or metadata |
+| Arrows need to connect to it | It describes something nearby |
+| The shape itself carries meaning (decision diamond, etc.) | It's a section title, subtitle, or annotation |
+| It represents a distinct "thing" in the system | It's a section title, subtitle, or annotation |
+
+**Typography as hierarchy**: Use font size, weight, and color to create visual hierarchy without boxes. A 28px title doesn't need a rectangle around it.
+
+**The container test**: For each boxed element, ask "Would this work as free-floating text?" If yes, remove the container.
+
+---
+
+## Design Process (Do This BEFORE Generating JSON)
+
+### Step 0: Assess Depth Required
+Before anything else, determine if this needs to be:
+- **Simple/Conceptual**: Abstract shapes, labels, relationships (mental models, philosophies)
+- **Comprehensive/Technical**: Concrete examples, code snippets, real data (systems, architectures, tutorials)
+
+**If comprehensive**: Do research first. Look up actual specs, formats, event names, APIs.
+
+### Step 1: Understand Deeply
+Read the content. For each concept, ask:
+- What does this concept **DO**? (not what IS it)
+- What relationships exist between concepts?
+- What's the core transformation or flow?
+- **What would someone need to SEE to understand this?** (not just read about)
+
+### Step 2: Map Concepts to Patterns
+For each concept, find the visual pattern that mirrors its behavior:
+
+| If the concept... | Use this pattern |
+|-------------------|------------------|
+| Spawns multiple outputs | **Fan-out** (radial arrows from center) |
+| Combines inputs into one | **Convergence** (funnel, arrows merging) |
+| Has hierarchy/nesting | **Tree** (lines + free-floating text) |
+| Is a sequence of steps | **Timeline** (line + dots + free-floating labels) |
+| Loops or improves continuously | **Spiral/Cycle** (arrow returning to start) |
+| Is an abstract state or context | **Cloud** (overlapping ellipses) |
+| Transforms input to output | **Assembly line** (before → process → after) |
+| Compares two things | **Side-by-side** (parallel with contrast) |
+| Separates into phases | **Gap/Break** (visual separation between sections) |
+
+### Step 3: Ensure Variety
+For multi-concept diagrams: **each major concept must use a different visual pattern**. No uniform cards or grids.
+
+### Step 4: Sketch the Flow
+Before JSON, mentally trace how the eye moves through the diagram. There should be a clear visual story.
+
+### Step 5: Generate JSON
+Only now create the Excalidraw elements. **See below for how to handle large diagrams.**
+
+### Step 6: Render & Validate (MANDATORY)
+After generating the JSON, you MUST run the render-view-fix loop until the diagram looks right. This is not optional — see the **Render & Validate** section below for the full process.
+
+---
+
+## Large / Comprehensive Diagram Strategy
+
+**For comprehensive or technical diagrams, you MUST build the JSON one section at a time.** Do NOT attempt to generate the entire file in a single pass. This is a hard constraint — output token limits mean a comprehensive diagram easily exceeds capacity in one shot. Even if it didn't, generating everything at once leads to worse quality. Section-by-section is better in every way.
+
+### The Section-by-Section Workflow
+
+**Phase 1: Build each section**
+
+1. **Create the base file** with the JSON wrapper (`type`, `version`, `appState`, `files`) and the first section of elements.
+2. **Add one section per edit.** Each section gets its own dedicated pass — take your time with it. Think carefully about the layout, spacing, and how this section connects to what's already there.
+3. **Use descriptive string IDs** (e.g., `"trigger_rect"`, `"arrow_fan_left"`) so cross-section references are readable.
+4. **Namespace seeds by section** (e.g., section 1 uses 100xxx, section 2 uses 200xxx) to avoid collisions.
+5. **Update cross-section bindings** as you go. When a new section's element needs to bind to an element from a previous section (e.g., an arrow connecting sections), edit the earlier element's `boundElements` array at the same time.
+
+**Phase 2: Review the whole**
+
+After all sections are in place, read through the complete JSON and check:
+- Are cross-section arrows bound correctly on both ends?
+- Is the overall spacing balanced, or are some sections cramped while others have too much whitespace?
+- Do IDs and bindings all reference elements that actually exist?
+
+Fix any alignment or binding issues before rendering.
+
+**Phase 3: Render & validate**
+
+Now run the render-view-fix loop from the Render & Validate section. This is where you'll catch visual issues that aren't obvious from JSON — overlaps, clipping, imbalanced composition.
+
+### Section Boundaries
+
+Plan your sections around natural visual groupings from the diagram plan. A typical large diagram might split into:
+
+- **Section 1**: Entry point / trigger
+- **Section 2**: First decision or routing
+- **Section 3**: Main content (hero section — may be the largest single section)
+- **Section 4-N**: Remaining phases, outputs, etc.
+
+Each section should be independently understandable: its elements, internal arrows, and any cross-references to adjacent sections.
+
+### What NOT to Do
+
+- **Don't generate the entire diagram in one response.** You will hit the output token limit and produce truncated, broken JSON. Even if the diagram is small enough to fit, splitting into sections produces better results.
+- **Don't write a Python generator script.** The templating and coordinate math seem helpful but introduce a layer of indirection that makes debugging harder. Hand-crafted JSON with descriptive IDs is more maintainable.
+
+---
+
+## Visual Pattern Library
+
+### Fan-Out (One-to-Many)
+Central element with arrows radiating to multiple targets. Use for: sources, PRDs, root causes, central hubs.
+```
+        ○
+       ↗
+  □ → ○
+       ↘
+        ○
 ```
 
-### 3. Elbow Arrows Need Three Properties
+### Convergence (Many-to-One)
+Multiple inputs merging through arrows to single output. Use for: aggregation, funnels, synthesis.
+```
+  ○ ↘
+  ○ → □
+  ○ ↗
+```
 
-For 90-degree corners (not curved):
+### Tree (Hierarchy)
+Parent-child branching with connecting lines and free-floating text (no boxes needed). Use for: file systems, org charts, taxonomies.
+```
+  label
+  ├── label
+  │   ├── label
+  │   └── label
+  └── label
+```
+Use `line` elements for the trunk and branches, free-floating text for labels.
+
+### Spiral/Cycle (Continuous Loop)
+Elements in sequence with arrow returning to start. Use for: feedback loops, iterative processes, evolution.
+```
+  □ → □
+  ↑     ↓
+  □ ← □
+```
+
+### Cloud (Abstract State)
+Overlapping ellipses with varied sizes. Use for: context, memory, conversations, mental states.
+
+### Assembly Line (Transformation)
+Input → Process Box → Output with clear before/after. Use for: transformations, processing, conversion.
+```
+  ○○○ → [PROCESS] → □□□
+  chaos              order
+```
+
+### Side-by-Side (Comparison)
+Two parallel structures with visual contrast. Use for: before/after, options, trade-offs.
+
+### Gap/Break (Separation)
+Visual whitespace or barrier between sections. Use for: phase changes, context resets, boundaries.
+
+### Lines as Structure
+Use lines (type: `line`, not arrows) as primary structural elements instead of boxes:
+- **Timelines**: Vertical or horizontal line with small dots (10-20px ellipses) at intervals, free-floating labels beside each dot
+- **Tree structures**: Vertical trunk line + horizontal branch lines, with free-floating text labels (no boxes needed)
+- **Dividers**: Thin dashed lines to separate sections
+- **Flow spines**: A central line that elements relate to, rather than connecting boxes
+
+```
+Timeline:           Tree:
+  ●─── Label 1        │
+  │                   ├── item
+  ●─── Label 2        │   ├── sub
+  │                   │   └── sub
+  ●─── Label 3        └── item
+```
+
+Lines + free-floating text often creates a cleaner result than boxes + contained text.
+
+---
+
+## Shape Meaning
+
+Choose shape based on what it represents—or use no shape at all:
+
+| Concept Type | Shape | Why |
+|--------------|-------|-----|
+| Labels, descriptions, details | **none** (free-floating text) | Typography creates hierarchy |
+| Section titles, annotations | **none** (free-floating text) | Font size/weight is enough |
+| Markers on a timeline | small `ellipse` (10-20px) | Visual anchor, not container |
+| Start, trigger, input | `ellipse` | Soft, origin-like |
+| End, output, result | `ellipse` | Completion, destination |
+| Decision, condition | `diamond` | Classic decision symbol |
+| Process, action, step | `rectangle` | Contained action |
+| Abstract state, context | overlapping `ellipse` | Fuzzy, cloud-like |
+| Hierarchy node | lines + text (no boxes) | Structure through lines |
+
+**Rule**: Default to no container. Add shapes only when they carry meaning. Aim for <30% of text elements to be inside containers.
+
+---
+
+## Color as Meaning
+
+Colors encode information, not decoration. Every color choice should come from `references/color-palette.md` — the semantic shape colors, text hierarchy colors, and evidence artifact colors are all defined there.
+
+**Key principles:**
+- Each semantic purpose (start, end, decision, AI, error, etc.) has a specific fill/stroke pair
+- Free-floating text uses color for hierarchy (titles, subtitles, details — each at a different level)
+- Evidence artifacts (code snippets, JSON examples) use their own dark background + colored text scheme
+- Always pair a darker stroke with a lighter fill for contrast
+
+**Do not invent new colors.** If a concept doesn't fit an existing semantic category, use Primary/Neutral or Secondary.
+
+---
+
+## Modern Aesthetics
+
+For clean, professional diagrams:
+
+### Roughness
+- `roughness: 0` — Clean, crisp edges. Use for modern/technical diagrams.
+- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming/informal diagrams.
+
+**Default to 0** for most professional use cases.
+
+### Stroke Width
+- `strokeWidth: 1` — Thin, elegant. Good for lines, dividers, subtle connections.
+- `strokeWidth: 2` — Standard. Good for shapes and primary arrows.
+- `strokeWidth: 3` — Bold. Use sparingly for emphasis (main flow line, key connections).
+
+### Opacity
+**Always use `opacity: 100` for all elements.** Use color, size, and stroke width to create hierarchy instead of transparency.
+
+### Small Markers Instead of Shapes
+Instead of full shapes, use small dots (10-20px ellipses) as:
+- Timeline markers
+- Bullet points
+- Connection nodes
+- Visual anchors for free-floating text
+
+---
+
+## Layout Principles
+
+### Hierarchy Through Scale
+- **Hero**: 300×150 - visual anchor, most important
+- **Primary**: 180×90
+- **Secondary**: 120×60
+- **Small**: 60×40
+
+### Whitespace = Importance
+The most important element has the most empty space around it (200px+).
+
+### Flow Direction
+Guide the eye: typically left→right or top→bottom for sequences, radial for hub-and-spoke.
+
+### Connections Required
+Position alone doesn't show relationships. If A relates to B, there must be an arrow.
+
+---
+
+## Text Rules
+
+**CRITICAL**: The JSON `text` property contains ONLY readable words.
 
 ```json
 {
-  "type": "arrow",
-  "roughness": 0,        // Clean lines
-  "roundness": null,     // Sharp corners
-  "elbowed": true        // 90-degree mode
+  "id": "myElement1",
+  "text": "Start",
+  "originalText": "Start"
 }
 ```
 
-### 4. Arrow Edge Calculations
-
-Arrows must start/end at shape edges, not centers:
-
-| Edge | Formula |
-|------|---------|
-| Top | `(x + width/2, y)` |
-| Bottom | `(x + width/2, y + height)` |
-| Left | `(x, y + height/2)` |
-| Right | `(x + width, y + height/2)` |
-
-**Detailed arrow routing:** See `references/arrows.md`
+Settings: `fontSize: 16`, `fontFamily: 3`, `textAlign: "center"`, `verticalAlign: "middle"`
 
 ---
 
-## Element Types
+## JSON Structure
 
-| Type | Use For |
-|------|---------|
-| `rectangle` | Services, databases, containers, orchestrators |
-| `ellipse` | Users, external systems, start/end points |
-| `text` | Labels inside shapes, titles, annotations |
-| `arrow` | Data flow, connections, dependencies |
-| `line` | Grouping boundaries, separators |
-
-**Full JSON format:** See `references/json-format.md`
-
----
-
-## Workflow
-
-### Step 1: Analyze Codebase
-
-Discover components by looking for:
-
-| Codebase Type | What to Look For |
-|---------------|------------------|
-| Monorepo | `packages/*/package.json`, workspace configs |
-| Microservices | `docker-compose.yml`, k8s manifests |
-| IaC | Terraform/Pulumi resource definitions |
-| Backend API | Route definitions, controllers, DB models |
-| Frontend | Component hierarchy, API calls |
-
-**Use tools:**
-- `Glob` → `**/package.json`, `**/Dockerfile`, `**/*.tf`
-- `Grep` → `app.get`, `@Controller`, `CREATE TABLE`
-- `Read` → README, config files, entry points
-
-### Step 2: Plan Layout
-
-**Vertical flow (most common):**
-```
-Row 1: Users/Entry points (y: 100)
-Row 2: Frontend/Gateway (y: 230)
-Row 3: Orchestration (y: 380)
-Row 4: Services (y: 530)
-Row 5: Data layer (y: 680)
-
-Columns: x = 100, 300, 500, 700, 900
-Element size: 160-200px x 80-90px
-```
-
-**Other patterns:** See `references/examples.md`
-
-### Step 3: Generate Elements
-
-For each component:
-1. Create shape with unique `id`
-2. Add `boundElements` referencing text
-3. Create text with `containerId`
-4. Choose color based on type
-
-**Color palettes:** See `references/colors.md`
-
-### Step 4: Add Connections
-
-For each relationship:
-1. Calculate source edge point
-2. Plan elbow route (avoid overlaps)
-3. Create arrow with `points` array
-4. Match stroke color to destination type
-
-**Arrow patterns:** See `references/arrows.md`
-
-### Step 5: Add Grouping (Optional)
-
-For logical groupings:
-- Large transparent rectangle with `strokeStyle: "dashed"`
-- Standalone text label at top-left
-
-### Step 6: Validate and Write
-
-Run validation before writing. Save to `docs/` or user-specified path.
-
-**Validation checklist:** See `references/validation.md`
-
----
-
-## Quick Arrow Reference
-
-**Straight down:**
 ```json
-{ "points": [[0, 0], [0, 110]], "x": 590, "y": 290 }
+{
+  "type": "excalidraw",
+  "version": 2,
+  "source": "https://excalidraw.com",
+  "elements": [...],
+  "appState": {
+    "viewBackgroundColor": "#ffffff",
+    "gridSize": 20
+  },
+  "files": {}
+}
 ```
 
-**L-shape (left then down):**
-```json
-{ "points": [[0, 0], [-325, 0], [-325, 125]], "x": 525, "y": 420 }
-```
+## Element Templates
 
-**U-turn (callback):**
-```json
-{ "points": [[0, 0], [50, 0], [50, -125], [20, -125]], "x": 710, "y": 440 }
-```
-
-**Arrow width/height** = bounding box of points:
-```
-points [[0,0], [-440,0], [-440,70]] → width=440, height=70
-```
-
-**Multiple arrows from same edge** - stagger positions:
-```
-5 arrows: 20%, 35%, 50%, 65%, 80% across edge width
-```
+See `references/element-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). Pull colors from `references/color-palette.md` based on each element's semantic purpose.
 
 ---
 
-## Default Color Palette
+## Render & Validate (MANDATORY)
 
-| Component | Background | Stroke |
-|-----------|------------|--------|
-| Frontend | `#a5d8ff` | `#1971c2` |
-| Backend/API | `#d0bfff` | `#7048e8` |
-| Database | `#b2f2bb` | `#2f9e44` |
-| Storage | `#ffec99` | `#f08c00` |
-| AI/ML | `#e599f7` | `#9c36b5` |
-| External APIs | `#ffc9c9` | `#e03131` |
-| Orchestration | `#ffa8a8` | `#c92a2a` |
-| Message Queue | `#fff3bf` | `#fab005` |
-| Cache | `#ffe8cc` | `#fd7e14` |
-| Users | `#e7f5ff` | `#1971c2` |
+You cannot judge a diagram from JSON alone. After generating or editing the Excalidraw JSON, you MUST render it to PNG, view the image, and fix what you see — in a loop until it's right. This is a core part of the workflow, not a final check.
 
-**Cloud-specific palettes:** See `references/colors.md`
+### How to Render
+
+Run the render script from the skill's `references/` directory:
+
+```bash
+python3 <skill-references-dir>/render_excalidraw.py <path-to-file.excalidraw>
+```
+
+This outputs a PNG next to the `.excalidraw` file. Then use the **Read tool** on the PNG to actually view it.
+
+### The Loop
+
+After generating the initial JSON, run this cycle:
+
+**1. Render & View** — Run the render script, then Read the PNG.
+
+**2. Audit against your original vision** — Before looking for bugs, compare the rendered result to what you designed in Steps 1-4. Ask:
+- Does the visual structure match the conceptual structure you planned?
+- Does each section use the pattern you intended (fan-out, convergence, timeline, etc.)?
+- Does the eye flow through the diagram in the order you designed?
+- Is the visual hierarchy correct — hero elements dominant, supporting elements smaller?
+- For technical diagrams: are the evidence artifacts (code snippets, data examples) readable and properly placed?
+
+**3. Check for visual defects:**
+- Text clipped by or overflowing its container
+- Text or shapes overlapping other elements
+- Arrows crossing through elements instead of routing around them
+- Arrows landing on the wrong element or pointing into empty space
+- Labels floating ambiguously (not clearly anchored to what they describe)
+- Uneven spacing between elements that should be evenly spaced
+- Sections with too much whitespace next to sections that are too cramped
+- Text too small to read at the rendered size
+- Overall composition feels lopsided or unbalanced
+
+**4. Fix** — Edit the JSON to address everything you found. Common fixes:
+- Widen containers when text is clipped
+- Adjust `x`/`y` coordinates to fix spacing and alignment
+- Add intermediate waypoints to arrow `points` arrays to route around elements
+- Reposition labels closer to the element they describe
+- Resize elements to rebalance visual weight across sections
+
+**5. Re-render & re-view** — Run the render script again and Read the new PNG.
+
+**6. Repeat** — Keep cycling until the diagram passes both the vision check (Step 2) and the defect check (Step 3). Typically takes 2-4 iterations. Don't stop after one pass just because there are no critical bugs — if the composition could be better, improve it.
+
+### When to Stop
+
+The loop is done when:
+- The rendered diagram matches the conceptual design from your planning steps
+- No text is clipped, overlapping, or unreadable
+- Arrows route cleanly and connect to the right elements
+- Spacing is consistent and the composition is balanced
+- You'd be comfortable showing it to someone without caveats
 
 ---
 
-## Quick Validation Checklist
+## Quality Checklist
 
-Before writing file:
-- [ ] Every shape with label has boundElements + text element
-- [ ] Text elements have containerId matching shape
-- [ ] Multi-point arrows have `elbowed: true`, `roundness: null`
-- [ ] Arrow x,y = source shape edge point
-- [ ] Arrow final point offset reaches target edge
-- [ ] No diamond shapes
-- [ ] No duplicate IDs
+### Depth & Evidence (Check First for Technical Diagrams)
+1. **Research done**: Did you look up actual specs, formats, event names?
+2. **Evidence artifacts**: Are there code snippets, JSON examples, or real data?
+3. **Multi-zoom**: Does it have summary flow + section boundaries + detail?
+4. **Concrete over abstract**: Real content shown, not just labeled boxes?
+5. **Educational value**: Could someone learn something concrete from this?
 
-**Full validation algorithm:** See `references/validation.md`
+### Conceptual
+6. **Isomorphism**: Does each visual structure mirror its concept's behavior?
+7. **Argument**: Does the diagram SHOW something text alone couldn't?
+8. **Variety**: Does each major concept use a different visual pattern?
+9. **No uniform containers**: Avoided card grids and equal boxes?
 
----
+### Container Discipline
+10. **Minimal containers**: Could any boxed element work as free-floating text instead?
+11. **Lines as structure**: Are tree/timeline patterns using lines + text rather than boxes?
+12. **Typography hierarchy**: Are font size and color creating visual hierarchy (reducing need for boxes)?
 
-## Common Issues
+### Structural
+13. **Connections**: Every relationship has an arrow or line
+14. **Flow**: Clear visual path for the eye to follow
+15. **Hierarchy**: Important elements are larger/more isolated
 
-| Issue | Fix |
-|-------|-----|
-| Labels don't appear | Use TWO elements (shape + text), not `label` property |
-| Arrows curved | Add `elbowed: true`, `roundness: null`, `roughness: 0` |
-| Arrows floating | Calculate x,y from shape edge, not center |
-| Arrows overlapping | Stagger start positions across edge |
+### Technical
+16. **Text clean**: `text` contains only readable words
+17. **Font**: `fontFamily: 3`
+18. **Roughness**: `roughness: 0` for clean/modern (unless hand-drawn style requested)
+19. **Opacity**: `opacity: 100` for all elements (no transparency)
+20. **Container ratio**: <30% of text elements should be inside containers
 
-**Detailed bug fixes:** See `references/validation.md`
-
----
-
-## Reference Files
-
-| File | Contents |
-|------|----------|
-| `references/json-format.md` | Element types, required properties, text bindings |
-| `references/arrows.md` | Routing algorithm, patterns, bindings, staggering |
-| `references/colors.md` | Default, AWS, Azure, GCP, K8s palettes |
-| `references/examples.md` | Complete JSON examples, layout patterns |
-| `references/validation.md` | Checklists, validation algorithm, bug fixes |
-
----
-
-## Output
-
-- **Location:** `docs/architecture/` or user-specified
-- **Filename:** Descriptive, e.g., `system-architecture.excalidraw`
-- **Testing:** Open in https://excalidraw.com or VS Code extension
+### Visual Validation (Render Required)
+21. **Rendered to PNG**: Diagram has been rendered and visually inspected
+22. **No text overflow**: All text fits within its container
+23. **No overlapping elements**: Shapes and text don't overlap unintentionally
+24. **Even spacing**: Similar elements have consistent spacing
+25. **Arrows land correctly**: Arrows connect to intended elements without crossing others
+26. **Readable at export size**: Text is legible in the rendered PNG
+27. **Balanced composition**: No large empty voids or overcrowded regions

skills/excalidraw/references/arrows.md

@@ -1,288 +0,0 @@
-# Arrow Routing Reference
-
-Complete guide for creating elbow arrows with proper connections.
-
----
-
-## Critical: Elbow Arrow Properties
-
-Three required properties for 90-degree corners:
-
-```json
-{
-  "type": "arrow",
-  "roughness": 0,        // Clean lines
-  "roundness": null,     // Sharp corners (not curved)
-  "elbowed": true        // Enables elbow mode
-}
-```
-
-**Without these, arrows will be curved, not 90-degree elbows.**
-
----
-
-## Edge Calculation Formulas
-
-| Shape Type | Edge | Formula |
-|------------|------|---------|
-| Rectangle | Top | `(x + width/2, y)` |
-| Rectangle | Bottom | `(x + width/2, y + height)` |
-| Rectangle | Left | `(x, y + height/2)` |
-| Rectangle | Right | `(x + width, y + height/2)` |
-| Ellipse | Top | `(x + width/2, y)` |
-| Ellipse | Bottom | `(x + width/2, y + height)` |
-
----
-
-## Universal Arrow Routing Algorithm
-
-```
-FUNCTION createArrow(source, target, sourceEdge, targetEdge):
-  // Step 1: Get source edge point
-  sourcePoint = getEdgePoint(source, sourceEdge)
-
-  // Step 2: Get target edge point
-  targetPoint = getEdgePoint(target, targetEdge)
-
-  // Step 3: Calculate offsets
-  dx = targetPoint.x - sourcePoint.x
-  dy = targetPoint.y - sourcePoint.y
-
-  // Step 4: Determine routing pattern
-  IF sourceEdge == "bottom" AND targetEdge == "top":
-    IF abs(dx) < 10:  // Nearly aligned
-      points = [[0, 0], [0, dy]]
-    ELSE:  // Need L-shape
-      points = [[0, 0], [dx, 0], [dx, dy]]
-
-  ELSE IF sourceEdge == "right" AND targetEdge == "left":
-    IF abs(dy) < 10:
-      points = [[0, 0], [dx, 0]]
-    ELSE:
-      points = [[0, 0], [0, dy], [dx, dy]]
-
-  ELSE IF sourceEdge == targetEdge:  // U-turn
-    clearance = 50
-    IF sourceEdge == "right":
-      points = [[0, 0], [clearance, 0], [clearance, dy], [dx, dy]]
-    ELSE IF sourceEdge == "bottom":
-      points = [[0, 0], [0, clearance], [dx, clearance], [dx, dy]]
-
-  // Step 5: Calculate bounding box
-  width = max(abs(p[0]) for p in points)
-  height = max(abs(p[1]) for p in points)
-
-  RETURN {x: sourcePoint.x, y: sourcePoint.y, points, width, height}
-
-FUNCTION getEdgePoint(shape, edge):
-  SWITCH edge:
-    "top":    RETURN (shape.x + shape.width/2, shape.y)
-    "bottom": RETURN (shape.x + shape.width/2, shape.y + shape.height)
-    "left":   RETURN (shape.x, shape.y + shape.height/2)
-    "right":  RETURN (shape.x + shape.width, shape.y + shape.height/2)
-```
-
----
-
-## Arrow Patterns Reference
-
-| Pattern | Points | Use Case |
-|---------|--------|----------|
-| Down | `[[0,0], [0,h]]` | Vertical connection |
-| Right | `[[0,0], [w,0]]` | Horizontal connection |
-| L-left-down | `[[0,0], [-w,0], [-w,h]]` | Go left, then down |
-| L-right-down | `[[0,0], [w,0], [w,h]]` | Go right, then down |
-| L-down-left | `[[0,0], [0,h], [-w,h]]` | Go down, then left |
-| L-down-right | `[[0,0], [0,h], [w,h]]` | Go down, then right |
-| S-shape | `[[0,0], [0,h1], [w,h1], [w,h2]]` | Navigate around obstacles |
-| U-turn | `[[0,0], [w,0], [w,-h], [0,-h]]` | Callback/return arrows |
-
----
-
-## Worked Examples
-
-### Vertical Connection (Bottom to Top)
-
-```
-Source: x=500, y=200, width=180, height=90
-Target: x=500, y=400, width=180, height=90
-
-source_bottom = (500 + 180/2, 200 + 90) = (590, 290)
-target_top = (500 + 180/2, 400) = (590, 400)
-
-Arrow x = 590, y = 290
-Distance = 400 - 290 = 110
-Points = [[0, 0], [0, 110]]
-```
-
-### Fan-out (One to Many)
-
-```
-Orchestrator: x=570, y=400, width=140, height=80
-Target: x=120, y=550, width=160, height=80
-
-orchestrator_bottom = (570 + 140/2, 400 + 80) = (640, 480)
-target_top = (120 + 160/2, 550) = (200, 550)
-
-Arrow x = 640, y = 480
-Horizontal offset = 200 - 640 = -440
-Vertical offset = 550 - 480 = 70
-
-Points = [[0, 0], [-440, 0], [-440, 70]]  // Left first, then down
-```
-
-### U-turn (Callback)
-
-```
-Source: x=570, y=400, width=140, height=80
-Target: x=550, y=270, width=180, height=90
-Connection: Right of source -> Right of target
-
-source_right = (570 + 140, 400 + 80/2) = (710, 440)
-target_right = (550 + 180, 270 + 90/2) = (730, 315)
-
-Arrow x = 710, y = 440
-Vertical distance = 315 - 440 = -125
-Final x offset = 730 - 710 = 20
-
-Points = [[0, 0], [50, 0], [50, -125], [20, -125]]
-// Right 50px (clearance), up 125px, left 30px
-```
-
----
-
-## Staggering Multiple Arrows
-
-When N arrows leave from same edge, spread evenly:
-
-```
-FUNCTION getStaggeredPositions(shape, edge, numArrows):
-  positions = []
-  FOR i FROM 0 TO numArrows-1:
-    percentage = 0.2 + (0.6 * i / (numArrows - 1))
-
-    IF edge == "bottom" OR edge == "top":
-      x = shape.x + shape.width * percentage
-      y = (edge == "bottom") ? shape.y + shape.height : shape.y
-    ELSE:
-      x = (edge == "right") ? shape.x + shape.width : shape.x
-      y = shape.y + shape.height * percentage
-
-    positions.append({x, y})
-  RETURN positions
-
-// Examples:
-// 2 arrows: 20%, 80%
-// 3 arrows: 20%, 50%, 80%
-// 5 arrows: 20%, 35%, 50%, 65%, 80%
-```
-
----
-
-## Arrow Bindings
-
-For better visual attachment, use `startBinding` and `endBinding`:
-
-```json
-{
-  "id": "arrow-workflow-convert",
-  "type": "arrow",
-  "x": 525,
-  "y": 420,
-  "width": 325,
-  "height": 125,
-  "points": [[0, 0], [-325, 0], [-325, 125]],
-  "roughness": 0,
-  "roundness": null,
-  "elbowed": true,
-  "startBinding": {
-    "elementId": "cloud-workflows",
-    "focus": 0,
-    "gap": 1,
-    "fixedPoint": [0.5, 1]
-  },
-  "endBinding": {
-    "elementId": "convert-pdf-service",
-    "focus": 0,
-    "gap": 1,
-    "fixedPoint": [0.5, 0]
-  },
-  "startArrowhead": null,
-  "endArrowhead": "arrow"
-}
-```
-
-### fixedPoint Values
-
-- Top center: `[0.5, 0]`
-- Bottom center: `[0.5, 1]`
-- Left center: `[0, 0.5]`
-- Right center: `[1, 0.5]`
-
-### Update Shape boundElements
-
-```json
-{
-  "id": "cloud-workflows",
-  "boundElements": [
-    { "type": "text", "id": "cloud-workflows-text" },
-    { "type": "arrow", "id": "arrow-workflow-convert" }
-  ]
-}
-```
-
----
-
-## Bidirectional Arrows
-
-For two-way data flows:
-
-```json
-{
-  "type": "arrow",
-  "startArrowhead": "arrow",
-  "endArrowhead": "arrow"
-}
-```
-
-Arrowhead options: `null`, `"arrow"`, `"bar"`, `"dot"`, `"triangle"`
-
----
-
-## Arrow Labels
-
-Position standalone text near arrow midpoint:
-
-```json
-{
-  "id": "arrow-api-db-label",
-  "type": "text",
-  "x": 305,                        // Arrow x + offset
-  "y": 245,                        // Arrow midpoint
-  "text": "SQL",
-  "fontSize": 12,
-  "containerId": null,
-  "backgroundColor": "#ffffff"
-}
-```
-
-**Positioning formula:**
-- Vertical: `label.y = arrow.y + (total_height / 2)`
-- Horizontal: `label.x = arrow.x + (total_width / 2)`
-- L-shaped: Position at corner or longest segment midpoint
-
----
-
-## Width/Height Calculation
-
-Arrow `width` and `height` = bounding box of path:
-
-```
-points = [[0, 0], [-440, 0], [-440, 70]]
-width = abs(-440) = 440
-height = abs(70) = 70
-
-points = [[0, 0], [50, 0], [50, -125], [20, -125]]
-width = max(abs(50), abs(20)) = 50
-height = abs(-125) = 125
-```

skills/excalidraw/references/color-palette.md

@@ -0,0 +1,67 @@
+# Color Palette & Brand Style
+
+**This is the single source of truth for all colors and brand-specific styles.** To customize diagrams for your own brand, edit this file — everything else in the skill is universal.
+
+---
+
+## Shape Colors (Semantic)
+
+Colors encode meaning, not decoration. Each semantic purpose has a fill/stroke pair.
+
+| Semantic Purpose | Fill | Stroke |
+|------------------|------|--------|
+| Primary/Neutral | `#3b82f6` | `#1e3a5f` |
+| Secondary | `#60a5fa` | `#1e3a5f` |
+| Tertiary | `#93c5fd` | `#1e3a5f` |
+| Start/Trigger | `#fed7aa` | `#c2410c` |
+| End/Success | `#a7f3d0` | `#047857` |
+| Warning/Reset | `#fee2e2` | `#dc2626` |
+| Decision | `#fef3c7` | `#b45309` |
+| AI/LLM | `#ddd6fe` | `#6d28d9` |
+| Inactive/Disabled | `#dbeafe` | `#1e40af` (use dashed stroke) |
+| Error | `#fecaca` | `#b91c1c` |
+
+**Rule**: Always pair a darker stroke with a lighter fill for contrast.
+
+---
+
+## Text Colors (Hierarchy)
+
+Use color on free-floating text to create visual hierarchy without containers.
+
+| Level | Color | Use For |
+|-------|-------|---------|
+| Title | `#1e40af` | Section headings, major labels |
+| Subtitle | `#3b82f6` | Subheadings, secondary labels |
+| Body/Detail | `#64748b` | Descriptions, annotations, metadata |
+| On light fills | `#374151` | Text inside light-colored shapes |
+| On dark fills | `#ffffff` | Text inside dark-colored shapes |
+
+---
+
+## Evidence Artifact Colors
+
+Used for code snippets, data examples, and other concrete evidence inside technical diagrams.
+
+| Artifact | Background | Text Color |
+|----------|-----------|------------|
+| Code snippet | `#1e293b` | Syntax-colored (language-appropriate) |
+| JSON/data example | `#1e293b` | `#22c55e` (green) |
+
+---
+
+## Default Stroke & Line Colors
+
+| Element | Color |
+|---------|-------|
+| Arrows | Use the stroke color of the source element's semantic purpose |
+| Structural lines (dividers, trees, timelines) | Primary stroke (`#1e3a5f`) or Slate (`#64748b`) |
+| Marker dots (fill + stroke) | Primary fill (`#3b82f6`) |
+
+---
+
+## Background
+
+| Property | Value |
+|----------|-------|
+| Canvas background | `#ffffff` |

skills/excalidraw/references/colors.md

@@ -1,91 +0,0 @@
-# Color Palettes Reference
-
-Color schemes for different platforms and component types.
-
----
-
-## Default Palette (Platform-Agnostic)
-
-| Component Type | Background | Stroke | Example |
-|----------------|------------|--------|---------|
-| Frontend/UI | `#a5d8ff` | `#1971c2` | Next.js, React apps |
-| Backend/API | `#d0bfff` | `#7048e8` | API servers, processors |
-| Database | `#b2f2bb` | `#2f9e44` | PostgreSQL, MySQL, MongoDB |
-| Storage | `#ffec99` | `#f08c00` | Object storage, file systems |
-| AI/ML Services | `#e599f7` | `#9c36b5` | ML models, AI APIs |
-| External APIs | `#ffc9c9` | `#e03131` | Third-party services |
-| Orchestration | `#ffa8a8` | `#c92a2a` | Workflows, schedulers |
-| Validation | `#ffd8a8` | `#e8590c` | Validators, checkers |
-| Network/Security | `#dee2e6` | `#495057` | VPC, IAM, firewalls |
-| Classification | `#99e9f2` | `#0c8599` | Routers, classifiers |
-| Users/Actors | `#e7f5ff` | `#1971c2` | User ellipses |
-| Message Queue | `#fff3bf` | `#fab005` | Kafka, RabbitMQ, SQS |
-| Cache | `#ffe8cc` | `#fd7e14` | Redis, Memcached |
-| Monitoring | `#d3f9d8` | `#40c057` | Prometheus, Grafana |
-
----
-
-## AWS Palette
-
-| Service Category | Background | Stroke |
-|-----------------|------------|--------|
-| Compute (EC2, Lambda, ECS) | `#ff9900` | `#cc7a00` |
-| Storage (S3, EBS) | `#3f8624` | `#2d6119` |
-| Database (RDS, DynamoDB) | `#3b48cc` | `#2d3899` |
-| Networking (VPC, Route53) | `#8c4fff` | `#6b3dcc` |
-| Security (IAM, KMS) | `#dd344c` | `#b12a3d` |
-| Analytics (Kinesis, Athena) | `#8c4fff` | `#6b3dcc` |
-| ML (SageMaker, Bedrock) | `#01a88d` | `#017d69` |
-
----
-
-## Azure Palette
-
-| Service Category | Background | Stroke |
-|-----------------|------------|--------|
-| Compute | `#0078d4` | `#005a9e` |
-| Storage | `#50e6ff` | `#3cb5cc` |
-| Database | `#0078d4` | `#005a9e` |
-| Networking | `#773adc` | `#5a2ca8` |
-| Security | `#ff8c00` | `#cc7000` |
-| AI/ML | `#50e6ff` | `#3cb5cc` |
-
----
-
-## GCP Palette
-
-| Service Category | Background | Stroke |
-|-----------------|------------|--------|
-| Compute (GCE, Cloud Run) | `#4285f4` | `#3367d6` |
-| Storage (GCS) | `#34a853` | `#2d8e47` |
-| Database (Cloud SQL, Firestore) | `#ea4335` | `#c53929` |
-| Networking | `#fbbc04` | `#d99e04` |
-| AI/ML (Vertex AI) | `#9334e6` | `#7627b8` |
-
----
-
-## Kubernetes Palette
-
-| Component | Background | Stroke |
-|-----------|------------|--------|
-| Pod | `#326ce5` | `#2756b8` |
-| Service | `#326ce5` | `#2756b8` |
-| Deployment | `#326ce5` | `#2756b8` |
-| ConfigMap/Secret | `#7f8c8d` | `#626d6e` |
-| Ingress | `#00d4aa` | `#00a888` |
-| Node | `#303030` | `#1a1a1a` |
-| Namespace | `#f0f0f0` | `#c0c0c0` (dashed) |
-
----
-
-## Diagram Type Suggestions
-
-| Diagram Type | Recommended Layout | Key Elements |
-|--------------|-------------------|--------------|
-| Microservices | Vertical flow | Services, databases, queues, API gateway |
-| Data Pipeline | Horizontal flow | Sources, transformers, sinks, storage |
-| Event-Driven | Hub-and-spoke | Event bus center, producers/consumers |
-| Kubernetes | Layered groups | Namespace boxes, pods inside deployments |
-| CI/CD | Horizontal flow | Source -> Build -> Test -> Deploy -> Monitor |
-| Network | Hierarchical | Internet -> LB -> VPC -> Subnets -> Instances |
-| User Flow | Swimlanes | User actions, system responses, external calls |

skills/excalidraw/references/element-templates.md

@@ -0,0 +1,182 @@
+# Element Templates
+
+Copy-paste JSON templates for each Excalidraw element type. The `strokeColor` and `backgroundColor` values are placeholders — always pull actual colors from `color-palette.md` based on the element's semantic purpose.
+
+## Free-Floating Text (no container)
+```json
+{
+  "type": "text",
+  "id": "label1",
+  "x": 100, "y": 100,
+  "width": 200, "height": 25,
+  "text": "Section Title",
+  "originalText": "Section Title",
+  "fontSize": 20,
+  "fontFamily": 3,
+  "textAlign": "left",
+  "verticalAlign": "top",
+  "strokeColor": "<title color from palette>",
+  "backgroundColor": "transparent",
+  "fillStyle": "solid",
+  "strokeWidth": 1,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 11111,
+  "version": 1,
+  "versionNonce": 22222,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": null,
+  "link": null,
+  "locked": false,
+  "containerId": null,
+  "lineHeight": 1.25
+}
+```
+
+## Line (structural, not arrow)
+```json
+{
+  "type": "line",
+  "id": "line1",
+  "x": 100, "y": 100,
+  "width": 0, "height": 200,
+  "strokeColor": "<structural line color from palette>",
+  "backgroundColor": "transparent",
+  "fillStyle": "solid",
+  "strokeWidth": 2,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 44444,
+  "version": 1,
+  "versionNonce": 55555,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": null,
+  "link": null,
+  "locked": false,
+  "points": [[0, 0], [0, 200]]
+}
+```
+
+## Small Marker Dot
+```json
+{
+  "type": "ellipse",
+  "id": "dot1",
+  "x": 94, "y": 94,
+  "width": 12, "height": 12,
+  "strokeColor": "<marker dot color from palette>",
+  "backgroundColor": "<marker dot color from palette>",
+  "fillStyle": "solid",
+  "strokeWidth": 1,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 66666,
+  "version": 1,
+  "versionNonce": 77777,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": null,
+  "link": null,
+  "locked": false
+}
+```
+
+## Rectangle
+```json
+{
+  "type": "rectangle",
+  "id": "elem1",
+  "x": 100, "y": 100, "width": 180, "height": 90,
+  "strokeColor": "<stroke from palette based on semantic purpose>",
+  "backgroundColor": "<fill from palette based on semantic purpose>",
+  "fillStyle": "solid",
+  "strokeWidth": 2,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 12345,
+  "version": 1,
+  "versionNonce": 67890,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": [{"id": "text1", "type": "text"}],
+  "link": null,
+  "locked": false,
+  "roundness": {"type": 3}
+}
+```
+
+## Text (centered in shape)
+```json
+{
+  "type": "text",
+  "id": "text1",
+  "x": 130, "y": 132,
+  "width": 120, "height": 25,
+  "text": "Process",
+  "originalText": "Process",
+  "fontSize": 16,
+  "fontFamily": 3,
+  "textAlign": "center",
+  "verticalAlign": "middle",
+  "strokeColor": "<text color — match parent shape's stroke or use 'on light/dark fills' from palette>",
+  "backgroundColor": "transparent",
+  "fillStyle": "solid",
+  "strokeWidth": 1,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 11111,
+  "version": 1,
+  "versionNonce": 22222,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": null,
+  "link": null,
+  "locked": false,
+  "containerId": "elem1",
+  "lineHeight": 1.25
+}
+```
+
+## Arrow
+```json
+{
+  "type": "arrow",
+  "id": "arrow1",
+  "x": 282, "y": 145, "width": 118, "height": 0,
+  "strokeColor": "<arrow color — typically matches source element's stroke from palette>",
+  "backgroundColor": "transparent",
+  "fillStyle": "solid",
+  "strokeWidth": 2,
+  "strokeStyle": "solid",
+  "roughness": 0,
+  "opacity": 100,
+  "angle": 0,
+  "seed": 33333,
+  "version": 1,
+  "versionNonce": 44444,
+  "isDeleted": false,
+  "groupIds": [],
+  "boundElements": null,
+  "link": null,
+  "locked": false,
+  "points": [[0, 0], [118, 0]],
+  "startBinding": {"elementId": "elem1", "focus": 0, "gap": 2},
+  "endBinding": {"elementId": "elem2", "focus": 0, "gap": 2},
+  "startArrowhead": null,
+  "endArrowhead": "arrow"
+}
+```
+
+For curves: use 3+ points in `points` array.

skills/excalidraw/references/examples.md

@@ -1,381 +0,0 @@
-# Complete Examples Reference
-
-Full JSON examples showing proper element structure.
-
----
-
-## 3-Tier Architecture Example
-
-This is a REFERENCE showing JSON structure. Replace IDs, labels, positions, and colors based on discovered components.
-
-```json
-{
-  "type": "excalidraw",
-  "version": 2,
-  "source": "claude-code-excalidraw-skill",
-  "elements": [
-    {
-      "id": "user",
-      "type": "ellipse",
-      "x": 150,
-      "y": 50,
-      "width": 100,
-      "height": 60,
-      "angle": 0,
-      "strokeColor": "#1971c2",
-      "backgroundColor": "#e7f5ff",
-      "fillStyle": "solid",
-      "strokeWidth": 2,
-      "strokeStyle": "solid",
-      "roughness": 1,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": { "type": 2 },
-      "seed": 1,
-      "version": 1,
-      "versionNonce": 1,
-      "isDeleted": false,
-      "boundElements": [{ "type": "text", "id": "user-text" }],
-      "updated": 1,
-      "link": null,
-      "locked": false
-    },
-    {
-      "id": "user-text",
-      "type": "text",
-      "x": 175,
-      "y": 67,
-      "width": 50,
-      "height": 25,
-      "angle": 0,
-      "strokeColor": "#1e1e1e",
-      "backgroundColor": "transparent",
-      "fillStyle": "solid",
-      "strokeWidth": 1,
-      "strokeStyle": "solid",
-      "roughness": 0,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": null,
-      "seed": 2,
-      "version": 1,
-      "versionNonce": 2,
-      "isDeleted": false,
-      "boundElements": null,
-      "updated": 1,
-      "link": null,
-      "locked": false,
-      "text": "User",
-      "fontSize": 16,
-      "fontFamily": 1,
-      "textAlign": "center",
-      "verticalAlign": "middle",
-      "baseline": 14,
-      "containerId": "user",
-      "originalText": "User",
-      "lineHeight": 1.25
-    },
-    {
-      "id": "frontend",
-      "type": "rectangle",
-      "x": 100,
-      "y": 180,
-      "width": 200,
-      "height": 80,
-      "angle": 0,
-      "strokeColor": "#1971c2",
-      "backgroundColor": "#a5d8ff",
-      "fillStyle": "solid",
-      "strokeWidth": 2,
-      "strokeStyle": "solid",
-      "roughness": 1,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": { "type": 3 },
-      "seed": 3,
-      "version": 1,
-      "versionNonce": 3,
-      "isDeleted": false,
-      "boundElements": [{ "type": "text", "id": "frontend-text" }],
-      "updated": 1,
-      "link": null,
-      "locked": false
-    },
-    {
-      "id": "frontend-text",
-      "type": "text",
-      "x": 105,
-      "y": 195,
-      "width": 190,
-      "height": 50,
-      "angle": 0,
-      "strokeColor": "#1e1e1e",
-      "backgroundColor": "transparent",
-      "fillStyle": "solid",
-      "strokeWidth": 1,
-      "strokeStyle": "solid",
-      "roughness": 0,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": null,
-      "seed": 4,
-      "version": 1,
-      "versionNonce": 4,
-      "isDeleted": false,
-      "boundElements": null,
-      "updated": 1,
-      "link": null,
-      "locked": false,
-      "text": "Frontend\nNext.js",
-      "fontSize": 16,
-      "fontFamily": 1,
-      "textAlign": "center",
-      "verticalAlign": "middle",
-      "baseline": 14,
-      "containerId": "frontend",
-      "originalText": "Frontend\nNext.js",
-      "lineHeight": 1.25
-    },
-    {
-      "id": "database",
-      "type": "rectangle",
-      "x": 100,
-      "y": 330,
-      "width": 200,
-      "height": 80,
-      "angle": 0,
-      "strokeColor": "#2f9e44",
-      "backgroundColor": "#b2f2bb",
-      "fillStyle": "solid",
-      "strokeWidth": 2,
-      "strokeStyle": "solid",
-      "roughness": 1,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": { "type": 3 },
-      "seed": 5,
-      "version": 1,
-      "versionNonce": 5,
-      "isDeleted": false,
-      "boundElements": [{ "type": "text", "id": "database-text" }],
-      "updated": 1,
-      "link": null,
-      "locked": false
-    },
-    {
-      "id": "database-text",
-      "type": "text",
-      "x": 105,
-      "y": 345,
-      "width": 190,
-      "height": 50,
-      "angle": 0,
-      "strokeColor": "#1e1e1e",
-      "backgroundColor": "transparent",
-      "fillStyle": "solid",
-      "strokeWidth": 1,
-      "strokeStyle": "solid",
-      "roughness": 0,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": null,
-      "seed": 6,
-      "version": 1,
-      "versionNonce": 6,
-      "isDeleted": false,
-      "boundElements": null,
-      "updated": 1,
-      "link": null,
-      "locked": false,
-      "text": "Database\nPostgreSQL",
-      "fontSize": 16,
-      "fontFamily": 1,
-      "textAlign": "center",
-      "verticalAlign": "middle",
-      "baseline": 14,
-      "containerId": "database",
-      "originalText": "Database\nPostgreSQL",
-      "lineHeight": 1.25
-    },
-    {
-      "id": "arrow-user-frontend",
-      "type": "arrow",
-      "x": 200,
-      "y": 115,
-      "width": 0,
-      "height": 60,
-      "angle": 0,
-      "strokeColor": "#1971c2",
-      "backgroundColor": "transparent",
-      "fillStyle": "solid",
-      "strokeWidth": 2,
-      "strokeStyle": "solid",
-      "roughness": 0,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": null,
-      "seed": 7,
-      "version": 1,
-      "versionNonce": 7,
-      "isDeleted": false,
-      "boundElements": null,
-      "updated": 1,
-      "link": null,
-      "locked": false,
-      "points": [[0, 0], [0, 60]],
-      "lastCommittedPoint": null,
-      "startBinding": null,
-      "endBinding": null,
-      "startArrowhead": null,
-      "endArrowhead": "arrow",
-      "elbowed": true
-    },
-    {
-      "id": "arrow-frontend-database",
-      "type": "arrow",
-      "x": 200,
-      "y": 265,
-      "width": 0,
-      "height": 60,
-      "angle": 0,
-      "strokeColor": "#2f9e44",
-      "backgroundColor": "transparent",
-      "fillStyle": "solid",
-      "strokeWidth": 2,
-      "strokeStyle": "solid",
-      "roughness": 0,
-      "opacity": 100,
-      "groupIds": [],
-      "frameId": null,
-      "roundness": null,
-      "seed": 8,
-      "version": 1,
-      "versionNonce": 8,
-      "isDeleted": false,
-      "boundElements": null,
-      "updated": 1,
-      "link": null,
-      "locked": false,
-      "points": [[0, 0], [0, 60]],
-      "lastCommittedPoint": null,
-      "startBinding": null,
-      "endBinding": null,
-      "startArrowhead": null,
-      "endArrowhead": "arrow",
-      "elbowed": true
-    }
-  ],
-  "appState": {
-    "gridSize": 20,
-    "viewBackgroundColor": "#ffffff"
-  },
-  "files": {}
-}
-```
-
----
-
-## Layout Patterns
-
-### Vertical Flow (Most Common)
-
-```
-Grid positioning:
-- Column width: 200-250px
-- Row height: 130-150px
-- Element size: 160-200px x 80-90px
-- Spacing: 40-50px between elements
-
-Row positions (y):
-  Row 0: 20   (title)
-  Row 1: 100  (users/entry points)
-  Row 2: 230  (frontend/gateway)
-  Row 3: 380  (orchestration)
-  Row 4: 530  (services)
-  Row 5: 680  (data layer)
-  Row 6: 830  (external services)
-
-Column positions (x):
-  Col 0: 100
-  Col 1: 300
-  Col 2: 500
-  Col 3: 700
-  Col 4: 900
-```
-
-### Horizontal Flow (Pipelines)
-
-```
-Stage positions (x):
-  Stage 0: 100  (input/source)
-  Stage 1: 350  (transform 1)
-  Stage 2: 600  (transform 2)
-  Stage 3: 850  (transform 3)
-  Stage 4: 1100 (output/sink)
-
-All stages at same y: 200
-Arrows: "right" -> "left" connections
-```
-
-### Hub-and-Spoke
-
-```
-Center hub: x=500, y=350
-8 positions at 45° increments:
-  N:  (500, 150)
-  NE: (640, 210)
-  E:  (700, 350)
-  SE: (640, 490)
-  S:  (500, 550)
-  SW: (360, 490)
-  W:  (300, 350)
-  NW: (360, 210)
-```
-
----
-
-## Complex Architecture Layout
-
-```
-Row 0: Title/Header (y: 20)
-Row 1: Users/Clients (y: 80)
-Row 2: Frontend/Gateway (y: 200)
-Row 3: Orchestration (y: 350)
-Row 4: Processing Services (y: 550)
-Row 5: Data Layer (y: 680)
-Row 6: External Services (y: 830)
-
-Columns (x):
-  Col 0: 120
-  Col 1: 320
-  Col 2: 520
-  Col 3: 720
-  Col 4: 920
-```
-
----
-
-## Diagram Complexity Guidelines
-
-| Complexity | Max Elements | Max Arrows | Approach |
-|------------|-------------|------------|----------|
-| Simple | 5-10 | 5-10 | Single file, no groups |
-| Medium | 10-25 | 15-30 | Use grouping rectangles |
-| Complex | 25-50 | 30-60 | Split into multiple diagrams |
-| Very Complex | 50+ | 60+ | Multiple focused diagrams |
-
-**When to split:**
-- More than 50 elements
-- Create: `architecture-overview.excalidraw`, `architecture-data-layer.excalidraw`
-
-**When to use groups:**
-- 3+ related services
-- Same deployment unit
-- Logical boundaries (VPC, Security Zone)

skills/excalidraw/references/json-format.md

@@ -1,210 +0,0 @@
-# Excalidraw JSON Format Reference
-
-Complete reference for Excalidraw JSON structure and element types.
-
----
-
-## File Structure
-
-```json
-{
-  "type": "excalidraw",
-  "version": 2,
-  "source": "claude-code-excalidraw-skill",
-  "elements": [],
-  "appState": {
-    "gridSize": 20,
-    "viewBackgroundColor": "#ffffff"
-  },
-  "files": {}
-}
-```
-
----
-
-## Element Types
-
-| Type | Use For | Arrow Reliability |
-|------|---------|-------------------|
-| `rectangle` | Services, components, databases, containers, orchestrators, decision points | Excellent |
-| `ellipse` | Users, external systems, start/end points | Good |
-| `text` | Labels inside shapes, titles, annotations | N/A |
-| `arrow` | Data flow, connections, dependencies | N/A |
-| `line` | Grouping boundaries, separators | N/A |
-
-### BANNED: Diamond Shapes
-
-**NEVER use `type: "diamond"` in generated diagrams.**
-
-Diamond arrow connections are fundamentally broken in raw Excalidraw JSON:
-- Excalidraw applies `roundness` to diamond vertices during rendering
-- Visual edges appear offset from mathematical edge points
-- No offset formula reliably compensates
-- Arrows appear disconnected/floating
-
-**Use styled rectangles instead** for visual distinction:
-
-| Semantic Meaning | Rectangle Style |
-|------------------|-----------------|
-| Orchestrator/Hub | Coral (`#ffa8a8`/`#c92a2a`) + strokeWidth: 3 |
-| Decision Point | Orange (`#ffd8a8`/`#e8590c`) + dashed stroke |
-| Central Router | Larger size + bold color |
-
----
-
-## Required Element Properties
-
-Every element MUST have these properties:
-
-```json
-{
-  "id": "unique-id-string",
-  "type": "rectangle",
-  "x": 100,
-  "y": 100,
-  "width": 200,
-  "height": 80,
-  "angle": 0,
-  "strokeColor": "#1971c2",
-  "backgroundColor": "#a5d8ff",
-  "fillStyle": "solid",
-  "strokeWidth": 2,
-  "strokeStyle": "solid",
-  "roughness": 1,
-  "opacity": 100,
-  "groupIds": [],
-  "frameId": null,
-  "roundness": { "type": 3 },
-  "seed": 1,
-  "version": 1,
-  "versionNonce": 1,
-  "isDeleted": false,
-  "boundElements": null,
-  "updated": 1,
-  "link": null,
-  "locked": false
-}
-```
-
----
-
-## Text Inside Shapes (Labels)
-
-**Every labeled shape requires TWO elements:**
-
-### Shape with boundElements
-
-```json
-{
-  "id": "{component-id}",
-  "type": "rectangle",
-  "x": 500,
-  "y": 200,
-  "width": 200,
-  "height": 90,
-  "strokeColor": "#1971c2",
-  "backgroundColor": "#a5d8ff",
-  "boundElements": [{ "type": "text", "id": "{component-id}-text" }],
-  // ... other required properties
-}
-```
-
-### Text with containerId
-
-```json
-{
-  "id": "{component-id}-text",
-  "type": "text",
-  "x": 505,                          // shape.x + 5
-  "y": 220,                          // shape.y + (shape.height - text.height) / 2
-  "width": 190,                      // shape.width - 10
-  "height": 50,
-  "text": "{Component Name}\n{Subtitle}",
-  "fontSize": 16,
-  "fontFamily": 1,
-  "textAlign": "center",
-  "verticalAlign": "middle",
-  "containerId": "{component-id}",
-  "originalText": "{Component Name}\n{Subtitle}",
-  "lineHeight": 1.25,
-  // ... other required properties
-}
-```
-
-### DO NOT Use the `label` Property
-
-The `label` property is for the JavaScript API, NOT raw JSON files:
-
-```json
-// WRONG - will show empty boxes
-{ "type": "rectangle", "label": { "text": "My Label" } }
-
-// CORRECT - requires TWO elements
-// 1. Shape with boundElements reference
-// 2. Separate text element with containerId
-```
-
-### Text Positioning
-
-- Text `x` = shape `x` + 5
-- Text `y` = shape `y` + (shape.height - text.height) / 2
-- Text `width` = shape `width` - 10
-- Use `\n` for multi-line labels
-- Always use `textAlign: "center"` and `verticalAlign: "middle"`
-
-### ID Naming Convention
-
-Always use pattern: `{shape-id}-text` for text element IDs.
-
----
-
-## Dynamic ID Generation
-
-IDs and labels are generated from codebase analysis:
-
-| Discovered Component | Generated ID | Generated Label |
-|---------------------|--------------|-----------------|
-| Express API server | `express-api` | `"API Server\nExpress.js"` |
-| PostgreSQL database | `postgres-db` | `"PostgreSQL\nDatabase"` |
-| Redis cache | `redis-cache` | `"Redis\nCache Layer"` |
-| S3 bucket for uploads | `s3-uploads` | `"S3 Bucket\nuploads/"` |
-| Lambda function | `lambda-processor` | `"Lambda\nProcessor"` |
-| React frontend | `react-frontend` | `"React App\nFrontend"` |
-
----
-
-## Grouping with Dashed Rectangles
-
-For logical groupings (namespaces, VPCs, pipelines):
-
-```json
-{
-  "id": "group-ai-pipeline",
-  "type": "rectangle",
-  "x": 100,
-  "y": 500,
-  "width": 1000,
-  "height": 280,
-  "strokeColor": "#9c36b5",
-  "backgroundColor": "transparent",
-  "strokeStyle": "dashed",
-  "roughness": 0,
-  "roundness": null,
-  "boundElements": null
-}
-```
-
-Group labels are standalone text (no containerId) at top-left:
-
-```json
-{
-  "id": "group-ai-pipeline-label",
-  "type": "text",
-  "x": 120,
-  "y": 510,
-  "text": "AI Processing Pipeline (Cloud Run)",
-  "textAlign": "left",
-  "verticalAlign": "top",
-  "containerId": null
-}
-```

skills/excalidraw/references/json-schema.md

@@ -0,0 +1,71 @@
+# Excalidraw JSON Schema
+
+## Element Types
+
+| Type | Use For |
+|------|---------|
+| `rectangle` | Processes, actions, components |
+| `ellipse` | Entry/exit points, external systems |
+| `diamond` | Decisions, conditionals |
+| `arrow` | Connections between shapes |
+| `text` | Labels inside shapes |
+| `line` | Non-arrow connections |
+| `frame` | Grouping containers |
+
+## Common Properties
+
+All elements share these:
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `id` | string | Unique identifier |
+| `type` | string | Element type |
+| `x`, `y` | number | Position in pixels |
+| `width`, `height` | number | Size in pixels |
+| `strokeColor` | string | Border color (hex) |
+| `backgroundColor` | string | Fill color (hex or "transparent") |
+| `fillStyle` | string | "solid", "hachure", "cross-hatch" |
+| `strokeWidth` | number | 1, 2, or 4 |
+| `strokeStyle` | string | "solid", "dashed", "dotted" |
+| `roughness` | number | 0 (smooth), 1 (default), 2 (rough) |
+| `opacity` | number | 0-100 |
+| `seed` | number | Random seed for roughness |
+
+## Text-Specific Properties
+
+| Property | Description |
+|----------|-------------|
+| `text` | The display text |
+| `originalText` | Same as text |
+| `fontSize` | Size in pixels (16-20 recommended) |
+| `fontFamily` | 3 for monospace (use this) |
+| `textAlign` | "left", "center", "right" |
+| `verticalAlign` | "top", "middle", "bottom" |
+| `containerId` | ID of parent shape |
+
+## Arrow-Specific Properties
+
+| Property | Description |
+|----------|-------------|
+| `points` | Array of [x, y] coordinates |
+| `startBinding` | Connection to start shape |
+| `endBinding` | Connection to end shape |
+| `startArrowhead` | null, "arrow", "bar", "dot", "triangle" |
+| `endArrowhead` | null, "arrow", "bar", "dot", "triangle" |
+
+## Binding Format
+
+```json
+{
+  "elementId": "shapeId",
+  "focus": 0,
+  "gap": 2
+}
+```
+
+## Rectangle Roundness
+
+Add for rounded corners:
+```json
+"roundness": { "type": 3 }
+```

skills/excalidraw/references/render_excalidraw.py

@@ -0,0 +1,205 @@
+#!/usr/bin/env python3
+"""Render Excalidraw JSON to PNG using Playwright + headless Chromium.
+
+Usage:
+    python3 render_excalidraw.py <path-to-file.excalidraw> [--output path.png] [--scale 2] [--width 1920]
+
+Dependencies (playwright, chromium) are provided by the Nix flake / direnv environment.
+"""
+
+from __future__ import annotations
+
+import argparse
+import json
+import sys
+from pathlib import Path
+
+
+def validate_excalidraw(data: dict) -> list[str]:
+    """Validate Excalidraw JSON structure. Returns list of errors (empty = valid)."""
+    errors: list[str] = []
+
+    if data.get("type") != "excalidraw":
+        errors.append(f"Expected type 'excalidraw', got '{data.get('type')}'")
+
+    if "elements" not in data:
+        errors.append("Missing 'elements' array")
+    elif not isinstance(data["elements"], list):
+        errors.append("'elements' must be an array")
+    elif len(data["elements"]) == 0:
+        errors.append("'elements' array is empty — nothing to render")
+
+    return errors
+
+
+def compute_bounding_box(elements: list[dict]) -> tuple[float, float, float, float]:
+    """Compute bounding box (min_x, min_y, max_x, max_y) across all elements."""
+    min_x = float("inf")
+    min_y = float("inf")
+    max_x = float("-inf")
+    max_y = float("-inf")
+
+    for el in elements:
+        if el.get("isDeleted"):
+            continue
+        x = el.get("x", 0)
+        y = el.get("y", 0)
+        w = el.get("width", 0)
+        h = el.get("height", 0)
+
+        # For arrows/lines, points array defines the shape relative to x,y
+        if el.get("type") in ("arrow", "line") and "points" in el:
+            for px, py in el["points"]:
+                min_x = min(min_x, x + px)
+                min_y = min(min_y, y + py)
+                max_x = max(max_x, x + px)
+                max_y = max(max_y, y + py)
+        else:
+            min_x = min(min_x, x)
+            min_y = min(min_y, y)
+            max_x = max(max_x, x + abs(w))
+            max_y = max(max_y, y + abs(h))
+
+    if min_x == float("inf"):
+        return (0, 0, 800, 600)
+
+    return (min_x, min_y, max_x, max_y)
+
+
+def render(
+    excalidraw_path: Path,
+    output_path: Path | None = None,
+    scale: int = 2,
+    max_width: int = 1920,
+) -> Path:
+    """Render an .excalidraw file to PNG. Returns the output PNG path."""
+    # Import playwright here so validation errors show before import errors
+    try:
+        from playwright.sync_api import sync_playwright
+    except ImportError:
+        print("ERROR: playwright not installed.", file=sys.stderr)
+        print("Ensure the Nix dev shell is active (direnv allow).", file=sys.stderr)
+        sys.exit(1)
+
+    # Read and validate
+    raw = excalidraw_path.read_text(encoding="utf-8")
+    try:
+        data = json.loads(raw)
+    except json.JSONDecodeError as e:
+        print(f"ERROR: Invalid JSON in {excalidraw_path}: {e}", file=sys.stderr)
+        sys.exit(1)
+
+    errors = validate_excalidraw(data)
+    if errors:
+        print(f"ERROR: Invalid Excalidraw file:", file=sys.stderr)
+        for err in errors:
+            print(f"  - {err}", file=sys.stderr)
+        sys.exit(1)
+
+    # Compute viewport size from element bounding box
+    elements = [e for e in data["elements"] if not e.get("isDeleted")]
+    min_x, min_y, max_x, max_y = compute_bounding_box(elements)
+    padding = 80
+    diagram_w = max_x - min_x + padding * 2
+    diagram_h = max_y - min_y + padding * 2
+
+    # Cap viewport width, let height be natural
+    vp_width = min(int(diagram_w), max_width)
+    vp_height = max(int(diagram_h), 600)
+
+    # Output path
+    if output_path is None:
+        output_path = excalidraw_path.with_suffix(".png")
+
+    # Template path (same directory as this script)
+    template_path = Path(__file__).parent / "render_template.html"
+    if not template_path.exists():
+        print(f"ERROR: Template not found at {template_path}", file=sys.stderr)
+        sys.exit(1)
+
+    template_url = template_path.as_uri()
+
+    with sync_playwright() as p:
+        try:
+            browser = p.chromium.launch(headless=True)
+        except Exception as e:
+            if "Executable doesn't exist" in str(e) or "browserType.launch" in str(e):
+                print("ERROR: Chromium not installed for Playwright.", file=sys.stderr)
+                print("Ensure the Nix dev shell is active (direnv allow).", file=sys.stderr)
+                sys.exit(1)
+            raise
+
+        page = browser.new_page(
+            viewport={"width": vp_width, "height": vp_height},
+            device_scale_factor=scale,
+        )
+
+        # Load the template
+        page.goto(template_url)
+
+        # Wait for the ES module to load (imports from esm.sh)
+        page.wait_for_function("window.__moduleReady === true", timeout=30000)
+
+        # Inject the diagram data and render
+        json_str = json.dumps(data)
+        result = page.evaluate(f"window.renderDiagram({json_str})")
+
+        if not result or not result.get("success"):
+            error_msg = (
+                result.get("error", "Unknown render error")
+                if result
+                else "renderDiagram returned null"
+            )
+            print(f"ERROR: Render failed: {error_msg}", file=sys.stderr)
+            browser.close()
+            sys.exit(1)
+
+        # Wait for render completion signal
+        page.wait_for_function("window.__renderComplete === true", timeout=15000)
+
+        # Screenshot the SVG element
+        svg_el = page.query_selector("#root svg")
+        if svg_el is None:
+            print("ERROR: No SVG element found after render.", file=sys.stderr)
+            browser.close()
+            sys.exit(1)
+
+        svg_el.screenshot(path=str(output_path))
+        browser.close()
+
+    return output_path
+
+
+def main() -> None:
+    """Entry point for rendering Excalidraw JSON files to PNG."""
+    parser = argparse.ArgumentParser(description="Render Excalidraw JSON to PNG")
+    parser.add_argument("input", type=Path, help="Path to .excalidraw JSON file")
+    parser.add_argument(
+        "--output",
+        "-o",
+        type=Path,
+        default=None,
+        help="Output PNG path (default: same name with .png)",
+    )
+    parser.add_argument(
+        "--scale", "-s", type=int, default=2, help="Device scale factor (default: 2)"
+    )
+    parser.add_argument(
+        "--width",
+        "-w",
+        type=int,
+        default=1920,
+        help="Max viewport width (default: 1920)",
+    )
+    args = parser.parse_args()
+
+    if not args.input.exists():
+        print(f"ERROR: File not found: {args.input}", file=sys.stderr)
+        sys.exit(1)
+
+    png_path = render(args.input, args.output, args.scale, args.width)
+    print(str(png_path))
+
+
+if __name__ == "__main__":
+    main()

skills/excalidraw/references/render_template.html

@@ -0,0 +1,57 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8" />
+  <style>
+    * { margin: 0; padding: 0; box-sizing: border-box; }
+    body { background: #ffffff; overflow: hidden; }
+    #root { display: inline-block; }
+    #root svg { display: block; }
+  </style>
+</head>
+<body>
+  <div id="root"></div>
+
+  <script type="module">
+    import { exportToSvg } from "https://esm.sh/@excalidraw/excalidraw?bundle";
+
+    window.renderDiagram = async function(jsonData) {
+      try {
+        const data = typeof jsonData === "string" ? JSON.parse(jsonData) : jsonData;
+        const elements = data.elements || [];
+        const appState = data.appState || {};
+        const files = data.files || {};
+
+        // Force white background in appState
+        appState.viewBackgroundColor = appState.viewBackgroundColor || "#ffffff";
+        appState.exportWithDarkMode = false;
+
+        const svg = await exportToSvg({
+          elements: elements,
+          appState: {
+            ...appState,
+            exportBackground: true,
+          },
+          files: files,
+        });
+
+        // Clear any previous render
+        const root = document.getElementById("root");
+        root.innerHTML = "";
+        root.appendChild(svg);
+
+        window.__renderComplete = true;
+        window.__renderError = null;
+        return { success: true, width: svg.getAttribute("width"), height: svg.getAttribute("height") };
+      } catch (err) {
+        window.__renderComplete = true;
+        window.__renderError = err.message;
+        return { success: false, error: err.message };
+      }
+    };
+
+    // Signal that the module is loaded and ready
+    window.__moduleReady = true;
+  </script>
+</body>
+</html>

skills/excalidraw/references/validation.md

@@ -1,182 +0,0 @@
-# Validation Reference
-
-Checklists, validation algorithms, and common bug fixes.
-
----
-
-## Pre-Flight Validation Algorithm
-
-Run BEFORE writing the file:
-
-```
-FUNCTION validateDiagram(elements):
-  errors = []
-
-  // 1. Validate shape-text bindings
-  FOR each shape IN elements WHERE shape.boundElements != null:
-    FOR each binding IN shape.boundElements:
-      textElement = findById(elements, binding.id)
-      IF textElement == null:
-        errors.append("Shape {shape.id} references missing text {binding.id}")
-      ELSE IF textElement.containerId != shape.id:
-        errors.append("Text containerId doesn't match shape")
-
-  // 2. Validate arrow connections
-  FOR each arrow IN elements WHERE arrow.type == "arrow":
-    sourceShape = findShapeNear(elements, arrow.x, arrow.y)
-    IF sourceShape == null:
-      errors.append("Arrow {arrow.id} doesn't start from shape edge")
-
-    finalPoint = arrow.points[arrow.points.length - 1]
-    endX = arrow.x + finalPoint[0]
-    endY = arrow.y + finalPoint[1]
-    targetShape = findShapeNear(elements, endX, endY)
-    IF targetShape == null:
-      errors.append("Arrow {arrow.id} doesn't end at shape edge")
-
-    IF arrow.points.length > 2:
-      IF arrow.elbowed != true:
-        errors.append("Arrow {arrow.id} missing elbowed:true")
-      IF arrow.roundness != null:
-        errors.append("Arrow {arrow.id} should have roundness:null")
-
-  // 3. Validate unique IDs
-  ids = [el.id for el in elements]
-  duplicates = findDuplicates(ids)
-  IF duplicates.length > 0:
-    errors.append("Duplicate IDs: {duplicates}")
-
-  // 4. Validate bounding boxes
-  FOR each arrow IN elements WHERE arrow.type == "arrow":
-    maxX = max(abs(p[0]) for p in arrow.points)
-    maxY = max(abs(p[1]) for p in arrow.points)
-    IF arrow.width < maxX OR arrow.height < maxY:
-      errors.append("Arrow {arrow.id} bounding box too small")
-
-  RETURN errors
-
-FUNCTION findShapeNear(elements, x, y, tolerance=15):
-  FOR each shape IN elements WHERE shape.type IN ["rectangle", "ellipse"]:
-    edges = [
-      (shape.x + shape.width/2, shape.y),              // top
-      (shape.x + shape.width/2, shape.y + shape.height), // bottom
-      (shape.x, shape.y + shape.height/2),             // left
-      (shape.x + shape.width, shape.y + shape.height/2)  // right
-    ]
-    FOR each edge IN edges:
-      IF abs(edge.x - x) < tolerance AND abs(edge.y - y) < tolerance:
-        RETURN shape
-  RETURN null
-```
-
----
-
-## Checklists
-
-### Before Generating
-
-- [ ] Identified all components from codebase
-- [ ] Mapped all connections/data flows
-- [ ] Chose layout pattern (vertical, horizontal, hub-and-spoke)
-- [ ] Selected color palette (default, AWS, Azure, K8s)
-- [ ] Planned grid positions
-- [ ] Created ID naming scheme
-
-### During Generation
-
-- [ ] Every labeled shape has BOTH shape AND text elements
-- [ ] Shape has `boundElements: [{ "type": "text", "id": "{id}-text" }]`
-- [ ] Text has `containerId: "{shape-id}"`
-- [ ] Multi-point arrows have `elbowed: true`, `roundness: null`, `roughness: 0`
-- [ ] Arrows have `startBinding` and `endBinding`
-- [ ] No diamond shapes used
-- [ ] Applied staggering formula for multiple arrows
-
-### Arrow Validation (Every Arrow)
-
-- [ ] Arrow `x,y` calculated from shape edge
-- [ ] Final point offset = `targetEdge - sourceEdge`
-- [ ] Arrow `width` = `max(abs(point[0]))`
-- [ ] Arrow `height` = `max(abs(point[1]))`
-- [ ] U-turn arrows have 40-60px clearance
-
-### After Generation
-
-- [ ] All `boundElements` IDs reference valid text elements
-- [ ] All `containerId` values reference valid shapes
-- [ ] All arrows start within 15px of shape edge
-- [ ] All arrows end within 15px of shape edge
-- [ ] No duplicate IDs
-- [ ] Arrow bounding boxes match points
-- [ ] File is valid JSON
-
----
-
-## Common Bugs and Fixes
-
-### Bug: Arrow appears disconnected/floating
-
-**Cause**: Arrow `x,y` not calculated from shape edge.
-
-**Fix**:
-```
-Rectangle bottom: arrow_x = shape.x + shape.width/2
-                  arrow_y = shape.y + shape.height
-```
-
-### Bug: Arrow endpoint doesn't reach target
-
-**Cause**: Final point offset calculated incorrectly.
-
-**Fix**:
-```
-target_edge = (target.x + target.width/2, target.y)
-offset_x = target_edge.x - arrow.x
-offset_y = target_edge.y - arrow.y
-Final point = [offset_x, offset_y]
-```
-
-### Bug: Multiple arrows from same source overlap
-
-**Cause**: All arrows start from identical `x,y`.
-
-**Fix**: Stagger start positions:
-```
-For 5 arrows from bottom edge:
-  arrow1.x = shape.x + shape.width * 0.2
-  arrow2.x = shape.x + shape.width * 0.35
-  arrow3.x = shape.x + shape.width * 0.5
-  arrow4.x = shape.x + shape.width * 0.65
-  arrow5.x = shape.x + shape.width * 0.8
-```
-
-### Bug: Callback arrow doesn't loop correctly
-
-**Cause**: U-turn path lacks clearance.
-
-**Fix**: Use 4-point path:
-```
-Points = [[0, 0], [clearance, 0], [clearance, -vert], [final_x, -vert]]
-clearance = 40-60px
-```
-
-### Bug: Labels don't appear inside shapes
-
-**Cause**: Using `label` property instead of separate text element.
-
-**Fix**: Create TWO elements:
-1. Shape with `boundElements` referencing text
-2. Text with `containerId` referencing shape
-
-### Bug: Arrows are curved, not 90-degree
-
-**Cause**: Missing elbow properties.
-
-**Fix**: Add all three:
-```json
-{
-  "roughness": 0,
-  "roundness": null,
-  "elbowed": true
-}
-```

skills/knowledge-management/SKILL.md

@@ -1,210 +0,0 @@
----
-name: knowledge-management
-description: "Knowledge base and note management with Obsidian. Use when: (1) saving information for later, (2) organizing notes and references, (3) finding past notes, (4) building knowledge connections, (5) managing documentation. Triggers: save this, note, remember, knowledge base, where did I put, find my notes on, documentation."
-compatibility: opencode
----
-
-# Knowledge Management
-
-Note capture and knowledge organization using Obsidian as the backend.
-
-## Status: Active
-
-Quick note capture and knowledge organization using Obsidian markdown vault.
-
-## Quick Note Capture
-
-- Minimal friction capture to Obsidian vault (~/CODEX/)
-- Auto-tagging based on content
-- Link to related notes using WikiLinks
-- Use frontmatter for metadata
-
-## Knowledge Retrieval
-
-- Fast search using ripgrep across vault
-- Tag-based filtering (#tag syntax)
-- WikiLink connections for related notes
-- Use Obsidian graph view for visual connections
-
-## Resource Organization
-
-- PARA Resources category management (03-resources/)
-- Topic clustering with folders
-- Archive maintenance (04-archive/)
-- Frontmatter for structured metadata
-
-## Documentation Management
-
-- Technical docs organization
-- Version tracking via Git
-- Cross-reference linking
-- Template-driven structure
-
-## Integration Points
-
-- **Obsidian**: Primary storage (Markdown vault at ~/CODEX/)
-- **task-management**: Link notes to projects/areas
-- **research**: Save research findings to Resources
-
-## Quick Commands
-
-| Command | Description |
-|---------|-------------|
-| `note: [content]` | Quick capture to inbox |
-| `find notes on [topic]` | Search vault with ripgrep |
-| `link [note] to [note]` | Create WikiLink connection |
-| `organize [tag/topic]` | Cluster related notes |
-
-## Note Structure
-
-### Quick Note Format
-```markdown
----
-date: 2026-01-27
-created: 2026-01-27T18:30:00Z
-type: note
-tags: #quick-capture #{{topic_tag}}
----
-
-# {{topic}}
-
-## Content
-{{note content}}
-
-## Related
-- [[Related Note 1]]
-- [[Related Note 2]]
-```
-
-### Resource Format
-```markdown
----
-date: 2026-01-27
-created: 2026-01-27T18:30:00Z
-type: resource
-tags: #{{topic}} #{{category}}
-status: active
----
-
-# {{topic}}
-
-## Overview
-{{brief description}}
-
-## Key Information
-- Point 1
-- Point 2
-- Point 3
-
-## Resources
-- [Link 1](https://...)
-- [Link 2](https://...)
-
-## Related Notes
-- [[Note 1]]
-- [[Note 2]]
-```
-
-## Storage Locations
-
-```
-~/CODEX/
-├── 00-inbox/                # Quick captures
-│   ├── quick-capture.md      # Unprocessed notes
-│   ├── web-clips.md         # Saved web content
-│   └── learnings.md         # New learnings
-├── 01-projects/             # Project-specific knowledge
-├── 02-areas/               # Ongoing responsibilities
-├── 03-resources/            # Reference material
-│   ├── programming/
-│   ├── tools/
-│   ├── documentation/
-│   └── brainstorms/
-└── 04-archive/             # Stale content
-    ├── projects/
-    ├── areas/
-    └── resources/
-```
-
-## Search Patterns
-
-Use ripgrep for fast vault-wide searches:
-
-```bash
-# Search by topic
-rg "NixOS" ~/CODEX --type md
-
-# Search by tag
-rg "#programming" ~/CODEX --type md
-
-# Search for links
-rg "\\[\\[" ~/CODEX --type md
-
-# Find recent notes
-rg "date: 2026-01-2" ~/CODEX --type md
-```
-
-## Best Practices
-
-1. **Capture quickly, organize later** - Don't overthink during capture
-2. **Use WikiLinks generously** - Creates network effect
-3. **Tag for retrieval** - Tag by how you'll search, not how you think
-4. **Maintain PARA structure** - Keep notes in appropriate folders
-5. **Archive regularly** - Move inactive content to 04-archive
-6. **Use templates** - Consistent structure for same note types
-7. **Leverage graph view** - Visual connections reveal patterns
-
-## Templates
-
-### Quick Capture Template
-```markdown
----
-date: {{date}}
-created: {{timestamp}}
-type: note
-tags: #quick-capture
----
-
-# {{title}}
-
-## Notes
-{{content}}
-
-## Related
-- [[]]
-```
-
-### Learning Template
-```markdown
----
-date: {{date}}
-created: {{timestamp}}
-type: learning
-tags: #learning #{{topic}}
----
-
-# {{topic}}
-
-## What I Learned
-{{key insight}}
-
-## Why It Matters
-{{application}}
-
-## References
-- [Source](url)
-- [[]]
-```
-
-## Integration with Other Skills
-
-| From | To knowledge-management | Trigger |
-|------|----------------------|---------|
-| research | Save findings | "Save this research" |
-| task-management | Link to projects/areas | "Note about project X" |
-| brainstorming | Save brainstorm | "Save this brainstorm" |
-| daily-routines | Process inbox | "Weekly review" |
-
-## Notes
-
-Expand based on actual note-taking patterns. Consider integration with mem0-memory skill for AI-assisted recall.

skills/meeting-notes/SKILL.md

@@ -1,338 +0,0 @@
----
-name: meeting-notes
-description: "Structured meeting note capture and action item extraction. Use when: (1) taking meeting notes, (2) starting a meeting, (3) processing raw meeting notes, (4) extracting action items. Triggers: meeting, notes, attendies, action items, follow up."
-compatibility: opencode
----
-
-# Meeting Notes
-
-Structured meeting note creation with action item tracking for Chiron system.
-
-## Meeting Creation
-
-**When user says**: "Start meeting: X", "Meeting about X", "Take meeting notes for X"
-
-**Steps:**
-
-1. **Determine meeting type**
-   - Standup (daily/weekly sync)
-   - 1:1 meeting
-   - Workshop/brainstorm
-   - Decision meeting
-
-2. **Create meeting note using template**
-   - Template: `_chiron/templates/meeting.md`
-   - Location: Depends on context
-     - Project-specific: `01-projects/[work|personal]/[project]/meetings/[topic]-YYYYMMDD.md`
-     - Area-related: `02-areas/[area]/meetings/[topic]-YYYYMMDD.md`
-     - General: `00-inbox/meetings/[topic]-YYYYMMDD.md`
-
-3. **Fill in sections:**
-   - Title, date, time, duration
-   - Attendees (names and roles)
-   - Agenda (if known in advance)
-   - Notes (during or after)
-   - Decisions made
-   - Action items
-
-4. **Create action item tasks**
-   - Extract each action item
-   - Create as tasks in note (Obsidian Tasks format)
-   - Assign owners and due dates
-   - Link to related projects/areas
-
-5. **Link to context**
-   - Link to project if meeting was about project
-   - Link to area if about area
-   - Link to related resources
-
-**Output format:**
-```markdown
----
-title: "Meeting Title"
-date: 2026-01-27
-time: "14:00-15:00"
-duration: "1 hour"
-location: [Zoom/Office/etc.]
-attendees: [Person 1, Person 2]
-type: [standup|1:1|workshop|decision]
-project: [[Project Name]]
-tags: [meeting, work]
----
-
-## Attendees
-- [Name] - [Role] - [Organization]
-- [Name] - [Role] - [Organization]
-
-## Agenda
-1. [Item 1]
-2. [Item 2]
-3. [Item 3]
-
-## Notes
-
-### [Item 1]
-- [Key point 1]
-- [Key point 2]
-
-### [Item 2]
-- [Key point 1]
-- [Key point 2]
-
-## Decisions Made
-1. [Decision 1] - [reasoning]
-2. [Decision 2] - [reasoning]
-
-## Action Items
-
-- [ ] [Action description] #meeting #todo 🔼 👤 @name 📅 YYYY-MM-DD
-- [ ] [Action description] #meeting #todo 🔼 👤 @self 📅 YYYY-MM-DD
-- [ ] [Action description] #meeting #todo 🔽 👤 @name 📅 YYYY-MM-DD
-
-## Next Steps
-- [ ] Schedule follow-up meeting
-- [ ] Share notes with team
-```
-
-## Processing Raw Notes
-
-**When user says**: "Process these meeting notes", "Clean up meeting notes", [provides raw text]
-
-**Steps:**
-
-1. **Parse raw text for:**
-   - Attendees (people mentioned)
-   - Action items (next steps, to-dos, action points)
-   - Decisions (agreed, decided, resolved)
-   - Key topics/themes
-
-2. **Structure into template**
-   - Create meeting note with proper sections
-   - Extract action items as tasks
-   - Identify decisions made
-
-3. **Link to context**
-   - Detect mentions of projects/areas
-   - Create wiki-links automatically
-   - Add appropriate tags
-
-4. **Confirm with user**
-   - Show extracted structure
-   - Ask for corrections
-   - Finalize note
-
-**Example:**
-```
-User provides raw notes:
-"Met with John and Sarah about Q1 roadmap. Decided to prioritize feature A over B. John to talk to engineering. Sarah to create PRD. Next meeting next Tuesday."
-
-Action:
-Create meeting note:
----
-title: "Q1 Roadmap Discussion"
-attendees: [John, Sarah]
-type: decision
----
-
-## Decisions Made
-1. Prioritize feature A over B - Resource constraints
-
-## Action Items
-- [ ] Talk to engineering about timeline #meeting #todo 🔼 👤 @john 📅 2026-02-03
-- [ ] Create PRD for feature A #meeting #todo 🔼 👤 @sarah 📅 2026-02-05
-
-## Next Steps
-- [ ] Schedule follow-up next Tuesday
-
-Confirm: "Created meeting note with 2 action items assigned to John and Sarah."
-```
-
-## Action Item Extraction
-
-**When user says**: "Extract action items", "What are the action items?", [shows meeting note]
-
-**Steps:**
-
-1. **Read meeting note**
-2. **Extract action items section**
-3. **Parse each action item:**
-   - Task description
-   - Owner (@mention)
-   - Due date (📅 date)
-   - Priority (⏫/🔼/🔽)
-   - Tags
-
-4. **Present summary:**
-   - Total action items
-   - Grouped by owner
-   - Highlight overdue items
-
-**Output format:**
-```markdown
-## Action Items Summary
-
-Total: 5 items
-
-### Assigned to @john
-- [ ] Task 1 🔼 📅 2026-01-30
-- [ ] Task 2 ⏫ 📅 2026-01-28
-
-### Assigned to @sarah
-- [ ] Task 3 🔼 📅 2026-02-05
-
-### Unassigned
-- [ ] Task 4 🔽
-
-### Overdue
-- [ ] Task 2 ⏫ 📅 2026-01-27 (DUE TODAY)
-```
-
-## Meeting Follow-Up
-
-**When user says**: "Follow up on meeting", "Check action items", "What's outstanding from X meeting?"
-
-**Steps:**
-
-1. **Find meeting note** (by title, date, or attendee)
-2. **Check action items status**
-3. **Generate follow-up note**:
-   - Completed items
-   - Incomplete items
-   - Blockers or delays
-   - Next actions
-
-**Output format:**
-```markdown
-# Follow-Up: [Meeting Title]
-
-## Completed Items ✅
-- [x] Task 1 - Completed on 2026-01-26
-- [x] Task 2 - Completed on 2026-01-27
-
-## Incomplete Items ⏭️
-- [ ] Task 3 - Blocked: Waiting for approval
-- [ ] Task 4 - In progress
-
-## Recommended Next Actions
-- [ ] Follow up with @john on Task 3
-- [ ] Check Task 4 progress on Wednesday
-- [ ] Schedule next meeting
-```
-
-## Meeting Types
-
-### Standup
-**Duration**: 15-30 minutes
-**Purpose**: Sync, blockers, quick updates
-**Template variation**: Minimal notes, focus on blockers and today's plan
-
-### 1:1 Meeting
-**Duration**: 30-60 minutes
-**Purpose**: In-depth discussion, problem-solving
-**Template variation**: Detailed notes, multiple action items
-
-### Workshop/Brainstorm
-**Duration**: 1-3 hours
-**Purpose**: Idea generation, collaboration
-**Template variation**: Focus on ideas, themes, next steps (few action items)
-
-### Decision Meeting
-**Duration**: 30-60 minutes
-**Purpose**: Make decisions on specific topics
-**Template variation**: Emphasize decisions, reasoning, action items
-
-## Integration with Other Skills
-
-**Delegates to:**
-- `obsidian-management` - Create/update meeting notes
-- `task-management` - Extract action items as tasks
-- `chiron-core` - Link to projects/areas
-- `calendar-scheduling` - Schedule follow-up meetings
-- `quick-capture` - Quick capture mode during meetings
-
-**Delegation rules:**
-- File operations → `obsidian-management`
-- Task operations → `task-management`
-- PARA linkage → `chiron-core`
-- Calendar actions → `calendar-scheduling`
-
-## Best Practices
-
-### During Meeting
-- Focus on decisions and action items
-- Capture attendees and roles
-- Note dates/times for reference
-- Link to relevant projects immediately
-
-### After Meeting
-- Extract action items within 24 hours
-- Share notes with attendees
-- Schedule follow-ups if needed
-- Link note to daily note (tagged with #meeting)
-
-### Action Items
-- Be specific (not vague like "follow up")
-- Assign owners clearly (@mention)
-- Set realistic due dates
-- Set appropriate priorities
-- Link to related work
-
-## File Naming
-
-**Pattern:** `[topic]-YYYYMMDD.md`
-
-**Examples:**
-- `product-roadmap-20260127.md`
-- `standup-team-20260127.md`
-- `feature-planning-20260127.md`
-- `decision-budget-20260127.md`
-
-## Template Variables
-
-**Replace in `_chiron/templates/meeting.md`:**
-
-| Variable | Replacement |
-|----------|-------------|
-| `{{title}}` | Meeting title |
-| `{{date}}` | Meeting date (YYYY-MM-DD) |
-| `{{time}}` | Meeting time (HH:mm) |
-| `{{attendees}}` | Attendee list |
-| `{{type}}` | Meeting type |
-| `{{project}}` | Linked project |
-
-## Error Handling
-
-### Ambiguous Attendees
-1. Ask for clarification
-2. Offer to use generic names (e.g., "Team", "Design Team")
-3. Note that owner is unclear
-
-### No Action Items
-1. Confirm with user
-2. Ask: "Any action items from this meeting?"
-3. If no, note as informational only
-
-### Duplicate Meeting Notes
-1. Search for similar meetings
-2. Ask user: "Merge or create new?"
-3. If merge, combine information appropriately
-
-## Quick Reference
-
-| Action | Command Pattern |
-|--------|-----------------|
-| Start meeting | "Meeting: [topic]" or "Start meeting: [title]" |
-| Process notes | "Process meeting notes: [raw text]" |
-| Extract actions | "Extract action items from meeting" |
-| Follow up | "Follow up on meeting: [title]" or "Check action items" |
-| Find meeting | "Find meeting about [topic]" |
-
-## Resources
-
-- `references/meeting-formats.md` - Different meeting type templates
-- `references/action-item-extraction.md` - Patterns for detecting action items
-
-**Load references when:**
-- Customizing meeting templates
-- Processing raw meeting notes
-- Troubleshooting extraction issues

skills/meeting-notes/references/teams-transcript-workflow.md

@@ -1,558 +0,0 @@
-# Teams Transcript Processing Workflow
-
-Manual workflow for processing Teams meeting transcripts (.docx) into structured meeting notes with action items.
-
-## Table of Contents
-1. [Workflow Overview](#workflow-overview)
-2. [Prerequisites](#prerequisites)
-3. [Step-by-Step Process](#step-by-step-process)
-4. [Templates](#templates)
-5. [Integration Points](#integration-points)
-6. [Best Practices](#best-practices)
-7. [Troubleshooting](#troubleshooting)
-
----
-
-## Workflow Overview
-
-```
-Teams Transcript (.docx)
-    ↓
-[Manual: Upload transcript]
-    ↓
-[Extract text content]
-    ↓
-[AI Analysis: Extract key info]
-    ├─→ Attendees
-    ├─→ Topics discussed
-    ├─→ Decisions made
-    └─→ Action items
-    ↓
-[Create Obsidian meeting note]
-    ├─→ Use meeting-notes template
-    ├─→ Include transcript summary
-    └─→ Extract action items as tasks
-    ↓
-[Optional: Sync to Basecamp]
-    ├─→ Create todos in Basecamp
-    └─→ Assign to project
-```
-
----
-
-## Prerequisites
-
-### Tools Needed
-- Teams (for recording and downloading transcripts)
-- Python with `python-docx` library (for text extraction)
-- Obsidian (for storing meeting notes)
-- Basecamp MCP (for syncing action items - optional)
-
-### Install Dependencies
-
-```bash
-pip install python-docx
-```
-
----
-
-## Step-by-Step Process
-
-### Step 1: Download Teams Transcript
-
-**In Teams**:
-1. Go to meeting recording
-2. Click "..." (more options)
-3. Select "Open transcript" or "Download transcript"
-4. Save as `.docx` file
-5. Note filename (includes date/time)
-
-**Filename format**: `MeetingTitle_YYYY-MM-DD_HHMM.docx`
-
-### Step 2: Extract Text from DOCX
-
-**Python script** (`/tmp/extract_transcript.py`):
-
-```python
-#!/usr/bin/env python3
-from docx import Document
-import sys
-import os
-
-def extract_transcript(docx_path):
-    """Extract text from Teams transcript DOCX"""
-    try:
-        doc = Document(docx_path)
-        full_text = '\n'.join([para.text for para in doc.paragraphs])
-        return full_text
-    except Exception as e:
-        print(f"Error reading DOCX: {e}")
-        return None
-
-if __name__ == "__main__":
-    if len(sys.argv) != 2:
-        print("Usage: python extract_transcript.py <transcript.docx>")
-        sys.exit(1)
-
-    docx_path = sys.argv[1]
-    text = extract_transcript(docx_path)
-    
-    if text:
-        print(text)
-        # Optionally save to text file
-        output_path = docx_path.replace('.docx', '.txt')
-        with open(output_path, 'w') as f:
-            f.write(text)
-        print(f"\nExtracted to: {output_path}")
-```
-
-**Usage**:
-```bash
-python extract_transcript.py "MeetingName_2026-01-28_1400.docx"
-```
-
-### Step 3: AI Analysis of Transcript
-
-**Prompt for AI** (ask your AI assistant):
-
-```
-Analyze this Teams meeting transcript and extract:
-
-1. Attendees:
-   - Names and roles (if mentioned)
-   - Who spoke the most
-   - Any key stakeholders
-
-2. Topics Discussed:
-   - Main topics (3-5 key items)
-   - Brief summary of each topic
-
-3. Decisions Made:
-   - Clear decisions with reasoning
-   - Format: "Decision: [what] - [reasoning]"
-   - Include: "Deferred decisions" if applicable
-
-4. Action Items:
-   - Extract specific, actionable tasks
-   - Include: owner (@mention), due date (if mentioned), priority (implicit from context)
-   - Format: "- [ ] Task description #meeting #todo 🔼 👤 @name 📅 YYYY-MM-DD"
-
-5. Next Steps:
-   - Follow-up meetings needed
-   - Deliverables expected
-   - Blockers or dependencies
-
-Format output in markdown ready for Obsidian meeting template.
-```
-
-### Step 4: Create Obsidian Meeting Note
-
-**Ask AI to**:
-- Use meeting-notes skill template
-- Format extracted content
-- Create proper frontmatter
-- Add wiki-links to related projects/areas
-
-**Template structure** (from meeting-notes skill):
-
-```markdown
----
-title: "[Meeting Title]"
-platform: teams
-date: YYYY-MM-DD
-time: HH:mm-HH:mm
-duration: "X minutes"
-attendees: [names]
-transcript_file: "MeetingName_2026-01-28.docx"
-project: [[Project Name]]
-tags: [meeting, work, teams]
----
-
-## Attendees
-- [Name] - [Role]
-- [Name] - [Role]
-
-## Topics Discussed
-### [Topic 1]
-- [Summary]
-
-### [Topic 2]
-- [Summary]
-
-## Decisions Made
-1. [Decision] - [Reasoning]
-2. [Decision] - [Reasoning]
-
-## Action Items
-- [ ] [Action description] #meeting #todo 🔼 👤 @name 📅 YYYY-MM-DD
-- [ ] [Action description] #meeting #todo 🔽 👤 @self 📅 YYYY-MM-DD
-
-## Next Steps
-- [ ] Schedule follow-up meeting
-- [ ] Share notes with team
-```
-
-### Step 5: Save to Obsidian
-
-**Location**:
-```
-~/CODEX/01-projects/work/[project]/meetings/[topic]-YYYYMMDD.md
-```
-
-**Ask AI to**:
-- Determine project from context
-- Create proper folder structure
-- Use kebab-case for filename
-- Add to project MOC
-
-### Step 6: Sync Action Items to Basecamp (Optional)
-
-**When to sync**:
-- Meeting was about a specific project
-- Action items have clear owners
-- Project uses Basecamp for task tracking
-
-**Ask user**: "Sync these action items to Basecamp?"
-
-**If yes**:
-1. Delegate to basecamp skill
-2. Ask: "Which Basecamp project?"
-3. Create todos with:
-   - Proper due dates
-   - Assignees (from @mentions)
-   - Linked to project
-4. Confirm: "Created X todos in [project]"
-
----
-
-## Templates
-
-### AI Analysis Prompt Template
-
-**Copy this prompt** for consistent results:
-
-```text
-You are a meeting analysis assistant. Analyze this Teams meeting transcript and extract:
-
-1. Attendees:
-   - List all participants mentioned
-   - Identify speakers (who talked most)
-   - Note any key stakeholders (managers, decision-makers)
-
-2. Topics Discussed (3-5 main topics):
-   For each topic:
-   - Title (2-4 words)
-   - Summary (2-3 sentences)
-   - Time spent on topic (if discernible from transcript)
-
-3. Decisions Made:
-   For each decision:
-   - Decision statement (what was decided)
-   - Reasoning (brief justification)
-   - Consensus level (unanimous / majority / proposed)
-   - Format as checklist item: `- [ ] Decision: [text]`
-
-4. Action Items:
-   For each action item:
-   - Description (specific, actionable verb)
-   - Owner (@mention if clear, otherwise "Unassigned")
-   - Due date (YYYY-MM-DD if mentioned, else "No deadline")
-   - Priority (implicit: ⏫ urgent, 🔼 high, 🔽 low)
-   - Format: `- [ ] Task #meeting #todo [priority] 👤 @owner 📅 date`
-
-5. Next Steps:
-   - Follow-up meetings needed?
-   - Deliverables expected?
-   - Blockers or dependencies?
-
-**Output Format**: Markdown ready for Obsidian meeting note template.
-
-**Meeting Type**: [standup / 1:1 / workshop / decision]
-
-Transcript:
-[PASTE TEAMS TRANSCRIPT HERE]
-```
-
-### Meeting Note Template (Enhanced for Teams)
-
-```markdown
----
-title: "[Meeting Title]"
-platform: teams
-date: YYYY-MM-DD
-time: HH:mm-HH:mm
-duration: "X minutes"
-attendees: [Name 1 - Role, Name 2 - Role, ...]
-transcript_file: "transcripts/[Topic]-YYYYMMDD.docx"
-recording_link: "[Teams recording URL if available]"
-project: [[Project Name]]
-tags: [meeting, work, teams, transcript]
----
-
-## Attendees
-
-| Name | Role | Company |
-|-------|-------|---------|
-| [Name] | [Role] | [Company] |
-| [Name] | [Role] | [Company] |
-
-## Agenda
-[If agenda was known in advance]
-1. [Item 1]
-2. [Item 2]
-3. [Item 3]
-
-## Transcript Summary
-
-[AI-generated summary of transcript]
-
-## Topics Discussed
-
-### [Topic 1]
-- [Summary points]
-- [Time spent: X minutes]
-
-### [Topic 2]
-- [Summary points]
-- [Time spent: X minutes]
-
-## Decisions Made
-
-1. ✅ [Decision 1]
-   - **Reasoning**: [Why this decision]
-   - **Owner**: [Who made decision]
-   - **Due**: [If applicable]
-
-2. ✅ [Decision 2]
-   - **Reasoning**: [Why this decision]
-   - **Owner**: [Who made decision]
-
-### Deferred Decisions
-- [ ] [Decision deferred] - [Why deferred, revisit date]
-
-## Action Items
-
-- [ ] [Task 1] #meeting #todo 🔼 👤 @owner 📅 YYYY-MM-DD
-- [ ] [Task 2] #meeting #todo ⏫ 👤 @owner 📅 YYYY-MM-DD
-- [ ] [Task 3] #meeting #todo 🔽 👤 self 📅 YYYY-MM-DD
-
-### Action Item Summary
-
-| Task | Owner | Due | Priority |
-|-------|--------|------|----------|
-| [Task 1] | @owner | YYYY-MM-DD | ⏫ |
-| [Task 2] | @owner | YYYY-MM-DD | 🔼 |
-| [Task 3] | @self | N/A | 🔽 |
-
-## Next Steps
-
-- [ ] Schedule follow-up meeting: [Topic] - [Proposed date]
-- [ ] Share notes with: [attendee list]
-- [ ] Update project status in Basecamp
-
-## Notes
-
-[Additional notes, observations, or clarifications]
-
-## Links
-
-- 📹 Teams Recording: [URL if available]
-- 📄 Transcript: [[transcript_filename]]
-- 🗄 Project: [[Project Name]]
-- 📄 Related Docs: [[Related Outline Doc]](outline://document/abc123)
-```
-
----
-
-## Integration Points
-
-### With meeting-notes Skill
-
-**Flow**:
-```
-User: "Process transcript: [file.docx]"
-
-1. Extract text from DOCX
-2. Ask AI to analyze transcript
-3. AI extracts: attendees, topics, decisions, action items
-4. Create meeting note using meeting-notes skill
-5. Ask: "Sync action items to Basecamp?"
-```
-
-### With basecamp Skill
-
-**Flow** (optional):
-```
-User: "Yes, sync to Basecamp"
-
-1. Ask: "Which Basecamp project?"
-2. List available projects
-3. For each action item:
-   - create_todo(project_id, todolist_id, content, due_on, assignee_ids)
-4. Confirm: "Created X todos in [project]"
-```
-
-### With obsidian-management Skill
-
-**Flow**:
-```
-1. Create meeting note at: 01-projects/work/[project]/meetings/[topic]-YYYYMMDD.md
-2. Update project MOC with link to meeting:
-   - Add to "Meetings" section in project _index.md
-3. If decision made, create in decisions/ folder
-4. If applicable, export decision to Outline wiki
-```
-
----
-
-## Best Practices
-
-### During Meeting
-1. **Use Teams recording**: Get transcript automatically
-2. **Name attendees**: Add their roles to transcript
-3. **Speak clearly**: Improves transcript accuracy
-4. **Agenda first**: Helps AI structure analysis
-
-### Processing Transcripts
-1. **Process quickly**: Within 24 hours while fresh
-2. **Clean up text**: Remove filler words (um, ah, like)
-3. **Be specific**: Action items must be actionable, not vague
-4. **Assign owners**: Every action item needs @mention
-5. **Set due dates**: Even if approximate (next week, by next meeting)
-
-### Storage
-1. **Consistent location**: All work meetings in project/meetings/
-2. **Link everything**: Link to project, related docs, areas
-3. **Tag properly**: #meeting, #work, #teams, #transcript
-4. **Archive old**: Move completed project meetings to archive/
-
-### Basecamp Sync
-1. **Sync important meetings**: Not every meeting needs sync
-2. **Use project context**: Sync to relevant project
-3. **Verify in Basecamp**: Check todos were created correctly
-4. **Follow up**: Check completion status regularly
-
----
-
-## Troubleshooting
-
-### Transcript Won't Open
-
-**Problem**: DOCX file corrupted or wrong format
-
-**Solution**:
-1. Re-download from Teams
-2. Try opening in Word first to verify
-3. Use alternative: Copy-paste text manually
-
-### AI Misses Action Items
-
-**Problem**: Transcript analysis misses clear action items
-
-**Solution**:
-1. Manually add missed items to meeting note
-2. Reprompt AI with specific context: "Review transcript again, focus on action items"
-3. Check transcript: Was the audio clear?
-
-### Wrong Project Assigned
-
-**Problem**: Meeting note created in wrong project folder
-
-**Solution**:
-1. Move file to correct location
-2. Update links in project MOCs
-3. Use consistent naming conventions
-
-### Basecamp Sync Fails
-
-**Problem**: Todos not created in Basecamp
-
-**Solution**:
-1. Check Basecamp MCP is connected
-2. Verify project ID is correct
-3. Check assignee IDs are valid
-4. Check todo list exists in project
-5. Retry with fewer items
-
----
-
-## Example End-to-End
-
-### Input
-**Teams transcript**: `api-design-review_2026-01-28_1400.docx`
-
-### AI Output
-```markdown
-## Attendees
-- Alice (Product Owner)
-- Bob (Lead Developer)
-- Charlie (Tech Lead)
-- Sarah (UX Designer)
-
-## Topics Discussed
-1. API Authentication Design (20 min)
-2. Rate Limiting Strategy (15 min)
-3. Error Handling (10 min)
-
-## Decisions Made
-1. Use OAuth2 with refresh tokens - Industry standard, better security
-2. Implement 1000 req/min rate limit - Based on load tests
-
-## Action Items
-- [ ] Create OAuth2 implementation guide #meeting #todo 🔼 👤 @alice 📅 2026-02-05
-- [ ] Document rate limiting policy #meeting #todo 🔼 👤 @bob 📅 2026-02-10
-- [ ] Update error handling documentation #meeting #todo 🔽 👤 @sarah 📅 2026-02-15
-```
-
-### Obsidian Note Created
-**File**: `~/CODEX/01-projects/work/api-integration-platform/meetings/api-design-review-20260128.md`
-
-### Basecamp Sync
-**Project**: API Integration Platform
-**Todos created**: 3
-- OAuth2 guide (assigned to Alice, due 2026-02-05)
-- Rate limiting (assigned to Bob, due 2026-02-10)
-- Error handling (assigned to Sarah, due 2026-02-15)
-
----
-
-## Automation (Future n8n Implementation)
-
-When n8n is added, automate:
-
-1. **Watch transcript folder**: Auto-trigger on new .docx files
-2. **AI auto-analysis**: Use AI API to extract meeting info
-3. **Auto-create meeting notes**: Save to Obsidian automatically
-4. **Auto-sync to Basecamp**: Create todos for action items
-5. **Send notifications**: "Meeting processed, X action items created"
-
-**Workflow diagram**:
-```
-Teams transcript folder
-    ↓ (n8n: Watch folder)
-[Trigger: new .docx]
-    ↓
-[Extract text]
-    ↓
-[AI Analysis]
-    ↓
-[Create meeting note]
-    ↓
-[Sync to Basecamp] (conditional)
-    ↓
-[Send ntfy notification]
-```
-
----
-
-## Quick Reference
-
-| Action | Tool/Script |
-|--------|--------------|
-| Download transcript | Teams UI |
-| Extract text | python extract_transcript.py |
-| Analyze transcript | AI assistant prompt |
-| Create meeting note | meeting-notes skill |
-| Sync to Basecamp | basecamp skill |
-| Store in Obsidian | obsidian-management skill |
-| Export decision | outline skill (optional) |

skills/mem0-memory/SKILL.md

@@ -1,10 +1,16 @@
 ---
 name: mem0-memory
-description: "Store and retrieve memories using Mem0 REST API. Use when: (1) storing information for future recall, (2) searching past conversations or facts, (3) managing user/agent memory contexts, (4) building conversational AI with persistent memory. Triggers on keywords like 'remember', 'recall', 'memory', 'store for later', 'what did I say about'."
+description: "DEPRECATED: Replaced by opencode-memory plugin. See skills/memory/SKILL.md for current memory system."
 compatibility: opencode
 ---
 
-# Mem0 Memory
+> ⚠️ **DEPRECATED**
+>
+> This skill is deprecated. The memory system has been replaced by the opencode-memory plugin.
+>
+> **See:** `skills/memory/SKILL.md` for the current memory system.
+
+# Mem0 Memory (Legacy)
 
 Store and retrieve memories via Mem0 REST API at `http://localhost:8000`.
 
@@ -108,6 +114,36 @@ Combine scopes for fine-grained control:
 }
 ```
 
+## Memory Categories
+
+Memories are classified into 5 categories for organization:
+
+| Category | Definition | Obsidian Path | Example |
+|----------|------------|---------------|---------|
+| `preference` | Personal preferences | `80-memory/preferences/` | UI settings, workflow styles |
+| `fact` | Objective information | `80-memory/facts/` | Tech stack, role, constraints |
+| `decision` | Choices with rationale | `80-memory/decisions/` | Tool selections, architecture |
+| `entity` | People, orgs, systems | `80-memory/entities/` | Contacts, APIs, concepts |
+| `other` | Everything else | `80-memory/other/` | General learnings |
+
+### Metadata Pattern
+
+Include category in metadata when storing:
+
+```json
+{
+  "messages": [...],
+  "user_id": "user123",
+  "metadata": {
+    "category": "preference",
+    "source": "explicit"
+  }
+}
+```
+
+- `category`: One of preference, fact, decision, entity, other
+- `source`: "explicit" (user requested) or "auto-capture" (automatic)
+
 ## Workflow Patterns
 
 ### Pattern 1: Remember User Preferences
@@ -137,6 +173,43 @@ curl -X POST http://localhost:8000/memories \
   -d '{"messages":[...], "run_id":"SESSION_ID"}'
 ```
 
+## Dual-Layer Sync
+
+Memories are stored in BOTH Mem0 AND the Obsidian CODEX vault for redundancy and accessibility.
+
+### Sync Pattern
+
+1. **Store in Mem0 first** - Get `mem0_id` from response
+2. **Create Obsidian note** - In `80-memory/<category>/` using memory template
+3. **Cross-reference**:
+   - Add `mem0_id` to Obsidian note frontmatter
+   - Update Mem0 metadata with `obsidian_ref` (file path)
+
+### Example Flow
+
+```bash
+# 1. Store in Mem0
+RESPONSE=$(curl -s -X POST http://localhost:8000/memories \
+  -d '{"messages":[{"role":"user","content":"I prefer dark mode"}],"user_id":"m3tam3re","metadata":{"category":"preference","source":"explicit"}}')
+
+# 2. Extract mem0_id
+MEM0_ID=$(echo $RESPONSE | jq -r '.id')
+
+# 3. Create Obsidian note (via REST API or MCP)
+# Path: 80-memory/preferences/prefers-dark-mode.md
+# Frontmatter includes: mem0_id: $MEM0_ID
+
+# 4. Update Mem0 with Obsidian reference
+curl -X PUT http://localhost:8000/memories/$MEM0_ID \
+  -d '{"metadata":{"obsidian_ref":"80-memory/preferences/prefers-dark-mode.md"}}'
+```
+
+### When Obsidian Unavailable
+
+- Store in Mem0 only
+- Log sync failure
+- Retry on next access
+
 ## Response Format
 
 Memory objects include:
@@ -161,6 +234,45 @@ Verify API is running:
 curl http://localhost:8000/health
 ```
 
+### Pre-Operation Check
+
+Before any memory operation, verify Mem0 is running:
+
+```bash
+if ! curl -s http://localhost:8000/health > /dev/null 2>&1; then
+  echo "WARNING: Mem0 unavailable. Memory operations skipped."
+  # Continue without memory features
+fi
+```
+
+## Error Handling
+
+### Mem0 Unavailable
+
+When `curl http://localhost:8000/health` fails:
+- Skip all memory operations
+- Warn user: "Memory system unavailable. Mem0 not running at localhost:8000"
+- Continue with degraded functionality
+
+### Obsidian Unavailable
+
+When vault sync fails:
+- Store in Mem0 only
+- Log: "Obsidian sync failed for memory [id]"
+- Do not block user workflow
+
+### API Errors
+
+| Status | Meaning | Action |
+|--------|---------|--------|
+| 400 | Bad request | Check JSON format, required fields |
+| 404 | Memory not found | Memory may have been deleted |
+| 500 | Server error | Retry, check Mem0 logs |
+
+### Graceful Degradation
+
+Always continue core functionality even if memory system fails. Memory is enhancement, not requirement.
+
 ## API Reference
 
 See [references/api_reference.md](references/api_reference.md) for complete OpenAPI schema.

skills/obsidian-management/SKILL.md

@@ -1,403 +0,0 @@
----
-name: obsidian-management
-description: "Obsidian vault operations and file management for ~/CODEX. Use when: (1) creating/editing notes in Obsidian vault, (2) using templates from _chiron/templates/, (3) managing vault structure, (4) reading vault files, (5) organizing files within PARA structure. Triggers: obsidian, vault, note, template, create note, read note, organize files."
-compatibility: opencode
----
-
-# Obsidian Management
-
-File operations and template usage for Obsidian vault at `~/CODEX/`.
-
-## Vault Structure
-
-```
-~/CODEX/
-├── _chiron/              # System files
-│   ├── context.md        # Primary context
-│   └── templates/       # Note templates
-├── 00-inbox/            # Quick captures
-├── 01-projects/         # Active projects
-├── 02-areas/            # Ongoing responsibilities
-├── 03-resources/        # Reference material
-├── 04-archive/          # Completed items
-├── daily/               # Daily notes
-└── tasks/               # Task management
-```
-
-## Core Operations
-
-### Create Note
-
-**When user says**: "Create a note called X", "Make a new note for X", "Add a note"
-
-**Steps:**
-1. Determine location (ask if unclear):
-   - `00-inbox/` for quick captures
-   - `01-projects/[work|personal]/[project]/` for project notes
-   - `02-areas/` for area notes
-   - `03-resources/` for reference material
-2. Create file with proper filename (kebab-case, .md extension)
-3. Add frontmatter if using template
-4. Confirm creation
-
-**Example:**
-```
-User: "Create a note about Obsidian plugins in resources"
-
-Action:
-1. Locate: ~/CODEX/03-resources/tools/obsidian-plugins.md
-2. Create file with template or basic frontmatter
-3. Confirm: "Created obsidian-plugins.md in 03-resources/tools/"
-```
-
-### Read Note
-
-**When user says**: "Read the note X", "Show me X note", "What's in X?"
-
-**Steps:**
-1. Find note by:
-   - Exact path if provided
-   - Fuzzy search across vault
-   - Dataview query if complex
-2. Read full note content
-3. Summarize key points if long
-4. Offer follow-up actions
-
-**Example:**
-```
-User: "Read my learning-python note"
-
-Action:
-1. Search: rg "learning-python" ~/CODEX --type md
-2. Read matching file
-3. Present content
-4. Offer: "Want to edit this? Add tasks? Link to other notes?"
-```
-
-### Edit Note
-
-**When user says**: "Update X", "Change X to Y", "Add to X"
-
-**Steps:**
-1. Read existing note
-2. Locate section to modify
-3. Apply changes preserving formatting
-4. Maintain frontmatter structure
-5. Confirm changes
-
-**Preserve:**
-- Wiki-links `[[Note Name]]`
-- Frontmatter YAML
-- Task formatting
-- Tags
-- Dataview queries
-
-### Use Template
-
-**When user says**: "Create using template", "Use the X template"
-
-**Available templates:**
-
-| Template | Location | Purpose |
-|----------|----------|---------|
-| `daily-note.md` | `_chiron/templates/` | Daily planning/reflection |
-| `weekly-review.md` | `_chiron/templates/` | Weekly review |
-| `project.md` | `_chiron/templates/` | Project initialization |
-| `meeting.md` | `_chiron/templates/` | Meeting notes |
-| `resource.md` | `_chiron/templates/` | Reference material |
-| `area.md` | `_chiron/templates/` | Area definition |
-
-**Steps:**
-1. Read template from `_chiron/templates/[template-name].md`
-2. Replace template variables ({{date}}, {{project}}, etc.)
-3. Create new file in appropriate location
-4. Fill in placeholder sections
-
-**Example:**
-```
-User: "Create a new project using the project template for 'Learn Rust'"
-
-Action:
-1. Read _chiron/templates/project.md
-2. Replace {{project}} with "learn-rust", {{date}} with today
-3. Create: ~/CODEX/01-projects/personal/learn-rust/_index.md
-4. Fill in: deadline, priority, goals, etc.
-```
-
-### Search Vault
-
-**When user says**: "Search for X", "Find notes about X", "Where's X?"
-
-**Search methods:**
-
-1. **Simple search**: `rg "term" ~/CODEX --type md`
-2. **Tag search**: `rg "#tag" ~/CODEX --type md`
-3. **Task search**: `rg "- \\[ \\]" ~/CODEX --type md`
-4. **Wiki-link search**: `rg "\\[\\[.*\\]\\]" ~/CODEX --type md`
-
-**Present results grouped by:**
-- Location (Projects/Areas/Resources)
-- Relevance
-- Date modified
-
-### Organize Files
-
-**When user says**: "Organize inbox", "Move X to Y", "File this note"
-
-**Steps:**
-1. Read file to determine content
-2. Consult chiron-core PARA guidance for proper placement
-3. Create proper directory structure if needed
-4. Move file maintaining links
-5. Update wiki-links if file moved
-
-**Example:**
-```
-User: "Organize my inbox"
-
-Action:
-1. List files in 00-inbox/
-2. For each file:
-   - Read content
-   - Determine PARA category
-   - Move to appropriate location
-3. Update broken links
-4. Confirm: "Moved 5 files from inbox to Projects (2), Resources (2), Archive (1)"
-```
-
-## File Operations
-
-### Paths
-
-**Always use absolute paths:**
-- `~/CODEX/` → `/home/username/knowledge/`
-- Expand `~` before file operations
-
-### Filenames
-
-**Naming conventions:**
-- Notes: `kebab-case.md` (all lowercase, hyphens)
-- Projects: `project-name/` (directory with `_index.md`)
-- Daily notes: `YYYY-MM-DD.md` (ISO date)
-- Templates: `template-name.md` (kebab-case)
-
-**Do NOT use:**
-- Spaces in filenames
-- CamelCase (use kebab-case)
-- Special characters (except hyphens and underscores)
-
-### Frontmatter
-
-**Required fields:**
-```yaml
----
-title: "Note Title"
-tags: [tag1, tag2]
-created: YYYY-MM-DD
-modified: YYYY-MM-DD
----
-```
-
-**Project frontmatter:**
-```yaml
----
-title: "Project Name"
-status: active | on-hold | completed
-deadline: YYYY-MM-DD
-priority: critical | high | medium | low
-tags: [work, personal]
----
-```
-
-**Task file frontmatter:**
-```yaml
----
-title: "Task List"
-context: daily | project | area
-tags: [tasks]
----
-```
-
-### Wiki-Links
-
-**Format:** `[[Note Name]]` or `[[Note Name|Display Text]]`
-
-**Best practices:**
-- Use exact note titles
-- Include display text for clarity
-- Link to related concepts
-- Back-link from destination notes
-
-### Tags
-
-**Format:** `#tagname` or `#tag/subtag`
-
-**Common tags:**
-- `#work`, `#personal`
-- `#critical`, `#high`, `#low`
-- `#project`, `#area`, `#resource`
-- `#todo`, `#done`, `#waiting`
-
-## Template System
-
-### Template Variables
-
-Replace these when using templates:
-
-| Variable | Replacement |
-|----------|-------------|
-| `{{date}}` | Current date (YYYY-MM-DD) |
-| `{{datetime}}` | Current datetime (YYYY-MM-DD HH:mm) |
-| `{{project}}` | Project name |
-| `{{area}}` | Area name |
-| `{{title}}` | Note title |
-| `{{week}}` | Week number (e.g., W04) |
-
-### Template Locations
-
-**Core templates** in `_chiron/templates/`:
-- `daily-note.md` - Daily planning and reflection
-- `weekly-review.md` - Weekly review structure
-- `project.md` - Project initialization
-- `meeting.md` - Meeting notes template
-- `resource.md` - Reference material
-- `area.md` - Area definition
-- `learning.md` - Learning capture
-
-### Custom Templates
-
-**User can add** templates to `_chiron/templates/`:
-1. Create new template file
-2. Use variable syntax: `{{variable}}`
-3. Document in `_chiron/templates/README.md`
-4. Reference in obsidian-management skill
-
-## Integration with Other Skills
-
-**Calls to other skills:**
-- `chiron-core` - PARA methodology guidance for organization
-- `task-management` - Extract/update tasks from notes
-- `quick-capture` - Process inbox items
-- `meeting-notes` - Apply meeting template
-
-**Delegation rules:**
-- User asks about PARA → `chiron-core`
-- User wants task operations → `task-management`
-- User wants quick capture → `quick-capture`
-- User wants meeting structure → `meeting-notes`
-
-## File Format Standards
-
-### Task Format (Obsidian Tasks plugin)
-
-```markdown
-- [ ] Task description #tag ⏫ 📅 YYYY-MM-DD
-```
-
-**Priority indicators:**
-- ⏫ = Critical (urgent AND important)
-- 🔼 = High (important, not urgent)
-- 🔽 = Low (nice to have)
-
-**Date indicators:**
-- 📅 = Due date
-- ⏳ = Start date
-- 🛫 = Scheduled date
-
-### Dataview Queries
-
-```dataview
-LIST WHERE status = "active"
-FROM "01-projects"
-SORT deadline ASC
-```
-
-```dataview
-TABLE deadline, status, priority
-FROM "-04-archive"
-WHERE contains(tags, "#work")
-SORT deadline ASC
-```
-
-### Callouts
-
-```markdown
-> [!INFO] Information
-> Helpful note
-
-> [!WARNING] Warning
-> Important alert
-
-> [!TIP] Tip
-> Suggestion
-
-> [!QUESTION] Question
-> To explore
-```
-
-## Error Handling
-
-### File Not Found
-1. Search for similar filenames
-2. Ask user to confirm
-3. Offer to create new file
-
-### Directory Not Found
-1. Create directory structure
-2. Confirm with user
-3. Create parent directories as needed
-
-### Template Not Found
-1. List available templates
-2. Offer to create template
-3. Use basic note structure if needed
-
-### Link Breaks After Move
-1. Find all notes linking to moved file
-2. Update links to new path
-3. Confirm updated links count
-
-## Best Practices
-
-### When Creating Notes
-1. Use descriptive titles
-2. Add relevant tags
-3. Link to related notes immediately
-4. Use appropriate frontmatter
-
-### When Editing Notes
-1. Preserve existing formatting
-2. Update `modified` date in frontmatter
-3. Maintain wiki-link structure
-4. Check for broken links
-
-### When Organizing
-1. Ask user before moving files
-2. Update all links
-3. Confirm final locations
-4. Document changes in daily note
-
-## Quick Reference
-
-| Action | Command Pattern |
-|--------|-----------------|
-| Create note | "Create note [title] in [location]" |
-| Read note | "Read [note-name]" or "Show me [note-name]" |
-| Edit note | "Update [note-name] with [content]" |
-| Search | "Search vault for [term]" or "Find notes about [topic]" |
-| Use template | "Create [note-type] using template" |
-| Organize inbox | "Organize inbox" or "Process inbox items" |
-| Move file | "Move [file] to [location]" |
-
-## Resources
-
-- `references/file-formats.md` - Detailed format specifications
-- `references/dataview-guide.md` - Dataview query patterns
-- `references/link-management.md` - Wiki-link best practices
-- `assets/templates/` - All template files
-
-**Load references when:**
-- User asks about format details
-- Creating complex queries
-- Troubleshooting link issues
-- Template customization needed

skills/obsidian/SKILL.md

@@ -0,0 +1,337 @@
+---
+name: obsidian
+description: "Obsidian Local REST API integration for knowledge management. Use when: (1) Creating, reading, updating, or deleting notes in Obsidian vault, (2) Searching vault content by title, content, or tags, (3) Managing daily notes and journaling, (4) Working with WikiLinks and vault metadata. Triggers: 'Obsidian', 'note', 'vault', 'WikiLink', 'daily note', 'journal', 'create note'."
+compatibility: opencode
+---
+
+# Obsidian
+
+Knowledge management integration via Obsidian Local REST API for vault operations, note CRUD, search, and daily notes.
+
+## Prerequisites
+
+- **Obsidian Local REST API plugin** installed and enabled in Obsidian
+- **API server running** on default port `27124` (or configured custom port)
+- **Vault path** configured in plugin settings
+- **API key** set (optional, if authentication enabled)
+
+API endpoints available at `http://127.0.0.1:27124` by default.
+
+## Core Workflows
+
+### List Vault Files
+
+Get list of all files in vault:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/list"
+```
+
+Returns array of file objects with `path`, `mtime`, `ctime`, `size`.
+
+### Get File Metadata
+
+Retrieve metadata for a specific file:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/get-file-info?path=Note%20Title.md"
+```
+
+Returns file metadata including tags, links, frontmatter.
+
+### Create Note
+
+Create a new note in the vault:
+
+```bash
+curl -X POST "http://127.0.0.1:27124/create-note" \
+  -H "Content-Type: application/json" \
+  -d '{"content": "# Note Title\n\nNote content..."}'
+```
+
+Use `path` parameter for specific location:
+```json
+{
+  "content": "# Note Title\n\nNote content...",
+  "path": "subdirectory/Note Title.md"
+}
+```
+
+### Read Note
+
+Read note content by path:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/read-note?path=Note%20Title.md"
+```
+
+Returns note content as plain text or structured JSON with frontmatter parsing.
+
+### Update Note
+
+Modify existing note:
+
+```bash
+curl -X PUT "http://127.0.0.1:27124/update-note" \
+  -H "Content-Type: application/json" \
+  -d '{"path": "Note Title.md", "content": "# Updated Title\n\nNew content..."}'
+```
+
+### Delete Note
+
+Remove note from vault:
+
+```bash
+curl -X DELETE "http://127.0.0.1:27124/delete-note?path=Note%20Title.md"
+```
+
+**Warning**: This operation is irreversible. Confirm with user before executing.
+
+### Search Notes
+
+Find notes by content, title, or tags:
+
+```bash
+# Content search
+curl -X GET "http://127.0.0.1:27124/search?q=search%20term"
+
+# Search with parameters
+curl -X GET "http://127.0.0.1:27124/search?q=search%20term&path=subdirectory&context-length=100"
+```
+
+Returns array of matches with file path and context snippets.
+
+### Daily Notes
+
+#### Get Daily Note
+
+Retrieve or create daily note for specific date:
+
+```bash
+# Today
+curl -X GET "http://127.0.0.1:27124/daily-note"
+
+# Specific date (YYYY-MM-DD)
+curl -X GET "http://127.0.0.1:27124/daily-note?date=2026-02-03"
+```
+
+Returns daily note content or creates using Obsidian's Daily Notes template.
+
+#### Update Daily Note
+
+Modify today's daily note:
+
+```bash
+curl -X PUT "http://127.0.0.1:27124/daily-note" \
+  -H "Content-Type: application/json" \
+  -d '{"content": "## Journal\n\nToday I learned..."}'
+```
+
+### Get Vault Info
+
+Retrieve vault metadata:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/vault-info"
+```
+
+Returns vault path, file count, and configuration details.
+
+## Note Structure Patterns
+
+### Frontmatter Conventions
+
+Use consistent frontmatter for note types:
+
+```yaml
+---
+date: 2026-02-03
+created: 2026-02-03T10:30:00Z
+type: note
+tags: #tag1 #tag2
+status: active
+---
+```
+
+### WikiLinks
+
+Reference other notes using Obsidian WikiLinks:
+- `[[Note Title]]` - Link to note by title
+- `[[Note Title|Alias]]` - Link with custom display text
+- `[[Note Title#Heading]]` - Link to specific heading
+- `![[Image.png]]` - Embed images or media
+
+### Tagging
+
+Use tags for categorization:
+- `#tag` - Single-word tag
+- `#nested/tag` - Hierarchical tags
+- Tags in frontmatter for metadata
+- Tags in content for inline categorization
+
+## Workflow Examples
+
+### Create Brainstorm Note
+
+```bash
+curl -X POST "http://127.0.0.1:27124/create-note" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "path": "03-resources/brainstorms/2026-02-03-Topic.md",
+    "content": "---\ndate: 2026-02-03\ncreated: 2026-02-03T10:30:00Z\ntype: brainstorm\nframework: pros-cons\nstatus: draft\ntags: #brainstorm #pros-cons\n---\n\n# Topic\n\n## Context\n\n## Options\n\n## Decision\n"
+  }'
+```
+
+### Append to Daily Journal
+
+```bash
+# Get current daily note
+NOTE=$(curl -s "http://127.0.0.1:27124/daily-note")
+
+# Append content
+curl -X PUT "http://127.0.0.1:27124/daily-note" \
+  -H "Content-Type: application/json" \
+  -d "{\"content\": \"${NOTE}\n\n## Journal Entry\n\nLearned about Obsidian API integration.\"}"
+```
+
+### Search and Link Notes
+
+```bash
+# Search for related notes
+curl -s "http://127.0.0.1:27124/search?q=Obsidian"
+
+# Create note with WikiLinks to found notes
+curl -X POST "http://127.0.0.1:27124/create-note" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "path": "02-areas/Obsidian API Guide.md",
+    "content": "# Obsidian API Guide\n\nSee [[API Endpoints]] and [[Workflows]] for details."
+  }'
+```
+
+## Integration with Other Skills
+
+| From Obsidian | To skill | Handoff pattern |
+|--------------|----------|----------------|
+| Note created | brainstorming | Create brainstorm note with frontmatter |
+| Daily note updated | reflection | Append conversation analysis to journal |
+| Research note | research | Save research findings with tags |
+| Project note | task-management | Link tasks to project notes |
+| Plan document | plan-writing | Save generated plan to vault |
+| Memory note | memory | Create/read memory notes in 80-memory/ |
+
+## Best Practices
+
+1. **Use paths consistently** - Follow PARA structure or vault conventions
+2. **Include frontmatter** - Enables search and metadata queries
+3. **Use WikiLinks** - Creates knowledge graph connections
+4. **Validate paths** - Check file existence before operations
+5. **Handle errors** - API may return 404 for non-existent files
+6. **Escape special characters** - URL-encode paths with spaces or symbols
+7. **Backup vault** - REST API operations modify files directly
+
+---
+
+## Memory Folder Conventions
+
+The `80-memory/` folder stores dual-layer memories synced with Mem0.
+
+### Structure
+
+```
+80-memory/
+├── preferences/    # Personal preferences (UI, workflow, communication)
+├── facts/          # Objective information (role, tech stack, constraints)
+├── decisions/      # Choices with rationale (tool selections, architecture)
+├── entities/       # People, organizations, systems, concepts
+└── other/          # Everything else
+```
+
+### Naming Convention
+
+Memory notes use kebab-case: `prefers-dark-mode.md`, `uses-typescript.md`
+
+### Required Frontmatter
+
+```yaml
+---
+type: memory
+category:        # preference | fact | decision | entity | other
+mem0_id:         # Mem0 memory ID (e.g., "mem_abc123")
+source: explicit # explicit | auto-capture
+importance:      # critical | high | medium | low
+created: 2026-02-12
+updated: 2026-02-12
+tags:
+  - memory
+sync_targets: []
+---
+```
+
+### Key Fields
+
+| Field | Purpose |
+|-------|---------|
+| `mem0_id` | Links to Mem0 entry for semantic search |
+| `category` | Determines subfolder and classification |
+| `source` | How memory was captured (explicit request vs auto) |
+| `importance` | Priority for recall ranking |
+
+---
+
+## Memory Note Workflows
+
+### Create Memory Note
+
+When creating a memory note in the vault:
+
+```bash
+# Using REST API
+curl -X POST "http://127.0.0.1:27124/create-note" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "path": "80-memory/preferences/prefers-dark-mode.md",
+    "content": "---\ntype: memory\ncategory: preference\nmem0_id: mem_abc123\nsource: explicit\nimportance: medium\ncreated: 2026-02-12\nupdated: 2026-02-12\ntags:\n  - memory\nsync_targets: []\n---\n\n# Prefers Dark Mode\n\n## Content\n\nUser prefers dark mode in all applications.\n\n## Context\n\nStated during UI preferences discussion on 2026-02-12.\n\n## Related\n\n- [[UI Settings]]\n"
+  }'
+```
+
+### Read Memory Note
+
+Read by path with URL encoding:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/read-note?path=80-memory%2Fpreferences%2Fprefers-dark-mode.md"
+```
+
+### Search Memories
+
+Search within memory folder:
+
+```bash
+curl -X GET "http://127.0.0.1:27124/search?q=dark%20mode&path=80-memory"
+```
+
+### Update Memory Note
+
+Update content and frontmatter:
+
+```bash
+curl -X PUT "http://127.0.0.1:27124/update-note" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "path": "80-memory/preferences/prefers-dark-mode.md",
+    "content": "# Updated content..."
+  }'
+```
+
+---
+
+## Error Handling
+
+Common HTTP status codes:
+- `200 OK` - Success
+- `404 Not Found` - File or resource doesn't exist
+- `400 Bad Request` - Invalid parameters or malformed JSON
+- `500 Internal Server Error` - Plugin or vault error
+
+Check API response body for error details before retrying operations.

skills/outline/SKILL.md

@@ -1,484 +1,126 @@
 ---
 name: outline
-description: "Search, read, and manage Outline wiki documentation via MCP. Use when: (1) searching Outline wiki, (2) reading/exporting Outline documents, (3) creating/updating Outline docs, (4) managing collections, (5) finding wiki content. Triggers: outline, wiki, search outline, find in wiki, export document."
+description: "Outline wiki integration for knowledge management and documentation workflows. Use when Opencode needs to interact with Outline for: (1) Creating and editing documents, (2) Searching and retrieving knowledge base content, (3) Managing document collections and hierarchies, (4) Handling document sharing and permissions, (5) Collaborative features like comments. Triggers: 'Outline', 'wiki', 'knowledge base', 'documentation', 'team docs', 'document in Outline', 'search Outline', 'Outline collection'."
 compatibility: opencode
 ---
 
 # Outline Wiki Integration
 
-MCP server integration for Outline wiki documentation - search, read, create, and manage wiki content.
+Outline is a team knowledge base and wiki platform. This skill provides guidance for Outline API operations and knowledge management workflows.
 
-## Quick Reference
+## Core Capabilities
 
-| Action          | Command Pattern                        |
-| --------------- | -------------------------------------- |
-| Search wiki     | "Search Outline for [topic]"             |
-| Read document   | "Show me [document name]"               |
-| Export to vault  | "Export [document] to Obsidian"         |
-| Create doc      | "Create Outline doc: [title]"            |
-| List collections | "Show Outline collections"                 |
+### Document Operations
 
-## Core Workflows
-
-### 1. Search Wiki
-
-**When user says**: "Search Outline for X", "Find in wiki about X", "Outline wiki: X"
-
-**Steps**:
-```
-1. search_documents(query, collection_id?, limit?, offset?)
-   - If collection_id provided → search in specific collection
-   - If no collection_id → search all collections
-   - Default limit: 20 results
-2. Present results:
-   - Document titles
-   - Collection names
-   - Relevance (if available)
-3. Offer actions:
-   - "Read specific document"
-   - "Export to Obsidian"
-   - "Find related documents"
-```
-
-**Example output**:
-```
-Found 5 documents matching "API authentication":
-
-📄 Authentication Best Practices (Collection: Engineering)
-📄 OAuth2 Setup Guide (Collection: Security)
-📄 API Key Management (Collection: DevOps)
-📄 Common Auth Errors (Collection: Troubleshooting)
-
-Read any document or export to Obsidian?
-```
-
-### 2. Read Document
-
-**When user says**: "Show me [document]", "What's in [document]", "Read [doc from Outline]"
-
-**Steps**:
-```
-1. get_document_id_from_title(query, collection_id?)
-   - Search by exact title
-   - Return document ID
-2. read_document(document_id)
-   - Get full markdown content
-3. Present content:
-   - Title and metadata
-   - Document content (formatted)
-   - Collection location
-   - Tags (if available)
-4. Offer follow-up:
-   - "Export to Obsidian?"
-   - "Find related documents?"
-   - "Add to project?"
-```
-
-**Example output**:
-```markdown
-# Authentication Best Practices
-**Collection**: Engineering
-**Last updated**: 2026-01-25
-
-## OAuth2 Flow
-[Document content...]
-
-## API Keys
-[Document content...]
-
----
-
-📂 Export to Obsidian | 🔗 Find related | ➕ Add to project
-```
-
-### 3. Export to Obsidian
-
-**When user says**: "Export [document] to Obsidian", "Save [wiki page] to vault"
-
-**Steps**:
-```
-1. export_document(document_id)
-   - Get markdown content
-2. Determine Obsidian location:
-   - If for project: `01-projects/work/[project]/notes/[doc-name].md`
-   - If general: `03-resources/work/wiki-mirror/[doc-name].md`
-3. Add frontmatter:
-   ---
-   title: "[Document Title]"
-   source: outline
-   document_id: [ID]
-   collection: "[Collection Name]"
-   tags: [work, wiki, outline]
-   ---
-4. Create file in vault
-5. Link to context:
-   - Project: [[Project Name]]
-   - Related resources
-6. Confirm: "Exported [document] to [location]"
-```
-
-**File naming**:
-- Convert to kebab-case: `Authentication Best Practices` → `authentication-best-practices.md`
-- Preserve collection hierarchy: `[collection-name]/[doc-name].md`
-
-### 4. Create Document
-
-**When user says**: "Create Outline doc: [title]", "Add wiki page: [title]"
-
-**Steps**:
-```
-1. Ask for details:
-   - Collection (list available if needed)
-   - Content (markdown text)
-   - Parent document (if hierarchical)
-   - Publish immediately?
-
-2. create_document(title, collection_id, text?, parent_document_id?, publish?)
-3. Confirm creation:
-   - Document ID
-   - URL (if Outline has web UI)
-4. Offer actions:
-   - "Add backlink?"
-   - "Create in Obsidian too?"
-   - "Link to project?"
-```
-
-### 5. Document Discovery
-
-**When user says**: "Show Outline collections", "Browse wiki", "What's in [collection]?"
-
-**Steps**:
-```
-1. list_collections()
-   - Get all collections with metadata
-2. Present hierarchy:
-   - Collection names
-   - Document counts
-   - Colors (if set)
-3. User selects collection
-4. get_collection_structure(collection_id)
-   - Show document tree
-   - Hierarchical view
-```
-
-**Example output**:
-```
-Outline Wiki Collections:
-
-📁 Engineering (15 docs)
-  ├─ API Documentation (8 docs)
-  └─ System Design (7 docs)
-
-📁 Product (12 docs)
-  ├─ Features (6 docs)
-  └─ User Guides (6 docs)
-
-📁 Security (8 docs)
-
-Browse which collection?
-```
-
-### 6. AI-Powered Search
-
-**When user says**: "Ask Outline about X", "What does Outline say about X?"
-
-**Steps**:
-```
-1. ask_ai_about_documents(question, collection_id?, document_id?)
-   - Natural language query
-   - AI searches across documents
-2. Present AI answer:
-   - Summary of findings
-   - Source documents referenced
-   - Confidence (if available)
-3. Offer:
-   - "Read source documents"
-   - "Export to Obsidian"
-```
-
-**Example output**:
-```
-🤖 Answer from Outline wiki:
-
-Based on 12 documents, here's what I found about API authentication:
-
-**Summary**:
-- OAuth2 is preferred over API keys
-- Tokens expire after 30 days
-- Refresh tokens allow seamless re-authentication
-
-**Key Sources**:
-1. OAuth2 Setup Guide (Engineering/Security)
-2. Authentication Best Practices (Engineering)
-3. Token Management (DevOps)
-
-Read any source document?
-```
-
-## Tool Reference
-
-### Search & Discovery
-
-- `search_documents(query, collection_id?, limit?, offset?)`
-  - Full-text search across wiki
-  - Optional: Scope to specific collection
-  - Pagination support
-
-- `list_collections()`
-  - Get all collections with metadata
-  - Names, descriptions, colors, doc counts
-
-- `get_collection_structure(collection_id)`
-  - Hierarchical document tree
-  - Parent-child relationships
-
-- `get_document_id_from_title(query, collection_id?)`
-  - Find document by title
-  - Exact or fuzzy match
-
-### Document Reading
-
-- `read_document(document_id)`
-  - Full document content
-  - Markdown format
-  - Metadata included
-
-- `export_document(document_id)`
-  - Export as markdown
-  - Same content as read_document
-  - Designed for exports
-
-### Document Management
-
-- `create_document(title, collection_id, text?, parent_document_id?, publish?)`
-  - Create new wiki page
-  - Support for hierarchical docs
-  - Draft or published
-
-- `update_document(document_id, title?, text?, append?)`
-  - Update existing document
-  - Append mode for additions
-  - Preserve history
-
-- `move_document(document_id, collection_id?, parent_document_id?)`
-  - Move between collections
-  - Reorganize hierarchy
-
-### Document Lifecycle
-
-- `archive_document(document_id)`
-  - Archive (not delete)
-  - Can be restored
-
-- `unarchive_document(document_id)`
-  - Restore from archive
-
-- `delete_document(document_id, permanent?)`
-  - Move to trash or permanent delete
-  - Requires careful confirmation
-
-### Comments & Collaboration
-
-- `add_comment(document_id, text, parent_comment_id?)`
-  - Add threaded comments
-  - Support for replies
-
-- `list_document_comments(document_id, include_anchor_text?, limit?, offset?)`
-  - View discussion on document
-  - Threaded view
-
-- `get_document_backlinks(document_id)`
-  - Find documents linking here
-  - Useful for context
+- **Create**: Create new documents with markdown content
+- **Read**: Retrieve document content, metadata, and revisions
+- **Update**: Edit existing documents, update titles and content
+- **Delete**: Remove documents (with appropriate permissions)
 
 ### Collection Management
 
-- `create_collection(name, description?, color?)`
-  - Create new collection
-  - For organizing docs
+- **Organize**: Structure documents in collections and nested collections
+- **Hierarchies**: Create parent-child relationships
+- **Access Control**: Set permissions at collection level
 
-- `update_collection(collection_id, name?, description?, color?)`
-  - Edit collection metadata
+### Search and Discovery
 
-- `delete_collection(collection_id)`
-  - Remove collection
-  - Affects all documents in it
+- **Full-text search**: Find documents by content
+- **Metadata filters**: Search by collection, author, date
+- **Advanced queries**: Combine multiple filters
 
-- `export_collection(collection_id, format?)`
-  - Export entire collection
-  - Default: outline-markdown
+### Sharing and Permissions
 
-- `export_all_collections(format?)`
-  - Export all wiki content
-  - Full backup
+- **Public links**: Generate shareable document URLs
+- **Team access**: Manage member permissions
+- **Guest access**: Control external sharing
 
-### Batch Operations
+### Collaboration
 
-- `batch_create_documents(documents)`
-  - Create multiple docs at once
-  - For bulk imports
+- **Comments**: Add threaded discussions to documents
+- **Revisions**: Track document history and changes
+- **Notifications**: Stay updated on document activity
 
-- `batch_update_documents(updates)`
-  - Update multiple docs
-  - For maintenance
+## Workflows
 
-- `batch_move_documents(document_ids, collection_id?, parent_document_id?)`
-  - Move multiple docs
-  - Reorganization
+### Creating a New Document
 
-### AI-Powered
+1. Determine target collection
+2. Create document with title and initial content
+3. Set appropriate permissions
+4. Share with relevant team members if needed
 
-- `ask_ai_about_documents(question, collection_id?, document_id?)`
-  - Natural language queries
-  - AI-powered search
-  - Synthesizes across documents
+### Searching Knowledge Base
 
-## Integration with Other Skills
+1. Formulate search query
+2. Apply relevant filters (collection, date, author)
+3. Review search results
+4. Retrieve full document content when needed
 
-| From Skill | To Outline |
-| ----------- | ---------- |
-| meeting-notes | Export decisions to wiki |
-| project-structures | Link project docs to wiki |
-| daily-routines | Capture learnings in wiki |
-| brainstorming | Save decisions to wiki |
+### Organizing Documents
 
-## Integration with Obsidian
+1. Review existing collection structure
+2. Identify appropriate parent collection
+3. Create or update documents in hierarchy
+4. Update collection metadata if needed
 
-### Export Workflow
+### Document Collaboration
 
-**When to export**:
-- Important decisions made
-- Project documentation needed offline
-- Wiki content to reference locally
-- Job transition (export all)
+1. Add comments for feedback or discussion
+2. Track revision history for changes
+3. Notify stakeholders when needed
+4. Resolve comments when addressed
 
-**Export locations**:
-```
-~/CODEX/
-├── 01-projects/work/
-│   └── [project]/
-│       └── notes/
-│           └── [exported-doc].md  # Linked to project
-└── 03-resources/work/
-    └── wiki-mirror/
-        ├── [collection-name]/
-        │   └── [doc].md          # Exported wiki pages
-        └── _wiki-index.md           # Index of all exports
-```
+## Integration Patterns
 
-**Wiki index structure**:
-```markdown
----
-title: "Outline Wiki Index"
-source: outline
-last_sync: YYYY-MM-DD
----
+### Knowledge Capture
 
-## Collections
-- [Engineering](engineering/) - 15 docs
-- [Product](product/) - 12 docs
-- [Security](security/) - 8 docs
+When capturing information from conversations or research:
+- Create document in appropriate collection
+- Use clear, descriptive titles
+- Structure content with headers for readability
+- Add tags for discoverability
 
-## Recently Exported
-- [[OAuth2 Setup Guide]] - 2026-01-25
-- [[API Documentation]] - 2026-01-24
-- [[System Design]] - 2026-01-23
+### Documentation Updates
 
-## Search Wiki
-<!-- Use outline MCP for live search -->
-"Search Outline for..." → outline skill
-```
+When updating existing documentation:
+- Retrieve current document revision
+- Make targeted, minimal changes
+- Add comments explaining significant updates
+- Share updates with relevant stakeholders
 
-## Access Control Notes
+### Knowledge Retrieval
 
-If Outline MCP is configured with `OUTLINE_READ_ONLY=true`:
-- ❌ Cannot create documents
-- ❌ Cannot update documents
-- ❌ Cannot move/archive/delete
-- ✅ Can search and read
-- ✅ Can export documents
+When searching for information:
+- Start with broad search terms
+- Refine with collection and metadata filters
+- Review multiple relevant documents
+- Cross-reference linked documents for context
 
-If `OUTLINE_DISABLE_DELETE=true`:
-- ✅ Can create and update
-- ❌ Cannot delete (protects against accidental loss)
+## Common Use Cases
 
-## Work vs Personal Usage
-
-### Work Wiki (Primary)
-- Collections: Engineering, Product, Security, etc.
-- Export to: `03-resources/work/wiki-mirror/`
-- Projects link to: `[[Engineering/Design Decisions]]`
-
-### Personal Wiki (Optional)
-- Collections: Recipes, Travel, Hobbies, etc.
-- Export to: `03-resources/personal/wiki/`
-- Separate from work content
+| Use Case | Recommended Approach |
+|----------|---------------------|
+| Project documentation | Create collection per project, organize by phase |
+| Team guidelines | Use dedicated collection, group by topic |
+| Meeting notes | Create documents with templates, tag by team |
+| Knowledge capture | Search before creating, link to related docs |
+| Onboarding resources | Create structured collection with step-by-step guides |
 
 ## Best Practices
 
-### Searching
-- Use specific keywords (not "everything about X")
-- Use collection_id for focused search
-- Check multiple collections if first search is limited
+- **Consistent naming**: Use clear, descriptive titles
+- **Logical organization**: Group related documents in collections
+- **Regular maintenance**: Review and update outdated content
+- **Access control**: Set appropriate permissions for sensitive content
+- **Searchability**: Use tags and metadata effectively
+- **Collaboration**: Use comments for discussions, not content changes
 
-### Exporting
-- Export decisions, not just reference docs
-- Link exported docs to projects immediately
-- Update wiki index after export
-- Regular exports for offline access
+## Handoff to Other Skills
 
-### Creating Documents
-- Use clear, descriptive titles
-- Add to appropriate collection
-- Link related documents
-- Add tags for discoverability
-
-### AI Queries
-- Ask specific questions (not "everything about X")
-- Use collection_id to scope query
-- Verify AI sources by reading docs
-- Use AI to synthesize, not replace reading
-
-## Error Handling
-
-### Document Not Found
-1. Check title spelling
-2. Try fuzzy search
-3. Search collection directly
-
-### Collection Not Found
-1. List all collections
-2. Check collection name
-3. Verify access permissions
-
-### Export Failed
-1. Check Obsidian vault path
-2. Verify disk space
-3. Check file permissions
-4. Create directories if needed
-
-### Rate Limiting
-- Outline MCP handles automatically with retries
-- Reduce concurrent operations if persistent errors
-
-## Quick Reference
-
-| Action | Command Pattern |
-|--------|-----------------|
-| Search wiki | "Search Outline for [topic]" |
-| Read document | "Show me [document name]" |
-| Export to vault | "Export [document] to Obsidian" |
-| Create doc | "Create Outline doc: [title]" |
-| List collections | "Show Outline collections" |
-| AI query | "Ask Outline about [question]" |
-| Browse structure | "Browse wiki" or "Show Outline collections" |
-
-## Resources
-
-- `references/outline-workflows.md` - Detailed workflow examples
-- `references/export-patterns.md` - Obsidian integration patterns
-
-**Load references when**:
-- Designing complex exports
-- Troubleshooting integration issues
-- Setting up project-to-wiki links
+| Output | Next Skill | Trigger |
+|--------|------------|---------|
+| Research findings | knowledge-management | "Organize this research in Outline" |
+| Documentation draft | communications | "Share this document via email" |
+| Task from document | task-management | "Create tasks from this outline" |
+| Project plan | plan-writing | "Create project plan in Outline" |

skills/outline/references/export-patterns.md

@@ -1,524 +0,0 @@
-# Export Patterns
-
-Patterns and examples for exporting Outline wiki content to Obsidian vault.
-
-## Table of Contents
-1. [Frontmatter Patterns](#frontmatter-patterns)
-2. [Folder Structure](#folder-structure)
-3. [Linking Strategies](#linking-strategies)
-4. [Index Management](#index-management)
-5. [Batch Operations](#batch-operations)
-
----
-
-## Frontmatter Patterns
-
-### Standard Export Frontmatter
-
-```yaml
----
-title: "Document Title"
-source: outline
-document_id: "abc123def456"
-collection: "Engineering/Security"
-collection_id: "col_789"
-tags: [work, wiki, outline, security]
-outline_url: "https://outline.example.com/doc/abc123"
-created_at: "2026-01-28"
-exported_at: "2026-01-28"
-last_updated: "2026-01-25"
----
-```
-
-### Decision Document Frontmatter
-
-```yaml
----
-title: "API Authentication Decision"
-source: outline
-type: decision
-decision_date: "2026-01-28"
-made_by: "Team Name"
-decision_status: active | implemented | archived
-tags: [work, wiki, decision, api, security]
----
-
-# Decision
-Use OAuth2 for all external API integrations.
-```
-
-### Process Document Frontmatter
-
-```yaml
----
-title: "API Onboarding Process"
-source: outline
-type: process
-version: "2.1"
-last_reviewed: "2026-01-28"
-tags: [work, wiki, process, onboarding]
----
-
-# API Onboarding Process
-Step-by-step guide for new API consumers...
-```
-
-### Reference Document Frontmatter
-
-```yaml
----
-title: "OAuth2 Setup Guide"
-source: outline
-type: reference
-language: "markdown"
-estimated_read_time: "10 min"
-difficulty: intermediate
-tags: [work, wiki, reference, oauth2, api]
----
-
-# OAuth2 Setup Guide
-Complete guide for implementing OAuth2...
-```
-
----
-
-## Folder Structure
-
-### Standard Wiki Mirror Structure
-
-```
-~/CODEX/03-resources/work/wiki-mirror/
-├── _wiki-index.md                    # Main index
-├── engineering/                        # Collection folder
-│   ├── security/                      # Subfolder (hierarchy)
-│   │   ├── api-auth-decision.md
-│   │   └── security-best-practices.md
-│   ├── architecture/
-│   │   ├── system-design.md
-│   │   └── data-flow.md
-│   └── api-docs/
-│       ├── oauth2-setup.md
-│       ├── token-management.md
-│       └── api-reference.md
-├── product/
-│   ├── design-system.md
-│   ├── features/
-│   └── user-guides/
-└── operations/
-    ├── deployment/
-    ├── monitoring/
-    └── incident-response/
-```
-
-### Project-Specific Wiki Structure
-
-```
-~/CODEX/01-projects/work/[project]/
-├── _index.md                       # Project MOC with wiki links
-├── notes/
-│   ├── requirements.md
-│   ├── architecture-notes.md
-│   └── implementation-notes.md
-├── meetings/
-│   └── project-sync-20260128.md
-├── decisions/
-│   └── tech-stack-decision.md       # Also exported to wiki
-└── wiki-exports/                     # Project-specific wiki copies
-    ├── api-spec.md                 # Copy from Outline
-    └── design-decisions.md          # Copy from Outline
-```
-
----
-
-## Linking Strategies
-
-### Outline Document Link (MCP URI)
-
-```markdown
-# Direct MCP Link (Best for Outline)
-[OAuth2 Setup Guide](outline://document/abc123def456)
-```
-
-**Pros**:
-- Direct integration with Outline MCP
-- Always points to current version
-- Can open in Outline web UI if MCP fails
-
-**Cons**:
-- Requires Outline MCP to be active
-- Not clickable in external viewers
-
-### Wiki-Link with Reference
-
-```markdown
-# Wiki-Link (Best for Obsidian)
-📄 [[OAuth2 Setup Guide]]
-```
-
-**Frontmatter link**:
-```yaml
----
-title: "API Authentication Decision"
-wiki_link: "[[OAuth2 Setup Guide]]"
-wiki_doc_id: "abc123def456"
----
-```
-
-### External URL Link (Fallback)
-
-```markdown
-# URL Link (Fallback for offline/viewer access)
-[OAuth2 Setup Guide](https://outline.example.com/doc/abc123)
-```
-
-**In frontmatter**:
-```yaml
----
-outline_url: "https://outline.example.com/doc/abc123"
----
-```
-
-### Combined Strategy (Recommended)
-
-```markdown
----
-title: "API Authentication Decision"
-source: outline
-document_id: "abc123def456"
-wiki_link: "[[OAuth2 Setup Guide]]"
-outline_url: "https://outline.example.com/doc/abc123"
-tags: [work, decision, api]
----
-
-## Decision
-Use OAuth2 for all external APIs.
-
-## References
-
-### Primary Source
-📄 [[OAuth2 Setup Guide]](outline://document/abc123)
-
-### Related Documents
-📄 [[Token Management Policy]](outline://document/def456)
-📄 [[API Security Best Practices]](outline://document/ghi789)
-
-### External Links
-- [View in Outline Web UI](https://outline.example.com/doc/abc123)
-```
-
----
-
-## Index Management
-
-### Main Wiki Index
-
-```markdown
----
-title: "Outline Wiki Index"
-source: outline
-last_sync: "2026-01-28T18:50:00Z"
-total_docs: 45
-total_collections: 6
-tags: [work, wiki, outline]
----
-
-# Outline Wiki Index
-
-## Collections
-
-### 📁 Engineering (15 docs)
-**ID**: col_eng_123
-**Description**: Technical documentation, architecture, APIs
-
-**Subfolders**:
-- [security](engineering/security/) (3 docs)
-- [architecture](engineering/architecture/) (5 docs)
-- [api-docs](engineering/api-docs/) (7 docs)
-
-### 📁 Product (12 docs)
-**ID**: col_prod_456
-**Description**: Product specs, user guides, features
-
-**Subfolders**:
-- [design-system](product/design-system.md) (4 docs)
-- [features](product/features/) (6 docs)
-- [user-guides](product/user-guides/) (2 docs)
-
-### 📁 Security (8 docs)
-**ID**: col_sec_789
-**Description**: Security policies, incident response, compliance
-
-### 📁 Operations (10 docs)
-**ID**: col_ops_012
-**Description**: Deployment, monitoring, runbooks
-
-## Recently Exported
-
-| Date | Document | Collection | Tags |
-|-------|-----------|------------|-------|
-| 2026-01-28 | OAuth2 Setup Guide | Engineering/Security | api, oauth2 |
-| 2026-01-27 | System Design | Engineering/Architecture | architecture |
-| 2026-01-26 | Deployment Guide | Operations/Deployment | ops, devops |
-
-## Document Types
-
-- 📄 **Reference**: 30 docs
-- 🎯 **Decision**: 8 docs
-- 📋 **Process**: 5 docs
-- 📘 **Guide**: 2 docs
-
-## Search
-
-- 🔍 [Search Outline for](outline://search/) live content
-- 🔍 [Search exports](#exported-documents) in vault
-
----
-
-## Exported Documents
-
-### By Collection
-
-#### Engineering
-- [[OAuth2 Setup Guide]]
-- [[Token Management Policy]]
-- [[API Security Best Practices]]
-- [[System Design]]
-- [[Data Flow Architecture]]
-
-#### Product
-- [[Design System]]
-- [[Component Library]]
-- [[User Guide]]
-
-#### Security
-- [[Incident Response]]
-- [[Security Policy]]
-
-### By Tag
-
-#api
-- [[OAuth2 Setup Guide]]
-- [[API Security Best Practices]]
-
-#security
-- [[API Security Best Practices]]
-- [[Incident Response]]
-
-#architecture
-- [[System Design]]
-- [[Data Flow Architecture]]
-```
-
-### Collection-Specific Indexes
-
-Create `_index.md` in each collection folder:
-
-```markdown
----
-title: "Engineering Wiki"
-collection: Engineering
-collection_id: col_eng_123
-source: outline
-tags: [work, wiki, engineering]
----
-
-# Engineering Wiki
-
-## Overview
-Technical documentation, architecture decisions, and API references.
-
-## Structure
-
-### Security (3 docs)
-📄 [[API Authentication Decision]]
-📄 [[Security Best Practices]]
-📄 [[Incident Response]]
-
-### Architecture (5 docs)
-📄 [[System Design]]
-📄 [[Data Flow]]
-📄 [[Component Architecture]]
-📄 [[Scalability Guide]]
-📄 [[Performance Optimization]]
-
-### API Docs (7 docs)
-📄 [[OAuth2 Setup Guide]]
-📄 [[Token Management]]
-📄 [[API Reference]]
-📄 [[Rate Limiting]]
-📄 [[Error Handling]]
-📄 [[Webhooks]]
-📄 [[Testing Guide]]
-
-## Quick Links
-- 🔍 [Search Outline](outline://collection/col_eng_123)
-- 📄 [Export Collection](outline://export/col_eng_123)
-- 🌐 [Open in Web UI](https://outline.example.com/c/col_eng_123)
-```
-
----
-
-## Batch Operations
-
-### Export Multiple Documents
-
-```bash
-# Pattern for batch export (manual script outline)
-
-documents = [
-    {"id": "abc123", "path": "engineering/api/oauth2.md"},
-    {"id": "def456", "path": "engineering/api/token.md"},
-    {"id": "ghi789", "path": "engineering/security/best-practices.md"},
-]
-
-for doc in documents:
-    content = export_document(doc["id"])
-    write_file(f"wiki-mirror/{doc['path']}", content)
-    update_index(doc["id"], doc["path"])
-```
-
-### Update Index After Batch
-
-```markdown
----
-title: "Batch Export Report"
-export_date: 2026-01-28
-documents_exported: 45
-collections_exported: 6
----
-
-## Export Summary
-
-- Exported 45 documents from 6 collections
-- Total size: 2.3 MB
-- Processing time: 3.2 minutes
-
-## Collections Updated
-- ✅ Engineering: 15 docs
-- ✅ Product: 12 docs
-- ✅ Security: 8 docs
-- ✅ Operations: 10 docs
-
-## Next Steps
-- [ ] Verify all exports in Obsidian
-- [ ] Test wiki links
-- [ ] Update wiki index
-```
-
----
-
-## Naming Conventions
-
-### File Naming
-
-**Rules**:
-1. Lowercase only
-2. Replace spaces with hyphens
-3. Remove special characters
-4. Keep meaningful names
-5. Avoid dates in names (use frontmatter instead)
-
-**Examples**:
-```
-OAuth2 Setup Guide → oauth2-setup-guide.md
-API Security Best Practices → api-security-best-practices.md
-System Design (2026) → system-design.md (use frontmatter for version)
-```
-
-### Folder Naming
-
-**Rules**:
-1. Use collection names from Outline
-2. Preserve hierarchy (subcollections as subfolders)
-3. Consistent with project structure
-
-**Examples**:
-```
-Engineering/Security → engineering/security/
-Engineering/API Docs → engineering/api-docs/
-Product/Features → product/features/
-```
-
----
-
-## Version Control for Exports
-
-### Git Tracking
-
-```
-~/CODEX/03-resources/work/wiki-mirror/
-├── .git/                      # Git repo for exports
-├── _wiki-index.md
-└── engineering/
-    └── ...
-```
-
-**Benefits**:
-- Track changes to exported docs
-- Diff between export versions
-- Revert to previous exports
-- Track when docs were last synced
-
-### Sync Workflow
-
-```bash
-# Before export
-cd ~/CODEX/03-resources/work/wiki-mirror/
-git pull
-git add .
-git commit -m "Pre-export checkpoint"
-git push
-
-# After export
-git add .
-git commit -m "Exported 45 docs from Outline (2026-01-28)"
-git push
-```
-
----
-
-## Troubleshooting
-
-### Duplicate Exports
-
-**Problem**: Same document exported multiple times
-
-**Solution**:
-1. Check for existing file before export
-2. Add timestamp to duplicates: `doc-name.20260128.md`
-3. Or ask user: "Overwrite or create new version?"
-
-### Broken Links After Export
-
-**Problem**: Wiki links don't work in Obsidian
-
-**Solution**:
-1. Verify document IDs in frontmatter
-2. Check file paths match index
-3. Use wiki-links for same-vault docs
-4. Use MCP URIs for Outline docs
-
-### Large Exports Timeout
-
-**Problem**: Exporting entire collection fails (too large)
-
-**Solution**:
-1. Export in batches (e.g., 20 docs at a time)
-2. Use `export_collection` instead of individual docs
-3. Implement progress tracking
-4. Retry failed documents
-
----
-
-## Best Practices Summary
-
-1. **Always Include Frontmatter**: Document metadata is crucial
-2. **Maintain Hierarchy**: Preserve collection structure
-3. **Update Index**: Keep wiki index current
-4. **Use Multiple Link Types**: MCP URI + wiki-link + URL
-5. **Tag Exports**: Make exported docs discoverable
-6. **Track Changes**: Use Git for version control
-7. **Regular Exports**: Don't wait for job transition
-8. **Verify Links**: Test after every export batch
-9. **Organize by Type**: Reference, Decision, Process folders
-10. **Document Exports**: Keep export log for reference

skills/outline/references/outline-workflows.md

@@ -1,410 +0,0 @@
-# Outline Workflows
-
-This reference provides detailed examples and patterns for Outline wiki integration with Obsidian.
-
-## Table of Contents
-1. [Export Decision to Wiki](#export-decision-to-wiki)
-2. [Project Documentation Sync](#project-documentation-sync)
-3. [Knowledge Discovery](#knowledge-discovery)
-4. [Batch Export](#batch-export)
-5. [Wiki Migration](#wiki-migration)
-
----
-
-## Export Decision to Wiki
-
-### Scenario
-After a meeting, you made an important decision about API authentication. You want to preserve it in the company wiki.
-
-### Workflow
-```
-User: "Export decision: Use OAuth2 for all external APIs"
-
-Outline skill:
-1. Create document:
-   - Title: "API Authentication Decision"
-   - Collection: Engineering/Security
-   - Content:
-     ---
-     title: "API Authentication Decision"
-     date: 2026-01-28
-     decision_made_by: "[Team Name]"
-     tags: [decision, api, security]
-     ---
-
-     # Decision
-     Use OAuth2 for all external API integrations.
-
-     # Reasoning
-     - OAuth2 provides better security (no shared secrets)
-     - Token rotation reduces risk exposure
-     - Industry standard for API auth
-     - Existing libraries available
-
-     # Implementation
-     - Use RFC 6749 OAuth2 framework
-     - Implement refresh token flow
-     - Set 30-day token expiry
-     - Document API endpoints in collection
-
-     # Alternatives Considered
-     - API Keys: Rejected (security risk)
-     - JWT: Rejected (overkill for external APIs)
-     - Custom Auth: Rejected (maintenance burden)
-
-     # Related Documents
-     - [[OAuth2 Setup Guide]]
-     - [[Token Management Policy]]
-     - [[API Security Best Practices]]
-
-2. Confirm: "Created API Authentication Decision in Engineering/Security"
-3. Offer: "Link to project?"
-```
-
-### Obsidian Integration
-After creating in Outline, create cross-reference in Obsidian:
-```markdown
-~/CODEX/01-projects/work/[project]/decisions/api-auth-decision.md
----
-title: "API Authentication Decision"
-date: 2026-01-28
-source: outline
-outline_doc_id: [ID]
-tags: [work, decision, api]
----
-
-## Decision
-Use OAuth2 for all external API integrations.
-
-## Outline Link
-📄 [API Authentication Decision](outline://document/abc123)
-
-## Context
-- Made during API integration project
-- Discussed in [Security Review Meeting]
-- Approved by: [Stakeholder names]
-
-## Project Notes
-- Update authentication service by Q2
-- Train team on OAuth2 flow
-```
-
----
-
-## Project Documentation Sync
-
-### Scenario
-You're starting a new project. You want to link project docs with the wiki for context.
-
-### Workflow
-```
-User: "Start project: Customer Portal Redesign"
-
-outline skill:
-1. Search for related docs:
-   - "Search Outline for Customer Portal"
-   - "Search Outline for UI/UX guidelines"
-   - "Search Outline for architecture decisions"
-
-2. Present findings:
-   📄 Customer Portal Architecture (Engineering)
-   📄 UI Design System (Product/Design)
-   📄 Accessibility Guidelines (Engineering/Docs)
-
-3. Create project folder in Obsidian with wiki links
-```
-
-### Project MOC with Wiki Links
-```markdown
-~/CODEX/01-projects/work/customer-portal-redesign/_index.md
----
-title: "Customer Portal Redesign"
-status: active
-deadline: 2026-06-30
-priority: high
-tags: [work, project]
----
-
-## Overview
-Redesign of customer portal with improved UX, performance, and accessibility.
-
-## Wiki Resources
-
-### Architecture
-📄 [[Customer Portal Architecture]](outline://document/abc123)
-- Backend architecture decisions
-- Database schema
-- API endpoints
-
-### Design System
-📄 [[UI Design System]](outline://document/def456)
-- Component library
-- Color palette
-- Typography
-
-### Guidelines
-📄 [[Accessibility Guidelines]](outline://document/ghi789)
-- WCAG 2.1 AA compliance
-- Testing checklist
-- Common patterns
-
-## Notes
-<!-- Your project notes here -->
-
-## Tasks
-<!-- Tasks linked from Basecamp -->
-```
-
----
-
-## Knowledge Discovery
-
-### Scenario
-You need to implement a feature but don't remember the authentication pattern used in the codebase.
-
-### Workflow
-```
-User: "Ask Outline: How do we handle API authentication?"
-
-outline skill:
-1. ask_ai_about_documents(
-     question: "How do we handle API authentication?"
-     collection_id: "engineering"
-   )
-
-2. Present AI answer with sources:
-   🤖 **Answer**:
-   Based on 12 documents, here's the authentication pattern:
-
-   **Standard Pattern**:
-   - OAuth2 with refresh tokens
-   - 30-day token expiry
-   - Automatic refresh before expiry
-
-   **Implementation**:
-   1. Use `/auth/oauth2/token` endpoint
-   2. Store refresh token securely
-   3. Implement token rotation
-   4. Handle 401 Unauthorized with retry
-
-   **Exceptions**:
-   - Internal services use API keys (documented separately)
-   - Admin portals use session-based auth
-
-   **Key Sources**:
-   1. [[OAuth2 Setup Guide]](outline://document/abc123)
-   2. [[Token Management Policy]](outline://document/def456)
-   3. [[API Security Best Practices]](outline://document/ghi789)
-
-3. Offer:
-   - "Read OAuth2 Setup Guide?"
-   - "Export to current project?"
-```
-
----
-
-## Batch Export
-
-### Scenario
-You're preparing for a job transition or need offline access to critical documentation.
-
-### Workflow
-```
-User: "Export all Engineering docs to Obsidian"
-
-outline skill:
-1. export_collection(collection_id: "engineering_id")
-2. Create Obsidian structure:
-   ~/CODEX/03-resources/work/wiki-mirror/engineering/
-   ├── api-docs/
-   │   ├── oauth2-setup-guide.md
-   │   ├── token-management.md
-   │   └── api-security.md
-   ├── architecture/
-   │   ├── system-design.md
-   │   └── data-flow.md
-   └── decisions/
-       ├── auth-decision.md
-       └── database-choice.md
-
-3. Update wiki index:
-   Update ~/CODEX/03-resources/work/wiki-mirror/_wiki-index.md
-   with new export metadata
-
-4. Confirm: "Exported 15 Engineering docs to wiki-mirror/engineering/"
-```
-
----
-
-## Wiki Migration
-
-### Scenario
-You're switching from a different wiki system to Outline and want to migrate content.
-
-### Workflow (No n8n - Manual Process)
-```
-Step 1: Export from Old Wiki
-- Export all pages as Markdown
-- Preserve structure/folders
-- Keep metadata (created dates, authors)
-
-Step 2: Batch Import to Outline
-outline skill:
-1. batch_create_documents(documents):
-   [
-     {
-       "title": "API Documentation",
-       "collection_id": "engineering_id",
-       "text": "# API Documentation\n\n...",
-       "publish": true
-     },
-     {
-       "title": "System Design",
-       "collection_id": "engineering_id",
-       "text": "# System Design\n\n...",
-       "publish": true
-     }
-   ]
-2. Confirm: "Imported 50 documents to Outline"
-
-Step 3: Verify Migration
-- Check Outline web UI
-- Verify document counts
-- Test search functionality
-- Fix any formatting issues
-
-Step 4: Archive Old Wiki
-- Mark old wiki as read-only
-- Add deprecation notice
-- Link to new Outline location
-```
-
----
-
-## Cross-Tool Patterns
-
-### Outline ↔ Obsidian
-
-| When | Action | Location |
-|------|---------|----------|
-| Important decision | Create in Outline + link in Obsidian | Outline: Primary, Obsidian: Reference |
-| Project docs | Link wiki docs from project MOC | Obsidian: Primary, Outline: Source |
-| Meeting outcome | Export key decisions to Outline | Outline: Persistent, Obsidian: Session context |
-| Research | Export findings to Outline | Outline: Knowledge base, Obsidian: Working notes |
-
-### Search Workflow
-
-1. **First**: Search Obsidian vault (personal knowledge)
-2. **Then**: Search Outline wiki (team knowledge)
-3. **Finally**: Search both with context
-
-```
-User: "Find info about OAuth2"
-
-Obsidian search:
-- Check ~/CODEX/03-resources/work/wiki-mirror/
-- Check project notes
-- Return local copies
-
-Outline search:
-- search_documents("OAuth2")
-- Return live wiki content
-- Export if needed for offline access
-```
-
----
-
-## Advanced Workflows
-
-### Decision Audit
-
-Periodically review all decisions to check:
-- Relevance (still applicable?)
-- Implementation status (actually done?)
-- Outdated decisions (need update?)
-
-```bash
-# List all decision docs
-search_documents("decision")
-
-# For each:
-read_document(document_id)
-# Check frontmatter:
-# - implemented: true/false
-# - reviewed_at: date
-# - status: active/archived
-```
-
-### Knowledge Gap Analysis
-
-Identify missing documentation:
-
-1. List all project areas
-2. Search Outline for each area
-3. Identify gaps:
-   - "No results found for X"
-   - "Documentation is outdated"
-   - "Information is scattered"
-
-Create follow-up tasks:
-```markdown
-## Documentation Tasks
-- [ ] Write API rate limiting guide (missing)
-- [ ] Update OAuth2 examples (outdated)
-- [ ] Create testing best practices (scattered)
-```
-
----
-
-## Troubleshooting
-
-### Export Failed
-**Problem**: Document exported to wrong location or failed to export
-
-**Solution**:
-1. Verify collection hierarchy
-2. Check Obsidian vault path
-3. Ensure directory exists: `mkdir -p 03-resources/work/wiki-mirror/[collection]/`
-4. Check file permissions
-
-### Search No Results
-**Problem**: search_documents returns empty results
-
-**Solution**:
-1. Try broader query (fewer keywords)
-2. Remove collection_id to search everywhere
-3. Check if document exists in Outline web UI
-4. Use ask_ai_about_documents for semantic search
-
-### Wiki Link Broken
-**Problem**: `(outline://document/abc123)` link doesn't work
-
-**Solution**:
-1. Verify document_id is correct
-2. Check Outline MCP is running
-3. Test with `read_document(document_id)`
-4. Fallback: Use Outline web UI URL
-
----
-
-## Best Practices Summary
-
-1. **Export Early, Export Often**: Don't wait until job transition
-2. **Link Immediately**: Create Obsidian links when exporting
-3. **Index Everything**: Maintain wiki index for easy navigation
-4. **AI as Helper**: Use `ask_ai_about_documents` but verify sources
-5. **Preserve Hierarchy**: Maintain collection structure in exports
-6. **Tag Generously**: Add tags for discoverability
-7. **Cross-Reference**: Link related documents in Outline
-8. **Decisions Matter**: Export all decisions, not just docs
-
----
-
-## Automation (Future n8n Workflows)
-
-These will be implemented later with n8n automation:
-
-1. **Daily Wiki Sync**: Export updated Outline docs each night
-2. **Decision Auto-Export**: Hook meeting-notes → Outline create
-3. **Search Integration**: Combine Obsidian + Outline search
-4. **Backup Workflow**: Weekly export_all_collections

skills/plan-writing/SKILL.md

@@ -1,165 +0,0 @@
----
-name: plan-writing
-description: "Transform ideas into comprehensive, actionable project plans with templates. Use when: (1) creating project kickoff documents, (2) structuring new projects, (3) building detailed task breakdowns, (4) documenting project scope and stakeholders, (5) setting up project for execution. Triggers: project plan, kickoff document, plan out, structure project, project setup, create plan for, what do I need to start."
-compatibility: opencode
----
-
-# Plan Writing
-
-Transform brainstormed ideas into comprehensive, actionable project plans using modular templates.
-
-## Quick Reference
-
-| Project Type | Templates to Use |
-|--------------|------------------|
-| Solo, <2 weeks | project-brief, todo-structure |
-| Solo, >2 weeks | project-brief, todo-structure, risk-register |
-| Team, any size | project-kickoff, stakeholder-map, todo-structure, risk-register |
-
-## Process
-
-### 1. Intake
-
-Gather initial context:
-- What project are we planning?
-- Check for existing brainstorming output in `docs/brainstorms/`
-- If starting fresh, gather basic context first
-
-### 2. Scope Assessment
-
-Ask these questions (one at a time):
-
-1. **Solo or team project?**
-   - Solo → lighter documentation
-   - Team → need alignment docs (kickoff, stakeholders)
-
-2. **Rough duration estimate?**
-   - <2 weeks → skip risk register
-   - >2 weeks → include risk planning
-
-3. **Known deadline or flexible?**
-   - Hard deadline → prioritize milestone planning
-   - Flexible → focus on phased approach
-
-4. **Which PARA area does this belong to?** (optional)
-   - Helps categorization and later task-management integration
-
-### 3. Component Selection
-
-Based on scope, select appropriate templates:
-
-```
-"Based on [team project, 6 weeks], I'll include:
-✓ Project Kickoff (team alignment)
-✓ Stakeholder Map (communication planning)
-✓ Todo Structure (task breakdown)
-✓ Risk Register (duration >2 weeks)
-
-Shall I proceed with this structure?"
-```
-
-See [references/component-guide.md](references/component-guide.md) for selection logic.
-
-### 4. Draft Generation
-
-For each selected template:
-1. Load template from `assets/templates/`
-2. Fill with project-specific content
-3. Present each major section for validation
-4. Adjust based on feedback
-
-Work through templates in this order:
-1. Kickoff/Brief (establishes context)
-2. Stakeholders (who's involved)
-3. Todos (what needs doing)
-4. Risks (what could go wrong)
-
-### 5. Output
-
-Generate final documents:
-- Create `docs/plans/<project-name>/` directory
-- Write each component as separate file
-- Create `index.md` linking all components
-
-```
-docs/plans/<project-name>/
-├── index.md           # Links to all components
-├── kickoff.md         # or brief.md for solo projects
-├── stakeholders.md    # if team project
-├── tasks.md           # task breakdown
-├── risks.md           # if >2 weeks duration
-└── updates/           # for future progress updates
-    └── YYYY-MM-DD.md
-```
-
-### 6. Handoff (Optional)
-
-After plan is complete, offer next steps:
-
-> "Ready to create this project in Basecamp? I can:
-> - Create todo lists from the task structure
-> - Set up card table columns from phases
-> - Add initial cards/todos with due dates"
-
-This triggers the basecamp skill for execution.
-
-## Templates
-
-All templates in `assets/templates/`:
-
-| Template | Purpose | When to Include |
-|----------|---------|-----------------|
-| project-kickoff.md | Comprehensive 8-section kickoff | Team projects |
-| project-brief.md | 1-page summary | Solo or simple projects |
-| stakeholder-map.md | Who needs what, when | Team projects |
-| risk-register.md | Risks and mitigations | Projects >2 weeks |
-| todo-structure.md | Hierarchical task breakdown | Always |
-| progress-update.md | Status update template | For ongoing tracking |
-
-## PARA Integration (Optional)
-
-If user wants PARA integration:
-1. Prompt for Area assignment (from their defined Areas)
-2. Can trigger task-management skill to create Obsidian task entries
-3. Include Area reference in kickoff/brief document
-
-This is optional - not all users use PARA.
-
-## Integration with Other Skills
-
-| From | To plan-writing | Output |
-|------|-----------------|--------|
-| brainstorming | Decision/context | Informs kickoff scope |
-| plan-writing | → basecamp | Todo lists, cards |
-| plan-writing | → task-management | Obsidian tasks (optional) |
-
-## Example Workflow
-
-```
-User: "Create a project plan for launching the Q2 training program"
-
-AI: "I'll help structure this project. First, a few questions:
-
-Is this a solo project or will others be involved?"
-
-User: "Team - 3 people"
-
-AI: "Duration estimate?
-a) Less than 2 weeks
-b) 2-4 weeks  
-c) More than a month"
-
-User: "B - about 3 weeks"
-
-AI: "Got it. For a 3-week team project, I'll include:
-✓ Project Kickoff (team alignment)
-✓ Stakeholder Map (communication)
-✓ Todo Structure (task breakdown)
-✓ Risk Register (3 weeks warrants this)
-
-Shall I proceed?"
-
-User: "Yes"
-
-AI: [Proceeds through each template, filling with project details]
-```

skills/plan-writing/assets/templates/progress-update.md

@@ -1,89 +0,0 @@
-# Progress Update: [Project Name]
-
-**Period**: [Date] to [Date]  
-**Author**: [Name]  
-**Status**: 🟢 On Track / 🟡 At Risk / 🔴 Blocked
-
----
-
-## Summary
-
-[2-3 sentence executive summary: Where are we, what's the headline?]
-
-**Overall Progress**: [X]% complete
-
----
-
-## Completed This Period
-
-- [x] [Task/milestone completed] - [Impact or note]
-- [x] [Task completed]
-- [x] [Task completed]
-
-**Highlights**:
-- [Notable achievement or win]
-
----
-
-## In Progress
-
-| Task | Owner | Progress | Expected Complete |
-|------|-------|----------|-------------------|
-| [Task 1] | [Name] | [X]% | [Date] |
-| [Task 2] | [Name] | [X]% | [Date] |
-| [Task 3] | [Name] | [X]% | [Date] |
-
----
-
-## Blockers & Risks
-
-### Active Blockers
-
-| Blocker | Impact | Owner | Action Needed | ETA |
-|---------|--------|-------|---------------|-----|
-| [Blocker 1] | [High/Med/Low] | [Name] | [What's needed] | [Date] |
-
-### Emerging Risks
-
-| Risk | Probability | Mitigation |
-|------|-------------|------------|
-| [Risk 1] | [H/M/L] | [Action] |
-
----
-
-## Next Period Plan
-
-**Focus**: [Main focus for next period]
-
-| Priority | Task | Owner | Target Date |
-|----------|------|-------|-------------|
-| 1 | [Highest priority task] | [Name] | [Date] |
-| 2 | [Second priority] | [Name] | [Date] |
-| 3 | [Third priority] | [Name] | [Date] |
-
----
-
-## Metrics
-
-| Metric | Target | Current | Trend |
-|--------|--------|---------|-------|
-| [Metric 1] | [X] | [Y] | ↑/↓/→ |
-| [Metric 2] | [X] | [Y] | ↑/↓/→ |
-| Tasks Complete | [X] | [Y] | ↑ |
-
----
-
-## Decisions Needed
-
-- [ ] [Decision 1]: [Options and recommendation] - Need by: [Date]
-- [ ] [Decision 2]: [Context] - Need by: [Date]
-
----
-
-## Notes / Context
-
-[Any additional context, changes in scope, stakeholder feedback, etc.]
-
----
-
-*Next update: [Date]*

skills/plan-writing/assets/templates/project-brief.md

@@ -1,48 +0,0 @@
-# Project Brief: [Project Name]
-
-**Owner**: [Name]  
-**Timeline**: [Start Date] → [Target Date]  
-**Area**: [PARA Area, if applicable]
-
-## Goal
-
-[One clear sentence: What will be true when this project is complete?]
-
-## Success Criteria
-
-How we'll know it's done:
-
-- [ ] [Criterion 1 - specific and measurable]
-- [ ] [Criterion 2]
-- [ ] [Criterion 3]
-
-## Scope
-
-**Included**:
-- [Deliverable 1]
-- [Deliverable 2]
-
-**Not Included**:
-- [Exclusion 1]
-
-## Key Milestones
-
-| Milestone | Target Date | Status |
-|-----------|-------------|--------|
-| [Milestone 1] | [Date] | [ ] |
-| [Milestone 2] | [Date] | [ ] |
-| [Complete] | [Date] | [ ] |
-
-## Initial Tasks
-
-1. [ ] [First task to start] - Due: [Date]
-2. [ ] [Second task]
-3. [ ] [Third task]
-
-## Notes
-
-[Any context, constraints, or references worth capturing]
-
----
-
-*Created: [Date]*

skills/plan-writing/assets/templates/project-kickoff.md

@@ -1,106 +0,0 @@
-# Project Kickoff: [Project Name]
-
-## 1. Project Essentials
-
-| Field | Value |
-|-------|-------|
-| **Project Name** | [Name] |
-| **Owner** | [Name] |
-| **Start Date** | [YYYY-MM-DD] |
-| **Target Completion** | [YYYY-MM-DD] |
-| **PARA Area** | [Area, if applicable] |
-
-### Overview
-
-[2-3 sentence description of what this project will accomplish and why it matters.]
-
-## 2. Goals and Success Criteria
-
-**Primary Goal**: [One sentence describing the end state - what does "done" look like?]
-
-**Success Criteria**:
-- [ ] [Measurable criterion 1]
-- [ ] [Measurable criterion 2]
-- [ ] [Measurable criterion 3]
-
-**Out of Scope** (explicitly):
-- [Item that might be assumed but is NOT included]
-- [Another exclusion]
-
-## 3. Stakeholders
-
-| Role | Person | Involvement Level |
-|------|--------|-------------------|
-| Project Owner | [Name] | High - decisions |
-| Core Team | [Names] | High - execution |
-| Informed | [Names] | Low - updates only |
-| Approver | [Name, if any] | Medium - sign-off |
-
-## 4. Timeline and Milestones
-
-| Milestone | Target Date | Dependencies | Owner |
-|-----------|-------------|--------------|-------|
-| [Milestone 1] | [Date] | None | [Who] |
-| [Milestone 2] | [Date] | Milestone 1 | [Who] |
-| [Milestone 3] | [Date] | Milestone 2 | [Who] |
-| **Project Complete** | [Date] | All above | [Owner] |
-
-### Key Dates
-
-- **Kickoff**: [Date]
-- **First Review**: [Date]
-- **Final Deadline**: [Date]
-
-## 5. Scope
-
-### In Scope
-
-- [Deliverable 1]: [Brief description]
-- [Deliverable 2]: [Brief description]
-- [Deliverable 3]: [Brief description]
-
-### Out of Scope
-
-- [Explicitly excluded item 1]
-- [Explicitly excluded item 2]
-
-### Assumptions
-
-- [Assumption 1 - e.g., "Budget approved"]
-- [Assumption 2 - e.g., "Team available full-time"]
-
-## 6. Risks
-
-| Risk | Probability | Impact | Mitigation | Owner |
-|------|-------------|--------|------------|-------|
-| [Risk 1] | H/M/L | H/M/L | [Plan] | [Who] |
-| [Risk 2] | H/M/L | H/M/L | [Plan] | [Who] |
-
-*See detailed risk register if needed: [link to risks.md]*
-
-## 7. Communication Plan
-
-| What | Audience | Frequency | Channel | Owner |
-|------|----------|-----------|---------|-------|
-| Status Update | All stakeholders | Weekly | [Email/Basecamp] | [Who] |
-| Team Sync | Core team | [Daily/2x week] | [Meeting/Slack] | [Who] |
-| Milestone Review | Approvers | At milestone | [Meeting] | [Who] |
-
-### Escalation Path
-
-1. First: [Team lead/Owner]
-2. Then: [Manager/Sponsor]
-3. Finally: [Executive, if applicable]
-
-## 8. Next Steps
-
-Immediate actions to kick off the project:
-
-- [ ] [Action 1] - @[owner] - Due: [date]
-- [ ] [Action 2] - @[owner] - Due: [date]
-- [ ] [Action 3] - @[owner] - Due: [date]
-
----
-
-*Document created: [Date]*
-*Last updated: [Date]*

skills/plan-writing/assets/templates/risk-register.md

@@ -1,104 +0,0 @@
-# Risk Register: [Project Name]
-
-## Risk Summary
-
-| ID | Risk | Probability | Impact | Risk Score | Status |
-|----|------|-------------|--------|------------|--------|
-| R1 | [Brief risk name] | H/M/L | H/M/L | [H/M/L] | Open |
-| R2 | [Brief risk name] | H/M/L | H/M/L | [H/M/L] | Open |
-| R3 | [Brief risk name] | H/M/L | H/M/L | [H/M/L] | Open |
-
-**Risk Score**: Probability × Impact (H×H=Critical, H×M or M×H=High, M×M=Medium, others=Low)
-
----
-
-## Detailed Risk Analysis
-
-### R1: [Risk Name]
-
-| Aspect | Detail |
-|--------|--------|
-| **Description** | [What could go wrong?] |
-| **Probability** | High / Medium / Low |
-| **Impact** | High / Medium / Low |
-| **Category** | Technical / Resource / External / Schedule / Budget |
-| **Trigger** | [What would indicate this risk is materializing?] |
-
-**Mitigation Plan**:
-- [Action 1 to reduce probability or impact]
-- [Action 2]
-
-**Contingency Plan** (if risk occurs):
-- [Fallback action 1]
-- [Fallback action 2]
-
-**Owner**: [Name]  
-**Review Date**: [Date]
-
----
-
-### R2: [Risk Name]
-
-| Aspect | Detail |
-|--------|--------|
-| **Description** | [What could go wrong?] |
-| **Probability** | High / Medium / Low |
-| **Impact** | High / Medium / Low |
-| **Category** | Technical / Resource / External / Schedule / Budget |
-| **Trigger** | [What would indicate this risk is materializing?] |
-
-**Mitigation Plan**:
-- [Action 1]
-- [Action 2]
-
-**Contingency Plan**:
-- [Fallback action]
-
-**Owner**: [Name]  
-**Review Date**: [Date]
-
----
-
-### R3: [Risk Name]
-
-| Aspect | Detail |
-|--------|--------|
-| **Description** | [What could go wrong?] |
-| **Probability** | High / Medium / Low |
-| **Impact** | High / Medium / Low |
-| **Category** | Technical / Resource / External / Schedule / Budget |
-| **Trigger** | [What would indicate this risk is materializing?] |
-
-**Mitigation Plan**:
-- [Action 1]
-- [Action 2]
-
-**Contingency Plan**:
-- [Fallback action]
-
-**Owner**: [Name]  
-**Review Date**: [Date]
-
----
-
-## Risk Categories
-
-| Category | Examples |
-|----------|----------|
-| **Technical** | Technology doesn't work, integration issues, performance |
-| **Resource** | Key person unavailable, skill gaps, overcommitment |
-| **External** | Vendor delays, regulatory changes, dependencies |
-| **Schedule** | Delays, unrealistic timeline, competing priorities |
-| **Budget** | Cost overruns, funding cuts, unexpected expenses |
-
-## Review Schedule
-
-- **Weekly**: Quick scan of high risks
-- **Bi-weekly**: Full risk register review
-- **At milestones**: Comprehensive reassessment
-
----
-
-*Created: [Date]*  
-*Last reviewed: [Date]*  
-*Next review: [Date]*

skills/plan-writing/assets/templates/stakeholder-map.md

@@ -1,72 +0,0 @@
-# Stakeholder Map: [Project Name]
-
-## Stakeholder Matrix
-
-| Stakeholder | Role | Interest Level | Influence | Information Needs |
-|-------------|------|----------------|-----------|-------------------|
-| [Name/Group] | [Role] | High/Medium/Low | High/Medium/Low | [What they need to know] |
-| [Name/Group] | [Role] | High/Medium/Low | High/Medium/Low | [What they need to know] |
-| [Name/Group] | [Role] | High/Medium/Low | High/Medium/Low | [What they need to know] |
-
-## Communication Plan by Stakeholder
-
-### [Stakeholder 1: Name/Role]
-
-| Aspect | Detail |
-|--------|--------|
-| **Needs** | [What information they need] |
-| **Frequency** | [How often: daily, weekly, at milestones] |
-| **Channel** | [Email, Basecamp, meeting, Slack] |
-| **Format** | [Brief update, detailed report, presentation] |
-| **Owner** | [Who communicates with them] |
-
-### [Stakeholder 2: Name/Role]
-
-| Aspect | Detail |
-|--------|--------|
-| **Needs** | [What information they need] |
-| **Frequency** | [How often] |
-| **Channel** | [Preferred channel] |
-| **Format** | [Format preference] |
-| **Owner** | [Who communicates] |
-
-### [Stakeholder 3: Name/Role]
-
-| Aspect | Detail |
-|--------|--------|
-| **Needs** | [What information they need] |
-| **Frequency** | [How often] |
-| **Channel** | [Preferred channel] |
-| **Format** | [Format preference] |
-| **Owner** | [Who communicates] |
-
-## RACI Matrix
-
-| Decision/Task | [Person 1] | [Person 2] | [Person 3] | [Person 4] |
-|---------------|------------|------------|------------|------------|
-| [Decision 1] | R | A | C | I |
-| [Decision 2] | I | R | A | C |
-| [Task 1] | R | I | I | A |
-
-**Legend**:
-- **R** = Responsible (does the work)
-- **A** = Accountable (final decision maker)
-- **C** = Consulted (input required)
-- **I** = Informed (kept updated)
-
-## Escalation Path
-
-1. **First Level**: [Name/Role] - for [types of issues]
-2. **Second Level**: [Name/Role] - if unresolved in [timeframe]
-3. **Executive**: [Name/Role] - for [critical blockers only]
-
-## Notes
-
-- [Any stakeholder-specific considerations]
-- [Political or relationship notes]
-- [Historical context if relevant]
-
----
-
-*Created: [Date]*
-*Last updated: [Date]*

skills/plan-writing/assets/templates/todo-structure.md

@@ -1,94 +0,0 @@
-# Task Structure: [Project Name]
-
-## Overview
-
-| Metric | Value |
-|--------|-------|
-| **Total Tasks** | [X] |
-| **Phases** | [Y] |
-| **Timeline** | [Start] → [End] |
-
----
-
-## Phase 1: [Phase Name]
-
-**Target**: [Date]  
-**Owner**: [Name]
-
-| # | Task | Owner | Estimate | Due | Depends On | Status |
-|---|------|-------|----------|-----|------------|--------|
-| 1.1 | [Task description] | [Name] | [Xh/Xd] | [Date] | - | [ ] |
-| 1.2 | [Task description] | [Name] | [Xh/Xd] | [Date] | 1.1 | [ ] |
-| 1.3 | [Task description] | [Name] | [Xh/Xd] | [Date] | - | [ ] |
-
-**Phase Deliverable**: [What's complete when this phase is done]
-
----
-
-## Phase 2: [Phase Name]
-
-**Target**: [Date]  
-**Owner**: [Name]
-
-| # | Task | Owner | Estimate | Due | Depends On | Status |
-|---|------|-------|----------|-----|------------|--------|
-| 2.1 | [Task description] | [Name] | [Xh/Xd] | [Date] | Phase 1 | [ ] |
-| 2.2 | [Task description] | [Name] | [Xh/Xd] | [Date] | 2.1 | [ ] |
-| 2.3 | [Task description] | [Name] | [Xh/Xd] | [Date] | - | [ ] |
-
-**Phase Deliverable**: [What's complete when this phase is done]
-
----
-
-## Phase 3: [Phase Name]
-
-**Target**: [Date]  
-**Owner**: [Name]
-
-| # | Task | Owner | Estimate | Due | Depends On | Status |
-|---|------|-------|----------|-----|------------|--------|
-| 3.1 | [Task description] | [Name] | [Xh/Xd] | [Date] | Phase 2 | [ ] |
-| 3.2 | [Task description] | [Name] | [Xh/Xd] | [Date] | 3.1 | [ ] |
-| 3.3 | [Task description] | [Name] | [Xh/Xd] | [Date] | 3.1 | [ ] |
-
-**Phase Deliverable**: [What's complete when this phase is done]
-
----
-
-## Unphased / Ongoing Tasks
-
-| # | Task | Owner | Frequency | Notes |
-|---|------|-------|-----------|-------|
-| O.1 | [Recurring task] | [Name] | Weekly | [Notes] |
-| O.2 | [Monitoring task] | [Name] | Daily | [Notes] |
-
----
-
-## Dependencies Summary
-
-```
-Phase 1 ──────► Phase 2 ──────► Phase 3
-    │               │
-    ├── 1.1 ► 1.2   ├── 2.1 ► 2.2
-    └── 1.3         └── 2.3 (parallel)
-```
-
-## Milestone Checklist
-
-- [ ] **Milestone 1**: [Name] - [Date]
-  - [ ] [Required task 1.1]
-  - [ ] [Required task 1.2]
-
-- [ ] **Milestone 2**: [Name] - [Date]
-  - [ ] [Required task 2.1]
-  - [ ] [Required task 2.2]
-
-- [ ] **Project Complete** - [Date]
-  - [ ] All phases complete
-  - [ ] Success criteria met
-  - [ ] Handoff complete
-
----
-
-*Created: [Date]*  
-*Last updated: [Date]*

skills/plan-writing/references/component-guide.md

@@ -1,117 +0,0 @@
-# Component Selection Guide
-
-Decision matrix for which templates to include based on project characteristics.
-
-## Decision Matrix
-
-| Question | If Yes | If No |
-|----------|--------|-------|
-| Team project (>1 person)? | +kickoff, +stakeholders | Use brief instead of kickoff |
-| Duration >2 weeks? | +risk-register | Skip risks |
-| External stakeholders? | +stakeholders (detailed) | Stakeholders optional |
-| Complex dependencies? | +detailed todos with deps | Simple todo list |
-| Ongoing tracking needed? | +progress-update template | One-time plan |
-
-## Quick Selection by Project Type
-
-### Solo, Short (<2 weeks)
-```
-✓ project-brief.md
-✓ todo-structure.md
-```
-
-### Solo, Medium (2-4 weeks)
-```
-✓ project-brief.md
-✓ todo-structure.md
-✓ risk-register.md
-```
-
-### Solo, Long (>4 weeks)
-```
-✓ project-brief.md (or kickoff for complex)
-✓ todo-structure.md
-✓ risk-register.md
-✓ progress-update.md (for self-tracking)
-```
-
-### Team, Any Duration
-```
-✓ project-kickoff.md (always for team alignment)
-✓ stakeholder-map.md
-✓ todo-structure.md
-✓ risk-register.md (if >2 weeks)
-✓ progress-update.md (for status updates)
-```
-
-## Template Purposes
-
-### project-kickoff.md
-Full 8-section document for team alignment:
-1. Project essentials (name, owner, dates)
-2. Goals and success criteria
-3. Stakeholders overview
-4. Timeline and milestones
-5. Scope (in/out)
-6. Risks overview
-7. Communication plan
-8. Next steps
-
-**Use when**: Multiple people need alignment on what/why/how.
-
-### project-brief.md
-1-page summary for simpler projects:
-- Goal statement
-- Success criteria
-- Key milestones
-- Initial tasks
-
-**Use when**: Solo project or simple scope that doesn't need formal kickoff.
-
-### stakeholder-map.md
-Communication matrix:
-- Who needs information
-- What they need to know
-- How often
-- Which channel
-
-**Use when**: Team projects with multiple stakeholders needing different information.
-
-### risk-register.md
-Risk tracking table:
-- Risk description
-- Probability (H/M/L)
-- Impact (H/M/L)
-- Mitigation plan
-- Owner
-
-**Use when**: Projects >2 weeks or high-stakes projects of any duration.
-
-### todo-structure.md
-Hierarchical task breakdown:
-- Phases or milestones
-- Tasks under each phase
-- Subtasks if needed
-- Metadata: owner, estimate, due date, dependencies
-
-**Use when**: Always. Every project needs task breakdown.
-
-### progress-update.md
-Status reporting template:
-- Completed since last update
-- In progress
-- Blockers
-- Next steps
-- Metrics/progress %
-
-**Use when**: Projects needing regular status updates (weekly, sprint-based, etc.).
-
-## Customization Notes
-
-Templates are starting points. Common customizations:
-- Remove sections that don't apply
-- Add project-specific sections
-- Adjust detail level based on audience
-- Combine templates for simpler output
-
-The goal is useful documentation, not template compliance.

skills/project-structures/SKILL.md

@@ -1,463 +0,0 @@
----
-name: project-structures
-description: "PARA project initialization and lifecycle management. Use when: (1) creating new projects, (2) reviewing project status, (3) archiving completed projects, (4) structuring project files, (5) linking projects to areas. Triggers: new project, create project, project status, archive project."
-compatibility: opencode
----
-
-# Project Structures
-
-PARA-based project creation, organization, and lifecycle management for Chiron system.
-
-## Project Structure
-
-```
-01-projects/
-├── work/
-│   └── [project-name]/
-│       ├── _index.md          # Main project file (MOC)
-│       ├── meetings/           # Meeting notes
-│       ├── decisions/          # Decision records
-│       ├── notes/             # General notes
-│       └── resources/         # Project-specific resources
-└── personal/
-    └── [project-name]/
-        └── [same structure]
-```
-
-## Create New Project
-
-**When user says**: "Create project: X", "New project: X", "Start project: X", "/chiron-project X"
-
-**Steps:**
-
-1. **Parse project request:**
-   - Project name
-   - Context (work/personal) - ask if unspecified
-   - Deadline (if specified)
-   - Priority (if specified)
-   - Related area (if specified)
-
-2. **Create project directory**:
-   - Path: `01-projects/[work|personal]/[project-name]/`
-   - Create subdirectories: `meetings/`, `decisions/`, `notes/`, `resources/`
-
-3. **Create _index.md** using template:
-   - Template: `_chiron/templates/project.md`
-   - Fill in: title, status, deadline, priority, tags
-   - Set to `status: active`
-
-4. **Create initial files:**
-   - `notes/_index.md` - Project notes index
-   - Link to related area if provided
-
-5. **Confirm creation**
-   - Show project structure
-   - Ask: "Ready to add tasks?"
-
-**Output format:**
-```markdown
----
-title: "Project Name"
-status: active
-created: 2026-01-27
-deadline: 2026-03-31
-priority: high
-area: [[Area Name]]
-tags: [work, development]
----
-
-## Project Overview
-[Brief description of what this project is about]
-
-## Goals
-1. [Goal 1]
-2. [Goal 2]
-3. [Goal 3]
-
-## Success Criteria
-- [Criteria 1]
-- [Criteria 2]
-- [Criteria 3]
-
-## Timeline
-- Start: 2026-01-27
-- Milestone 1: 2026-02-15
-- Milestone 2: 2026-03-15
-- Deadline: 2026-03-31
-
-## Tasks
-See [[Project Tasks]] for full task list
-
-## Resources
-- [[Related Resource 1]]
-- [[Related Resource 2]]
-
-## Notes
-See [[Project Notes]] for detailed notes
-
-## Decisions
-See [[Project Decisions]] for decision history
-```
-
-**Example:**
-```
-User: "Create project: Q1 Budget Review, work, critical, due March 15"
-
-Action:
-1. Parse: name="Q1 Budget Review", context="work", priority="critical", deadline="2026-03-15"
-2. Create: 01-projects/work/q1-budget-review/
-3. Create subdirectories
-4. Create _index.md with template filled
-5. Confirm: "Created Q1 Budget Review project in work. Ready to add tasks?"
-```
-
-## Project Status Review
-
-**When user says**: "Project status", "Review projects", "How's project X going?"
-
-**Steps:**
-
-1. **Find project** (by name or list all)
-2. **Read _index.md** for status and metadata
-3. **Check task completion**:
-   - Read project task list (in `_index.md` or separate file)
-   - Calculate: completed vs total tasks
-   - Identify overdue tasks
-4. **Check milestones**:
-   - Compare current date vs milestone dates
-   - Identify: on track, behind, ahead
-5. **Generate status report**
-
-**Output format:**
-```markdown
-# Project Status: Q1 Budget Review
-
-## Current Status: 🟡 On Track
-
-## Progress
-- Tasks: 8/12 completed (67%)
-- Deadline: 2026-03-15 (48 days remaining)
-- Priority: Critical
-
-## Milestones
-- ✅ Milestone 1: Draft budget (Completed 2026-02-10)
-- 🟡 Milestone 2: Review with team (Due 2026-02-20)
-- ⏭️ Milestone 3: Final approval (Due 2026-03-15)
-
-## Completed Tasks
-- [x] Gather historical data
-- [x] Draft initial budget
-- [x] Review with finance team
-
-## In Progress
-- [ ] Address feedback from finance
-- [ ] Prepare presentation for leadership
-- [ ] Schedule review meeting
-
-## Overdue
-- [ ] Collect final approval signatures ⏫ 📅 2026-02-20 (DUE YESTERDAY)
-
-## Blockers
-- Leadership review delayed - waiting for director availability
-
-## Recommendations
-1. Follow up with director to schedule review meeting
-2. Prioritize final approval task
-3. Update team on timeline
-
-## Related Notes
-- [[Budget Review Meeting 2026-02-10]]
-- [[Finance Team Notes]]
-```
-
-## Project Search & List
-
-**When user says**: "List projects", "Show all projects", "Find project X"
-
-**Steps:**
-
-1. **Search project directories**:
-   - `rg "- status:" 01-projects --type md -A 2`
-   - Extract: title, status, deadline, priority
-2. **Group by context** (work/personal)
-3. **Sort by priority/deadline**
-4. **Present summary**
-
-**Output format:**
-```markdown
-# Active Projects
-
-## Work Projects (4 active)
-
-| Project | Priority | Deadline | Status | Progress |
-|----------|-----------|-----------|----------|-----------|
-| Q1 Budget Review | ⏫ Critical | 2026-03-15 | 🟡 On Track |
-| Website Relaunch | 🔼 High | 2026-04-30 | 🟡 On Track |
-| API Integration | 🔼 High | 2026-02-28 | 🔴 Behind |
-| Team Onboarding | 🔽 Low | 2026-03-01 | 🟢 Ahead |
-
-## Personal Projects (2 active)
-
-| Project | Priority | Deadline | Status | Progress |
-|----------|-----------|-----------|----------|-----------|
-| Learn Rust | 🔼 High | 2026-04-30 | 🟡 On Track |
-| Home Office Setup | 🔽 Low | 2026-02-15 | 🟢 Ahead |
-
-## Summary
-- Total active projects: 6
-- Critical projects: 1
-- Behind schedule: 1
-- Projects with overdue tasks: 1
-```
-
-## Archive Project
-
-**When user says**: "Archive project: X", "Complete project: X", "Project X is done"
-
-**Steps:**
-
-1. **Find project**
-2. **Confirm completion**:
-   - Show project status
-   - Ask: "Is this project complete? All tasks done?"
-3. **Update _index.md**:
-   - Set `status: completed`
-   - Add `completed_date: YYYY-MM-DD`
-4. **Move to archive**:
-   - Source: `01-projects/[work|personal]/[project]/`
-   - Destination: `04-archive/projects/[work|personal]/[project]/`
-5. **Update project _index.md** (if exists):
-   - Mark project as completed
-   - Add to completed list
-6. **Confirm archive**
-
-**Output format:**
-```markdown
-# Project Archived: Q1 Budget Review
-
-## Archive Summary
-- Status: ✅ Completed
-- Completed date: 2026-03-14 (1 day before deadline)
-- Location: 04-archive/projects/work/q1-budget-review/
-
-## Outcomes
-- Budget approved and implemented
-- $50K savings identified
-- New process documented
-
-## Lessons Learned
-1. Start stakeholder reviews earlier
-2. Include finance team from beginning
-3. Automated tools would reduce manual effort
-
-## Related Resources
-- [[Final Budget Document]]
-- [[Process Documentation]]
-```
-
-## Project Notes Management
-
-**When user says**: "Add note to project X", "Project X notes: [content]"
-
-**Steps:**
-
-1. **Find project directory**
-2. **Create or update note** in `notes/`:
-   - Use timestamp for new notes
-   - Add frontmatter with date and tags
-3. **Link to _index.md**:
-   - Update _index.md if it's the main project file
-   - Add to "Notes" section
-4. **Confirm**
-
-**Example:**
-```
-User: "Add note to Q1 Budget Review: Remember to check last year's Q1 for comparison"
-
-Action:
-Create 01-projects/work/q1-budget-review/notes/2026-02-01-comparison.md:
----
-title: "Comparison with Last Year"
-date: 2026-02-01
-project: [[Q1 Budget Review]]
-tags: [research, historical]
----
-
-Check last year's Q1 budget for comparison points:
-- Categories that increased significantly
-- One-time expenses from last year
-- Adjustments made mid-year
-
-Confirm: "Added note to Q1 Budget Review."
-```
-
-## Decision Recording
-
-**When user says**: "Record decision for project X", "Decision: [topic]", "Made a decision: [content]"
-
-**Steps:**
-
-1. **Create decision note** in `decisions/`:
-   - Filename: `decision-[topic]-YYYYMMDD.md`
-   - Use decision template
-2. **Fill in sections**:
-   - Decision made
-   - Options considered
-   - Reasoning
-   - Impact
-   - Alternatives rejected
-3. **Link to _index.md**
-4. **Confirm**
-
-**Output format:**
-```markdown
----
-title: "Decision: Use External Vendor"
-date: 2026-02-15
-project: [[Q1 Budget Review]]
-tags: [decision, vendor, budget]
----
-
-## Decision Made
-Use External Vendor for cloud infrastructure instead of building internally.
-
-## Context
-Need to decide between internal build vs external purchase for cloud infrastructure.
-
-## Options Considered
-1. **Build internally**
-   - Pros: Full control, no recurring cost
-   - Cons: High initial cost, maintenance burden, 6-month timeline
-
-2. **Purchase external**
-   - Pros: Quick deployment, no maintenance, lower risk
-   - Cons: Monthly cost, vendor lock-in
-
-## Reasoning
-- Timeline pressure (need by Q2)
-- Team expertise is in product, not infrastructure
-- Monthly cost is within budget
-- Vendor has strong SLA guarantees
-
-## Impact
-- Project timeline reduced by 4 months
-- $120K savings in development cost
-- Monthly operational cost: $2,000
-- Reduced risk of project failure
-
-## Alternatives Rejected
-- Build internally: Too slow and expensive for current timeline
-
-## Next Actions
-- [ ] Contract vendor by 2026-02-20
-- [ ] Plan migration by 2026-03-01
-- [ ] Budget review by 2026-03-15
-```
-
-## Project-Area Linking
-
-**When user says**: "Link project to area", "Project X belongs to area Y"
-
-**Steps:**
-
-1. **Read project _index.md**
-2. **Find or create area file**:
-   - Location: `02-areas/[work|personal]/[area].md`
-3. **Update project _index.md**:
-   - Add `area: [[Area Name]]` to frontmatter
-   - Update links section
-4. **Update area file**:
-   - Add project to area's project list
-   - Link back to project
-
-**Example:**
-```
-User: "Link Q1 Budget Review to Finances area"
-
-Action:
-1. Read 01-projects/work/q1-budget-review/_index.md
-2. Read 02-areas/personal/finances.md
-3. Update project _index.md frontmatter:
-   area: [[Finances]]
-4. Update finances.md:
-   ## Active Projects
-   - [[Q1 Budget Review]]
-
-Confirm: "Linked Q1 Budget Review to Finances area."
-```
-
-## Integration with Other Skills
-
-**Delegates to:**
-- `obsidian-management` - File operations and templates
-- `chiron-core` - PARA methodology guidance
-- `task-management` - Project task lists
-- `quick-capture` - Quick meeting/decision capture
-- `meeting-notes` - Meeting note templates
-
-**Delegation rules:**
-- File creation → `obsidian-management`
-- Task operations → `task-management`
-- PARA guidance → `chiron-core`
-- Meeting/decision templates → `meeting-notes`
-
-## Best Practices
-
-### Creating Projects
-- Use clear, descriptive names
-- Set realistic deadlines
-- Define success criteria
-- Link to areas immediately
-- Create task list early
-
-### Managing Projects
-- Update status regularly
-- Document decisions
-- Track progress visibly
-- Celebrate milestones
-- Learn from completed projects
-
-### Archiving
-- Document outcomes
-- Capture lessons learned
-- Keep accessible for reference
-- Update area health after archive
-
-## Quick Reference
-
-| Action | Command Pattern |
-|--------|-----------------|
-| Create project | "Create project: [name] [work|personal]" |
-| Project status | "Project status: [name]" or "Review projects" |
-| Archive project | "Archive project: [name]" or "Complete project: [name]" |
-| Add note | "Add note to project [name]: [content]" |
-| Record decision | "Decision: [topic] for project [name]" |
-| Link to area | "Link project [name] to area [area]" |
-
-## Error Handling
-
-### Project Already Exists
-1. Ask user: "Update existing or create variant?"
-2. If update: Open existing _index.md
-3. If variant: Create with version suffix
-
-### Area Not Found
-1. Ask user: "Create new area [name]?"
-2. If yes: Create area file
-3. Link project to new area
-
-### Archive Conflicts
-1. Check if already in archive
-2. Ask: "Overwrite or create new version?"
-3. Use timestamp if keeping both
-
-## Resources
-
-- `references/project-templates.md` - Project initiation templates
-- `references/decision-frameworks.md` - Decision-making tools
-- `assets/project-structure/` - Project file templates
-
-**Load references when:**
-- Customizing project templates
-- Complex decision-making
-- Project troubleshooting

skills/quick-capture/SKILL.md

@@ -1,324 +0,0 @@
----
-name: quick-capture
-description: "Minimal friction inbox capture for Chiron system. Use when: (1) capturing quick thoughts, (2) adding tasks, (3) saving meeting notes, (4) recording learnings, (5) storing ideas. Triggers: capture, quick note, remember, save this, todo, inbox."
-compatibility: opencode
----
-
-# Quick Capture
-
-Minimal friction capture to `00-inbox/` for later processing.
-
-## Philosophy
-
-**Capture everything now, organize later.**
-
-The inbox is a temporary holding area. Speed is prioritized over structure. Processing happens during weekly review.
-
-## Capture Types
-
-### Task Capture
-
-**When user says**: "Add task: X", "Remember to X", "Todo: X"
-
-**Steps:**
-1. Parse task from request:
-   - Task description
-   - Priority (if specified)
-   - Due date (if specified)
-   - Tags (if specified)
-2. Create task in `tasks/inbox.md`:
-   ```markdown
-   - [ ] [Task description] #inbox ⏫ 📅 [date if specified]
-   ```
-3. Confirm capture
-
-**Examples:**
-```
-User: "Capture: Review Q1 budget proposal"
-
-Action:
-Create task in tasks/inbox.md:
-- [ ] Review Q1 budget proposal #inbox ⏫
-
-Confirm: "Captured to inbox. Process during weekly review."
-```
-
-```
-User: "Add task: Email John about project deadline, due Friday"
-
-Action:
-Create task in tasks/inbox.md:
-- [ ] Email John about project deadline #inbox 🔼 📅 2026-01-31
-
-Confirm: "Captured to inbox. Process during weekly review."
-```
-
-### Note Capture
-
-**When user says**: "Note: X", "Capture this: X", "Remember: X"
-
-**Steps:**
-1. Create note in `00-inbox/` with timestamp:
-   - Filename: `quick-capture-YYYYMMDD-HHMM.md`
-   - Content: Captured text with tags
-2. Add frontmatter with creation date
-3. Confirm capture
-
-**Examples:**
-```
-User: "Capture this: Obsidian plugin that syncs with Notion would be amazing. Need to research this."
-
-Action:
-Create 00-inbox/quick-capture-20260127-1730.md:
----
-title: "Obsidian-Notion sync plugin idea"
-tags: [idea, obsidian]
-created: 2026-01-27
----
-
-Obsidian plugin that syncs with Notion would be amazing. Need to research this.
-
-Confirm: "Captured to inbox."
-```
-
-### Meeting Capture
-
-**When user says**: "Meeting notes: X", "Just finished meeting with X", "Capture meeting about X"
-
-**Steps:**
-1. Create meeting note in `00-inbox/meetings/`:
-   - Filename: `meeting-[topic]-YYYYMMDD.md`
-   - Use meeting template if available
-2. Fill in: attendees, key points, action items
-3. Link to project if mentioned
-
-**Examples:**
-```
-User: "Meeting notes: Product roadmap discussion with team"
-
-Action:
-Create 00-inbox/meetings/product-roadmap-20260127.md:
----
-title: "Product Roadmap Discussion"
-date: 2026-01-27
-attendees: [Team]
-tags: [meeting, work]
----
-
-## Attendees
-- [Person 1]
-- [Person 2]
-
-## Agenda
-- Review Q1 roadmap
-- Discuss feature prioritization
-
-## Key Points
-- ...
-
-## Action Items
-- [ ] Create JIRA tickets for Q1 features
-- [ ] Schedule follow-up with design team
-- [ ] Update stakeholders
-
-Confirm: "Captured meeting notes to inbox."
-```
-
-### Learning Capture
-
-**When user says**: "Learned X", "Discovery: X", "Insight: X"
-
-**Steps:**
-1. Create learning note in `00-inbox/`:
-   - Filename: `learning-[topic]-YYYYMMDD.md`
-   - Content: What was learned, context, applications
-2. Add tags: `#learning`, `#[domain]`
-3. Confirm capture
-
-**Examples:**
-```
-User: "Learned: Git rebase vs merge - use rebase for local history, merge for shared branches"
-
-Action:
-Create 00-inbox/learning-git-rebase-merge-20260127.md:
----
-title: "Git: Rebase vs Merge"
-tags: [learning, git, programming]
-created: 2026-01-27
----
-
-## Learning
-Use rebase for local history cleanup, merge for shared branches.
-
-## Context
-Reading about Git workflows. Confusion about when to use each.
-
-## Applications
-- Local feature branch before push: Rebase
-- Updating shared branch: Merge
-- Cleaning up history: Rebase -i
-
-Confirm: "Captured learning to inbox."
-```
-
-### Web Clip / Reference Capture
-
-**When user says**: "Save this article: URL", "Clip this: X", "Reference: X"
-
-**Steps:**
-1. Create reference in `00-inbox/web-clips/`:
-   - Filename: `[source]-[topic].md`
-   - Content: Title, URL, summary, key takeaways
-2. Add tags for topic and source
-3. Link to relevant areas/projects if obvious
-
-**Examples:**
-```
-User: "Save this: article about PARA method from Forte Labs"
-
-Action:
-Create 00-inbox/web-clips/forte-labs-para.md:
----
-title: "PARA Method - Forte Labs"
-source: https://fortelabs.com/blog/para/
-tags: [productivity, para, organization]
-saved: 2026-01-27
----
-
-## Source
-[PARA Method - Forte Labs](https://fortelabs.com/blog/para/)
-
-## Summary
-Comprehensive guide to PARA method for organizing digital information. Projects, Areas, Resources, Archive.
-
-## Key Takeaways
-- Projects = short-term, deadline-driven
-- Areas = ongoing responsibilities
-- Resources = reference material
-- Archive = completed/inactive
-
-## Applications
-- Reorganize my knowledge vault using PARA
-- Clear out old inbox items
-
-Confirm: "Saved reference to inbox."
-```
-
-## File Structure
-
-```
-00-inbox/
-├── quick-capture-*.md        # Quick thoughts and notes
-├── meetings/                   # Unprocessed meeting notes
-│   └── meeting-*.md
-├── web-clips/                 # Saved articles and references
-│   └── [source]-*.md
-└── learnings/                  # Captured learnings
-    └── learning-*.md
-```
-
-## Processing Inbox
-
-**Trigger**: During weekly review (`/chiron-review`)
-
-**Processing workflow:**
-
-1. **For each item in inbox:**
-   - Read content
-   - Determine PARA category (consult `chiron-core`)
-   - Move to appropriate location
-
-2. **Task processing:**
-   - Add to project task list if project-specific
-   - Add to area task list if area-specific
-   - Keep in `tasks/inbox.md` if general
-
-3. **Note processing:**
-   - Move to `03-resources/` if reference material
-   - Move to `01-projects/` if project-specific
-   - Move to `02-areas/` if area-specific
-   - Archive to `04-archive/` if no longer relevant
-
-4. **Delete irrelevant items**
-
-**Example:**
-```
-Inbox has:
-- Task: "Buy groceries" → Move to 02-areas/personal/health.md
-- Note: "Obsidian tips" → Move to 03-resources/tools/obsidian.md
-- Task: "Finish project X" → Move to 01-projects/work/project-x/_index.md
-- Old reference from 2022 → Move to 04-archive/
-```
-
-## Best Practices
-
-### Speed Over Structure
-- Don't categorize during capture
-- Don't add tags during capture
-- Don't create projects during capture
-- Focus on getting it out of your head
-
-### Minimal Metadata
-- Only add what's immediately obvious
-- Date is automatic (filename or frontmatter)
-- Don't overthink tags
-
-### Batch Processing
-- Process inbox during weekly review
-- Don't process individually (except for urgent items)
-- Group similar items when organizing
-
-### Urgent Items
-- If user specifies "urgent" or "critical":
-  - Create directly in appropriate location (not inbox)
-  - Add high priority (⏫)
-  - Confirm: "This is urgent, created directly in [location]"
-
-## Integration with Other Skills
-
-**Delegates to:**
-- `obsidian-management` - File creation and operations
-- `chiron-core` - PARA methodology for processing inbox
-- `daily-routines` - Inbox processing during weekly review
-
-**Delegation rules:**
-- Processing inbox → `daily-routines` (weekly review)
-- Moving files → `obsidian-management`
-- PARA categorization → `chiron-core`
-
-## Quick Reference
-
-| Capture Type | Command Pattern | Location |
-|-------------|-----------------|------------|
-| Task | "Capture: [task]" or "Todo: [task]" | tasks/inbox.md |
-| Note | "Note: [content]" or "Remember: [content]" | 00-inbox/quick-capture-*.md |
-| Meeting | "Meeting notes: [topic]" | 00-inbox/meetings/meeting-*.md |
-| Learning | "Learned: [insight]" | 00-inbox/learnings/learning-*.md |
-| Reference | "Save: [article]" or "Clip: [URL]" | 00-inbox/web-clips/[source]-*.md |
-
-## Error Handling
-
-### Inbox Directory Not Found
-1. Create `00-inbox/` directory
-2. Create subdirectories: `meetings/`, `web-clips/`, `learnings/`
-3. Confirm structure created
-
-### File Already Exists
-1. Add timestamp to filename (if not present)
-2. Or append to existing file
-3. Ask user which approach
-
-### Processing Conflicts
-1. Ask user for clarification on PARA placement
-2. Provide options with reasoning
-3. Let user choose
-
-## Resources
-
-- `references/inbox-organization.md` - Detailed processing workflows
-- `references/capture-formats.md` - Format specifications by type
-
-**Load references when:**
-- Detailed processing questions
-- Format customization needed
-- Troubleshooting organization issues

skills/research/SKILL.md

@@ -1,59 +0,0 @@
----
-name: research
-description: "Research and investigation workflows. Use when: (1) researching technologies or tools, (2) investigating best practices, (3) comparing solutions, (4) gathering information for decisions, (5) deep-diving into topics. Triggers: research, investigate, explore, compare, learn about, what are best practices for, how does X work."
-compatibility: opencode
----
-
-# Research
-
-Research and investigation workflows for informed decision-making.
-
-## Status: Stub
-
-This skill is a placeholder for future development. Core functionality to be added:
-
-## Planned Features
-
-### Investigation Workflow
-- Multi-source research (web, docs, code)
-- Source credibility assessment
-- Summary with drill-down capability
-
-### Technology Evaluation
-- Feature comparison matrices
-- Pros/cons analysis
-- Fit-for-purpose assessment
-
-### Best Practices Discovery
-- Industry standards lookup
-- Implementation patterns
-- Common pitfalls
-
-### Learning Path Generation
-- Topic breakdown
-- Resource recommendations
-- Progress tracking
-
-### Output to Obsidian
-- Save research findings as resource notes
-- Create learning notes for topics
-- Link related resources using WikiLinks
-
-## Integration Points
-
-- **Obsidian**: Save research findings to Resources (03-resources/)
-- **Web Search**: Primary research source
-- **librarian agent**: External documentation lookup
-
-## Quick Commands (Future)
-
-| Command | Description |
-|---------|-------------|
-| `research [topic]` | Start research session |
-| `compare [A] vs [B]` | Feature comparison |
-| `best practices [topic]` | Lookup standards |
-| `learn [topic]` | Generate learning path |
-
-## Notes
-
-Expand this skill based on actual research patterns that emerge from usage.

skills/skill-creator/SKILL.md

@@ -79,6 +79,7 @@ Executable code (Python/Bash/etc.) for tasks that require deterministic reliabil
 - **Example**: `scripts/rotate_pdf.py` for PDF rotation tasks
 - **Benefits**: Token efficient, deterministic, may be executed without loading into context
 - **Note**: Scripts may still need to be read by Opencode for patching or environment-specific adjustments
+- **Dependencies**: Scripts with external dependencies (Python packages, system tools) require those dependencies to be registered in the repository's `flake.nix`. See Step 4 for details.
 
 ##### References (`references/`)
 
@@ -302,6 +303,37 @@ To begin implementation, start with the reusable resources identified above: `sc
 
 Added scripts must be tested by actually running them to ensure there are no bugs and that the output matches what is expected. If there are many similar scripts, only a representative sample needs to be tested to ensure confidence that they all work while balancing time to completion.
 
+#### Register Dependencies in flake.nix
+
+When scripts introduce external dependencies (Python packages or system tools), add them to the repository's `flake.nix`. Dependencies are defined once in `pythonEnv` (Python packages) or `packages` (system tools) inside the `skills-runtime` buildEnv. This runtime is exported as `packages.${system}.skills-runtime` and consumed by project flakes and home-manager — ensuring opencode always has the correct environment regardless of which project it runs in.
+
+**Python packages** — add to the `pythonEnv` block with a comment referencing the skill:
+
+```nix
+pythonEnv = pkgs.python3.withPackages (ps:
+  with ps; [
+    # <skill-name>: <script>.py
+    <package-name>
+  ]);
+```
+
+**System tools** (e.g. `poppler-utils`, `ffmpeg`, `imagemagick`) — add to the `paths` list in the `skills-runtime` buildEnv:
+
+```nix
+skills-runtime = pkgs.buildEnv {
+  name = "opencode-skills-runtime";
+  paths = [
+    pythonEnv
+    # <skill-name>: needed by <script>
+    pkgs.<tool-name>
+  ];
+};
+```
+
+**Convention**: Each entry must include a comment with `# <skill-name>: <reason>` so dependencies remain traceable to their originating skill.
+
+After adding dependencies, verify they resolve: `nix develop --command python3 -c "import <package>"`
+
 Any example files and directories not needed for the skill should be deleted. The initialization script creates example files in `scripts/`, `references/`, and `assets/` to demonstrate structure, but most skills won't need all of them.
 
 #### Update SKILL.md

skills/skill-creator/scripts/init_skill.py

@@ -6,8 +6,8 @@ Usage:
     init_skill.py <skill-name> --path <path>
 
 Examples:
-    init_skill.py my-new-skill --path ~/.config/opencode/skill
-    init_skill.py my-api-helper --path .opencode/skill
+    init_skill.py my-new-skill --path ~/.config/opencode/skills
+    init_skill.py my-api-helper --path .opencode/skills
     init_skill.py custom-skill --path /custom/location
 """
 

skills/task-management/SKILL.md

@@ -1,406 +0,0 @@
----
-name: task-management
-description: "PARA-based task management using Obsidian Tasks plugin format. Use when: (1) creating/managing tasks, (2) daily or weekly reviews, (3) prioritizing work, (4) searching for tasks, (5) planning sprints or focus blocks. Triggers: task, todo, find tasks, search tasks, overdue, prioritize."
-compatibility: opencode
----
-
-# Task Management
-
-PARA-based task management using Obsidian Tasks plugin format for Chiron system.
-
-## Obsidian Tasks Format
-
-**Basic format:**
-```markdown
-- [ ] Task description #tag ⏫ 📅 YYYY-MM-DD
-```
-
-**Priority indicators:**
-- ⏫ = Critical (urgent AND important)
-- 🔼 = High (important, not urgent)
-- 🔽 = Low (nice to have)
-
-**Date indicators:**
-- 📅 = Due date
-- ⏳ = Start date
-- 🛫 = Scheduled date
-
-**Owner attribution:**
-```markdown
-- [ ] Task description #todo 👤 @owner ⏫ 📅 YYYY-MM-DD
-```
-
-## Task Locations
-
-```
-~/CODEX/
-├── tasks/                    # Central task management
-│   ├── inbox.md            # Unprocessed tasks
-│   ├── waiting.md          # Blocked/delegated
-│   ├── someday.md           # Future ideas
-│   └── by-context/          # Context-based task lists
-│       ├── work.md
-│       ├── home.md
-│       └── errands.md
-├── 01-projects/             # Project-specific tasks (in _index.md or notes/tasks.md)
-└── 02-areas/                # Area-specific tasks (in area files)
-```
-
-## Core Workflows
-
-### Create Task
-
-**When user says**: "Add task: X", "Todo: X", "Remember to: X"
-
-**Steps:**
-
-1. **Parse task from request:**
-   - Task description
-   - Priority (if specified: critical, high, low)
-   - Due date (if specified)
-   - Owner (if specified: @mention)
-   - Context (if specified)
-   - Project/area (if specified)
-
-2. **Determine location:**
-   - Project-specific → `01-projects/[project]/_index.md` or `tasks.md`
-   - Area-specific → `02-areas/[area].md`
-   - General → `tasks/inbox.md`
-
-3. **Create task in Obsidian format:**
-   ```markdown
-   - [ ] [Task description] #tag [priority] 👤 [@owner] 📅 [date]
-   ```
-
-4. **Confirm creation**
-
-**Examples:**
-```
-User: "Add task: Review Q1 budget proposal, critical, due Friday"
-
-Action:
-Create in tasks/inbox.md:
-- [ ] Review Q1 budget proposal #inbox ⏫ 📅 2026-01-31
-
-Confirm: "Created task in inbox."
-```
-
-```
-User: "Task: Email John about project deadline, due Friday, @john"
-
-Action:
-Create in tasks/inbox.md:
-- [ ] Email John about project deadline #inbox 🔼 👤 @john 📅 2026-01-31
-
-Confirm: "Created task assigned to John."
-```
-
-```
-User: "Add task to Project X: Create PRD, high priority"
-
-Action:
-Create in 01-projects/work/project-x/_index.md:
-- [ ] Create PRD #high 📅 2026-02-15
-
-Confirm: "Created task in Project X."
-```
-
-### Find Tasks
-
-**When user says**: "Find tasks", "What tasks do I have?", "Show me tasks for [context/project]"
-
-**Steps:**
-
-1. **Determine search scope:**
-   - All tasks → Search all task files
-   - Context tasks → Search `tasks/by-context/[context].md`
-   - Project tasks → Read project's `_index.md` or `tasks.md`
-   - Area tasks → Read area file
-   - Overdue tasks → Search for tasks with past due dates
-
-2. **Search using rg:**
-   ```bash
-   # Find all tasks
-   rg "- \\[ \\]" ~/CODEX --type md
-
-   # Find tasks by tag
-   rg "#work" ~/CODEX --type md
-
-   # Find overdue tasks
-   rg "- \\[ \\].*📅" ~/CODEX --type md | filter-past-dates
-   ```
-
-3. **Parse and organize:**
-   - Extract task description
-   - Extract priority indicators (⏫/🔼/🔽)
-   - Extract due dates
-   - Extract owners (@mentions)
-   - Extract tags
-
-4. **Present results grouped by:**
-   - Priority
-   - Due date
-   - Context/project/area
-
-**Output format:**
-```markdown
-# Found 15 tasks
-
-## Critical Tasks (⏫)
-1. [ ] Review Q1 budget #work ⏫ 📅 2026-01-31
-2. [ ] Client presentation #work ⏫ 📅 2026-01-30
-
-## High Priority (🔼)
-1. [ ] Update documentation #project-a 🔼 📅 2026-02-15
-2. [ ] Team meeting notes #work 🔼 👤 @john
-3. [ ] Buy groceries #personal 🔼 📅 2026-01-28
-
-## Upcoming (by due date)
-This week:
-- [ ] Submit expense report #work 🔼 📅 2026-01-29
-- [ ] Dentist appointment #personal 🔼 📅 2026-01-30
-
-Next week:
-- [ ] Project milestone #work 🔼 📅 2026-02-05
-- [ ] Car service #personal 🔼 📅 2026-02-07
-
-## By Owner
-Assigned to @john (2 tasks):
-- [ ] Team meeting notes #work 🔼
-- [ ] Email stakeholder #work 🔼 📅 2026-02-01
-```
-
-### Search Specific Contexts
-
-**When user says**: "What [context] tasks do I have?", "Show work tasks", "Show personal tasks"
-
-**Steps:**
-
-1. **Read context file**: `tasks/by-context/[context].md`
-2. **Parse tasks**
-3. **Present filtered list**
-
-**Available contexts:**
-- `work.md` - Work-related tasks
-- `home.md` - Household/admin tasks
-- `errands.md` - Shopping/running errands
-- `deep-work.md` - Focus work (no interruptions)
-- `calls.md` - Phone/video calls
-- `admin.md` - Administrative tasks
-
-### Prioritize Tasks
-
-**When user says**: "Prioritize my tasks", "What should I work on?", "Focus check"
-
-**Steps:**
-
-1. **Fetch all incomplete tasks**:
-   - `rg "- \\[ \\]" ~/CODEX --type md`
-   - Filter out completed (`[x]`)
-
-2. **Sort by criteria:**
-   - Priority (⏫ > 🔼 > 🔽 > no indicator)
-   - Due date (sooner first)
-   - Energy level (if specified: high/medium/low)
-
-3. **Return top 3-5 tasks**
-4. **Include rationale** for prioritization
-
-**Output format:**
-```markdown
-# Focus Recommendations (5 tasks found)
-
-## Top Priority: ⏫ Critical
-1. **[Review Q1 budget]** #work ⏫ 📅 2026-01-31
-   - Why: Due in 4 days, critical for Q2 planning
-   - Area: Finances
-   - Estimated time: 2 hours
-
-## High Priority: 🔼 Important (due within week)
-1. **[Client presentation]** #work 🔼 📅 2026-01-30
-   - Why: Client commitment, high impact
-   - Area: Work
-   - Estimated time: 4 hours
-
-2. **[Team standup]** #work 🔼
-   - Why: Daily sync, keeps team aligned
-   - Area: Work
-   - Estimated time: 30 minutes
-
-3. **[Car registration]** #personal 🔼 📅 2026-02-01
-   - Why: Legal requirement, must complete
-   - Area: Home
-   - Estimated time: 1 hour
-
-## Recommended Order
-1. Team standup (30min, energizes for day)
-2. Review Q1 budget (2 hours, critical, morning focus)
-3. Client presentation (4 hours, high energy block)
-4. Car registration (1 hour, after lunch)
-
-## Not Now (someday)
-- [ ] Learn Rust #personal 🔽
-- [ ] Organize photos #personal 🔽
-```
-
-### Update Task Status
-
-**When user says**: "Mark task X as done", "Complete: X", "Task X finished"
-
-**Steps:**
-
-1. **Find task** (by description or show options)
-2. **Change checkbox:**
-   ```markdown
-   # Before:
-   - [ ] Task description
-
-   # After:
-   - [x] Task description
-   ```
-3. **Update modified date** in frontmatter (if present)
-4. **Confirm**
-
-### Move Tasks
-
-**When user says**: "Move task X to project Y", "Task X goes to area Z"
-
-**Steps:**
-
-1. **Find source task**
-2. **Read target location** (project `_index.md` or area file)
-3. **Move task** (copy to target, delete from source)
-4. **Update task context/tags** if needed
-5. **Confirm**
-
-**Example:**
-```
-User: "Move 'Buy groceries' to Finances area"
-
-Action:
-1. Find task in tasks/inbox.md
-2. Read 02-areas/personal/finances.md
-3. Copy task to finances.md
-4. Delete from tasks/inbox.md
-5. Confirm: "Moved 'Buy groceries' to Finances area."
-```
-
-### Task Delegation/Blocking
-
-**When user says**: "Delegate task X to Y", "Task X is blocked", "Waiting for X"
-
-**Steps:**
-
-1. **Find task**
-2. **Add owner or blocking info:**
-   ```markdown
-   # Delegation:
-   - [ ] Task description #waiting 👤 @owner ⏫ 📅 date
-
-   # Blocked:
-   - [ ] Task description #waiting 🛑 Blocked by: [reason]
-   ```
-3. **Move to `tasks/waiting.md`** if delegated/blocked
-4. **Confirm**
-
-## Integration with Other Skills
-
-**Delegates to:**
-- `obsidian-management` - File operations (create/update/delete tasks)
-- `chiron-core` - PARA methodology for task placement
-- `daily-routines` - Task prioritization and scheduling
-- `project-structures` - Project task lists
-- `meeting-notes` - Extract action items from meetings
-
-**Delegation rules:**
-- File operations → `obsidian-management`
-- PARA placement → `chiron-core`
-- Project tasks → `project-structures`
-- Meeting actions → `meeting-notes`
-
-## Quick Reference
-
-| Action | Command Pattern | Location |
-|--------|-----------------|------------|
-| Create task | "Task: [description] [priority] [due] [@owner]" | tasks/inbox.md or project/area |
-| Find tasks | "Find tasks" or "What tasks do I have?" | All task files |
-| Context tasks | "Show [context] tasks" | tasks/by-context/[context].md |
-| Prioritize | "Prioritize tasks" or "What should I work on?" | All tasks, sorted |
-| Mark done | "Task [description] done" or "Complete: [description]" | Task location |
-| Move task | "Move task [description] to [project/area]" | Target location |
-| Defer | "Someday: [task]" or "Defer: [task]" | tasks/someday.md |
-
-## Best Practices
-
-### Creating Tasks
-- Be specific (not vague like "follow up")
-- Set realistic due dates
-- Assign owners clearly
-- Link to projects/areas immediately
-- Use appropriate priorities
-
-### Managing Tasks
-- Review daily (delegate to daily-routines)
-- Process inbox weekly
-- Archive completed tasks regularly
-- Update context when tasks move
-
-### Searching Tasks
-- Use tags for filtering
-- Search by context when batching
-- Check overdue tasks daily
-- Review waiting tasks weekly
-
-## Error Handling
-
-### Task Not Found
-1. Search similar tasks
-2. Ask user: "Which task?"
-3. List options with context
-
-### Duplicate Tasks
-1. Detect duplicates by description
-2. Ask: "Merge or keep separate?"
-3. If merge, combine due dates/priorities
-
-### Location Not Found
-1. Create directory structure
-2. Ask user: "Create in this location?"
-3. Create task in inbox as fallback
-
-## Resources
-
-- `references/task-formats.md` - Obsidian Tasks plugin syntax
-- `references/prioritization-methods.md` - Eisenhower matrix, energy-based prioritization
-- `references/search-patterns.md` - rg patterns for finding tasks
-
-**Load references when:**
-- Format questions arise
-- Prioritization help needed
-- Search issues occur
-- Task automation questions
-
-## Obsidian Tasks Plugin Configuration
-
-For full functionality, configure Obsidian Tasks plugin:
-
-**Settings:**
-- Task format: `- [ ] Task #tag ⏫ 📅 YYYY-MM-DD`
-- Priority symbols: ⏫, 🔼, 🔽
-- Date format: YYYY-MM-DD
-- Default file: tasks/inbox.md
-
-**Queries:**
-```dataview
-TASK
-WHERE !completed
-GROUP BY priority
-SORT due date ASC
-```
-
-```dataview
-TASK
-WHERE !completed AND due < date(today)
-SORT due ASC
-GROUP BY project
-```