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. Do NOT proceed to step 3 if no code changes were made or if ce-work did not return control in return-to-caller mode.

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.

   Do not commit in this step. ce-simplify-code leaves its changes in the working tree; step 4's review scopes the working tree (uncommitted changes included), and step 8's ce-commit-push-pr commits whatever remains. Committing here would sweep any still-uncommitted ce-work edits into a misleading refactor commit and could stall on a tree that never goes clean.