/ia-lfg

name: ia-lfg
description: Full autonomous engineering workflow (plan, build, review, ship)
argument-hint: "[feature description] [--swarm for parallel execution]"
disable-model-invocation: true

Run applicable steps in order within the user's authorized scope. Carry explicit non-interactive pipeline context to child commands; `disable-model-invocation` metadata alone does not establish that context. Preserve material decisions requiring user input as blockers while completing independent work.

**Mode detection:** If `$ARGUMENTS` contains `--swarm`, use bounded parallelism for independent implementation/review units per `ia-orchestrating-swarms`. Otherwise run sequentially.

**Arguments guard:** If `$ARGUMENTS` is empty (no feature description and no `--swarm`), ask for a feature description before proceeding. Do not invoke `/ia-plan` with empty input.

Sequential steps

1. `/ia-plan $ARGUMENTS` (strip `--swarm` from arguments). Capture the exact returned plan path as the current pipeline's plan; never select another plan by recency. 2. If the plan has unresolved implementation or verification gaps, call `/ia-deepen-plan <exact-plan-path>` with those gaps. Otherwise skip and record why.

Build

3. `/ia-work <exact-plan-path>` with explicit pipeline context: implement and verify locally, defer branch publication until the final review and fixes below. Share any review receipt with the next step to avoid reviewing an unchanged diff twice.

**Swarm mode:** Use Task list and launch parallel agent swarm subagents to build the plan. **Normal mode:** Execute sequentially.

Verify (parallel in swarm mode)

4. `/ia-review` on the current change. Capture the exact todo paths returned by this review as `current_review_todos`; pre-existing todos are outside this pipeline's scope. If step 3 already completed the same review protocol on the same revision, reuse that receipt and review only subsequent changes. 5. Run `/ia-test-browser` only when the change affects browser-visible routes or interactions and a usable local server exists. Pass explicit non-interactive context and use headless mode. Record missing browser coverage as a gap; a skipped stage is not a pass. Add only this invocation's returned todo paths to `current_review_todos`.

**Swarm mode:** Review and browser verification may run in parallel when both are read-only against the same revision and isolated from writers. Wait for both to complete. **Normal mode:** Run sequentially.

Finalize

6. Triage `current_review_todos`: accept only fixes supported by evidence and the user's existing implementation authority, mark those `ready`, and retain judgment/approval-dependent items as `pending`. Call `/ia-resolve-todo-parallel` with the exact accepted paths and defer publication. Do not enumerate or act on unrelated backlog. Verify integrated fixes before closing them; unresolved blockers prevent a ready-to-ship claim. 7. Run final project gates, then finish the branch according to the user's publication authority. If a PR is opened, record its number. Run `/ia-feature-video <pr-number>` only for a browser-visible feature with a useful walkthrough and authorized upload destination; otherwise omit it. A video is documentation, not a verification gate.

CI watch (after PR opens)

8. Only watch CI when a PR exists and the user's authorized workflow includes CI fixes. **Before polling: distinguish actionable CI failures from non-actionable gates.** Run `gh pr view --json isDraft,reviewDecision` plus `gh pr checks --json name,state,bucket` (the `bucket` field categorizes `state` into `pass`, `fail`, `pending`, `skipping`, or `cancel`; there is no `conclusion` field on this subcommand). Add `--required` to see only required checks. Classify by bucket, not vendor name:

• `bucket: fail` on a required check (`gh pr checks --required --json name,state,bucket`) -> actionable, fix in Step 9.
• `isDraft: true` with no checks after a grace period -> stop and report `DRAFT_PR_WITH_NO_CHECKS`. Do not mark ready for review unless asked.
• `reviewDecision: REVIEW_REQUIRED` or any human-approval gate with no failing checks -> stop and report `BLOCKED_BY_REVIEW_GATE`. Human review is not an actionable failure.
• No checks registered after a grace period -> stop and report `NO_CHECKS_REGISTERED`.
• `bucket: skipping`/`cancel`, or `bucket: pending` on non-required checks -> do not wait. Required-status-checks (configurable via `gh api repos/{owner}/{repo}/branches/{branch}/protection`) are the source of truth; common examples include test/lint/build jobs and code-review bots (Sentry, Codecov, Cursor, BugBot, etc.) — treat each by its bucket, not its name.

9. Poll CI for the new PR. On failure: read the job log, identify the root cause, fix, push. Cap at **3 fix iterations**. 10. Do **NOT** weaken, skip, or mock the failing assertion to make CI green -- repair the actual issue. After 3 unsuccessful fix iterations, report the unresolved failure and evidence; the iteration count does not prove flakiness. Update the PR only when authorized.

Start now.