oh-my-claudecode

Maintains a registry of 28 specialized agents organized into tiers (architecture, implementation, review, testing) that automatically route tasks based on delegation categories and agent specialization profiles. Uses a hook-driven execution model where pre-processing hooks analyze incoming requests, match them against agent capabilities via metadata, and delegate to the most appropriate tier. Agents can be customized with domain-specific prompts and skill bindings without modifying core orchestration logic.

Implements project-level session isolation using an inbox/outbox pattern where each session maintains separate state files containing mode state, agent decisions, and execution history. State is persisted to disk in JSON schemas specific to each execution mode (Ralph Loop, Autopilot, Ultrawork, Team Orchestration), enabling recovery from interruptions and resumption of multi-step workflows. Session isolation prevents cross-project contamination and allows parallel execution of independent sessions with their own model routing and hook configurations.

Generates structured artifacts (code files, reports, documentation) from agent outputs using post-processing hooks that parse agent responses and format them according to artifact templates. Artifacts are stored in the project directory with metadata (agent, timestamp, mode) for tracking. Artifact generation supports multiple formats (code, markdown, JSON) and can apply transformations (linting, formatting) before writing. Artifacts are indexed in session state, enabling retrieval and versioning.

Manages configuration through settings.json (hook registry, model routing, skill definitions) and CLAUDE.md (project-specific context and constraints). Configuration changes are merged intelligently when updating oh-my-claudecode, preserving user customizations while incorporating new defaults. Settings are validated against a schema before application, preventing invalid configurations. Configuration is scoped per project, enabling different teams to use different settings. Configuration changes trigger hook reloads without requiring plugin restart.

Provides automated installation via setup wizard and auto-update mechanism that checks for new versions and applies updates with rollback capability. Installation guards prevent incompatible versions from being installed. Plugin cache is managed to prevent stale code from being loaded. Version reconciliation ensures that installed components match the expected versions. Update process preserves user configurations and custom hooks through the merge strategy. Installation diagnostics help troubleshoot setup issues.

Provides a CLI interface with commands for launching execution modes, querying analytics, managing configurations, and running diagnostics. CLI commands can be invoked from external scripts or CI/CD pipelines, enabling integration with existing workflows. Launch system supports parameterized execution (mode, agents, skills, hooks) via command-line arguments. CLI output is structured (JSON, CSV) for easy parsing by external tools. Commands are authenticated and authorized based on project permissions.

Provides a notification system that alerts users to execution events (task completion, failures, escalations) via configurable delivery channels (in-app, email, Slack, webhooks). Notifications are triggered by post-processing hooks and can be customized per project. Notification templates support variable substitution (agent name, task status, error details). Notification history is tracked in session state for audit purposes. Notification delivery is asynchronous and includes retry logic for failed deliveries.

Implements a multi-stage hook system with pre-processing hooks (analyze requests, validate context), orchestration hooks (route to agents, manage delegation), persistent mode hooks (maintain state across steps), quality control hooks (validate outputs), and post-processing hooks (recovery, artifact generation). Hooks are executed in a defined sequence and can modify request/response data, trigger side effects, or abort execution. Hook configuration is stored in settings.json and can be customized per project, enabling teams to inject custom logic (logging, validation, integration) without modifying core orchestration code.

Implements CCG Tri-Model Orchestration that routes requests to Claude Haiku (fast, cost-effective), Sonnet (balanced), or Opus (high-capability) based on task complexity, token budget, and model fallback policies. Routing decisions are made by orchestration hooks that analyze request characteristics (code size, task type, required reasoning depth) and select the optimal model tier. If a request fails on a lower-tier model, the system automatically escalates to the next tier with exponential backoff. Model selection is persisted in session state to enable consistent routing across multi-step workflows.

Provides four execution modes (Ralph Loop, Autopilot, Ultrawork, Team Orchestration) each with distinct workflow patterns, state schemas, and hook configurations. Ralph Loop implements iterative refinement with human feedback loops; Autopilot runs fully autonomous multi-step workflows; Ultrawork enables high-intensity parallel execution; Team Orchestration distributes tasks across worker agents with task claiming and communication. Each mode persists its state in a mode-specific JSON schema, enabling resumption and audit trails. Mode selection is determined by user intent or slash commands, and mode state is isolated per session.

Implements a team coordination layer where a coordinator agent distributes tasks to worker agents via a task claiming mechanism. Workers communicate status updates through a message queue, and the coordinator monitors progress and reassigns tasks on failure. Task distribution uses a load-balancing strategy that considers worker availability and specialization. Worker communication is asynchronous and persisted in session state, enabling recovery if workers or the coordinator fail. Security and permissions are enforced at the task level, preventing workers from accessing unauthorized resources.

Provides a modular skills library (33+ skills) where each skill is a reusable workflow component with a SKILL.md definition, invocation pattern, and hook bindings. Skills are invoked through magic keywords or slash commands and can be composed into larger workflows. Core skills include autonomous execution, persistent mode management, and team coordination. Skills are registered in a skill registry and can be customized per project by overriding skill definitions or adding new skills. Skill invocation is tracked in session state, enabling audit trails and skill reuse analysis.

Provides a command interface using magic keywords (e.g., @agent-name, #skill-name) and slash commands (e.g., /autopilot, /team-mode) that trigger specific agents, skills, or execution modes. Commands are parsed by pre-processing hooks and mapped to agent delegations or mode transitions. Command context includes the current project state, selected code, and execution history. Commands can accept parameters and options, enabling fine-grained control over execution. Command history is tracked in session state for audit and replay purposes.

Provides a heads-up display (HUD) statusline that shows real-time execution metrics including current agent, execution mode, token usage, session statistics, and progress indicators. HUD data is updated via a data pipeline that collects metrics from hooks and execution state. Analytics are tracked per session and aggregated across sessions for usage reporting. The HUD integrates with a Usage API that provides historical analytics and benchmarking data. Token tracking is granular (per-agent, per-model, per-mode) enabling cost analysis and optimization.

Enables long-running tasks to execute asynchronously in the background while the user continues working. Background jobs are registered with a job ID and polling mechanism that checks for completion. Job state is persisted in session state, enabling recovery if the plugin crashes. Jobs can be monitored via HUD or CLI commands. Job results are stored in an outbox pattern, allowing the user to retrieve results when ready. Multiple jobs can run in parallel, with resource limits enforced to prevent system overload.