본문으로 건너뛰기
cccskills
무료GitHub에 공개

lfg

Carry a request through the appropriate Compound Engineering skills with minimal intervention. For code changes, the workflow covers planning, implementation, review, browser testing, and an open pull request with automated check results assessed.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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.

설치 방법 보기

이럴 때 유용합니다

  • Taking a feature request through to an open pull request
  • Diagnosing a bug and preparing the fix for review
  • Implementing an existing plan through delivery
  • Recording unresolved review findings for handoff

포함된 파일(11)

  • SKILL.md7.7 KB
  • references/debug-return.md4.1 KB
  • references/intake.md8.3 KB
  • references/next-work-handoff.md4.5 KB
  • references/plan-brief.md3.9 KB
  • references/review-followup.md8.5 KB
  • references/shipping.md8.5 KB
  • references/stage-routing.md8.0 KB
  • references/task-visibility.md1.8 KB
  • references/tracker-defer.md14.4 KB
  • references/work-return.md4.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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-plan wrote 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-pov first, 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-brainstorm when a human is present, and to ce-plan in 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-pov did 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)

  1. Produce the work source per references/intake.md. On the plan route, read references/plan-brief.md first; it alone defines the settled-decisions brief and the artifact-root rule. Any explicit status: blocked return, including settled-decision-invalidated, stops the run. Blocked status outranks an existing artifact and is never retried. Only absence of both a blocker and a plan file ce-plan reported writing this run invokes ce-plan a second time with the same arguments, reusing the composed brief verbatim; the plan must then pass the readiness check in references/plan-brief.md. On the plan route the plan_model:<alias> carrier rides beside the request when a planning-stage directive resolved. Record the work source for every later step. LFG never launches /goal directly; ce-work implements and returns control.

  2. Read references/work-return.md first, then invoke the ce-work skill with mode:return-to-caller <plan-path-from-step-1>. On the defect route this step does not run: ce-debug already implemented and committed, and references/debug-return.md was its gate. Only a valid status: complete may advance; every other status or malformed return stops the pipeline.

  3. Read references/review-followup.md now; it governs steps 3 through 7. Invoke the ce-simplify-code skill with mode:pipeline on the branch diff; skip only the invocation for a docs-only or roughly sub-10-line change.

  4. Invoke the ce-code-review skill with mode:agent plan:<plan-path-from-step-1>; on the defect route omit plan:. A settled_conflict finding 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.

  1. 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.

  2. Autonomous residual handoff: whenever an unapplied actionable finding, a settled_conflict stamp from step 4, or a proceeded-and-flagged settled_decision_conflicts entry 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.

  3. Invoke the ce-compound skill with mode:non-interactive when the run produced durable reasoning the code, tests, and plan do not carry; that file states the full condition. Documentation skipped is success; running here puts the learning in the PR at open.

  4. Invoke the ce-test-browser skill with mode:pipeline.

  5. Read references/shipping.md first; it governs steps 9 through 11. Then invoke the ce-commit-push-pr skill with mode:pipeline branding:on.

  6. Watch the PR to CI-decided with ce-babysit-pr mode:pipeline <pr-url> when an open PR exists, as references/shipping.md decides. Do not reimplement CI-watching here.

  7. Output <promise>DONE</promise> after the close-out in references/shipping.md.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

ce-commit

무료

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin2.6만2026년 10월 17일 업데이트

EveryInc의 스킬 모두 보기

이 스킬의 문제 신고