---
name: code-auto-pilot
description: >
  Full autonomous pipeline: implement a GitLab issue, review loop until APPROVED,
  run CI, and finally merge the MR. Delegates implementation to /code-implement
  then handles review, CI, and merge.
  Use when the user says /code-auto-pilot, 'auto-pilot', 'pilote automatique',
  'implement and deploy', 'implement and review', or needs the full end-to-end flow
  from issue to approved MR with CI.
argument-hint: "[GitLab issue IID or URL]"
allowed-tools:
  - Bash
  - Skill
  - AskUserQuestion
---

Full autonomous pipeline: from GitLab issue to approved MR with CI validation.

## Required tools

- `glab`

Run `pysae-ai-tools tools require <tools>` before starting; if it exits non-zero, abort and report the install command from stderr to the user.

## Mode detection

```bash
CTX=$(pysae-ai-tools internal detect-context --local)
IS_CI=$(echo "$CTX" | jq -r '.is_ci')
```

In CI mode (`IS_CI == "true"`), all delegated skills inherit the headless behavior:
- `/code-implement`: infers type automatically, uses worktree, no questions
- `/glab-mr`: skips confirmation, creates MR directly
- `/code-review-fix`: fails with exit code 1 after 5 iterations instead of asking
- `/glab-mr-approve`: skips manual testing gate
- **Never use `AskUserQuestion`** — if a sub-skill would normally escalate to the user, it must fail or make a best-effort decision instead

## Step 1 : Implement and create MR

Invoke the `/code-implement` skill with the issue reference from `$ARGUMENTS`. This handles:
- Reading the issue and detecting type
- Setting the issue to In Progress
- Creating the branch
- Analyzing and planning
- Implementing with atomic commits
- Running tests/linters
- Creating the MR

Wait for `/code-implement` to complete before proceeding.

## Step 2 : Review and fix loop

Once the MR is created, invoke the `/code-review-fix` skill with the `COMMIT_PREFIX` as argument. This handles:
- Code review
- One commit per review fix
- Re-review until APPROVED
- MR approval (via `/glab-mr-approve`)

## Step 3 : Re-validate after review fixes

If the `/code-review-fix` loop produced commits (i.e. there were review fixes), invoke `/code-quality` again with the `COMMIT_PREFIX` to ensure the fixes didn't break anything. Skip this step if the review was APPROVED on the first iteration without any fixes.

## Step 4 : Run CI pipeline

Once the `/code-review-fix` skill completes (review **APPROVED**):

- **Default**: invoke the `/ci-run` skill with the `start` job on the MR pipeline
- **If the user explicitly requested a deployment** (e.g. "deploy", "déploie", "lance le deploy") **AND the changes affect the application** (not just tooling, scripts, CI config, dev utilities, or non-deployed code): invoke the `/ci-deploy` skill with `review` instead
- **If the changes only concern tooling** (e.g. `tooling/`, scripts, dev utilities, CLI commands, non-deployed code): always use `/ci-run` with `start`, even if the user requested a deployment — a review deploy would be pointless

In all cases, wait for the job to complete and report its status. If the job fails, invoke the `/ci-debug` skill to analyze the failure and inform the user.

**Note**: when the user asks for the "review URL", they mean the deployed review environment URL (output by the `/ci-deploy` skill after `deploy_review` completes), NOT the Slack message or MR link.

## Step 5 : Merge the MR

Only execute this step if **both** of the following hold:
- The review loop in step 2 ended with an **APPROVED** verdict
- The CI job in step 4 succeeded

Invoke the `/glab-mr-merge` skill with the MR IID. The skill re-checks the MR state (mergeable, no draft) and handles rebase automatically if conflicts are detected (delegates to `/glab-mr-rebase`), then merges with the project-level defaults (no flags passed).

If the merge fails (missing approvals, blocked by CI, unresolved conflicts after rebase), report the blocker and stop.

## Step 6 : Emit machine-readable result footer

At the very end of execution, emit a single structured block to stdout. This block is parsed by `/code-autopilot-batch` to determine the outcome. Emit ONE block, even on failure.

````
<<<AUTOPILOT_RESULT
{
  "status": "success" | "escalated" | "failed",
  "mr_url": "https://gitlab.com/...",
  "mr_iid": 567,
  "issue_iid": 1234,
  "project_path": "pysae/shift",
  "escalation_reason": null,
  "tokens_used": 0,
  "duration_seconds": 0
}
AUTOPILOT_RESULT>>>
````

The content between `<<<AUTOPILOT_RESULT` and `AUTOPILOT_RESULT>>>` MUST be a single valid JSON object and nothing else. No prose, no markdown, no commentary outside the JSON braces.

Field semantics :
- `status: success` => MR merged AND issue closed (full pipeline green)
- `status: escalated` => human required (review-fix did not converge, merge conflict, CI fail non-recoverable, merge blocker, ambiguous spec). Set `escalation_reason` to a short human string (max 200 chars).
- `status: failed` => technical failure not actionable by a human (rare; usually means a tool exploded).
- `mr_url` and `mr_iid` are required when a MR exists (regardless of status), otherwise null. An escalated run that already created a MR MUST set both fields.
- `tokens_used` and `duration_seconds` are best-effort. If unknown, emit 0.

If an unrecoverable tool error occurs at any earlier step, emit the footer immediately with `status: failed` and `escalation_reason` describing the failure, then stop. Never abort without emitting the footer.

## Critical rules

- **ALWAYS complete ALL steps (1→6)** — never stop after implementation. The full flow is: implement → review loop → CI → merge → emit footer.
- **Delegate, don't duplicate** — use `/code-implement` for the implementation, `/code-review-fix` for the review loop, `/code-quality` for validation, `/ci-run` or `/ci-deploy` for CI, `/glab-mr-merge` for the final merge (it handles its own pre-merge rebase if needed)
- **Review loop safety**: max 5 iterations. In local mode, escalate to the user; in CI mode, fail with exit code 1
- **Always emit AUTOPILOT_RESULT footer** as the very last output, even on early abort. Failure to emit causes the parent batch orchestrator to treat the run as `outcome unparseable` and escalate the ticket.

$ARGUMENTS
