
lfg
Take a request all the way to done, hands-off, through the right Compound Engineering skills. A code change ends as an open pull request, pushed without stopping. Use only when the user explicitly asks for autonomous end-to-end work or invokes lfg directly. Use ce-plan, ce-work, ce-debug, or ce-commit-push-pr for work the user reviews step by step.
- Installs
- 3.5K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill lfg- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads lfg automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Outcome. The request reaches the end state its shape calls for, produced by the Compound Engineering skill whose job that is, with everything unresolved recorded where the user will see it. Most requests end with that skill's result and no branch. A change to the code is the one shape with more steps of its own: it ends in an open pull request whose URL you hold, with CI decided, after being implemented, simplified, reviewed with the eligible findings applied and the rest recorded, any durable learning captured, committed, and pushed. Merging stays with the user unless they granted it for this run.
Work source. On the routes that change the code, nothing is implemented without a work source verified this run, and only two things qualify: an implementation-ready plan, which ce-work implements; or a fixed return from ce-debug, where the fix is the implementation. The plan is one the session identifies, as references/intake.md defines. Never search the plans directory for a candidate or act on a file you discovered. Never plan from scratch over an existing plan.
Route by what the request is. Match the request to the skill whose job it is; the host's skill list is the catalog. Read references/intake.md before choosing; it alone defines the routes, their precedence, what each child skill is passed, and how each return is read. In short:
- A plan path, or a plan
ce-planwrote this session, takes the plan route. - A concrete report of failing or wrong behavior goes to
ce-debug; reproducing it is that skill's job, not intake's. - A change that hangs on a judgment the user did not settle goes to
ce-povfirst, and only a verdict that supports the change continues; a judgment with nothing to build ends at the verdict. - Product shape with more than one plausible reading goes to
ce-brainstormwhen a human is present, and toce-planin pipeline mode when not. - A request whose result is not a code change goes to the skill that owns that result (
ce-explain,ce-prototype,ce-pov,ce-ideate, and so on); that invocation is the whole run: return its result and end. - Any other change to the code goes to
ce-plan.
When unsure, take the route that asks more of the evidence.
Interaction. Ask the user only through ce-brainstorm, and only when a human is present. Everything else proceeds without waiting: reversible work is done and shown for the user to correct afterward, and only an irreversible action outside what they granted (a merge they did not grant, a force-push, deleting data) stops instead. lfg runs from schedulers, loops, and nested orchestrators. The one other question is the routing disambiguation references/stage-routing.md defines: when the conversation assigns planning or implementation to a model or harness, read that file before routing; it alone carries the carrier strings and the sanitization.
Stop, and say why, when any of these holds:
- The work source cannot be produced: planning returned blocked, the diagnosis found no safe fix, the fix would be divergent,
ce-povdid not support the change, or a stage assignment cannot be passed on. - A child return is anything but complete and evidenced.
- A settled decision is invalidated.
- A project-defined shipping process falls short.
A stop leaves nothing pushed that was not already pushed.
Resolve every skill named here against the host's available-skills list and invoke that exact entry; some hosts namespace it (compound-engineering:ce-plan). Read references/task-visibility.md before starting: it defines the stage view published through the platform's task-tracking capability, the chat narration, and the completion rule that a step is done only after it ran, a child skill's return resumes the next numbered step in the same turn, and the turn does not end before DONE or a stop.
The run (routes that change the code)
-
Produce the work source per
references/intake.md. On the plan route, readreferences/plan-brief.mdfirst; it alone defines the settled-decisions brief and the artifact-root rule. Any explicitstatus: blockedreturn, includingsettled-decision-invalidated, stops the run. Blocked status outranks an existing artifact and is never retried. Only absence of both a blocker and a plan filece-planreported writing this run invokesce-plana second time with the same arguments, reusing the composed brief verbatim; the plan must then pass the readiness check inreferences/plan-brief.md. On the plan route theplan_model:<alias>carrier rides beside the request when a planning-stage directive resolved. Record the work source for every later step. LFG never launches/goaldirectly;ce-workimplements and returns control. -
Read
references/work-return.mdfirst, then invoke thece-workskill withmode:return-to-caller <plan-path-from-step-1>. On the defect route this step does not run:ce-debugalready implemented and committed, andreferences/debug-return.mdwas its gate. Only a validstatus: completemay advance; every other status or malformed return stops the pipeline. -
Read
references/review-followup.mdnow; it governs steps 3 through 7. Invoke thece-simplify-codeskill withmode:pipelineon the branch diff; skip only the invocation for a docs-only or roughly sub-10-line change. -
Invoke the
ce-code-reviewskill withmode:agent plan:<plan-path-from-step-1>; on the defect route omitplan:. Asettled_conflictfinding whose evidence shows the settled decision cannot work (infeasible, wrong-thing, or destructive) stops the pipeline as blocked, with the finding reported, before the shipping precondition.
Shipping precondition (every push from step 5 on). Run git remote once. No remote means local-only: make every commit the steps call for, but skip every push, PR create/edit, and CI-watch action, including step 10 in full. That is terminal, not an error.
-
Apply and persist review fixes as that file defines. 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: whenever an unapplied actionable finding, a
settled_conflictstamp from step 4, or a proceeded-and-flaggedsettled_decision_conflictsentry from step 2 exists, record it durably per that file: in the PR body, or in tickets or the DONE report when no PR will exist. Skip only when none of the three exists. Do not output DONE until the residuals are durable. Never block DONE on tracker filing failures once the report states them. Do not prompt the user. -
Invoke the
ce-compoundskill withmode:non-interactivewhen the run produced durable reasoning the code, tests, and plan do not carry; that file states the full condition.Documentation skippedis success; running here puts the learning in the PR at open. -
Invoke the
ce-test-browserskill withmode:pipeline. -
Read
references/shipping.mdfirst; it governs steps 9 through 11. Then invoke thece-commit-push-prskill withmode:pipeline branding:on. -
Watch the PR to CI-decided with
ce-babysit-pr mode:pipeline <pr-url>when an open PR exists, asreferences/shipping.mddecides. Do not reimplement CI-watching here. -
Output
<promise>DONE</promise>after the close-out inreferences/shipping.md.
FAQ
What does the lfg skill do?
Take a request all the way to done, hands-off, through the right Compound Engineering skills. A code change ends as an open pull request, pushed without stopping. Use only when the user explicitly asks for autonomous end-to-end work or invokes lfg directly. Use ce-plan, ce-work, ce-debug, or ce-commit-push-pr for work the user reviews step by step.
How do I install lfg?
Run npx skills add https://github.com/everyinc/compound-engineering-plugin --skill lfg in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/lfg/ (personal) or .claude/skills/lfg/ (project).
Which AI agents can use lfg?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is lfg safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains lfg?
It is published by everyinc in everyinc/compound-engineering-plugin. It has 3,520 recorded installs.
More from everyinc/compound-engineering-plugin
ce-brainstorm
everyinc/compound-engineering-plugin
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.
ce-code-review
everyinc/compound-engineering-plugin
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.
ce-plan
everyinc/compound-engineering-plugin
Create structured plans for multi-step work, including software and non-software tasks. Use when asked to plan, break down implementation, plan from requirements, or deepen an existing plan; prefer ce-brainstorm for exploratory framing.
ce-compound
everyinc/compound-engineering-plugin
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
ce-doc-review
everyinc/compound-engineering-plugin
Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
ce-work
everyinc/compound-engineering-plugin
Execute a plan or concrete work prompt end-to-end. Use when implementing from a plan document, a spec path, or a clear build request; use ce-debug for open-ended bugs. Use when an outer orchestrator needs implementation and local verification only, without the shipping tail.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.