home / skills / yeachan-heo / oh-my-claudecode / ultrapilot

ultrapilot skill

/skills/ultrapilot

This skill accelerates complex, multi-module tasks by orchestrating parallel subtasks with exclusive file ownership to unlock up to 5x speed.

npx playbooks add skill yeachan-heo/oh-my-claudecode --skill ultrapilot

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
467 B
---
name: ultrapilot
description: "[DEPRECATED] Use /autopilot or /team instead"
deprecated: true
deprecationMessage: "/ultrapilot has been removed in #1131. Use /autopilot or /team instead."
---

# Ultrapilot (Deprecated)

This mode has been deprecated and removed in issue #1131 (pipeline unification).

Use one of these alternatives instead:
- `/autopilot` - Full autonomous execution from idea to working code
- `/team` - N coordinated agents on shared task list

Overview

This skill runs a parallel autopilot that spawns multiple workers and partitions file ownership to speed up large code tasks. It decomposes a request into independent subtasks, assigns exclusive file sets to workers, executes them concurrently, then integrates and validates the combined result. The coordinator handles shared files and conflict resolution with configurable policies.

How this skill works

Ultrapilot first analyzes whether a task is parallelizable and performs AI-powered decomposition into subtasks with clear file boundaries. It writes an ownership map so each worker can only change its assigned files, spawns up to the configured number of parallel workers, collects their outputs, applies sequential integration for shared files, and runs full-system validation. State, progress, and ownership maps are persisted so runs can be cancelled and resumed.

When to use it

  • Large multi-component features (frontend, backend, DB, docs) where modules are separable
  • Wide refactors across service boundaries with minimal file overlap
  • Generating parallel test suites or test files across modules
  • Multi-service or microservice changes that can be split into independent workers
  • When you need faster throughput than a sequential autopilot for clearly partitionable work

Best practices

  • Design clear module and directory boundaries before running ultrapilot
  • Minimize shared state and configuration changes to reduce integration friction
  • Review the decomposition result and sharedFiles list before execution
  • Enable verbose progress for long runs and monitor the progress JSON
  • Use coordinator-handles policy unless you prefer manual merging on conflict

Example use cases

  • Build a full-stack todo app: spawn workers for frontend, backend, DB, tests, docs
  • Refactor services to dependency injection: assign each service to a separate worker
  • Generate tests for all untested modules in parallel across API, UI, DB, utilities
  • Parallelize a multi-repo or multi-package migration with ownership per package
  • Speed up large feature additions that touch distinct code areas

FAQ

What if the task is not parallelizable?

Ultrapilot detects non-parallelizable tasks and can automatically fall back to sequential autopilot to avoid unsafe parallel edits.

How are conflicts handled when two workers touch the same file?

Default policy is coordinator-handles: the coordinator will attempt automatic merges and surface complex conflicts for human review. An abort-on-conflict option cancels the run instead.