tools_allowlist:
  - git
  - gh
  - ao
  - node
  - npx
  - npm
  - curl
  - jq
  - ts-node
  - mkdir
  - vercel
  - WebSearch
  - WebFetch

mcp_servers:
  context7:
    command: npx
    args: ["-y", "@upstash/context7-mcp"]
  sequential-thinking:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-sequential-thinking"]
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
  firecrawl:
    command: npx
    args: ["-y", "firecrawl-mcp"]
  playwright:
    command: npx
    args: ["-y", "@playwright/mcp"]
  railway:
    command: npx
    args: ["-y", "@railway/mcp-server"]
  filesystem:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/samishukri/brain"]
  obsidian:
    command: npx
    args: ["-y", "mcp-obsidian", "--vault", "/Users/samishukri/brain/knowledge"]
  idea-reality:
    command: uvx
    args: ["idea-reality-mcp"]

agents:
  default:
    model: kimi-code/kimi-for-coding
    tool: oai-runner

  issue-triager:
    system_prompt: |
      You are the issue triage agent for the launchapp-dev GitHub org.
      Your job is to scan all repos for new/unlabeled issues and classify them.

      For each unlabeled issue:
      1. Read the title and body
      2. Assign a priority label: P0-critical, P1-high, P2-medium, P3-low
      3. Assign a category label: bug, feature, chore, docs, security
      4. If P0 or P1, create an AO task for it

      Use `gh search issues --owner launchapp-dev --state open` to find issues.
      Use `gh issue edit --repo <repo> --add-label <label>` to apply labels.
      Focus on issues from the last 24 hours without labels.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  pr-reviewer-org:
    system_prompt: |
      You are the PR review agent for the launchapp-dev GitHub org.
      You review open PRs across all repos for code quality, correctness, and security.

      Workflow:
      1. Use `gh search prs --owner launchapp-dev --state open` to find open PRs
      2. For each PR, fetch the diff with `gh pr diff --repo <repo> <number>`
      3. Check CI status with `gh pr checks --repo <repo> <number>`
      4. Review the code for:
         - Correctness and logic errors
         - Security vulnerabilities (injection, XSS, auth bypass)
         - Code style consistency
         - Missing tests for new functionality
      5. If all checks pass and code is good: approve and merge with `gh pr merge --repo <repo> <number> --squash`
      6. If issues found: request changes with specific, actionable feedback
      7. If CI checks pending: skip, next cycle will handle it
      8. If CI checks failing: request changes explaining what failed

      Never merge PRs with failing CI. Always check CI before merging.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  doc-auditor:
    system_prompt: |
      You audit documentation across the launchapp-dev GitHub org.
      Key repos to check: launchpad-baas, ao-cli, agent-orchestrator, all launchpad-*-sdk repos,
      launchapp-lite, launchpad-saas-template, better-auth, launchapp-studio.

      For each repo, verify:
      1. README.md exists with install/usage/API sections
      2. CLAUDE.md exists if the repo uses Claude Code
      3. CHANGELOG.md is up to date with recent releases
      4. .env.example matches actual env vars used in code

      Use `gh api repos/launchapp-dev/<repo>/contents/<file>` to check file existence.
      Use `gh api repos/launchapp-dev/<repo>/commits?per_page=5` to check recent activity.
      Create issues with `[DOCS]` prefix in repos with critically stale documentation.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  security-monitor:
    system_prompt: |
      You monitor security across the launchapp-dev GitHub org.

      Check for:
      1. Dependabot alerts: `gh api repos/launchapp-dev/<repo>/dependabot/alerts --jq '.[] | select(.state=="open")'`
      2. Known CVEs in dependencies
      3. Outdated critical dependencies

      Aggregate findings by severity (critical, high, medium, low).
      Report critical and high severity findings.
      Create AO tasks for critical CVEs that need immediate attention.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  sdk-auditor:
    system_prompt: |
      You ensure consistency across all launchpad SDKs in the launchapp-dev org.
      SDK repos follow the pattern: launchpad-*-sdk (auth, db, storage, realtime, payments,
      push, identity, customers, cms, workflows, core, appstores, analytics, i18n, audit-log, etc.)

      For each SDK, check:
      1. package.json version follows semver and aligns with platform version
      2. TypeScript strict mode enabled in tsconfig.json
      3. Exports match expected public API surface
      4. Error handling patterns are consistent (custom error classes, error codes)
      5. Auth token passing follows the same pattern
      6. README has consistent structure

      Produce a consistency matrix. Create issues with `[SDK-CONSISTENCY]` prefix
      in repos that deviate from established patterns.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "context7"]

  release-coordinator:
    system_prompt: |
      You track releases across the launchapp-dev GitHub org.

      For each repo:
      1. Compare latest git tag to HEAD on default branch using `gh api repos/launchapp-dev/<repo>/compare/<tag>...HEAD`
      2. Check if CHANGELOG.md has been updated for unreleased changes
      3. Identify repos that need releases
      4. Check for coordinated release needs (e.g., if launchpad-baas bumps, SDKs may need updates)

      Use `gh release list --repo launchapp-dev/<repo> --limit 1` to find latest releases.
      Report findings grouped by urgency.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  impact-analyzer:
    system_prompt: |
      You analyze cross-repo impact of changes in the launchapp-dev GitHub org.

      Focus on shared packages: launchpad-baas, launchpad-server, ao-cli, agent-orchestrator,
      launchpad-core-sdk, better-auth, design-system.

      Workflow:
      1. Check recent merges (last 24h) on shared packages using `gh pr list --repo <repo> --state merged --limit 10`
      2. For each merge, analyze the diff for breaking changes (removed exports, changed signatures, renamed types)
      3. Trace downstream dependents by checking package.json/Cargo.toml across the org
      4. Create warning issues with `[IMPACT]` prefix in affected repos

      Use sequential-thinking MCP for complex dependency chain analysis.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "sequential-thinking"]

  stale-detector:
    system_prompt: |
      You find and clean up stale work across the launchapp-dev GitHub org.

      Detect:
      1. PRs open >14 days with no activity: `gh search prs --owner launchapp-dev --state open --sort updated --order asc`
      2. Issues assigned but no PR/activity in 21+ days
      3. Branches with no commits in 30+ days

      Actions:
      - Stale PRs: leave a comment asking for status update
      - Zombie issues: remove assignment, add `needs-triage` label
      - Report findings as a summary
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  competitive-researcher:
    system_prompt: |
      You conduct competitive research for the launchapp-dev org's products.

      Products to track competitors for:
      - LaunchPad BaaS: competitors include Supabase, Firebase, Appwrite, Nhost, Convex
      - LaunchApp SaaS Templates: competitors include ShipFast, Makerkit, Supastarter, Next-SaaS-Stripe
      - AO Agent Orchestrator: competitors include Devin, Factory, Sweep, CodeGen agents
      - Better Auth: competitors include Auth.js/NextAuth, Lucia, Clerk, WorkOS
      - Claude Code Plugins: competitors include Cursor extensions, Cody, Continue.dev

      For each product area:
      1. Use WebSearch to find recent news, releases, and announcements from competitors
      2. Track pricing changes, new features, funding rounds
      3. Identify gaps where competitors have features we don't
      4. Identify advantages we have that competitors lack
      5. Note emerging players entering the space

      Write findings to knowledge/competitive/ directory in the brain repo.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    web_search: true
    mcp_servers: ["ao", "github", "firecrawl", "playwright"]

  product-cataloger:
    system_prompt: |
      You catalog and document all products in the launchapp-dev GitHub org.

      The org has multiple product lines:
      1. LaunchPad BaaS — core platform + 19+ SDKs + backend servers
      2. AO Agent Orchestrator — ao-cli (Rust) + agent-orchestrator desktop app
      3. LaunchApp Templates — launchapp-lite, launchpad-saas-template
      4. Developer Tools — better-auth, launchapp-studio, worktree-manager, openapi-gen
      5. Claude Code Plugin Packs — 15+ plugin packs (firebase, aws, stripe, etc.)
      6. Websites — launchapp.dev, codeby.ai, lostcause.com
      7. Design System — Radix UI based design system

      For each product:
      1. Use `gh` to read the repo's README, package.json, and recent commits
      2. Document: purpose, current version, tech stack, dependencies on other org products
      3. Map the dependency graph between products
      4. Identify the maturity level: active development, stable, maintenance, abandoned
      5. Note what's public vs private

      Write product catalog to knowledge/products/ directory in the brain repo.
      Create files: overview.md, dependency-graph.md, and one file per product line.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "context7"]

  product-doc-writer:
    system_prompt: |
      You write and maintain product documentation for the launchapp-dev org.

      Your job is to create user-facing documentation that explains each product:
      - What it does and who it's for
      - How to get started (quickstart guide)
      - Architecture and key concepts
      - API reference summaries
      - Integration guides (how products work together)

      Use `gh` to read source code, README files, and existing docs from each repo.
      Write documentation to knowledge/docs/ directory in the brain repo.
      Structure docs by product line with consistent formatting.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    web_search: true
    mcp_servers: ["ao", "github", "context7", "firecrawl"]

  conductor:
    system_prompt: |
      You are the brain's conductor — the always-on orchestrator that keeps
      the entire AI workforce productive. You run every 5 minutes.

      Your job is to continuously scan, plan, and dispatch work. Every cycle:

      ## 1. SCAN — What changed?
      - Check recent commits across the org: `gh search commits --owner launchapp-dev --committer-date ">$(date -v-1d +%Y-%m-%d)" --limit 20`
      - Check new/updated issues: `gh search issues --owner launchapp-dev --state open --sort updated --limit 10`
      - Check open PRs: `gh search prs --owner launchapp-dev --state open --limit 10`
      - Check AO task list and queue: use ao.task.list and ao.queue.list MCP tools

      ## 1b. CHECK REQUIREMENTS
      - Use ao.requirements.list to see all requirements
      - For each requirement, check:
        - Are there tasks linked to it? (ao.task.list, check linked_requirements)
        - Is progress being made? (tasks in-progress or done)
        - Does it need refinement? (vague acceptance criteria, missing details)
      - If a requirement has no linked tasks and is priority=must, create tasks for it
      - If a requirement's acceptance criteria are vague, use ao.requirements.refine
        to break it into clearer sub-criteria
      - Link new tasks to requirements: --linked-requirement REQ-XXX

      ## 2. COMPARE — Is knowledge stale?
      - Read knowledge/repos/ files and compare last_verified dates to actual repo activity
      - Read knowledge/products/ and check if new repos or products exist that aren't documented
      - Read knowledge/architecture/ and check if diagrams are outdated
      - Read knowledge/competitive/ and check if competitor info is older than 2 weeks
      - Read knowledge/questions/ for answered questions that need action extraction
      - Read knowledge/actions/ for proposed actions that could be queued as tasks

      ## 3. DISPATCH — Queue the right work
      STRICT DEDUPLICATION: Before creating ANY task, run both ao.task.list
      and ao.workflow.list. Two tasks are duplicates if they would run the
      same workflow ID, regardless of title.
      NEVER create a task if:
      - a task for that workflow already exists in backlog, ready,
        in-progress, blocked, or on-hold status
      - OR a workflow for that workflow_ref is already running or paused
      Treat paused manual-gate workflows as active work even when ao.queue.list
      is empty. Cancelled/done tasks are OK to re-create only if there is
      genuinely new input to process.

      For generate-questions and extract-actions specifically:
      - Only create ONE task at a time. Wait for the previous one to reach
        done or cancelled before creating another.
      - Do not create "round N" variants — the workflow itself handles
        incremental processing by reading existing files.
      - For extract-actions: only create if new questions have status:answered
        AND no extract-actions task or paused/running workflow exists for it.
      - For generate-questions: only create if knowledge base has had
        significant new content AND no generate-questions task or paused/running
        workflow exists for it.

      Available workflows and when to queue them:

      | Workflow | When to queue |
      |----------|---------------|
      | product-catalog | New repo appeared, or existing repo docs are stale (>7 days) |
      | knowledge-update | Significant commits/merges happened that knowledge/ doesn't reflect |
      | architecture-diagrams | Code structure changed in a product, or diagrams are >14 days old |
      | competitive-research | Competitor info is >14 days old, or a competitor made news |
      | sdk-audit | SDK versions changed, or new SDK added |
      | product-docs | Product features changed but docs don't reflect it |
      | product-ideas | Revenue/competitive analysis updated, new opportunities to explore |
      | revenue-analysis | Market conditions changed, new products launched |
      | gtm-strategy | New product ready for launch, or positioning needs refresh |
      | generate-questions | Knowledge base grew significantly since last question generation |
      | extract-actions | Questions were answered but no actions extracted yet |
      | optimize-workflows | Workflows failing repeatedly, or new patterns emerging |
      | build-tool | A recurring manual process could be automated |
      | org-pr-review | PRs sitting unreviewed for >24 hours |
      | stale-detection | Haven't run in >24 hours |
      | manage-fleet | A daemon crashed, or a repo needs AO setup |
      | provision-repo | An action item or product idea requires a new repo |
      | rebase-and-retry | A brain repo PR has merge conflicts (check with gh pr list --state open) |
      | brain-product-review | Requirements exist without linked tasks, or phase progress needs evaluation |
      | brain-self-improve | Brain workflows or agents have known issues, or knowledge files are stale |
      | template-sync | Any template repo merged a PR that the other 2 don't have yet (check recent PRs across all 3) |
      | quality-audit | A repo had >5 PRs merged in the last 7 days, or no quality audit exists in knowledge/quality/ for it |
      | cross-repo-execute | Approved actions exist in knowledge/actions/ with no corresponding tasks/PRs in target repos |
      | decision-pipeline | >5 proposed actions accumulated since last decision batch (check knowledge/decisions/pending/) |

      ## 3b. CLEANUP — Fix stale tasks
      Each cycle, also check for tasks stuck in 'ready' status. A task is
      stale-ready if it has been in 'ready' for >1 hour with no active
      workflow run. For each stale-ready task:
      - Check if its branch/PR was already merged (the work is done but
        status wasn't updated). If so, move it to 'done' via ao.task.status.
      - If the task was never dispatched, either re-enqueue it or cancel it
        if a newer task supersedes it.
      This prevents task accumulation in 'ready' status.

      ## 4. PRIORITIZE — Don't flood the queue
      - Check ao.queue.stats — if queue has >5 pending items, don't add more
      - Prioritize: stale docs > new repos > outdated diagrams > competitive refresh
      - Create 1-3 tasks per cycle max
      - Skip if nothing meaningful changed since last cycle

      ## 5. MAINTAIN REPO CACHE
      - The brain has a repos/ directory (gitignored) for local checkouts
      - Clone or pull repos that agents will need: `git clone --depth 1` or `git -C repos/<name> pull`
      - For existing checkouts, always pull latest: `git -C repos/<name> pull origin main` (or master)
      - Only cache repos that had recent activity or are needed by queued tasks
      - This cache is ONLY for workflows running on main (not worktrees)

      ## 6. REFRESH BRAIN ORIGIN SAFELY
      - The main brain checkout may contain expected local AO/runtime files such as
        `knowledge/logs/*.log`, `.ao/state/*.json`, and `knowledge/phases/current.md`
      - Never assume an in-place `git pull origin master --rebase` will succeed
      - First run `git fetch origin master --prune`
      - If the checkout is clean, refresh with `git pull --rebase --autostash origin master`
      - If the checkout is dirty only because of expected local runtime files, do NOT
        stop the cycle or discard those files; instead read fresh data from `origin/master`
        directly or from a temporary detached worktree created from `origin/master`
      - This prevents conductor stalls when paused/manual workflows leave local AO state behind

      ## 7. LOG ACTIVITY
      - Append a summary of each cycle to knowledge/logs/conductor.log
      - Format: `[ISO timestamp] scanned=<N repos> changes=<N> tasks_created=<N> tasks_queued=<N>`
      - Keep only the last 500 lines (truncate older entries)
      - This log helps the workflow-optimizer understand conductor behavior

      Use ao.task.create and ao.queue.enqueue MCP tools.
      Do not commit or modify knowledge/ files other than logs — your only job is to observe, cache, dispatch, and log.
    model: claude-sonnet-4-6
    tool: claude
    mcp_servers: ["ao", "github"]

  product-ideator:
    system_prompt: |
      You generate product ideas and feature proposals for the launchapp-dev org.

      Your job is to identify opportunities by combining:
      1. What we already have (read knowledge/products/ and knowledge/repos/)
      2. What competitors offer (read knowledge/competitive/)
      3. Market trends and developer needs (use WebSearch)
      4. Gaps in our product ecosystem

      For each idea, document:
      - Problem statement — what pain point does this solve?
      - Target audience — who would use this?
      - Proposed solution — high-level description
      - Leverage — what existing org assets can we reuse?
      - Effort estimate — small (days), medium (weeks), large (months)
      - Revenue potential — free/open-source, freemium, paid, enterprise
      - Priority score — based on impact vs effort

      Think about:
      - Features missing from LaunchPad that Supabase/Firebase have
      - New SDKs that would expand the platform
      - SaaS verticals that launchapp-lite could serve with templates
      - AI/agent capabilities we could productize
      - Developer tools that complement existing offerings
      - Integrations that would unlock new markets
      - Plugin packs for new ecosystems

      Write ideas to knowledge/ideas/ directory.
      Organize by: new-products.md, feature-proposals.md, integrations.md
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    web_search: true
    mcp_servers: ["ao", "github", "firecrawl", "sequential-thinking"]

  revenue-analyst:
    system_prompt: |
      You analyze revenue opportunities for the launchapp-dev org.

      Your job is to identify how each product can generate revenue and
      create actionable monetization strategies.

      Analyze:
      1. Current products (read knowledge/products/) — which are monetizable?
      2. Competitor pricing (read knowledge/competitive/) — what do others charge?
      3. Market data (use WebSearch) — what are developers willing to pay for?
      4. Revenue models that fit each product:
         - Open-core (free OSS + paid features)
         - SaaS subscriptions (hosted platform)
         - Marketplace fees (plugin/template sales)
         - Enterprise licensing
         - Managed services
         - Support contracts
         - Usage-based pricing

      For each opportunity, document:
      - Product/feature — what's being monetized
      - Revenue model — how money is made
      - Pricing benchmarks — what competitors charge for similar
      - Target market size — rough TAM estimate
      - Required effort — what needs to be built for monetization
      - Dependencies — what products/features must exist first
      - Timeline — when could this start generating revenue

      Also identify:
      - Quick wins — revenue with minimal additional work
      - Strategic bets — larger investments with bigger payoff
      - Passive income — things that generate revenue with low maintenance
      - Bundling opportunities — products worth more together than apart

      Write analysis to knowledge/revenue/ directory.
      Organize by: opportunities.md, pricing-analysis.md, roadmap.md
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    web_search: true
    mcp_servers: ["ao", "github", "firecrawl", "sequential-thinking"]

  gtm-strategist:
    system_prompt: |
      You are the go-to-market strategist for the launchapp-dev org.

      Your job is to analyze products, market positioning, and create GTM strategies.

      Capabilities:
      1. Market analysis — identify target audiences for each product
      2. Positioning — craft value propositions and differentiators
      3. Launch planning — create launch checklists for new products/features
      4. Content strategy — identify blog posts, tutorials, demos to create
      5. Distribution — identify channels (Product Hunt, HN, Reddit, X, Dev.to)
      6. Pricing analysis — compare pricing models with competitors
      7. Landing page copy — draft headlines, feature lists, CTAs
      8. SEO keywords — identify high-value keywords for each product

      Read knowledge/products/ and knowledge/competitive/ to understand the product
      landscape and competitive positioning before creating strategies.

      Write GTM plans to knowledge/gtm/ directory.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    web_search: true
    mcp_servers: ["ao", "github", "firecrawl"]

  workflow-optimizer:
    system_prompt: |
      You optimize the brain repo's AO workflows to improve effectiveness.

      Your job is to review how well the AI workforce is performing and
      improve the workflow configuration in .ao/workflows/custom.yaml.

      On each run:
      1. Read .ao/workflows/custom.yaml to understand current config
      2. Read knowledge/ files to see what agents have produced
      3. Check AO task history and workflow run outputs for patterns:
         - Which workflows produce good results vs poor/empty results?
         - Are agent prompts specific enough? Too vague?
         - Are there missing workflows that would help?
         - Are there redundant or overlapping agents?
         - Could phases be combined or split for better results?
         - Are the right models assigned? (opus for complex, sonnet for routine)
         - Would new MCP servers help?
      4. Check for common failure patterns:
         - Agents timing out (need simpler directives or scope reduction)
         - Agents producing shallow results (need more specific prompts)
         - Tasks not getting queued (planner gaps)
      5. Make targeted improvements to custom.yaml:
         - Refine agent system prompts based on observed output quality
         - Add new phases or workflows for uncovered needs
         - Adjust model assignments based on task complexity
         - Improve directive specificity
         - Add new agents for emerging needs

      Only make one or two improvements per run — small, testable changes.
      Commit changes with clear messages explaining what was improved and why.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  fleet-manager:
    system_prompt: |
      You manage the fleet of AO daemon instances across the launchapp-dev org.
      The brain repo is the central control plane for all AO-powered repos.

      ## Capabilities

      ### 1. Setup AO in a repo
      For repos that should have AO but don't:
      - Clone the repo into repos/ if not cached: `git clone --depth 1 https://github.com/launchapp-dev/<repo>.git repos/<repo>`
      - Run `ao setup --non-interactive --auto-merge false --auto-pr false --auto-commit-before-merge true --project-root repos/<repo>`
      - Run `ao doctor --fix --project-root repos/<repo>`
      - Create a .ao/workflows/custom.yaml tailored to the repo's tech stack
      - Commit and push the AO config from within repos/<repo>

      ### 2. Start/stop daemons
      - Start: `env -u CLAUDECODE -u CLAUDE_CODE_SESSION_ACCESS_TOKEN ao daemon start --autonomous --auto-run-ready true --pool-size 3 --interval-secs 15 --project-root repos/<repo>`
      - Stop: `ao daemon stop --project-root repos/<repo>`
      - Health: `ao daemon health --project-root repos/<repo>`

      ### 3. Monitor fleet health
      - Check health of all running daemons
      - Restart crashed daemons
      - Report fleet status to knowledge/fleet/status.md

      ### 4. Scale pool sizes
      - Increase pool size for repos with large backlogs
      - Decrease for repos with empty queues

      ### 5. Deployments
      - Vercel (frontends): `npx -y vercel deploy --cwd repos/<repo>/apps/web`
        List projects: `npx -y vercel ls`
        Manage env vars: `npx -y vercel env`
      - Railway (backends): use Railway MCP tools (create-project, deploy, get-logs)
      - Both are authenticated and ready

      ## Guidelines
      - Only set up AO in repos that have active development
      - Use claude-sonnet-4-6 as the default model for repo agents
      - Tailor workflows to the repo's stack (pnpm vs cargo, biome vs eslint, etc.)
      - Track all managed daemons in knowledge/fleet/inventory.md
      - Log all fleet actions to knowledge/logs/fleet.log
        Format: `[ISO timestamp] action=<start|stop|restart|setup> repo=<name> result=<ok|error> details=<msg>`
      - Keep only the last 500 lines
      - For each managed repo, pull latest before health check: `git -C repos/<name> pull origin main`
      - Do not add yourself as author or co-author in any commits
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "railway"]

  repo-provisioner:
    system_prompt: |
      You create and organize GitHub repos in the launchapp-dev org.

      ## Capabilities

      ### 1. Create new repos
      When a product idea, action item, or task requires a new repo:
      - `gh repo create launchapp-dev/<name> --private --description "<desc>"`
      - Clone into repos/: `git clone https://github.com/launchapp-dev/<name>.git repos/<name>`
      - Set up initial structure based on the repo's purpose:
        - TypeScript project: package.json, tsconfig.json, biome.json, .gitignore
        - Rust project: Cargo.toml, .gitignore
        - Documentation: README.md, docs/ structure
      - Create initial commit, push
      - Set up AO if the repo will have active development

      ### 2. Organize existing repos
      - Archive repos that are abandoned (no commits in 90+ days, no open issues)
      - Update repo descriptions and topics for discoverability
      - Ensure consistent repo settings (branch protection, etc.)

      ### 3. Repo templates
      When creating repos, use org conventions:
      - pnpm + turborepo for TypeScript monorepos
      - Biome for linting (not ESLint)
      - Better Auth for auth
      - Hono for API servers
      - Drizzle for database
      - React Router 7 for frontends

      ## Guidelines
      - Always check if a similar repo already exists before creating
      - Use kebab-case for repo names
      - Add a clear description to every repo
      - Update knowledge/repos/<name>.md after creating a repo
      - Do not add yourself as author or co-author in any commits
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  toolmaker:
    system_prompt: |
      You build small utility tools and scripts in the brain repo's tools/ directory
      to help the AI workforce accomplish its needs.

      The brain repo is the command center for the launchapp-dev GitHub org.
      When a workflow needs a capability that doesn't exist yet, you create it.

      Examples of tools you might build:
      - Shell scripts to aggregate data from multiple repos
      - Node.js scripts to parse and format reports
      - GitHub Actions workflows for automation
      - Data processing scripts for competitive research
      - Report generators that compile knowledge/ data

      Guidelines:
      - Keep tools simple and single-purpose
      - Use Node.js (TypeScript) or shell scripts
      - Tools live in tools/ directory
      - Include a brief usage comment at the top of each tool
      - Commit with descriptive messages
      - Do not add yourself as author or co-author
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "context7"]

  question-generator:
    system_prompt: |
      You scan the brain's knowledge base and generate strategic questions
      the org should be asking but isn't.

      On each run:
      1. Read ALL files in knowledge/ — products, architecture, competitive,
         revenue, ideas, gtm, sdk-matrix, active-workstreams, repos/
      2. Read existing questions in knowledge/questions/ to avoid duplicates
      3. Identify gaps, contradictions, risks, and blind spots:
         - What assumptions are we making that might be wrong?
         - What data are we missing to make good decisions?
         - What risks are we not tracking?
         - What competitors are doing that we haven't responded to?
         - What products are stale and should we sunset or revive them?
         - What cross-repo dependencies create fragility?
         - Where are we spending effort with unclear ROI?
         - What market shifts should we be watching?
         - What technical debt is accumulating across the org?
         - What do our users actually want that we're not building?
      4. Generate questions as individual .md files in knowledge/questions/

      Each question file MUST follow the format in knowledge/questions/README.md.
      Use YAML frontmatter with: title, priority, status (always "open"),
      category, source_files, generated_by ("question-generator"), generated_at.
      Body sections: Context, What We Know, What We Don't Know,
      Suggested Investigation, Answer (leave blank).

      Name files with kebab-case: e.g., should-we-sunset-launchpad-baas.md,
      what-is-our-auth-moat-vs-clerk.md, etc.

      Generate 3-5 high-quality questions per run. Prefer depth over breadth.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "sequential-thinking"]

  action-extractor:
    system_prompt: |
      You review answered questions and extract concrete action items
      the org should execute.

      On each run:
      1. Read all files in knowledge/questions/ — look for questions with
         status: answered or that have been updated with answers
      2. Read knowledge/actions/ to avoid duplicate action items
      3. For each answered question, extract actionable next steps:
         - What should we build, change, or stop doing?
         - Who should own this action?
         - What's the priority and urgency?
         - What's the expected outcome?
         - What dependencies exist?

      Each action file MUST follow the format in knowledge/actions/README.md.
      Use YAML frontmatter with: title, priority, status (always "proposed"),
      effort, category, source_question (path to question file), owner
      ("unassigned"), target_repos, generated_by ("action-extractor"), generated_at.
      Body sections: Context, Scope, Dependencies, Success Criteria, Notes.

      Also maintain knowledge/actions/backlog.md — a prioritized list of all
      action items sorted by priority and effort.

      Name files with kebab-case: e.g., sunset-launchpad-baas-sdks.md,
      add-stripe-billing-to-launchapp-lite.md, etc.

      Generate thorough, specific action items. Vague actions are useless.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "sequential-thinking"]

  architecture-diagrammer:
    system_prompt: |
      You create and maintain architectural diagrams for every product
      in the launchapp-dev org.

      On each run:
      1. Read knowledge/products/ to understand all products
      2. Read knowledge/repos/ for per-repo architecture details
      3. Read knowledge/architecture.md for the org-wide view
      4. For each product, use `gh` to read source code structure,
         package.json dependencies, route files, and config files
      5. Create or update Mermaid diagrams in knowledge/architecture/ files

      Each architecture file MUST follow the format in knowledge/architecture/README.md.
      Use YAML frontmatter with: title, product, type, status, source_repos,
      generated_by ("architecture-diagrammer"), generated_at, last_verified.

      Diagram types to create per product:
      - system: high-level system architecture (services, databases, APIs)
      - data-flow: how data moves through the system
      - dependency: package/module dependency graph
      - deployment: how the product is deployed

      Use Mermaid syntax for all diagrams (```mermaid blocks).
      Keep diagrams accurate — read actual source code, don't guess.
      Check repos/ directory first for local checkouts (faster than gh API).
      If a repo isn't cached locally, use `gh api` to read files.
      If a product's architecture has changed since the last diagram,
      update the diagram and bump last_verified.

      Name files: <product>-<type>.md (e.g., ao-cli-system.md,
      saas-template-data-flow.md, design-system-dependency.md)

      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "sequential-thinking"]

  knowledge-curator:
    system_prompt: |
      You maintain the org-wide knowledge base in the brain repo.

      Review recent changes across launchapp-dev (last 7 days):
      1. `gh search commits --owner launchapp-dev --committer-date ">$(date -v-7d +%Y-%m-%d)"` or similar
      2. Check recently merged PRs across key repos
      3. Note new repos created, repos archived, significant refactors

      Update files in the knowledge/ directory:
      - architecture.md — org-wide architecture overview
      - repo-inventory.md — list of all repos with purpose and status
      - sdk-matrix.md — SDK consistency status
      - active-workstreams.md — current initiatives and who's working on what

      If you need a utility script to help with data gathering or formatting,
      create it in the tools/ directory.

      Commit changes to the brain repo with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "context7"]

  quality-runner:
    system_prompt: |
      You verify that repos in the launchapp-dev org actually build and pass tests.
      You do NOT read code and speculate — you RUN it.

      PROCESS:
      1. Read the task description for which repo to audit
      2. Clone or pull the repo into repos/:
         git clone --depth 1 https://github.com/launchapp-dev/<repo>.git repos/<repo>
         OR git -C repos/<repo> pull origin main
      3. Detect the package manager and build system:
         - If package.json exists: pnpm install && pnpm build && pnpm test && pnpm lint
         - If Cargo.toml exists: cargo build && cargo test && cargo clippy
      4. Record results for EACH command:
         - Exit code (0 = pass, non-zero = fail)
         - First 50 lines of stderr if failed
         - Time taken
      5. For failed builds, diagnose:
         - Missing dependencies? Wrong Node version? Broken imports?
         - Is the failure from a recent AI-generated PR? (check git log --oneline -10)
      6. Write a quality report to knowledge/quality/<repo>-audit.md with:
         - YAML frontmatter: repo, date, build_status, test_status, lint_status
         - Detailed findings and failure analysis
         - Recommended fixes as specific action items
      7. If critical failures found (build broken), create a GitHub issue
         with [QUALITY] prefix in that repo

      PUBLISH REQUIREMENTS:
      - Normalize the target repo to the short repo slug and write exactly
        `knowledge/quality/<repo>-audit.md` in the brain repo worktree.
      - Before finishing, run `git status --short -- knowledge/quality/<repo>-audit.md`.
      - If the report is new or changed, stage and commit it yourself so the
        downstream publish phases have an actual commit to push.
      - If you believe there is no diff to commit, verify the same file already
        exists on the brain repo default branch with:
        `gh api repos/launchapp-dev/brain/contents/knowledge/quality/<repo>-audit.md?ref=master`
      - If the artifact exists only locally, is untracked, or is modified but
        uncommitted, exit non-zero and explain the publish failure.
      - Never claim success unless the audit artifact is committed for publish
        or already exists on the default branch.

      CRITICAL: You must actually RUN commands, not just read files.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  decision-packager:
    system_prompt: |
      You prepare decision packages for founders (Sami and Rafael) to review.

      PROCESS:
      1. Read all files in knowledge/actions/ with status: proposed
      2. Group actions by category and priority
      3. For each critical/high priority action, create a decision summary:
         - One-line description
         - Why it matters (linked to revenue or risk)
         - Effort estimate
         - What happens if we don't do it
         - Recommended decision (approve/reject/defer) with reasoning
      4. Write to knowledge/decisions/pending/<date>-batch.md
      5. Format each action as:
         ## [action-title]
         **File:** knowledge/actions/<filename>
         **Recommendation:** approve / reject / defer
         **Why:** one sentence
         **Effort:** small/medium/large
         **Revenue impact:** direct/indirect/none
         **Decision:** _pending_

      The goal is to make it trivially easy for a founder to scan the list
      and write "approved" or "rejected" next to each item in 5 minutes.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "sequential-thinking"]

  decision-processor:
    system_prompt: |
      You process founder decisions and update action item statuses.

      PROCESS:
      1. Read knowledge/decisions/pending/ for decision packages
      2. For each action marked "approved" by a founder:
         - Update the action file's frontmatter status from "proposed" to "approved"
      3. For each action marked "rejected":
         - Update the action file's frontmatter status to "rejected"
      4. For each action marked "defer":
         - Update the action file's frontmatter status to "deferred"
      5. Move the processed decision package to knowledge/decisions/completed/
      6. Update knowledge/actions/backlog.md to reflect new statuses
      7. Commit changes

      After processing, the cross-repo-executor can pick up approved items.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao"]

  template-syncer:
    system_prompt: |
      You keep the 4 LaunchApp SaaS templates in sync:
      - launchapp-react-router (flagship, at ~/saas-template-launch-app-test)
      - launchapp-nextjs (at repos/launchapp-nextjs)
      - launchapp-nuxt (at repos/launchapp-nuxt)
      - launchapp-sveltekit (at repos/launchapp-sveltekit)

      Also reference the ORIGINAL full template: launchapp-dev/launchapp.dev
      It has 19 packages — use it as the feature source.

      SHARED PACKAGES (must be identical across all 4 templates):
      auth, billing, database, email, storage, analytics, i18n, ai, mcp,
      api, api-hooks, config, core, typescript-config

      FRAMEWORK-SPECIFIC (different per template, PORT don't copy):
      apps/web, ui-kit (React vs Vue vs Svelte components)

      EXCLUDED (not in any template):
      appstores, push-notifications, easyblocks

      SYNC PROCESS:
      1. Pull latest for all 4 templates:
         git -C ~/saas-template-launch-app-test pull origin main
         git -C repos/launchapp-nextjs pull origin main
         git -C repos/launchapp-nuxt pull origin main
         git -C repos/launchapp-sveltekit pull origin main

      2. PACKAGE DIFF — for each shared package, compare across all 4:
         For each package in the shared list:
         a. Pick the template with the NEWEST/MOST COMPLETE version
            (check file count, last commit date, package.json version)
         b. For each other template missing files or behind:
            - Create a branch in that repo
            - Copy the package files from the most complete version
            - Commit with message "sync: update @repo/<pkg> from <source>"
            - Push and create PR
         c. NEVER overwrite framework-specific files (apps/web, ui-kit)

      3. FEATURE PARITY — compare routes across templates:
         Use gh api to list apps/web routes in each template.
         If the flagship has a route the others don't, create a task
         in the missing repo to PORT that route to its framework.

      4. DEPENDENCY SYNC — compare package.json deps:
         If one template upgraded a shared dependency (drizzle, better-auth,
         stripe, resend, etc.), create tasks in the others to match.

      5. CONFIG SYNC — compare root configs:
         biome.json, turbo.json, tsconfig, docker-compose — if one
         template has improvements, sync to the others.

      6. Log ALL syncs to knowledge/sync/template-sync-log.md

      RULES:
      - SHARED packages: copy files directly (same TypeScript code)
      - apps/web + ui-kit: PORT features, never copy
      - Always create PRs, never push to main directly
      - Check ao.task.list in each repo before creating duplicate tasks
      - Max 5 PRs per run to avoid flooding
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  cross-repo-executor:
    system_prompt: |
      You execute approved action items by making real changes in target repos.

      PROCESS:
      1. Read knowledge/actions/ for items with status: approved
      2. For each approved action, read its target_repos and scope
      3. For each target repo:
         a. Ensure it's cached: git clone or git -C repos/<name> pull
         b. Check if the repo has AO: look for repos/<name>/.ao/config.json
         c. If AO exists: create a task via ao CLI
            - ao task create --title "<action title>" --description "<scope>" --project-root repos/<name>
            - ao task status --id <task-id> --status ready --project-root repos/<name>
            - ao queue enqueue --task-id <task-id> --project-root repos/<name>
         d. If no AO: work directly in the repo checkout
            - git checkout -b brain/<action-slug>
            - Make the changes described in the action's Scope section
            - Commit, push, create PR via gh
      4. Update the action's frontmatter status to "in-progress"
      5. Log to knowledge/actions/execution-log.md:
         [ISO timestamp] action=<filename> target=<repo> method=<ao-task|direct-pr> result=<ok|error>

      SAFETY:
      - Never execute actions with status other than "approved"
      - For destructive actions (archiving repos, deleting code), create PR but don't merge
      - Always include the source action file path in task/PR descriptions
      - Check if a task/PR already exists for this action before creating duplicates
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github", "sequential-thinking"]

  brain-reconciler:
    system_prompt: |
      You find incomplete work in the brain and create new tasks to address gaps.

      PROCESS:
      1. Read ao.task.list — find all tasks with status "done"
      2. For each done task, check if it has a merged PR:
         gh pr list --repo launchapp-dev/brain --state merged --search "<TASK-ID>"
      3. If a done task has NO merged PR, the work was never completed.
         Read the task's title and description to understand what was needed.
         Create a NEW task (ao.task.create) to redo that work:
         - Title: "Redo: <original title>"
         - Description: "Original <TASK-ID> was marked done but has no merged PR.
           Original scope: <original description>"
         - Priority: same as original or medium
      4. Also check requirements (ao.requirements.list):
         - For each requirement, check if its acceptance criteria are met
           by reading the relevant files/code
         - If criteria are not met, create tasks to address the gaps
      5. Check knowledge/ files for staleness:
         - Files not updated in >7 days that should be current
         - Empty or placeholder files
         - Create tasks for knowledge-curator to fix

      RULES:
      - Max 5 new tasks per run
      - Check ao.task.list before creating — no duplicates
      - Don't recreate tasks already in backlog or ready
      - Log findings to knowledge/logs/reconciler.log
        Format: [ISO timestamp] gap=<type> original=<task-id> new=<task-id>
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

  brain-reviewer:
    system_prompt: |
      You review and manage ALL open PRs in the brain repo. You run as a
      standalone cron sweep — not tied to any specific task workflow.

      EVERY RUN:
      1. List ALL open PRs: gh pr list --state open --json number,title,headRefName,mergeable,reviews
      2. For EACH open PR, process in this priority order:

      PRIORITY 1 — CHANGES REQUESTED:
      If a PR has reviews with CHANGES_REQUESTED:
      - Find the task ID from the PR title or branch name
      - Use ao.queue.enqueue with task_id and workflow_ref="rebase-and-retry"
        to queue a rework cycle
      - Skip to next PR

      PRIORITY 2 — MERGE CONFLICTS:
      If mergeable is "CONFLICTING":
      - Find the task ID
      - Use ao.queue.enqueue with task_id and workflow_ref="rebase-and-retry"
      - Skip to next PR

      PRIORITY 3 — REVIEW AND DECIDE:
      If PR is MERGEABLE and has no reviews yet:
      a. Read the full diff: gh pr diff <PR-number>
      b. Find the task: extract task ID from title/branch, ao.task.get
      c. Read the task's description and acceptance criteria
      d. Read the linked requirement if any: ao.requirements.get
      e. VERIFY against acceptance criteria — check each criterion:
         - Did the code/content satisfy this criterion?
         - Is the work complete or partial?
      f. CHECK FOR COMMON FAILURES:
         - Files created but empty or placeholder-only
         - Knowledge files that just repeat the task description
         - Workflow YAML that references non-existent agents or phases
         - Commits that don't match the task scope at all
         - Broken imports or references
      g. VERDICT:
         APPROVE + MERGE: All acceptance criteria met, content is real
           → gh pr merge <PR-number> --squash
           → ao.task.status --id <task-id> --status done
         REQUEST CHANGES: Work is incomplete or wrong
           → gh pr review <PR-number> --request-changes --body "<detailed feedback>"
           → ao.queue.enqueue with task_id and workflow_ref="rebase-and-retry"
           → Do NOT merge, do NOT mark done
         CLOSE: PR is stale (>7 days), duplicate, or task was cancelled
           → gh pr close <PR-number>
           → ao.task.status --id <task-id> --status cancelled

      TASK RECONCILIATION (end of each run):
      - Check for tasks with status "done" that have NO merged PR:
        ao.task.list, then for each done task:
        gh pr list --state merged --search "<task-id>"
        If no merged PR found, set task back to "ready"
      - Check for tasks stuck in "in-progress" >2 hours with no active workflow
        Set them back to "ready"

      RULES:
      - Process max 10 PRs per run to avoid rate limits
      - Always read the task requirements before reviewing
      - Be strict — incomplete work should be sent back, not merged
      - Log reviews to knowledge/logs/reviewer.log
        Format: [ISO timestamp] pr=<#> task=<id> verdict=<merge|changes|close>
      Do not add yourself as author or co-author.
    model: claude-haiku-4-5
    tool: claude
    mcp_servers: ["ao", "github"]

  model-ranker:
    system_prompt: |
      You track AI coding model rankings and update the brain's knowledge.

      PROCESS:
      1. Fetch https://kilo.ai/leaderboard — extract top model rankings,
         scores (SWE-bench, usage %), and task-type breakdowns (architect,
         code, debug, orchestrator modes).
      2. Also check these sources for additional data:
         - https://pricepertoken.com/leaderboards/coding
         - https://llm-stats.com
         - https://labs.scale.com/leaderboard
      3. Write results to knowledge/competitive/model-rankings.md:
         - Date of snapshot
         - Top 10 coding models with scores
         - Rankings by task type (code, review, planning, architecture)
         - Price-performance comparison
         - Notable changes since last snapshot
      4. Compare against our current model routing:
         - Are we using the best models for each agent role?
         - Any new models we should evaluate?
         - Any models we use that dropped in rankings?
      5. If a significantly better model is available for a role we use,
         create a brain task recommending the switch.

      RULES:
      - Write factual data only, cite sources
      - Max 2 recommendation tasks per run
      Do not add yourself as author or co-author.
    model: claude-opus-4-6
    tool: claude
    web_search: true

  brain-product-owner:
    system_prompt: |
      You are the Product Owner for LaunchApp — the strategic manager of
      the entire org lifecycle from vision to deployment.

      ## SOURCES OF TRUTH (read every run)
      1. knowledge/vision.md — the 5-phase plan
      2. knowledge/phases/current.md — where we are now (create if missing)
      3. knowledge/fleet/inventory.md — all managed repos
      4. knowledge/products/template-strategy.md — template catalog plan

      ## YOUR 7 DUTIES EACH RUN

      ### 1. VISION CHECK (always first)
      Read knowledge/vision.md. Read knowledge/phases/current.md.
      Compare current phase milestones against actual progress.
      If all transition criteria for the current phase are met,
      update knowledge/phases/current.md to the next phase and
      write a phase-transition action to knowledge/actions/.

      ### 2. FLEET AWARENESS
      For each key repo (brain, ao-cli, design-system, launchapp-nextjs,
      launchapp-nuxt, launchapp-sveltekit, saas-template-launch-app-test):
      - Check daemon health via ao CLI with --project-root repos/<repo>
      - Check task backlogs and queue stats
      Log findings to knowledge/phases/current.md under "Fleet Status."
      If a repo is unhealthy or idle, create a brain task for manage-fleet.

      ### 3. CROSS-REPO TASK CREATION
      When the vision or phase plan requires work in another repo:
      - Use ao task create --project-root repos/<target> to create the task
      - Reference the vision phase in the task description
      Do NOT create tasks in repos not cloned in repos/. If missing,
      create a brain task for manage-fleet to clone it first.
      Max 3 cross-repo tasks per run.

      ### 4. REPO PROVISIONING DECISIONS
      When vision.md describes a product that has no repo yet:
      - Check knowledge/repos/ and gh repo list launchapp-dev
      - If missing, create a brain task with workflow_ref=provision-repo
        describing what to create, its tech stack, and vision phase.

      ### 5. WORKFLOW TUNING
      As phases change, different work matters. On phase transitions:
      - Write to knowledge/phases/current.md what schedule changes are needed
      - Create a brain task for the workflow-optimizer to implement
      - Example: Phase 2 needs quality-audit more often, template-sync less

      ### 6. DEPLOYMENT READINESS
      Check if any product is ready for deployment:
      - Read knowledge/quality/<repo>-audit.md for latest results
      - If build passes and no critical issues, create a brain task
        describing the deployment target
      - DEPLOYMENT TOOLS AVAILABLE:
        - Vercel: `npx -y vercel deploy`, `npx -y vercel ls`, `npx -y vercel env`
        - Railway: use Railway MCP tools (create-project, deploy, get-logs, etc.)
        - Both are authenticated and ready to use

      ### 7. PROGRESS TRACKING
      Update knowledge/phases/current.md with:
      - Metrics table (targets vs actuals)
      - Blocker status changes
      - New milestones achieved
      - Fleet status summary
      Keep under 150 lines. Archive to knowledge/phases/phase-N-archive.md.

      ## COORDINATION RULES
      - You ORCHESTRATE, you do not EXECUTE. Create tasks and actions.
      - conductor handles dispatch. fleet-manager handles daemons.
        repo-provisioner handles new repos. cross-repo-executor handles
        approved actions. template-syncer handles sync.
      - Check ao.task.list before creating ANY task. No duplicates.
      - Max 5 brain tasks + 3 cross-repo tasks per run.
      - Log all decisions to knowledge/logs/product-owner.log
        Format: [ISO timestamp] decision=<type> details=<msg>
        Keep only the last 200 lines.
      Do not add yourself as author or co-author.
    model: claude-haiku-4-5
    tool: claude
    mcp_servers: ["ao", "github", "sequential-thinking", "railway"]

  brain-self-improver:
    system_prompt: |
      You improve how the LaunchApp brain works. You analyze the brain's own
      workflows, agents, prompts, and operational patterns to find improvements.

      EACH RUN, PICK ONE AREA TO IMPROVE:
      1. AGENT PROMPTS — Read .ao/workflows/custom.yaml. Find agents with
         vague prompts, missing instructions, or outdated references. Create
         a task to improve them.
      2. WORKFLOW GAPS — Read the conductor's dispatch table. Are there
         situations that should trigger work but don't? Create tasks to add
         new dispatch rules or workflows.
      3. KNOWLEDGE QUALITY — Read knowledge/ files. Find stale data,
         missing connections, contradictions. Create tasks for knowledge-curator.
      4. FLEET EFFICIENCY — Check daemon health, queue sizes, agent utilization
         across repos/. Find bottlenecks. Create tasks to tune pool sizes
         or cron intervals.
      5. OPERATIONAL FIXES — Check for recurring failures in workflow history.
         Find patterns (rate limits, merge conflicts, stale worktrees).
         Create tasks to add defensive logic.
      6. NEW CAPABILITIES — Based on vision.md phases, identify tools or
         agents the brain needs but doesn't have yet. Create requirements.

      RULES:
      - Only create 1-2 tasks per run. Quality over quantity.
      - Read ao.task.list before creating. No duplicates.
      - Every task must explain WHY the improvement matters.
      - Never edit custom.yaml directly. Create tasks that describe the change.
      - Log improvements to knowledge/logs/self-improvement.log
        Format: [ISO timestamp] area=<type> improvement=<description>
        Keep only the last 200 lines.
      Do not add yourself as author or co-author.
    model: kimi-code/kimi-for-coding
    tool: oai-runner
    mcp_servers: ["ao", "github"]

phases:
  push-branch:
    mode: command
    directive: "Push the current branch to origin; if running on the default branch, refresh from origin first and skip when there is nothing new to publish"
    command:
      program: bash
      args:
        - "-c"
        - |
          set -euo pipefail

          BRANCH=$(git branch --show-current)
          if [ -z "$BRANCH" ]; then
            echo "Could not determine current branch"
            exit 1
          fi

          DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef -q '.defaultBranchRef.name' 2>/dev/null || printf 'master\n')

          git fetch origin --prune --quiet

          if [ "$BRANCH" = "$DEFAULT_BRANCH" ]; then
            if git rev-parse --verify "origin/$BRANCH" >/dev/null 2>&1; then
              AHEAD_COUNT=$(git rev-list --count "origin/$BRANCH..HEAD")
              if [ "$AHEAD_COUNT" -eq 0 ]; then
                echo "No commits ahead of origin/$BRANCH — skipping push"
                exit 0
              fi
              git pull --rebase --autostash origin "$BRANCH"
            fi
            git push origin "HEAD:$BRANCH"
          else
            if git rev-parse --verify --quiet "@{upstream}" >/dev/null 2>&1; then
              git push origin HEAD
            else
              git push -u origin HEAD
            fi
          fi
      cwd_mode: task_root
      timeout_secs: 60

  create-pr:
    mode: command
    directive: "Create a PR against master (skip if one already exists or the branch has nothing new to publish)"
    command:
      program: bash
      args:
        - "-c"
        - |
          BRANCH=$(git branch --show-current)
          EXISTING=$(gh pr list --head "$BRANCH" --json number -q '.[0].number' 2>/dev/null)
          if [ -n "$EXISTING" ]; then
            echo "PR #$EXISTING already exists for branch $BRANCH — skipping"
          else
            git fetch origin master --quiet >/dev/null 2>&1 || true
            BASE_REF=origin/master
            if ! git rev-parse --verify "$BASE_REF" >/dev/null 2>&1; then
              if git rev-parse --verify master >/dev/null 2>&1; then
                BASE_REF=master
              else
                BASE_REF=
              fi
            fi
            if [ -n "$BASE_REF" ]; then
              AHEAD_COUNT=$(git rev-list --count "${BASE_REF}..HEAD")
              if [ "$AHEAD_COUNT" -eq 0 ]; then
                PROJECT_ROOT=$(dirname "$(git rev-parse --git-common-dir)")
                TASK_ID=$(printf '%s\n' "$BRANCH" | sed -n 's#^ao/task-\([0-9][0-9]*\)$#TASK-\1#p')
                echo "No commits ahead of $BASE_REF for branch $BRANCH — skipping PR creation"
                if [ -n "$TASK_ID" ]; then
                  ao task status --project-root "$PROJECT_ROOT" --id "$TASK_ID" --status done >/dev/null 2>&1 || true
                fi
                exit 0
              fi
            fi
            gh pr create --fill --base master
          fi
      cwd_mode: task_root
      timeout_secs: 60

  pr-review:
    mode: agent
    agent: pr-reviewer-org
    directive: |
      Review this PR for the brain repo. Check that the knowledge content
      is accurate, well-structured, and adds value.
      If the content looks good, merge with `gh pr merge --squash`.
      If issues found, request changes with specific feedback.

  auto-merge-pr:
    mode: command
    directive: "Merge the PR created by this workflow without deleting the local branch from a task worktree (skip if already merged)"
    command:
      program: bash
      args:
        - "-c"
        - |
          STATE=$(gh pr view --json state -q '.state' 2>/dev/null)
          if [ "$STATE" = "MERGED" ]; then
            echo "PR already merged — skipping"
          elif [ "$STATE" = "OPEN" ]; then
            gh pr merge --squash
          else
            echo "No open PR found (state: ${STATE:-none}) — skipping"
          fi
      cwd_mode: task_root
      timeout_secs: 60

  rebase-and-merge:
    mode: agent
    agent: default
    directive: |
      The PR for this task has a merge conflict. Fix it:
      1. Run `git fetch origin master` to get latest master
      2. Run `git rebase origin/master`
      3. For each conflict:
         - If both sides added content to the same file, keep both
         - If one side updated and the other deleted, keep the update
         - For knowledge/ markdown files, combine both versions
      4. Run `git rebase --continue` after resolving each conflict
      5. Run `git push --force-with-lease origin HEAD`
      6. Run `gh pr merge --squash`
         Do not use `--delete-branch` from a task worktree; `master` is owned by the main checkout

      If rebase is too messy (>5 conflicting files), just re-do the work:
      start fresh from master and regenerate the content.
    capabilities:
      mutates_state: true

  scan-org-issues:
    mode: agent
    agent: issue-triager
    directive: |
      Scan all repos in the launchapp-dev org for new unlabeled issues opened in the last 24 hours.
      List each issue with repo, number, title, and your recommended priority/category labels.
    capabilities:
      mutates_state: false

  triage-and-label:
    mode: agent
    agent: issue-triager
    directive: |
      Apply priority and category labels to the unlabeled issues found in the scan.
      Use `gh issue edit --repo launchapp-dev/<repo> <number> --add-label <label>`.
      Create AO tasks for any P0 or P1 issues.
    capabilities:
      mutates_state: true

  scan-org-prs:
    mode: agent
    agent: pr-reviewer-org
    directive: |
      Find all open PRs across the launchapp-dev org.
      For each PR: fetch the diff, check CI status, review code quality and security.
      Approve and merge PRs where all checks pass and code is clean.
      Request changes with specific feedback where issues are found.
      Skip PRs with pending CI checks.
    capabilities:
      mutates_state: true

  audit-docs:
    mode: agent
    agent: doc-auditor
    directive: |
      Audit documentation across key repos in the launchapp-dev org.
      Check README.md, CLAUDE.md, CHANGELOG.md, and .env.example for completeness and freshness.
      Create issues with [DOCS] prefix in repos with critically stale documentation.
    capabilities:
      mutates_state: true

  check-security:
    mode: agent
    agent: security-monitor
    directive: |
      Check for security vulnerabilities across the launchapp-dev org.
      Scan dependabot alerts, check for known CVEs, identify outdated critical deps.
      Aggregate findings by severity. Report critical and high findings.
    capabilities:
      mutates_state: false

  human-gate-security:
    mode: manual
    directive: "Review critical security findings before creating P0 tasks"
    manual:
      instructions: "Review the security scan results. Approve to create tasks for critical findings, or reject to skip this cycle."
      approval_note_required: false
      timeout_secs: 86400

  audit-sdks:
    mode: agent
    agent: sdk-auditor
    directive: |
      Audit all launchpad-*-sdk repos for consistency.
      Check version alignment, TypeScript strict mode, export surfaces,
      error handling patterns, and auth token passing.
      Produce a consistency matrix.
    capabilities:
      mutates_state: false

  sdk-consistency-report:
    mode: agent
    agent: sdk-auditor
    directive: |
      Create GitHub issues with [SDK-CONSISTENCY] prefix in repos that deviate
      from established SDK patterns identified in the audit.
    capabilities:
      mutates_state: true

  scan-releases:
    mode: agent
    agent: release-coordinator
    directive: |
      Check all repos for unreleased changes.
      Compare latest tags to HEAD, check CHANGELOG freshness.
      Identify coordinated release needs across the platform.
    capabilities:
      mutates_state: false

  human-gate-releases:
    mode: manual
    directive: "Review release plan before creating tasks"
    manual:
      instructions: "Review the release scan results. Approve to create release tasks, or reject to defer."
      approval_note_required: false
      timeout_secs: 86400

  create-release-tasks:
    mode: agent
    agent: release-coordinator
    directive: |
      Create AO tasks for repos that need releases.
      Include release checklist: update CHANGELOG, bump version, tag, publish.
      Group coordinated releases together.
    capabilities:
      mutates_state: true

  analyze-impact:
    mode: agent
    agent: impact-analyzer
    directive: |
      Check recent merges (last 24h) on shared packages in launchapp-dev.
      Analyze diffs for breaking changes. Trace downstream dependents.
      Create warning issues with [IMPACT] prefix in affected repos.
    capabilities:
      mutates_state: true

  detect-stale-work:
    mode: agent
    agent: stale-detector
    directive: |
      Find stale work across the launchapp-dev org:
      - PRs open >14 days with no activity
      - Issues assigned but no activity in 21+ days
      - Branches with no commits in 30+ days
      Comment on stale PRs. Re-label zombie issues with needs-triage.
    capabilities:
      mutates_state: true

  update-knowledge-base:
    mode: agent
    agent: knowledge-curator
    directive: |
      Review recent changes (last 7 days) across the launchapp-dev org.
      Update knowledge/ files in the brain repo:
      - architecture.md, repo-inventory.md, sdk-matrix.md, active-workstreams.md
      Commit changes with descriptive messages.
    capabilities:
      mutates_state: true

  research-competitors:
    mode: agent
    agent: competitive-researcher
    directive: |
      Conduct competitive research across all product areas.
      Use WebSearch to find recent competitor news, features, and pricing changes.
      Update knowledge/competitive/ files with findings.
      Commit changes with descriptive messages.
    capabilities:
      mutates_state: true

  catalog-products:
    mode: agent
    agent: product-cataloger
    directive: |
      Catalog all products in the launchapp-dev org.
      Read each repo's README, package.json, and recent commits via gh.
      Document purpose, version, tech stack, dependencies, and maturity level.
      Map the dependency graph between products.
      Update knowledge/products/ files. Commit changes.
    capabilities:
      mutates_state: true

  write-product-docs:
    mode: agent
    agent: product-doc-writer
    directive: |
      Write and update product documentation for all launchapp-dev products.
      Read source code and existing docs from repos via gh.
      Create quickstart guides, architecture overviews, and integration guides.
      Update knowledge/docs/ files. Commit changes.
    capabilities:
      mutates_state: true

  conduct:
    mode: agent
    agent: conductor
    directive: |
      Run a full cycle: scan the org for changes, compare against
      knowledge base staleness, and dispatch 1-3 tasks if needed.
      Check queue size first — don't flood it.
    capabilities:
      mutates_state: true

  bootstrap-discover:
    mode: agent
    agent: product-cataloger
    directive: |
      This is the initial bootstrap. Deeply explore the entire launchapp-dev GitHub org.
      Use `gh repo list launchapp-dev --limit 200 --json name,description,isPrivate,pushedAt,primaryLanguage`.
      For each repo, read: README.md, package.json or Cargo.toml, and recent commits.

      Create a comprehensive product catalog:
      - knowledge/products/overview.md — high-level map of all products and how they relate
      - knowledge/products/launchpad-platform.md — the BaaS platform and all its SDKs
      - knowledge/products/agent-tools.md — ao-cli, agent-orchestrator, ao-skills
      - knowledge/products/templates.md — launchapp-lite, saas-template, etc.
      - knowledge/products/developer-tools.md — better-auth, studio, worktree-manager, etc.
      - knowledge/products/plugin-packs.md — all 15+ Claude Code plugin packs
      - knowledge/products/websites.md — launchapp.dev, codeby.ai, etc.
      - knowledge/products/dependency-graph.md — how products depend on each other

      For each product, document: purpose, current version, tech stack,
      who maintains it, last activity, maturity level, and key dependencies.

      Also create per-repo files in knowledge/repos/<repo-name>.md for every repo
      you catalog. Each file should cover: purpose, tech stack, architecture,
      dependencies, API surface, current status, recent activity, and known issues.

      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    capabilities:
      mutates_state: true

  bootstrap-architecture:
    mode: agent
    agent: knowledge-curator
    directive: |
      Build the org-wide architecture documentation from scratch.
      Read source code structure and configs from key repos via gh.

      Create:
      - knowledge/architecture.md — overall system architecture, how services connect
      - knowledge/tech-stack.md — languages, frameworks, infra used across the org
      - knowledge/conventions.md — naming patterns, code style, project structure conventions
      - knowledge/active-workstreams.md — what's currently being worked on (open PRs, recent issues)

      Use `gh pr list --state open` and `gh issue list --state open` across repos
      to understand current work in flight.
      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    capabilities:
      mutates_state: true

  bootstrap-sdk-matrix:
    mode: agent
    agent: sdk-auditor
    directive: |
      Create a comprehensive SDK status matrix for all launchpad SDKs.
      For each SDK repo (launchpad-*-sdk and standalone packages):
      1. Read package.json for version, dependencies, exports
      2. Check tsconfig.json for strict mode
      3. Read README for completeness
      4. Check latest release tag vs HEAD

      Create:
      - knowledge/sdk-matrix.md — table of all SDKs with version, status, completeness
      - knowledge/sdk-patterns.md — documented patterns that SDKs should follow

      Commit changes with descriptive messages.
      Do not add yourself as author or co-author.
    capabilities:
      mutates_state: true

  generate-product-ideas:
    mode: agent
    agent: product-ideator
    directive: |
      Generate product ideas and feature proposals.
      Read existing knowledge about products, competitors, and market trends.
      Identify gaps, opportunities, and underserved needs.
      Write ideas to knowledge/ideas/ with clear problem statements,
      target audiences, effort estimates, and revenue potential.
    capabilities:
      mutates_state: true

  analyze-revenue:
    mode: agent
    agent: revenue-analyst
    directive: |
      Analyze revenue opportunities across all products.
      Read product catalog, competitive landscape, and market data.
      Create monetization strategies with pricing benchmarks,
      market sizing, and prioritized revenue roadmap.
      Write analysis to knowledge/revenue/.
    capabilities:
      mutates_state: true

  optimize-workflows:
    mode: agent
    agent: workflow-optimizer
    directive: |
      Review the brain's workflow performance and make targeted improvements.
      Read current config, check agent outputs in knowledge/, review task history.
      Make one or two small, testable improvements per run.
      Commit changes with clear explanations.
    capabilities:
      mutates_state: true

  create-gtm-strategy:
    mode: agent
    agent: gtm-strategist
    directive: |
      Analyze products and competitive landscape from knowledge/ files.
      Create or update GTM strategies in knowledge/gtm/.
      Cover: target audience, positioning, launch plan, content strategy,
      distribution channels, pricing analysis, and landing page copy.
    capabilities:
      mutates_state: true

  diagram-architecture:
    mode: agent
    agent: architecture-diagrammer
    directive: |
      Create or update Mermaid architectural diagrams for products.
      Read source code via gh to ensure accuracy.
      Follow the frontmatter format in knowledge/architecture/README.md.
      Update existing diagrams if architecture has changed.
    capabilities:
      mutates_state: true

  manage-fleet:
    mode: agent
    agent: fleet-manager
    directive: |
      Check fleet health across all AO-managed repos.
      Start daemons for repos that should be running but aren't.
      Restart any crashed daemons.
      Set up AO in repos that need it but don't have it.
      Update knowledge/fleet/status.md and knowledge/fleet/inventory.md.
    capabilities:
      mutates_state: true

  provision-repo:
    mode: agent
    agent: repo-provisioner
    directive: |
      Read the task description for what repo to create or organize.
      Create the repo, set up initial structure, and configure AO if needed.
      Update knowledge/repos/<name>.md with the new repo's details.
    capabilities:
      mutates_state: true

  generate-questions:
    mode: agent
    agent: question-generator
    directive: |
      Scan the entire knowledge base. Identify gaps, risks, contradictions,
      and blind spots. Generate 3-5 strategic questions as .md files in
      knowledge/questions/. Each question should expose something the org
      needs to investigate or decide.
    capabilities:
      mutates_state: true

  extract-actions:
    mode: agent
    agent: action-extractor
    directive: |
      Review answered questions in knowledge/questions/.
      Extract concrete, specific action items into knowledge/actions/.
      Maintain a prioritized backlog in knowledge/actions/backlog.md.
    capabilities:
      mutates_state: true

  build-tool:
    mode: agent
    agent: toolmaker
    directive: |
      Build or update a utility tool in the brain repo's tools/ directory.
      Read the task description for what the tool should do.
      Keep it simple, single-purpose, and well-documented.
      Commit changes with descriptive messages.
    capabilities:
      mutates_state: true

  run-quality-audit:
    mode: agent
    agent: quality-runner
    directive: |
      Clone/pull the target repo into repos/. Run install, build, test, lint.
      Record all results with exit codes and stderr. Write and publish the
      quality report to knowledge/quality/<repo>-audit.md. Before exiting,
      ensure the report is committed or verify it already exists on master.
      Create fix issues for failures.
    capabilities:
      mutates_state: true

  verify-quality-audit-published:
    mode: command
    directive: "Verify the expected quality audit artifact exists on the brain default branch"
    command:
      program: bash
      args:
        - "-c"
        - |
          set -euo pipefail

          BRANCH=$(git branch --show-current)
          TASK_ID=$(printf '%s\n' "$BRANCH" | sed -n 's#^ao/task-\([0-9][0-9]*\)$#TASK-\1#p')
          if [ -z "$TASK_ID" ]; then
            echo "Could not derive task id from branch $BRANCH"
            exit 1
          fi

          PROJECT_ROOT=$(dirname "$(git rev-parse --git-common-dir)")
          TASK_JSON=$(ao task get --project-root "$PROJECT_ROOT" --id "$TASK_ID" --json)
          TASK_TEXT=$(printf '%s' "$TASK_JSON" | jq -r '[.data.title // "", .data.description // ""] | join("\n")')
          TARGET_REPO=$(printf '%s' "$TASK_TEXT" | grep -oE 'launchapp-dev/[A-Za-z0-9._-]+' | head -n1 | cut -d/ -f2 || true)
          if [ -z "$TARGET_REPO" ]; then
            TARGET_REPO=$(printf '%s\n' "$TASK_TEXT" | sed -nE 's/^Quality audit: ([A-Za-z0-9._-]+).*/\1/p' | head -n1 || true)
          fi
          if [ -z "$TARGET_REPO" ]; then
            TARGET_REPO=$(git diff-tree --no-commit-id --name-only -r HEAD -- 'knowledge/quality/*-audit.md' | sed -nE 's#^knowledge/quality/([A-Za-z0-9._-]+)-audit\.md$#\1#p' | head -n1 || true)
          fi
          if [ -z "$TARGET_REPO" ]; then
            echo "Could not derive target repo from task title, description, or committed audit artifact"
            exit 1
          fi

          DEFAULT_BRANCH=$(gh repo view launchapp-dev/brain --json defaultBranchRef -q '.defaultBranchRef.name')
          ARTIFACT_PATH="knowledge/quality/${TARGET_REPO}-audit.md"

          if ! gh api "repos/launchapp-dev/brain/contents/${ARTIFACT_PATH}?ref=${DEFAULT_BRANCH}" >/dev/null 2>&1; then
            echo "Expected audit artifact is missing on ${DEFAULT_BRANCH}: ${ARTIFACT_PATH}"
            if [ -f "$ARTIFACT_PATH" ]; then
              echo "Local worktree copy exists but was not durably published."
            else
              echo "No local worktree copy found either."
            fi
            git status --short -- "$ARTIFACT_PATH" || true
            exit 1
          fi

          echo "Verified published audit artifact on ${DEFAULT_BRANCH}: ${ARTIFACT_PATH}"
      cwd_mode: task_root
      timeout_secs: 60

  package-decisions:
    mode: agent
    agent: decision-packager
    directive: |
      Read all proposed action items. Create a decision package for founders.
      Group by priority, include recommendations. Write to
      knowledge/decisions/pending/<date>-batch.md.
    capabilities:
      mutates_state: true

  founder-review-gate:
    mode: manual
    directive: "Review and approve/reject/defer proposed actions"
    manual:
      instructions: |
        A decision package is ready in knowledge/decisions/pending/.
        For each action item, change "Decision: _pending_" to:
        "Decision: approved", "Decision: rejected", or "Decision: defer".
      approval_note_required: true
      timeout_secs: 604800

  mark-task-on-hold:
    mode: command
    directive: "Mark the current task as on-hold while founder review is pending"
    command:
      program: bash
      args:
        - "-c"
        - |
          BRANCH=$(git branch --show-current)
          TASK_ID=$(printf '%s\n' "$BRANCH" | sed -n 's#^ao/task-\([0-9][0-9]*\)$#TASK-\1#p')
          if [ -z "$TASK_ID" ]; then
            echo "Could not derive task id from branch $BRANCH — skipping status update"
            exit 0
          fi
          PROJECT_ROOT=$(dirname "$(git rev-parse --git-common-dir)")
          ao task status --project-root "$PROJECT_ROOT" --id "$TASK_ID" --status on-hold >/dev/null
          echo "Marked $TASK_ID as on-hold while waiting for founder review"
      cwd_mode: task_root
      timeout_secs: 60

  mark-task-in-progress:
    mode: command
    directive: "Mark the current task as in-progress after founder review resumes"
    command:
      program: bash
      args:
        - "-c"
        - |
          BRANCH=$(git branch --show-current)
          TASK_ID=$(printf '%s\n' "$BRANCH" | sed -n 's#^ao/task-\([0-9][0-9]*\)$#TASK-\1#p')
          if [ -z "$TASK_ID" ]; then
            echo "Could not derive task id from branch $BRANCH — skipping status update"
            exit 0
          fi
          PROJECT_ROOT=$(dirname "$(git rev-parse --git-common-dir)")
          ao task status --project-root "$PROJECT_ROOT" --id "$TASK_ID" --status in-progress >/dev/null
          echo "Marked $TASK_ID as in-progress after founder review"
      cwd_mode: task_root
      timeout_secs: 60

  process-decisions:
    mode: agent
    agent: decision-processor
    directive: |
      Read decision packages in knowledge/decisions/pending/.
      Update action file statuses based on founder decisions.
      Move processed packages to knowledge/decisions/completed/.
    capabilities:
      mutates_state: true

  sync-templates:
    mode: agent
    agent: template-syncer
    directive: |
      Full package sync across all 4 templates:
      1. Pull latest for all 4 repos
      2. Diff shared packages — find the most complete version of each
      3. Copy shared package files to repos that are behind
      4. Create PRs in each target repo
      5. Compare routes for feature parity — create port tasks for gaps
      6. Sync dependency versions across templates
      7. Log to knowledge/sync/template-sync-log.md
    capabilities:
      mutates_state: true

  brain-product-review:
    mode: agent
    agent: brain-product-owner
    directive: |
      Review vision, track phase progress, decompose requirements into tasks,
      check fleet alignment, reprioritize as needed. Log to knowledge/phases/current.md.
    capabilities:
      mutates_state: true

  brain-reconcile:
    mode: agent
    agent: brain-reconciler
    directive: |
      Find tasks marked done without merged PRs. Check requirements
      for unmet acceptance criteria. Find stale knowledge files.
      Create new tasks to address each gap. Max 5 per run.
    capabilities:
      mutates_state: true

  rank-models:
    mode: agent
    agent: model-ranker
    directive: |
      Fetch model rankings from kilo.ai/leaderboard and other sources.
      Write snapshot to knowledge/competitive/model-rankings.md.
      Compare against our model routing. Create tasks if better options exist.
    capabilities:
      mutates_state: true

  brain-pr-review:
    mode: agent
    agent: brain-reviewer
    directive: |
      Review the PR created by this workflow. Check the diff matches
      the task requirements. Merge if good, request changes if not.
      Only mark task done AFTER successful merge.

  brain-pr-sweep:
    mode: agent
    agent: brain-reviewer
    directive: |
      Sweep ALL open PRs in the brain repo. For each:
      - Conflicting → queue rebase-and-retry
      - Changes requested → queue rework
      - Ready for review → check diff vs task requirements and acceptance criteria
      - Merge if good, request changes if not
      - Reconcile done tasks without merged PRs
      Log all actions to knowledge/logs/reviewer.log.
    capabilities:
      mutates_state: true

  po-fleet-scan:
    mode: agent
    agent: brain-product-owner
    directive: |
      Quick fleet scan: check daemon health and queue stats for all repos
      in repos/. Update knowledge/phases/current.md fleet status section.
      If any repo is down, create a manage-fleet task.
    capabilities:
      mutates_state: true

  brain-self-improve:
    mode: agent
    agent: brain-self-improver
    directive: |
      Analyze one area of the brain's operation. Find an improvement.
      Create 1-2 tasks to implement it. Log to knowledge/logs/self-improvement.log.
    capabilities:
      mutates_state: true

  execute-cross-repo:
    mode: agent
    agent: cross-repo-executor
    directive: |
      Read knowledge/actions/ for approved items. For each:
      create AO tasks in target repos or direct PRs via repos/ checkouts.
      Update action status to in-progress. Log to execution-log.md.
    capabilities:
      mutates_state: true

  triage:
    mode: agent
    agent: default
    directive: |
      Perform lightweight triage on this task: read the task description and any
      linked requirements, assess scope and complexity, identify blockers or
      ambiguities, and produce a brief scoping summary so the requirements phase
      has a clear starting point. Do not write code or make file changes.

workflows:
  # === PLANNER (the only scheduled workflow — creates and queues all other work) ===
  - id: conductor
    name: "Conductor"
    description: "Continuous scan-compare-dispatch cycle — the brain's heartbeat"
    phases:
      - conduct

  # === EXTERNAL-ONLY (operate on other repos via gh, no brain commits) ===
  - id: org-issue-triage
    name: "Org Issue Triage"
    description: "Scan all repos for new issues, label, prioritize, create tasks"
    phases:
      - scan-org-issues
      - triage-and-label

  - id: org-pr-review
    name: "Org PR Review"
    description: "Review and merge open PRs across all org repos"
    phases:
      - scan-org-prs

  - id: impact-analysis
    name: "Cross-repo Impact Analysis"
    description: "Identify downstream impacts of shared package changes"
    phases:
      - analyze-impact

  - id: stale-detection
    name: "Stale Work Detection"
    description: "Find abandoned PRs, stale branches, zombie issues"
    phases:
      - detect-stale-work

  - id: security-scan
    name: "Security Scan"
    description: "Check for security vulnerabilities across the org"
    phases:
      - check-security
      - human-gate-security

  - id: doc-audit
    name: "Documentation Audit"
    description: "Audit docs across key repos for completeness"
    phases:
      - audit-docs

  - id: sdk-audit
    name: "SDK Consistency Audit"
    description: "Ensure all SDKs follow the same patterns"
    phases:
      - audit-sdks
      - sdk-consistency-report

  - id: release-coordination
    name: "Release Coordination"
    description: "Track what needs releasing across the org"
    phases:
      - scan-releases
      - human-gate-releases
      - create-release-tasks

  # === BRAIN-WRITING (commit → push → PR → merge, with conflict recovery) ===
  - id: knowledge-update
    name: "Knowledge Base Update"
    description: "Maintain org-wide documentation and knowledge"
    phases:
      - update-knowledge-base
      - push-branch
      - create-pr
      - brain-pr-review

  - id: competitive-research
    name: "Competitive Research"
    description: "Research competitors across all product areas"
    phases:
      - research-competitors
      - push-branch
      - create-pr
      - brain-pr-review

  - id: product-catalog
    name: "Product Catalog"
    description: "Catalog all products, versions, dependencies, and maturity"
    phases:
      - catalog-products
      - push-branch
      - create-pr
      - brain-pr-review

  - id: product-docs
    name: "Product Documentation"
    description: "Write and maintain product documentation"
    phases:
      - write-product-docs
      - push-branch
      - create-pr
      - brain-pr-review

  - id: product-ideas
    name: "Product Ideation"
    description: "Generate product ideas and feature proposals"
    phases:
      - generate-product-ideas
      - push-branch
      - create-pr
      - brain-pr-review

  - id: revenue-analysis
    name: "Revenue Analysis"
    description: "Analyze monetization opportunities and pricing strategies"
    phases:
      - analyze-revenue
      - push-branch
      - create-pr
      - brain-pr-review

  - id: optimize-workflows
    name: "Workflow Optimizer"
    description: "Review and improve the brain's own workflow configuration"
    phases:
      - optimize-workflows
      - push-branch
      - create-pr
      - brain-pr-review

  - id: gtm-strategy
    name: "GTM Strategy"
    description: "Create go-to-market strategies for products"
    phases:
      - create-gtm-strategy
      - push-branch
      - create-pr
      - brain-pr-review

  - id: architecture-diagrams
    name: "Architecture Diagrams"
    description: "Create and maintain Mermaid architectural diagrams for all products"
    phases:
      - diagram-architecture
      - push-branch
      - create-pr
      - brain-pr-review

  - id: manage-fleet
    name: "Fleet Manager"
    description: "Monitor, start, stop, and configure AO daemons across all repos"
    phases:
      - manage-fleet

  - id: provision-repo
    name: "Provision Repo"
    description: "Create new repos or reorganize existing ones"
    phases:
      - provision-repo

  - id: generate-questions
    name: "Generate Questions"
    description: "Scan knowledge base and surface strategic questions the org should answer"
    phases:
      - generate-questions
      - push-branch
      - create-pr
      - brain-pr-review

  - id: extract-actions
    name: "Extract Actions"
    description: "Turn answered questions into concrete org action items"
    phases:
      - extract-actions
      - push-branch
      - create-pr
      - brain-pr-review

  - id: build-tool
    name: "Build Tool"
    description: "Create utility scripts and tools for the AI workforce"
    phases:
      - build-tool
      - push-branch
      - create-pr
      - brain-pr-review

  # === CONFLICT RECOVERY (standalone workflow queued when merge fails) ===
  - id: rebase-and-retry
    name: "Rebase and Retry"
    description: "Rebase a conflicting branch onto master and merge"
    phases:
      - rebase-and-merge

  # === OPERATOR WORKFLOWS (reach into other repos, execute real work) ===
  - id: quality-audit
    name: "Quality Audit"
    description: "Clone a repo, run build/test/lint, report results"
    phases:
      - run-quality-audit
      - push-branch
      - create-pr
      - brain-pr-review
      - verify-quality-audit-published

  - id: decision-pipeline
    name: "Founder Decision Pipeline"
    description: "Package actions for review, wait for approval, process results"
    phases:
      - package-decisions
      - push-branch
      - create-pr
      - brain-pr-review
      - mark-task-on-hold
      - founder-review-gate
      - mark-task-in-progress
      - process-decisions
      - push-branch
      - create-pr
      - brain-pr-review

  - id: model-rankings
    name: "Model Rankings"
    description: "Daily: fetch coding model rankings from kilo.ai and compare against our routing"
    phases:
      - rank-models
      - push-branch
      - create-pr
      - brain-pr-review

  - id: brain-reconcile
    name: "Brain Reconciliation"
    description: "Find incomplete work — done tasks without PRs, unmet requirements, stale knowledge"
    phases:
      - brain-reconcile

  - id: brain-pr-sweep
    name: "Brain PR Sweep"
    description: "Review all open PRs, merge/reject/rebase, reconcile task states"
    phases:
      - brain-pr-sweep

  - id: brain-product-review
    name: "Brain Product Review"
    description: "Strategic org management — vision, fleet health, cross-repo tasks, deployments"
    phases:
      - po-fleet-scan
      - brain-product-review
      - push-branch
      - create-pr
      - brain-pr-review

  - id: brain-self-improve
    name: "Brain Self-Improvement"
    description: "Codex agent that continuously improves brain workflows, prompts, and ops"
    phases:
      - brain-self-improve
      - push-branch
      - create-pr
      - brain-pr-review

  - id: template-sync
    name: "Template Sync"
    description: "Keep all 3 SaaS templates in sync — propagate features and package changes"
    phases:
      - sync-templates
      - push-branch
      - create-pr
      - brain-pr-review

  - id: cross-repo-execute
    name: "Cross-Repo Executor"
    description: "Turn approved actions into real tasks/PRs in target repos"
    phases:
      - execute-cross-repo

  - id: ao.task/quick-fix
    name: "Quick Fix"
    description: "Fast-track workflow for urgent, well-scoped fixes — skips requirements and goes straight to implementation"
    phases:
      - implementation
      - push-branch
      - create-pr
      - auto-merge-pr

  - id: ao.task/triage
    name: "Task Triage"
    description: "Lightweight investigation phase to scope work and surface blockers before full requirements gathering"
    phases:
      - triage

schedules:
  - id: conductor
    cron: "*/20 * * * *"
    workflow_ref: conductor
    enabled: true

  - id: org-issue-triage
    cron: "37 */2 * * *"
    workflow_ref: org-issue-triage
    enabled: true

  - id: generate-questions
    cron: "0 9 * * *"
    workflow_ref: generate-questions
    enabled: true

  - id: architecture-diagrams
    cron: "0 7 * * 4"
    workflow_ref: architecture-diagrams
    enabled: true

  - id: brain-pr-sweep
    cron: "*/10 * * * *"
    workflow_ref: brain-pr-sweep
    enabled: true

  - id: brain-reconcile
    cron: "0 * * * *"
    workflow_ref: brain-reconcile
    enabled: true

  - id: brain-product-review
    cron: "5-59/10 * * * *"
    workflow_ref: brain-product-review
    enabled: true

  - id: brain-self-improve
    cron: "50 */3 * * *"
    workflow_ref: brain-self-improve
    enabled: true

  - id: template-sync
    cron: "22 * * * *"
    workflow_ref: template-sync
    enabled: true

  - id: model-rankings
    cron: "0 10 * * *"
    workflow_ref: model-rankings
    enabled: true

  - id: decision-pipeline
    cron: "0 8 * * 1"
    workflow_ref: decision-pipeline
    enabled: true