lfg
everyinc/compound-engineering-plugin
Run a complete hands-off engineering pipeline from planning through a green PR.
What is lfg?
LFG orchestrates a full software delivery workflow: planning, implementation, code simplification, review, fix application, residual tracking, testing, and PR creation. Use it when you have a feature description and want an end-to-end automated pipeline that produces a merged or ready-to-merge pull request.
- Executes planning phase to validate the task is software-implementable
- Runs implementation work and verifies code changes were made
- Simplifies code on non-trivial changes before review
- Performs code review against requirements and surfaces actionable findings
- Applies review fixes and commits them automatically
- Files residual findings to a tracker or fallback document
How to install lfg
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill lfg- Git repository with a configured remote (origin) for pushing and PR creation
- Available skills: ce-plan, ce-work, ce-simplify-code, ce-code-review, ce-test-browser, ce-commit-push-pr, and optionally tracker-defer
- For local-only mode: git init repository without a remote is supported but skips all push and PR actions
How to use lfg
- 1.Invoke lfg with a feature description as the argument
- 2.Wait for ce-plan to generate a plan file in docs/plans/ (LFG will retry if missing)
- 3.LFG runs ce-work to implement changes; verify files were modified
- 4.LFG runs ce-simplify-code on non-trivial diffs (skipped for docs-only or <10 line changes)
- 5.LFG runs ce-code-review in report-only mode and loads actionable findings
- 6.LFG applies eligible review fixes from references/review-followup.md and commits them
- 7.LFG files residual findings to a tracker or fallback document (no user prompt)
- 8.LFG runs ce-test-browser in pipeline mode
Use cases
- Implementing a feature from a written description without manual handoffs
- Automating the full development cycle from requirements through PR creation
- Ensuring code review findings are applied before shipping
- Handling residual review items that need tracker filing or documentation
- Running a complete pipeline on a feature branch with automatic testing and PR creation
- Engineering teams using compound-engineering plugins
- Developers who want hands-off automation from planning to PR
- Teams with CI/CD pipelines that need structured code review and testing
lfg FAQ
LFG stops the pipeline immediately and informs you that LFG requires software tasks. No further steps are executed.
No. LFG enforces strict step ordering: planning must complete and produce a plan file before any implementation begins. Skipping this gate produces bad output.
LFG detects this and enters local-only mode: it makes all commits but skips every push, PR creation, and CI-watch action. All work remains on your local branch.
Yes. Step 5 commits review fixes, step 6 commits residual findings if needed, and step 8 commits any remaining changes and pushes the PR. You do not need to commit manually.
LFG loads the review findings, applies eligible fixes automatically in step 5, and files residual findings to a tracker or fallback document in step 6. The PR includes all applied fixes and residual tracking.
Full instructions (SKILL.md)
Source of truth, from everyinc/compound-engineering-plugin.
name: lfg description: Run the full hands-off engineering pipeline from planning through a green PR. disable-model-invocation: true argument-hint: "[feature description]"
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.
-
Invoke the
ce-planskill 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-planworkflow produced a plan file indocs/plans/. If no plan file was created, invokece-planagain 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 hasartifact_readiness: implementation-readyandexecution: code. Stop the pipeline forartifact_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/goaldirectly; when goal-mode or dynamic workflows are appropriate,ce-workowns that implementation engine choice and must return control to LFG afterward. -
Invoke the
ce-workskill withmode: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, andstandalone_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. -
Invoke the
ce-simplify-codeskill 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-coderesolve the branch-diff scope itself; it preserves behavior and runs the test suite.Do not commit in this step.
ce-simplify-codeleaves its changes in the working tree; step 4's review scopes the working tree (uncommitted changes included), and step 8'sce-commit-push-prcommits whatever remains. Committing here would sweep any still-uncommittedce-workedits into a misleadingrefactorcommit and could stall on a tree that never goes clean. -
Invoke the
ce-code-reviewskill withmode:agent plan:<plan-path-from-step-1>.Pass the plan file path from step 1 so ce-code-review can verify requirements completeness. Read the Actionable Findings summary the skill emits.
mode:agentis report-only by design — it surfaces findings but never edits the tree; LFG applies the eligible ones in step 5. When narrating progress to the user, frame this as "review found X → applied X in step 5," not as "code review did not auto-fix." A report-only review followed by an LFG-applied fix is the intended contract, not a gap.
Shipping precondition (steps 5–9). Run git remote once before the shipping steps. If it lists no remote (e.g. a sandbox/throwaway checkout that has git init but no origin), shipping is local-only: make every commit the steps below call for, but skip every push, PR create/edit, and CI-watch action — the pushes in steps 5 and 6, the push and PR creation in step 8, and step 9 in full. A missing remote is a terminal local-only state, not an error: never retry a push or hunt for a remote — make the local commits and proceed to step 10. Run steps 5–9 normally when a remote exists.
-
Apply and persist review fixes (REQUIRED after step 4, before residual handoff)
Load
references/review-followup.mdand execute its apply step (mechanical apply + commit/push when changes exist). Do not proceed to the residual handoff, run browser tests, or output DONE while eligible review fixes remain only in the working tree uncommitted. -
Autonomous residual handoff (only when step 4 reported one or more actionable
downstream-resolverfindings not applied in step 5; skip when it reportedActionable findings: none.)Do not prompt the user. This step embraces the autopilot contract: residuals must become durable before DONE, but the agent never stops to ask.
-
Load
references/tracker-defer.mdin non-interactive mode. Pass the residual actionable findings from step 4/5 (or the run artifact when the summary was truncated). -
Collect the structured return:
{ filed: [...], failed: [...], no_sink: [...] }. -
Compose a
## Residual Review Findingsmarkdown section from the structured return:- For each item in
filed: a bullet with severity, file:line, title, and a link to the tracker ticket URL. - For each item in
failed: a bullet with severity, file:line, title, and the failure reason (e.g.,Defer failed: gh returned 401 — tracker unavailable). - For each item in
no_sink: a bullet with severity, file:line, and title inlined verbatim so the PR body or fallback file is the durable record.
- For each item in
-
Detect the current branch's open PR without prompting:
gh pr view --json number,url,body,state -
If an open PR exists, update it directly with
gh; do not load any confirmation-driven PR update skill. Append or replace the## Residual Review Findingssection in the current PR body, write the new body to an OS temp file, then run:gh pr edit PR_NUMBER --body-file BODY_FILE -
If no open PR exists, create a tracked fallback file at
docs/residual-review-findings/<branch-or-head-sha>.mdcontaining the composed section and the source PR-review run context. Stage only that file, commit it withdocs(review): record residual review findings, and push the current branch when a remote is configured (per the shipping precondition). If an upstream exists, rungit push. If no upstream exists but a remote is configured, resolve a writable remote dynamically: preferoriginwhen present, otherwise usegit remoteand choose the first configured remote. Then rungit push --set-upstream <remote> HEAD. If there is no remote at all, do not push — the committed fallback file is the durable sink. This is the durable no-PR sink. Do not output DONE until the residual findings are durable: either the existing PR body has been updated, or this fallback file commit has been made (pushed when a remote exists, committed locally when none). A push that fails when a remote exists is a stop-and-report; never retry a push, or block DONE, when no remote exists.
Never block DONE on tracker filing failures once residuals have been durably recorded. A
no_sinkoutcome is success only when the findings are present in the PR body or in the pushed fallback file. -
-
Invoke the
ce-test-browserskill withmode:pipeline. -
Invoke the
ce-commit-push-prskill.This commits any remaining changes, pushes the branch, and opens a pull request. If step 6 already opened a PR (check with
gh pr view --json number,url,state 2>/dev/null), skip PR creation but still commit and push any uncommitted changes. Per the shipping precondition, when no remote is configured, do NOT invokece-commit-push-pr— its commit step pushes unconditionally (git push -u origin HEAD), so a literal invocation would still hit the impossible push. Instead commit any remaining changes locally yourself (git add -A && git commit) and skip the push and PR creation entirely. -
CI watch and autofix loop (only when an open PR exists for the current branch)
Detect the PR; if none exists or
ghis unavailable, skip this step entirely and proceed to step 10.gh pr view --json number,url,stateFor up to 3 fix iterations, repeat:
-
Wait for CI to complete:
gh pr checks --watchIf the command exits 0, all checks passed. Break out of the loop and proceed to step 10.
If it exits non-zero, one or more checks failed. Continue to (2).
-
Identify failing checks and pull their failure logs. Use
gh pr checks --json name,state,conclusion,workflow,linkto enumerate failures, then for each failing check read the run logs:gh run view <run-id> --log-failedwhere
<run-id>is parsed from the check's details URL or workflow run. -
Read the failure logs, identify the root cause, and apply a fix in the working tree. Do NOT weaken, skip, or mock the failing assertion to make it pass — repair the actual issue. If the failure is a flaky test that has no fix path, document that as the residual outcome below rather than retrying without a code change.
-
Stage only the files you changed, commit, and push:
git add <changed-files> git commit -m "fix(ci): <one-line summary of the failure repaired>" git push -
Return to iteration (1) with the next attempt counter.
GATE: STOP iterating after 3 failed attempts. If CI is still red after 3 fix cycles:
-
Compose a
## CI Failures Unresolvedmarkdown section listing each remaining failing check, the failure summary, and the run/check URL. -
Append or replace this section in the PR body, write the new body to an OS temp file, then run:
gh pr edit PR_NUMBER --body-file BODY_FILE -
Do NOT continue looping. The autopilot contract is "make residuals durable, then exit." Proceed to step 10.
-
-
Output
<promise>DONE</promise>when complete
Start with step 1 now. Remember: plan FIRST, then work. Never skip the plan.
Related skills
More from everyinc/compound-engineering-plugin and the wider catalog.

ce-agent-native-architecture
Build applications where agents are first-class citizens using atomic tools and prompt-defined features.

ce-agent-native-audit
Comprehensive agent-native architecture review with scored principles across 8 core dimensions

ce-brainstorm
Explore vague ideas into a right-sized requirements-only plan before building.

ce-clean-gone-branches
Delete local branches whose remote tracking branch is gone, including associated worktrees.
analyze-logs
Debug application behavior by analyzing structured logs from evlog's file system drain.
review-logging-patterns
Review and refactor logging patterns; adopt structured evlog for TypeScript/JavaScript projects.