- Modified `.gitignore` to reflect the new path for test results. - Updated `docker-compose.test.yml` to mount the correct test results directory. - Adjusted `Dockerfile.test` to set the `PYTHONPATH` and ensure test results are saved in the updated location. - Added `boto3` and `netron` to `requirements-test.txt` to support new functionalities. - Updated `pytest.ini` to include the new `pythonpath` for test discovery. These changes streamline the testing process and ensure compatibility with the updated directory structure.
6.3 KiB
name, description, category, tags, disable-model-invocation
| name | description | category | tags | disable-model-invocation | |||||
|---|---|---|---|---|---|---|---|---|---|
| autopilot | Auto-chaining orchestrator that drives the full BUILD-SHIP workflow from problem gathering through deployment. Detects current project state from _docs/ folder, resumes from where it left off, and flows through problem → research → plan → decompose → implement → deploy without manual skill invocation. Maximizes work per conversation by auto-transitioning between skills. Trigger phrases: - "autopilot", "auto", "start", "continue" - "what's next", "where am I", "project status" | meta |
|
true |
Autopilot Orchestrator
Auto-chaining execution engine that drives the full BUILD → SHIP workflow. Detects project state from _docs/, resumes from where work stopped, and flows through skills automatically. The user invokes /autopilot once — the engine handles sequencing, transitions, and re-entry.
File Index
| File | Purpose |
|---|---|
flows/greenfield.md |
Detection rules, step table, and auto-chain rules for new projects |
flows/existing-code.md |
Detection rules, step table, and auto-chain rules for existing codebases |
state.md |
State file format, rules, re-entry protocol, session boundaries |
protocols.md |
User interaction, Jira MCP auth, choice format, error handling, status summary |
On every invocation: read all four files above before executing any logic.
Core Principles
- Auto-chain: when a skill completes, immediately start the next one — no pause between skills
- Only pause at decision points: BLOCKING gates inside sub-skills are the natural pause points; do not add artificial stops between steps
- State from disk: current step is persisted to
_docs/_autopilot_state.mdand cross-checked against_docs/folder structure - Re-entry: on every invocation, read the state file and cross-check against
_docs/folders before continuing - Delegate, don't duplicate: read and execute each sub-skill's SKILL.md; never inline their logic here
- Sound on pause: follow
.cursor/rules/human-attention-sound.mdc— play a notification sound before every pause that requires human input (AskQuestion tool preferred for structured choices; fall back to plain text if unavailable) - Minimize interruptions: only ask the user when the decision genuinely cannot be resolved automatically
- Single project per workspace: all
_docs/paths are relative to workspace root; for monorepos, each service needs its own Cursor workspace
Flow Resolution
Determine which flow to use:
- If workspace has source code files and
_docs/does not exist → existing-code flow (Pre-Step detection) - If
_docs/_autopilot_state.mdexists andstep >= 2(i.e. Document already ran) → existing-code flow - If
_docs/_autopilot_state.mdexists andstep: doneAND workspace contains source code → existing-code flow (completed project re-entry — loops to New Task) - Otherwise → greenfield flow
After selecting the flow, apply its detection rules (first match wins) to determine the current step.
Execution Loop
Every invocation follows this sequence:
1. Read _docs/_autopilot_state.md (if exists)
2. Read all File Index files above
3. Cross-check state file against _docs/ folder structure (rules in state.md)
4. Resolve flow (see Flow Resolution above)
5. Resolve current step (detection rules from the active flow file)
6. Present Status Summary (template in active flow file)
7. Execute:
a. Delegate to current skill (see Skill Delegation below)
b. If skill returns FAILED → apply Skill Failure Retry Protocol (see protocols.md):
- Auto-retry the same skill (failure may be caused by missing user input or environment issue)
- If 3 consecutive auto-retries fail → set status: failed, warn user, stop auto-retry
c. When skill completes successfully → reset retry counter, update state file (rules in state.md)
d. Re-detect next step from the active flow's detection rules
e. If next skill is ready → auto-chain (go to 7a with next skill)
f. If session boundary reached → update state, suggest new conversation (rules in state.md)
g. If all steps done → update state → report completion
Skill Delegation
For each step, the delegation pattern is:
- Update state file: set
stepto the autopilot step number, status toin_progress, setsub_stepto the sub-skill's current internal step/phase, resetretry_count: 0 - Announce: "Starting [Skill Name]..."
- Read the skill file:
.cursor/skills/[name]/SKILL.md - Execute the skill's workflow exactly as written, including all BLOCKING gates, self-verification checklists, save actions, and escalation rules. Update
sub_stepin state each time the sub-skill advances. - If the skill fails: follow the Skill Failure Retry Protocol in
protocols.md— incrementretry_count, auto-retry up to 3 times, then escalate. - When complete (success): reset
retry_count: 0, update state file to the next step withstatus: not_started, return to auto-chain rules (from active flow file)
Do NOT modify, skip, or abbreviate any part of the sub-skill's workflow. The autopilot is a sequencer, not an optimizer.
State File Template
The state file (_docs/_autopilot_state.md) is a minimal pointer — only the current step. Full format rules are in state.md.
# Autopilot State
## Current Step
flow: [greenfield | existing-code]
step: [number or "done"]
name: [step name]
status: [not_started / in_progress / completed / skipped / failed]
sub_step: [0 or N — sub-skill phase name]
retry_count: [0-3]
Trigger Conditions
This skill activates when the user wants to:
- Start a new project from scratch
- Continue an in-progress project
- Check project status
- Let the AI guide them through the full workflow
Keywords: "autopilot", "auto", "start", "continue", "what's next", "where am I", "project status"
Differentiation:
- User wants only research → use
/researchdirectly - User wants only planning → use
/plandirectly - User wants to document an existing codebase → use
/documentdirectly - User wants the full guided workflow → use
/autopilot
Flow Reference
See flows/greenfield.md and flows/existing-code.md for step tables, detection rules, auto-chain rules, and status summary templates.