* fix: config discovery, activity detection, and metadata port storage - findConfigFile() checks AO_CONFIG_PATH env var (resolved to absolute path) - loadConfig() delegates to findConfigFile() for consistent validation - Pure Node.js readLastJsonlEntry (no external tail binary), safe for multi-byte UTF-8 at chunk boundaries - Added "ready" activity state to agent plugins - Store dashboardPort, terminalWsPort, directTerminalWsPort in session metadata so ao stop targets the correct processes - Zod schema port default aligned with TypeScript interface Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: dashboard config discovery + CLI service layer refactoring - Config discovery via AO_CONFIG_PATH env var - Auto port detection with PortManager - Activity detection with ready state, pure Node.js readLastLine - 5 CLI services: ConfigService, PortManager, DashboardManager, MetadataService, ProcessManager - Store all service ports in metadata for ao stop - Set NEXT_PUBLIC_ env vars for frontend terminal components - Multi-byte UTF-8 safe readLastJsonlEntry - Tests for all new services and utils Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: address bugbot review comments (port fallback + systemPrompt) 1. Align port fallback to 3000 everywhere (matching Zod schema default): - start.ts: config.port ?? 3000 - dashboard.ts: config.port ?? 3000 - types.ts JSDoc: "defaults to 3000" - orchestrator-prompt.ts: already correct at 3000 2. Add --append-system-prompt to Claude Code plugin's getLaunchCommand so orchestrator context is actually passed to the Claude agent. Previously systemPrompt was generated but silently dropped. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: remove dead ConfigService mock from status test The vi.mock for ConfigService.js referenced a deleted module. Config mocking is already handled by the @composio/ao-core mock. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: extract shared buildDashboardEnv to eliminate duplication Dashboard env construction (AO_CONFIG_PATH, PORT, NEXT_PUBLIC_*) was duplicated between start.ts and dashboard.ts. Extracted into buildDashboardEnv() in web-dir.ts (already shared by both commands). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| README.md | ||
| auto-merge.yaml | ||
| codex-integration.yaml | ||
| linear-team.yaml | ||
| multi-project.yaml | ||
| simple-github.yaml | ||
README.md
Agent Orchestrator Config Examples
This directory contains example configurations for common use cases.
Quick Start
Copy an example and customize:
cp examples/simple-github.yaml agent-orchestrator.yaml
nano agent-orchestrator.yaml # edit as needed
ao spawn my-app ISSUE-123
Examples
simple-github.yaml
Minimal setup with GitHub Issues
Perfect for getting started. Just specify your repo and you're ready to spawn agents.
Use this if:
- You're working on a single GitHub repository
- You want to use GitHub Issues for task tracking
- You want the simplest possible setup
linear-team.yaml
Linear integration
Integrates with Linear for issue tracking. Requires LINEAR_API_KEY environment variable.
Use this if:
- Your team uses Linear for project management
- You want agents to update Linear ticket status
- You need custom agent rules per project
multi-project.yaml
Multiple repos with different trackers
Shows how to manage multiple projects with different trackers and notification routing.
Use this if:
- You're managing multiple repositories
- Different projects use different trackers (GitHub Issues vs Linear)
- You want Slack notifications in addition to desktop
- You need different rules per project
auto-merge.yaml
Aggressive automation with auto-merge
Automatically merges approved PRs with passing CI. Auto-retries CI failures and review comments.
Use this if:
- You trust your agents and CI pipeline
- You want maximum automation
- You want agents to handle routine failures autonomously
- You want escalation only when agents get stuck
codex-integration.yaml
Using Codex instead of Claude Code
Shows how to use a different AI agent (Codex) instead of the default Claude Code.
Use this if:
- You prefer GPT-4/Codex over Claude
- You need agent-specific configuration
- You're evaluating different AI coding assistants
Configuration Tips
- Start simple - Use
simple-github.yamlas a starting point - Add complexity incrementally - Enable features as you need them
- Test with one project first - Get comfortable before adding multiple projects
- Review defaults - Most sensible defaults are already configured
- Use environment variables - Store API keys in env vars, not config files
Environment Variables
These environment variables are commonly used:
# Linear integration
export LINEAR_API_KEY="lin_api_..."
# Slack notifications
export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..."
# GitHub (usually set by gh CLI)
# export GITHUB_TOKEN="ghp_..."
Add these to your shell profile (~/.zshrc or ~/.bashrc) to persist them.
Next Steps
After copying an example:
- Edit the config - Update repo paths, team IDs, etc.
- Validate - Run
ao startto check for config errors - Spawn an agent - Try
ao spawn project-id ISSUE-123 - Monitor - Use
ao statusor open the dashboard at http://localhost:3000
See SETUP.md for detailed configuration reference and troubleshooting.