
Lfg
Hands-off execution of a software feature from written plan through implementation, review, tests, commit, PR, and green CI when you explicitly want the agent to run the full pipeline.
Overview
LFG is an agent skill most often used in Ship (also Build, Ship testing/review) that runs an ordered autonomous pipeline from ce-plan through PR and green CI.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill lfgWhat is this skill?
- Strict ordered pipeline: ce-plan gate before any implementation work
- Chains plan → work → code review → test → commit → push → open PR → watch CI
- Stops entirely if ce-plan reports a non-software task unsuitable for pipeline mode
- Resolves dependent skills by exact name from the host’s available-skills list (no guessed short names)
- Repeats ce-plan until a plan file exists under docs/plans/ before step 2
- Ordered multi-step pipeline with mandatory plan gate before step 2
- Requires plan file under docs/plans/ before implementation
Adoption & trust: 1.8k installs on skills.sh; 20.5k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want a feature shipped without micromanaging each agent step, but ad-hoc execution skips planning, review, or CI and leaves broken merges.
Who is it for?
Solo builders with an existing repo who want one explicit “run the whole thing” command after describing a software feature.
Skip if: Non-software requests, exploratory chat, or tasks where you have not approved letting the agent commit, push, and open PRs autonomously.
When should I use this skill?
User explicitly requests hands-off execution of a software task and provides a feature description; do not auto-route casual conversation.
What do I get? / Deliverables
After a verified plan file, the agent completes implementation, review, tests, git push, PR, and CI remediation until green—or stops early if the task is not software-shaped for pipeline mode.
- Plan file in docs/plans/
- Commits and pushed branch
- Pull request with green CI
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill’s payoff is safe delivery—PR, CI, and fixes until green—even though it starts with planning. Launch subphase matches opening the PR, watching CI, and iterating until the change is ready to merge, which is the explicit end state of LFG.
Where it fits
Generate and lock docs/plans/ via ce-plan before any coding when kicking off a new feature.
Run structured code review as a mandatory step between implementation and merge.
Execute tests as part of the ordered pipeline before commit and PR.
Open the PR and watch CI until failures are fixed and checks pass.
How it compares
Use instead of chaining individual coding prompts when you need enforced gates and a fixed delivery ritual, not a single-purpose linter or test skill.
Common Questions / FAQ
Who is lfg for?
Indie and solo developers using compound-engineering-style agent stacks who want end-to-end delivery with explicit user consent for hands-off git and CI actions.
When should I use lfg?
Use it in Ship when you need PR + green CI; in Build when you want plan-then-implement in one run; avoid it unless you explicitly request pipeline mode with a feature description.
Is lfg safe to install?
It implies shell, git, network, and repository write actions—review the Security Audits panel on this page and your org policies before enabling autonomous commit and PR flows.
Workflow Chain
Requires first: ce plan
SKILL.md
READMESKILL.md - 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-code-review in step 3. 2. Invoke the `ce-work` skill. GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Do NOT proceed to step 3 if no code changes were made. 3. Invoke the `ce-code-review` skill with `mode:autofix plan:<plan-path-from-step-1>`. Pass the plan file path from step 1 so ce-code-review can verify requirements completeness. Read the Residual Actionable Work summary the skill emits. 4. **Persist review autofixes** (REQUIRED after step 3, before residual handoff) Check `git status --short`. If `ce-code-review mode:autofix` changed files, stage only those review-fix files, commit them with `fix(review): apply autofix feedback`, and push the current branch before continuing. If an upstream exists, run `git push`. If no upstream exists, resolve a writable remote dynamically: prefer `origin` when present, otherwise use `git remote` and choose the first configured remote. Then run `git push --set-upstream <remote> HEAD`. Do not proceed to step 5, run browser tests, or output DONE while review autofix edits remain only in the working tree. If no files changed, explicitly note that there were no review autofixes to persist. 5. **Autonomous residual handoff** (only when step 3 reported one or more residual `downstream-resolver` findings; skip when it reported `Residual actionable work: 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. 1. Load `references/tracker-defer.md` in **non-interactive mode**. Pass the residual actionable findings from step 3's summary (or the run artifact when the summary was truncated). 2. Collect the structured return: `{ filed: [...], failed: [...], no_sink: [...] }`. 3. Compose a `## Residual Review Findings` markdown 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. 4. Detect the current branch's open PR without prompting: ```bash gh pr view --json number,url,body,state ``` 5