lfg

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.

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., compound-engineering:ce-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.

1. Invoke the ce-plan skill with $ARGUMENTS.

   GATE: STOP. If ce-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 ce-plan workflow produced a plan file in docs/plans/. If no plan file was created, invoke ce-plan again with $ARGUMENTS. Do NOT proceed to step 2 until a written plan exists. Record the plan file path — it will be passed to ce-work in step 2 and ce-code-review in step 4.

   Read the plan metadata before continuing. If the plan has artifact_contract: ce-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, ce-work owns that implementation engine choice and must return control to LFG afterward.

2. Invoke the ce-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, U-IDs attempted/completed when present, verification results, blocker list, behavior-change signal, and standalone_shipping_skipped: true. When behavior_change: true, also require verification_evidence that names the relevant units/tasks, existing tests inspected, tests added/changed or used unchanged, red failure or characterization evidence when applicable, verification run, and any deliberate test exception. Do NOT decide the test strategy inside LFG; the evidence is ce-work's contract.

   If behavior_change: true but verification_evidence is missing or too vague to tell how behavior was protected, invoke ce-work one more time with the same mode:return-to-caller <plan-path-from-step-1> argument. Do not prompt the user and do not alter the plan path argument. The retry relies on ce-work's idempotency path to inspect the already-implemented work, fill the missing evidence, and return without reimplementing. If the second return still lacks coherent verification evidence, stop as blocked and report the missing fields instead of continuing to simplify/review/ship.

3. Invoke the ce-simplify-code skill on the branch diff.

   This runs before review so the code-review in step 4 covers the simplified code. Skip this step when the change is docs-only (only markdown/docs paths changed) or trivial (roughly under 10 changed lines). Otherwise let ce-simplify-code resolve the branch-diff scope itself; it preserves behavior and runs the test suite.