# Autopilot > Autonomously pick up a Jira issue and complete it end-to-end — plan, implement, test, verify, archive, commit, push, and confirm CI passes. Use when the user says "autopilot", "pick up the next ticket and finish it", "autonomous mode", or otherwise wants the full development cycle run without intermediate confirmations. Only pauses at the very start to confirm the issue selection. - Skill: `avantmedialtd/autopilot` (Agent Skill) - Install (CLI): `npx skillmds@latest add avantmedialtd/autopilot` - Raw SKILL.md: https://api.skillmd.com/api/skills/avantmedialtd/autopilot/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: avantmedialtd (https://skillmd.com/u/avantmedialtd) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/avantmedialtd/autopilot --- # Autopilot Run the full development cycle on a Jira issue without intermediate confirmations: pick up, plan, implement, test, verify, archive, commit, push, and check CI. ## When to use - The user wants an entire issue handled end-to-end without micromanaging each phase. - The user explicitly invokes `/autopilot` or asks for "autonomous" / "hands-off" work. - The task is well-scoped enough that reasonable defaults at each decision point are acceptable. Examples: - "autopilot" — takes the topmost backlog issue and runs the full cycle. - "autopilot PROJ-123" — runs the full cycle on a specific issue. ## Steps ## Phase 1: Pick Up Issue 0. **If no issue-key is provided**, fetch the topmost issue from the board: 1. Detect project key by running `af jira projects --json` - If single project: use it - If multiple projects: ask the user to choose 2. Fetch the topmost backlog issue using: ```bash af jira search "project = AND status = 'Selected for Development' ORDER BY Rank ASC" --limit 1 --json ``` 3. Display the issue summary and proceed immediately 4. If no backlog issues found: inform the user the Selected for Development column is empty and **STOP** 1. Fetch the issue details using `af jira get `. 2. Assign the issue to yourself using `af jira assign --to "$ATLASSIAN_EMAIL"`. `af` authenticates as the account in `ATLASSIAN_EMAIL` (legacy: `JIRA_EMAIL`), so that is "yourself" — do not derive an assignee from the issue's reporter field. 3. Transition the issue to "In Progress" using `af jira transition --to "In Progress"`. If this fails, run `af jira transitions ` to find the correct status name. 4. Derive a `change-id` from the issue key and summary (kebab-case, verb-led). Store ``, ``, and `` for use in all remaining phases. ## Phase 2: Fast-Forward Artifacts 5. Invoke the `openspec-ff-change` skill (Skill tool) with the ``. Enrich the proposal artifact with Jira context: - Jira issue link: `**Jira**: [ISSUE-KEY](jira-url)` - Why section derived from Jira issue description - What Changes derived from issue details This creates the change directory and generates ALL artifacts (proposal, specs, design, tasks) in one pass. **On failure**: If artifact creation fails critically (e.g., cannot create directory, CLI errors), report the error and **STOP**. ## Phase 3: Implement 6. Invoke the `openspec-apply-change` skill (Skill tool) with the ``. This implements all tasks from the generated tasks.md. Let the skill run through all tasks without interruption. **Auto-mode behavior**: When the apply skill would normally pause for clarification, make reasonable decisions and continue. Prefer the simplest correct approach. If implementation reveals a true design issue that cannot be resolved with reasonable defaults, **STOP** and explain the issue. ## Phase 4: Test 7. Run E2E tests: ```bash af e2e ``` 8. **If tests fail**, enter a fix-and-retry loop: - Read the reporter output for error messages, DOM snapshots, and file paths - For deeper debugging, read `./test-results/*/error-context.md` for full page state - Fix the code or test - If the failure is a visual regression from an intentional change, update baselines: ```bash af e2e npm run e2e -- --update-snapshots ``` - To iterate faster on the specific failing test, pass the full test command — bare args to `af e2e` are the *entire* container command, so `--grep` must be forwarded through the runner: ```bash af e2e npm run e2e -- --grep "booking" ``` - Once the targeted test passes, run the full suite (plain `af e2e`, no `--grep`) to confirm nothing else broke **Escape valve**: If E2E tests still fail after **3 full-suite attempts**, **STOP** and report which tests are failing, what fixes were attempted, and the current state. ## Phase 5: Verify 9. Invoke the `openspec-verify-change` skill (Skill tool) with the ``. 10. Handle verification results autonomously: - **CRITICAL issues**: Attempt to fix them (complete tasks, implement missing requirements). After fixing, re-run verification once. If critical issues persist, **STOP** and report. - **WARNING issues**: Note them but continue. - **SUGGESTION issues**: Ignore in auto mode. ## Phase 6: Complete 11. **Archive the OpenSpec change:** Invoke the `openspec-archive-change` skill (Skill tool) with the ``. In auto mode, when the archive skill encounters prompts: - Incomplete artifacts/tasks warnings: proceed - Delta spec sync prompt: choose "Sync now" (the recommended option) 12. **Commit with trailers:** ```bash git add -A git commit -m "" \ --trailer "Issue=" \ --trailer "OpenSpec-Id=" ``` 13. **Transition Jira to Done** — always supply a resolution, or the issue closes with an empty Resolution field: ```bash af jira transition --to "Done" --resolution "Fixed" --comment " archived and pushed" ``` Status and resolution names are workflow-specific. In auto mode, if this fails, run `af jira transitions ` — it lists the available transitions and the fields each one's screen requires — then retry with the correct `--to` / `--resolution` names (add `--field name=value` for any other required screen field). 14. **Push to remote:** ```bash git push ``` ## Phase 7: CI Verification 15. Read the Jenkins job path from the project's CLAUDE.md (e.g., `Jenkins job: folder/pipeline-name`). If not configured, skip this phase and warn the user. Job paths use `/` to separate folder/pipeline/branch segments, so the path to poll is the **branch** build the push just triggered: `/` — not the bare ``, which is the multibranch parent. (`af jenkins branches ` lists the per-branch build statuses.) 16. Wait ~30 seconds for Jenkins to pick up the push, then poll build status: ```bash af jenkins build / latest --json ``` Repeat every 30 seconds until the build is no longer in progress (check the `building` field or `result` field in JSON output). 17. **If build succeeds**: continue to final summary. 18. **If build fails**: - Run `af jenkins stages / latest` to identify the failing stage - Run `af jenkins stage-log / "" latest` to read the error output (arg order is ` [number|latest]`) - Fix the code based on the failure - Commit the fix using the same `git add -A && git commit -m "" --trailer ...` pattern from Phase 6 step 12, push, and poll again **Escape valve**: If the build still fails after **3 CI attempts**, **STOP** and report the failing stage, error output, and what fixes were attempted. ## Final Summary Display a completion summary: ``` ## Work Complete **Issue:** [ISSUE-KEY] **Change:** **Status:** Done ### Phases Completed 1. Issue picked up and transitioned to In Progress 2. All OpenSpec artifacts generated 3. All tasks implemented 4. E2E tests passing 5. Verification passed 6. Change archived, committed, pushed 7. CI build passed All done. ``` ## Auto Mode Behavior This skill runs without user interaction after the initial issue selection: - **NO intermediate confirmations** — proceed through phases automatically - **Make reasonable decisions** — when ambiguity arises, choose the simplest correct approach - **Fix forward** — if tests or CI fails, fix the code and retry (up to escape valve limits) - **Visual regression baselines** — update them automatically when the change intentionally affects the UI ## Escape Valves The skill **STOPS and reports** (rather than loop or proceed with broken state) when: 1. **Phase 1**: No issues in backlog, or Jira transitions fail 2. **Phase 2**: OpenSpec CLI errors or artifact creation fails 3. **Phase 3**: Unresolvable design issues during implementation 4. **Phase 4**: E2E tests fail after 3 full-suite retry attempts 5. **Phase 5**: Critical verification issues persist after one fix-and-reverify cycle 6. **Phase 6**: Commit or push fails (e.g., merge conflicts) 7. **Phase 7**: Jenkins build fails after 3 CI attempts When stopped, always report: which phase failed, what was attempted, and the current state so the user can resume manually. ## Project Defaults If the project instructions specify a default Jira project key (e.g., `Jira project: PROJ`), use it as the default for `--project`, `list`, `types`, and JQL queries. Explicit user input always overrides the default. ## Reference - See `openspec/AGENTS.md` for OpenSpec conventions - See the `jira` skill, or run bare `af jira` (not `af jira --help`, which is only a stub) for the full CLI reference - See `/opsx:ff`, `/opsx:apply`, `/opsx:verify`, `/opsx:archive` for individual phase details - See the `jenkins` skill for job paths, polling, and stage logs; run bare `af jenkins` for the full CLI reference