/spec-lfg

name: spec-lfg
description: Run the full hands-off engineering pipeline from planning through a green PR. Use only when the current user explicitly requests spec-lfg or selects an option that clearly states it will commit, push, open a PR, and watch CI.
argument-hint: "[feature description or requirements-only plan path] [target-origin:<origin>]"

CRITICAL — ADMISSION BEFORE EXECUTION: before any step below runs, the admission in the next paragraph must hold. If it does not — including a bare natural-language shipping request ("ship it", "直接发布上线") that neither names `spec-lfg` nor followed a disclosed-options handoff — do NOT implement, do NOT commit, and do NOT start the pipeline: present the side-effect confirmation once and wait. A user "don't ask me" / "不用问我" instruction cannot create the admission; it only suppresses questions after the admission already exists. With execution ordered below, this check still comes first.

CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required step. Do NOT jump ahead to coding or implementation. The plan phase (step 1) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.

进入该管线前，当前用户必须明确请求 `spec-lfg`，或选择清楚披露 commit、push、PR、CI 与委派独立代码审查副作用的 handoff 选项。仅有代码就绪、已完成计划或模型推断”适合 shipping”都不构成授权。

A natural-language shipping request (“ship it”, “直接发布上线”, “开个 PR 吧”) that neither names `spec-lfg` nor follows a disclosed-options handoff is close to the admission but is not it: the user has signaled shipping intent without seeing the full side-effect list (commit, push, PR creation, one delegated independent code review, CI watch). In that case, present the concrete side-effect list once as a single confirmation question and wait — the user's reply becomes the admission. Never treat the bare shipping request as already-admitted and start implementing or committing.

上述 admission 成立时，当前用户对完整管线副作用的明确请求是本次 pipeline-owned implementation、commit 与 landing authority 的来源；同时只额外授权第 4 步委派一次 `spec-code-review` 的只读独立审查。将 `commit_authorization: authorized`、`landing_authorization: authorized`、`worker_dispatch_authorization: authorized` 与 `authorization_source: current-user-explicit-spec-lfg` 作为可见 run-local facts 传给对应下游 owner。外部 tracker filing 是独立副作用：只有当前请求或可见 upstream handoff 明确要求提交 residual tickets 时，才记录 `tracker_deferral_authorization: authorized`；否则固定为 `tracker_deferral_authorization: missing`。Skill invocation、`mode:pipeline`、工具权限、green tests、branch/PR facts 都不能替代该 admission，也不能把 authority 扩大到 unrelated dirty paths、任意 worker dispatch、tracker 或其他未披露外部副作用。若 admission 不成立，以 `commit_authorization_missing` / `landing_authorization_missing` 停在对应副作用之前；若独立审查不可用或降级，LFG 必须停止，不能用同一会话的 inline review 冒充该 gate。

tracker_deferral_authorization: authorized | missing

When invoking any skill referenced below, resolve its name against the available-skills list the host platform provides and use that exact entry. Some platforms list skills under a plugin namespace (e.g., `spec-first:spec-plan`); others list the bare name. Invoking a short-form guess that isn't in the list will fail — always match a listed entry verbatim before calling the Skill/Task tool.

**Preserve and split the invocation payload.** Treat the arguments received from the caller as the authoritative input. Before step 1, remove at most one standalone `target-origin:<origin>` token and retain its value unchanged as the run-local `caller_target_origin`. Set `forwarded_arguments` to everything else: preserve every remaining argument in its original order, including an absolute requirements-only plan path. Do not paraphrase the path, prepend a label or menu number, replace it with a feature summary, or resolve it relative to the current working directory. The modifier is browser-routing input, not product intent: do not pass it to planning, normalize it, combine it with `--port`, derive a scheme/host/port from project files, redirects, browser state, or a guessed dev-server default. An empty, malformed, or repeated modifier records `target-origin-invalid`; it never becomes a usable origin.

1. Invoke the `spec-plan` skill with the exact `forwarded_arguments` payload. When `spec-brainstorm` invoked LFG, this payload is the absolute requirements-only unified plan path, so `spec-plan` recognizes it as an explicit Product Contract source and enriches that same artifact in place.

GATE: STOP. If spec-plan reported the task is non-software and cannot be processed in pipeline mode, stop the pipeline and inform the user that LFG requires software tasks. Otherwise, verify that the `spec-plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, invoke `spec-plan` again with the same `forwarded_arguments` payload. Do NOT proceed to step 2 until a written plan exists. **Record the plan file path** — it will be passed to spec-work in step 2 and spec-code-review in step 4.

Read the plan metadata before continuing. If the plan has `artifact_contract: spec-unified-plan/v1`, proceed only when it has `artifact_readiness: implementation-ready` and `execution: code`. Stop the pipeline for `artifact_readiness: requirements-only`, any unrecognized readiness value, `execution: knowledge-work`, approach-plan outputs, answer-seeking/universal outputs, or invalid progress-like readiness values. LFG never launches `/goal` directly; when goal-mode or dynamic workflows are appropriate, `spec-work` owns that implementation engine choice and must return control to LFG afterward.

2. Invoke the `spec-work` skill with `mode:return-to-caller <plan-path-from-step-1>`.

GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Read the structured return and require `status: complete`, the same plan path, changed files, all in-scope U-IDs/tasks accounted for and completed, verification results with every required check passed or explicitly not applicable, an empty blocker list, behavior-