mirror of
https://github.com/azaion/detections.git
synced 2026-04-23 06:36:31 +00:00
Oleksandr Bezdieniezhnykh
d28b9584f2
- Replace all Jira-specific references with generic tracker/work-item terminology (TRACKER-ID, work item epics); delete project-management.mdc and mcp.json.example - Restructure refactor skill: extract 8 phases (00–07) and templates into separate files; add guided mode for pre-built change lists - Add Step 3 "Code Testability Revision" to existing-code workflow (renumber steps 3–12 → 3–13) - Simplify autopilot state file to minimal current-step pointer - Strengthen coding rules: AAA test comments per language, test failures as blocking gates, dependency install policy - Add Docker Suitability Assessment to test-spec and test-run skills (local vs Docker execution) - Narrow human-attention sound rule to human-input-needed only - Add AskQuestion fallback to plain text across skills - Rename FINAL_implementation_report to implementation_report_* - Simplify cursor-meta (remove _docs numbering table, quality thresholds) - Make techstackrule alwaysApply, add alwaysApply:false to openapi
124 lines
6.3 KiB
Markdown
124 lines
6.3 KiB
Markdown
---
|
|
name: autopilot
|
|
description: |
|
|
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"
|
|
category: meta
|
|
tags: [orchestrator, workflow, auto-chain, state-machine, meta-skill]
|
|
disable-model-invocation: 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, tracker 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.md` and 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:
|
|
|
|
1. If workspace has **no source code files** → **greenfield flow**
|
|
2. If workspace has source code files **and** `_docs/` does not exist → **existing-code flow**
|
|
3. If workspace has source code files **and** `_docs/` exists **and** `_docs/_autopilot_state.md` does not exist → **existing-code flow**
|
|
4. If workspace has source code files **and** `_docs/_autopilot_state.md` exists → read the `flow` field from the state file and use that 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:
|
|
|
|
1. Update state file: set `step` to the autopilot step number, status to `in_progress`, set `sub_step` to the sub-skill's current internal step/phase, reset `retry_count: 0`
|
|
2. Announce: "Starting [Skill Name]..."
|
|
3. Read the skill file: `.cursor/skills/[name]/SKILL.md`
|
|
4. Execute the skill's workflow exactly as written, including all BLOCKING gates, self-verification checklists, save actions, and escalation rules. Update `sub_step` in state each time the sub-skill advances.
|
|
5. If the skill **fails**: follow the Skill Failure Retry Protocol in `protocols.md` — increment `retry_count`, auto-retry up to 3 times, then escalate.
|
|
6. When complete (success): reset `retry_count: 0`, update state file to the next step with `status: 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`.
|
|
|
|
```markdown
|
|
# 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 `/research` directly
|
|
- User wants only planning → use `/plan` directly
|
|
- User wants to document an existing codebase → use `/document` directly
|
|
- 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.
|