Skip to main content

autopilot

Autonomous orchestrator that takes a goal, discovers available tools and skills, decomposes into phases, maps phases to skills, executes, and monitors until the project is done. Use when the user wants full autonomous execution of a complex goal.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
mahmoud20138/Autopilot
آخر نشاط في المصدر
١١ يونيو ٢٠٢٦ في ١٨:٤٤
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٣
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
2 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
autopilot
description
Autonomous orchestrator that takes a goal, discovers available tools and skills, decomposes into phases, maps phases to skills, executes, and monitors until the project is done. Use when the user wants full autonomous execution of a complex goal.
argument-hint
The goal to accomplish autonomously
# Autopilot Agent Mode Fully autonomous orchestrator. Takes a user's goal, runs it to completion without human intervention. **Announce at start:** "I'm using the Autopilot skill to autonomously accomplish: {user_goal}" **Core principle:** Orchestrate existing skills and tools — never implement phases from scratch when a skill already covers the task. Each phase delegates to the most appropriate skill or set of tools. **Portability:** Works with Claude Code, OpenClaude, GitHub Copilot CLI, Cursor, and Kilo. Dynamically discovers available skills, MCP servers, integrations, and CLI tools — no hardcoded assumptions. ## Pipeline ``` Input → Memory Check → Discovery → Online Browser Search → Analysis → Phase Detection → Skill/Tool Mapping → Session Plan → Execution → Verification → Completion Report ``` ## Stop Conditions **Stop only when:** - All phases completed successfully - Final verification passes (typecheck, build, runtime check, no blockers) - Project goal achieved **Never stop for:** - "Should I continue?" prompts between phases - Progress summaries mid-execution - Asking permission to proceed to the next phase **Pause only if:** - Hard blocker that no skill or tool can resolve (missing external credential, genuinely ambiguous requirement with no safe assumption) - Report the blocker precisely and wait for user input - Resume from the current phase once the blocker is resolved --- ## Step 0 — Memory Check (Always First) Check if `.agents/memory/MEMORY.md` exists. If it does, read it and open any topic files relevant to the current goal. Apply documented constraints and past decisions immediately. If a past decision conflicts with what you observe now, trust the code and update the memory after the task. If the file doesn't exist, create it with a minimal header and a note that this is the first autopilot session for this project: ```markdown # Autopilot Memory First session for this project. No past decisions recorded. ``` --- ## Step 1 — Discovery Build an inventory of everything available on this system. Run discovery once per autopilot session. ### 1a. Scan Skills Sources Skills can be loaded at runtime via the `skill` tool, which matches against the `available_skills` list in the system prompt. Discover skills from ALL sources: **Source 1 — System Prompt `available_skills`:** Scan the system context for the `<available_skills>` block. Each skill entry has a `name` and `description`. These are loadable via the `skill` tool by name. Add them to the catalog with source `"system"`. **Source 2 — Skills Directory:** Check multiple known skills directories: | CLI | Skills Directory | |-----|----------------| | Claude Code | `~/.claude/skills/` | | OpenClaude | `~/.openclaude/skills/` | | GitHub Copilot | `~/.config/github-copilot/skills/` | | Cursor | `~/.cursor/skills/` | | Kilo | `~/.config/kilo/skills/` | For each directory that exists, iterate over subdirectories looking for `SKILL.md` files. Read the YAML frontmatter to extract: - `name:` field - `description:` field **Source 3 — Online Marketplace & Browser Search (Proactive):** Proactively search online registries, GitHub, and marketplaces for skills and plugins matching the goal — run during discovery, NOT deferred. Use these methods in order: **a. Curated reference sources (check FIRST):** Fetch these known, maintained registries for matching skills/plugins/MCP servers: | Source | URL | What to search for | |--------|-----|-------------------| | Awesome MCP Servers | `https://github.com/punkpeye/awesome-mcp-servers` | MCP servers matching the goal domain | | Agents Collection | `https://github.com/wshobson/agents` | Agent skills matching the phase needs | | Claude Code Plugins+Skills | `https://github.com/jeremylongshore/claude-code-plugins-plus-skills` | Claude Code plugins and skills for the goal | | CC Marketplace | `https://github.com/ananddtyagi/cc-marketplace` | Marketplace skills and plugins | | Build With Claude | `https://buildwithclaude.com/plugins` | Claude plugins for the goal domain | Use `webfetch` on each URL, then search the page content for entries matching the goal keywords. For any matching entry, extract the GitHub URL, skill name, description, and install method. **b.** `find-skills` skill — If in `available_skills`, load it to search across known marketplaces. **c.** `npx skills search <topic>` — If the `opencode` or `skills` CLI is available. **d.** Web Search — Use `websearch` as fallback to search for: - GitHub topics: `topic:opencode-skill`, `topic:claude-code-skill`, `topic:claude-code-plugin` - Direct search: `"opencode skill" <goal-keyword>`, `"claude code skill" <goal-keyword>` - Plugin ecosystems: `"mcp server" <domain>`, `"plugin" <goal-keyword>` **e.** Website Fetch — Use `webfetch` to crawl skill registry pages and marketplace listings. Fetch raw SKILL.md URLs from GitHub repos when found. **f.** Temp skill loader — If a skill is found remotely, use the `temp-skill` skill (when available) to fetch and load it without permanent installation. If temp-skill is not available, use `webfetch` to read the raw SKILL.md and follow its instructions directly. Marketplace-found skills go in the catalog with source `"marketplace"`, a `url` field, and a `methods` field documenting how it was found (for future reference). Build a catalog: `[{"name": "skill-name", "description": "what it does", "path": "path/to/skill", "url": "url", "source": "system|filesystem|marketplace"}, ...]` ### 1b. Scan MCP Servers Check what MCP tools are available by looking at tool names in the system context. Also scan MCP configuration files: **Pattern matching** — Look for known MCP tool prefixes: | Prefix | Server | Use Case | |--------|--------|----------| | `codegraph_*` | CodeGraph | Codebase understanding, symbol lookup, impact analysis | | `mcp__context7__*` | Context7 | Library documentation lookup | | `mcp__plugin_playwright_*` | Playwright | E2E browser testing | | `mcp__fal_*` | fal.ai | Image/video/audio generation | | `mcp__exa_*` | Exa | Web search and research | | `mcp__github_*` | GitHub | PR, issues, repo management | | `mcp__*` | Any MCP | General-purpose server tools | **Config file scan** — Check common MCP config locations for installed servers: - `~/.config/opencode/mcp.json` or `opencode.json` - `~/.codex/mcp.json` - `.mcp.json` in project root - `claude_desktop_config.json` For each discovered MCP server, note its capabilities and add to the catalog as `{"type": "mcp", "name": "server-name", "tools": ["tool1", "tool2"]}`. When Codegraph is available, use it BEFORE writing or editing code: - `codegraph_search` — Find symbols by name (faster than grep) - `codegraph_context` — Get comprehensive context for a task (composes search + callers + callees) - `codegraph_callers` / `codegraph_callees` — Understand dependencies - `codegraph_impact` — Analyze blast radius before changing a symbol - `codegraph_explore` — Deep dive into unfamiliar modules ### 1c. Scan CLI Tools Check PATH for common tools relevant to the project: ```bash # macOS / Linux for cmd in git node npm pnpm python pip pytest cargo go java mvn gradle docker; do command -v $cmd && echo "$cmd: available" done ``` ```powershell # Windows $tools = 'git','node','npm','pnpm','python','pip','pytest','cargo','go','java','mvn','gradle','docker' foreach ($cmd in $tools) { if (Get-Command $cmd -ErrorAction SilentlyContinue) { Write-Output "$cmd: available" } } ``` ### 1d. Scan Project Context Detect language/framework indicators and existing artifacts: ```bash git status --short git log --oneline -5 ``` Check for project indicators: - `package.json` → Node.js project - `requirements.txt` or `pyproject.toml` → Python project - `Cargo.toml` → Rust project - `go.mod` → Go project - `pom.xml` → Java/Maven project - `build.gradle` → Java/Gradle project - `.github/workflows/` directory → GitHub Actions CI ### 1e. Scan Environment Variables Check what env vars are set and what may be missing. Do not display actual values — only list key names and whether they are set. ### Discovery Output Present the inventory concisely: ``` Discovery complete: Skills: N total (N system / N filesystem / N online) — list names MCP: N servers (list names and tool counts) CLI: list available tools Project: language, framework, tooling detected Env vars: list set keys (not values), list missing critical ones Git: current branch, recent commits Online: searched (N skills found in marketplaces/registries) ``` Source rules for loading: | Source | Load Method | |--------|------------| | `system` | Use `skill name: <skill-name>` | | `filesystem` | Read `SKILL.md` from `path` | | `marketplace` | Use `temp-skill` or `webfetch` the SKILL.md from `url`; fallback to `websearch` for instructions | Online-found skills are already in the catalog ready for Step 4 mapping. --- ### 1f. Online Browser Search (Proactive) After scanning local tools but before analysis, run a proactive online search for better skills and plugins matching the user's goal. This ensures you don't miss a purpose-built skill that a marketplace or registry offers. **Use these tools in priority order:** **1. Curated reference sources (fetch FIRST, in parallel):** Use `webfetch` on each of these known registries and extract entries matching the goal: | Source | URL | What to extract | |--------|-----|----------------| | Awesome MCP Servers | `https://github.com/punkpeye/awesome-mcp-servers` | MCP servers for the goal domain | | Agents Collection | `https://github.com/wshobson/agents` | Agent skills for phase needs | | Claude Code Plugins+Skills | `https://github.com/jeremylongshore/claude-code-plugins-plus-skills` | Claude Code plugins and skills | | CC Marketplace | `https://github.com/ananddtyagi/cc-marketplace` | Marketplace skills and plugins | | Build With Claude | `https://buildwithclaude.com/plugins` | Claude plugins for the goal domain | For each matching entry, extract: name, description, GitHub URL, author, install method. **2. `websearch`** — Broaden the search with targeted queries: ``` Search queries (run in parallel): - "opencode skill <goal-keyword>" - "claude code skill <goal-keyword>" - "mcp server <domain/task>" - "plugin for <goal-keyword>" - "npx <package> <goal-keyword>" - site:github.com/topics/opencode-skill - site:github.com/topics/claude-code-skill ``` **3. `webfetch`** — Fetch raw SKILL.md files from discovered GitHub repos, registry pages, and marketplace listings to read their capabilities. **4. `find-skills` skill** — If in `available_skills`, load and use it to search across known marketplaces. **5. `npx skills search`** — If the `skills` CLI is detected on the system. **For each skill/plugin found online:** - Extract: name, description, source URL, author - Estimate relevance to the user's goal (high / medium / low) - Add to catalog: `source: "marketplace", url: <source>, relevance: high|medium|low` - If the skill has an install command, also record the install method **Browser search depth:** Search up to 3 rounds if earlier results reveal new keywords. Stop when searches converge (no new skills found). Budget: ~10 websearch calls max. **Output after search:** ``` Online search complete: N new skills discovered (N high relevance) N new plugins/MCP servers discovered Sources checked: Awesome MCP Servers, Agents, Claude Code Plugins+Skills, CC Marketplace, Build With Claude, GitHub topics, web Top finds: {skill-1}, {skill-2}, {skill-3} (high relevance) ``` --- ## Step 2 — Analysis Parse the goal to understand what needs to be done before decomposing phases. 1. **Parse the goal** — What is the user asking for exactly? 2. **Identify task type** — New feature, bug fix, refactor, full project build, research, maintenance? 3. **Identify scope** — Single file, multi-file feature, multi-artifact project? 4. **Identify constraints** — Existing tech stack, env vars needed, external credentials required? 5. **Identify parallelism opportunities** — Which phases are independent and could run concurrently? Output: ``` Goal: {restated in one sentence} Type: {task type} Scope: {scope assessment} Constraints: {identified constraints or "none"} Parallelism: {phases that can run in parallel, if any} ``` --- ## Step 3 — Phase Detection Decompose the goal into the **minimal viable set** of logical phases. Think from first principles — no rigid templates. YAGNI: don't over-decompose. For each phase, determine: - **Name** — short descriptive label (e.g. "Set up DB schema", "Implement auth routes") - **Goal** — what "done" looks like (verifiable output) - **Complexity** — simple / medium / complex - **Dependencies** — which prior phases must complete first (drives sequencing and parallelism) - **Criticality** — blocking (must pass) or non-blocking (can skip with warning) **Dynamic sub-phasing:** If a phase is Complex, break it into verifiable sub-tasks before executing it. **Parallelism rule:** If two phases share no dependency, they are candidates for parallel execution. Plan parallel branches explicitly. Phase list format: ``` Phase 1: {name} — {goal} [complexity: simple] [deps: none] [critical] Phase 2: {name} — {goal} [complexity: medium] [deps: Phase 1] [critical] Phase 3: {name} — {goal} [complexity: simple] [deps: Phase 1] [non-blocking] Phase 3+4 (parallel): {name-A} and {name-B} — independent, can run concurrently ``` ### Example Decompositions **Full project: "Build a REST API with auth and tests"** ``` Phase 1: Plan & Design → Goal: implementation plan exists Phase 2: Implement Core → Goal: API endpoints working Phase 3: Add Auth → Goal: JWT auth working Phase 4: Write Tests → Goal: tests passing Phase 5: Review & Verify → Goal: code reviewed, verified Phase 6: Ship → Goal: merged/deployed ``` **Bug fix: "Fix the login timeout error"** ``` Phase 1: Diagnose → Goal: root cause identified Phase 2: Fix → Goal: bug fixed Phase 3: Verify → Goal: fix verified, tests pass ``` **Small task: "Add a health check endpoint"** ``` Phase 1: Implement → Goal: endpoint working Phase 2: Test → Goal: test passing ``` --- ## Step 4 — Skill/Tool Mapping For each phase, select the best available skill or tool from the discovered inventory. Decision order: 1. **Installed skill match** — Does a skill from the catalog (system or filesystem) cover this phase? If so, note the skill name for use with the `skill` tool.
عرض على GitHub
ملف SKILL.md هذا كبير جدا، لذلك يعرض SkillsMP القسم الاول فقط هنا. عرض على GitHub