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

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

4. Invoke the ce-code-review skill with mode: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:agent is 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.

5. Apply and persist review fixes (REQUIRED after step 4, before residual handoff)

Load references/review-followup.md and 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.

6. Autonomous residual handoff (only when step 4 reported one or more actionable downstream-resolver findings not applied in step 5; skip when it reported Actionable 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.

1. Load references/tracker-defer.md in non-interactive mode. Pass the residual actionable findings from step 4/5 (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:

      gh pr view --json number,url,body,state

5. 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 Findings section 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

6. If no open PR exists, create a tracked fallback file at docs/residual-review-findings/<branch-or-head-sha>.md containing the composed section and the source PR-review run context. Stage only that file, commit it with docs(review): record residual review findings, and push the current branch. 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. This is the durable no-PR sink. Do not output DONE until either the existing PR body has been updated or this fallback file commit has been pushed. If both paths fail, stop and report the failed commands; do not silently proceed.

Never block DONE on tracker filing failures once residuals have been durably recorded. A no_sink outcome is success only when the findings are present in the PR body or in the pushed fallback file.

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

8. Invoke the ce-commit-push-pr skill.

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.

9. CI watch and autofix loop (only when an open PR exists for the current branch)

Detect the PR; if none exists or gh is unavailable, skip this step entirely and proceed to step 10.

   gh pr view --json number,url,state

For up to 3 fix iterations, repeat:

1. Wait for CI to complete:

      gh pr checks --watch

If 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).

2. Identify failing checks and pull their failure logs. Use gh pr checks --json name,state,conclusion,workflow,link to enumerate failures, then for each failing check read the run logs:

      gh run view <run-id> --log-failed

where <run-id> is parsed from the check's details URL or workflow run.

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

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

5. 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 Unresolved markdown 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.

10. Output <promise>DONE</promise> when complete

Start with step 1 now. Remember: plan FIRST, then work. Never skip the plan.

Review followup (LFG step 4–5)

ce-code-review is review-only. LFG applies eligible fixes itself, then commits.

Step 4 — invoke review

ce-code-review mode:agent plan:<plan-path-from-step-1>

Read the Actionable Findings summary and artifact path. Do not pass mode:autofix.

Capture parsed JSON (status, actionable_findings, findings, artifact_path, run_id) or the markdown Actionable Findings section. If status is failed, stop and surface reason.

Step 5 — apply and persist review fixes

What to apply

Apply a finding in the working tree only when all of the following hold:

1. `suggested_fix` is present — concrete change shape from the reviewer. 2. `confidence` is `100`, or `75` with cross-persona agreement noted in the report — do not apply anchor-50 findings. 3. The fix is mechanical — one coherent change, no contract/permission/security posture change, no new public API shape, no behavior change that needs product sign-off. 4. Evidence still matches the code at the cited file:line before editing.

Do not treat autofix_class as permission to auto-apply.

What not to apply

• autofix_class: manual without a clear mechanical suggested_fix
• autofix_class: advisory — report-only
• gated_auto findings that change behavior, contracts, auth, or permissions
• Anything that needs a design conversation

Execution

1. Filter actionable_findings (or markdown Actionable Findings) with the bar above. 2. Apply eligible fixes in the working tree in severity order (# stable from the review). 3. Run targeted tests when requires_verification: true on any applied finding. 4. If git status --short shows changes, stage only review-driven files, commit fix(review): apply review findings, and push before step 6. To push: if an upstream exists, run git push. If no upstream exists (common on a fresh feature branch, since step 8's ce-commit-push-pr has not run yet), 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. If no eligible fixes were applied, note explicitly and skip commit.

Step 6 — residual handoff

Residuals are actionable findings not applied in step 5 — not leftovers from in-skill autofix. Use the Actionable Findings summary / artifact from step 4.

Tracker Detection and Defer Execution

This reference covers how Defer actions file tickets in the project's tracker. It is loaded by SKILL.md when Interactive mode's routing question needs to decide whether to offer option C (File tickets), when the walk-through's Defer option executes, and when the bulk-preview of option C is shown. It is also loaded by autonomous callers (e.g., lfg) that need to file residual actionable findings without user prompts — see Execution Modes below.

---

Execution Modes

Tracker-defer has two execution modes. The caller selects one; the detection, fallback chain, and ticket composition are shared.

Interactive mode (default)

Used by ce-code-review Interactive mode's routing question, walk-through Defer actions, and bulk-preview option C. All user-facing prompts fire:

• First Defer of the session with a generic (non-named) label confirms the effective tracker choice.
• Execution failures prompt with Retry / Fall back to next sink / Convert to Skip.
• Labels in the routing question reflect named_sink_available (name the tracker) vs fallback generics.

Non-interactive mode

Used by autonomous callers like lfg that must not prompt. All blocking questions are skipped; the fallback chain is executed silently in order. Behavior:

• No confirmation on the first generic-label Defer; proceed directly.
• On execution failure, automatically fall to the next tier without prompting. Record the failure.
• On total chain exhaustion (every tier failed or no sink available), return findings in the no_sink bucket so the caller can route them to another surface (e.g., inline them in a PR description).
• Return a structured result: { filed: [{ finding_id, tracker, url }], failed: [{ finding_id, tracker, reason }], no_sink: [{ finding_id, title, severity, file, line }] }.

The caller decides how to surface the result to the user. The non-interactive mode treats "no sink available" as a data-producing outcome, not a prompt trigger.

---

Detection

The agent determines the project's tracker from whatever documentation is obvious. Primary source: the project's active instructions and conventions already in its context — no need to open or name specific instruction files. Read a file directly only when the relevant instructions aren't already in context: a subdirectory-scoped instruction file governing the area you're working in, or when you're a fresh subagent that wasn't given the project's instructions. Supplementary signals (when primary documentation is ambiguous): CONTRIBUTING.md, README.md, PR templates under .github/, visible tracker URLs in the repo.

A tracker can be surfaced via MCP tool (e.g., a Linear MCP server), CLI (e.g., gh), or direct API. All are acceptable. The detection output is a tuple with two availability flags — one for the named tracker specifically (drives label confidence in Interactive mode) and one for the full fallback chain (drives whether Defer is offered at all):

{ tracker_name, confidence, named_sink_available, any_sink_available }

Where:

• tracker_name — human-readable name ("Linear", "GitHub Issues", "Jira"), or null when detection cannot identify a specific tracker
• confidence — high when the tracker is named explicitly in documentation (or via a linked URL to a specific project/workspace) and is unambiguously the project's canonical tracker; low when the signal is thin, conflicting, or implied only
• named_sink_available — true only when the agent can actually invoke the detected tracker (MCP tool is loaded, CLI is authenticated, or API credentials are in environment); false when the tracker is documented but no tool reaches it, or when no tracker is found at all. Drives label confidence: inline tracker naming requires this to be true.
• any_sink_available — true when any tier in the fallback chain (named tracker or GitHub Issues via gh) can be invoked this session. Drives whether Defer is offered in Interactive mode, and drives the no_sink bucket in Non-interactive mode.

Detection is reasoning-based. Do not maintain an enumerated checklist of files to read. Read the obvious sources and form a confident conclusion; when the obvious sources don't resolve, the label falls back to generic wording and the agent confirms with the user before executing (Interactive mode only).

---

Probe timing and caching

Availability probes run at most once per session and only when Defer execution is imminent. Never speculatively at review start, never per-Defer, never per-walk-through-finding. The cached tuple is reused for every Defer action in the same run.

Typical probe sequence:

1. Consult the project's instructions already in context for tracker references — don't open or name specific instruction files; read one directly only when the relevant instructions aren't in context (subdirectory scope, or a fresh subagent). If nothing found, set tracker_name = null, confidence = low. 2. Probe the named tracker when one was found. For GitHub Issues, run gh auth status and gh repo view --json hasIssuesEnabled. For Linear or other connector/MCP-backed trackers, first discover available tools via the platform's tool-discovery primitive (e.g., ToolSearch in Claude Code) rather than assuming absence from an unloaded tool, then verify the discovered tool is responsive. For API-backed trackers, verify credentials wherever the platform exposes them (environment, connector auth, or a documented secrets location) — not only shell env vars. Set named_sink_available from the probe result. 3. Probe the GitHub Issues fallback to compute `any_sink_available`. Even when the named tracker was found and probed, gh matters for the no_sink bucket decision so that a run with no documented tracker but working gh still offers Defer.

• If named_sink_available = true: any_sink_available = true (no further probes needed).
• Otherwise, probe GitHub Issues via gh auth status + gh repo view --json hasIssuesEnabled (skip if already probed in step 2). If it works, any_sink_available = true.
• Otherwise, any_sink_available = false.

When Interactive mode's routing question is skipped entirely (R2 zero-findings case), no probes run. When the cached tuple is reused across a session, any named_sink_available = true from the session's first probe stays cached — do not re-probe per Defer.

---

Label logic (Interactive mode)

• When confidence = high AND named_sink_available = true: the routing question's option C and the walk-through's per-finding Defer option both include the tracker name verbatim. Example: File a Linear ticket per finding, Defer — file a Linear ticket.
• When any_sink_available = true but either confidence = low or named_sink_available = false (a fallback tier is working instead): the labels read generically — File an issue per finding, Defer — file a ticket. Before executing the first Defer of the session, the agent confirms the effective tracker choice with the user using the platform's blocking question tool.
• When any_sink_available = false: option C is omitted from the routing question, option B (Defer) is omitted from the walk-through per-finding options, and the agent tells the user why in the routing question's stem.

Non-interactive mode skips label decisions entirely — it acts silently on the detected sink.

---

Fallback chain

When the named tracker is unavailable or no tracker is named, fall back in this order. Prefer the project's detected tracker; use gh only when no named tracker was found or the named one is unreachable.

1. Named tracker (MCP tool, CLI, or API the agent can invoke directly, identified via Detection above) 2. GitHub Issues via `gh` — when gh auth status succeeds and the current repo has issues enabled (gh repo view --json hasIssuesEnabled returns true) 3. No sink — findings remain in the review report's residual-work section (Interactive mode) or are returned in the no_sink bucket for the caller to route (Non-interactive mode). The agent does not re-display them through a transient surface.

Previously this chain included a third in-session fallback tier. That tier was removed because in-session tasks do not survive past the session and therefore do not meet the "durable filing" intent of a Defer action. When no durable tracker exists, the correct behavior is to leave findings in the report (Interactive) or return them to the caller (Non-interactive).

---

Ticket composition

Every Defer action creates a ticket with the following content, adapted to the tracker's capabilities:

• Title: the merged finding's title (schema-capped at 10 words).
• Body:
• Plain-English problem statement — reads the persona-produced why_it_matters from the contributing reviewer's artifact file at /tmp/compound-engineering/ce-code-review/<run-id>/{reviewer}.json, using the same file + line_bucket(line, +/-3) + normalize(title) matching agent mode uses (see SKILL.md Stage 6 detail enrichment). Falls back to the merged finding's title, severity, file, and suggested_fix (when present) when no artifact match is available — these fields are guaranteed in the merge-tier compact return.
• Suggested fix (when present in the finding's suggested_fix).
• Evidence (direct quotes from the reviewer's artifact).
• Metadata block: Severity: <level>, Confidence: <score>, Reviewer(s): <list>, Finding ID: <fingerprint>.
• Labels (when the tracker supports labels): severity tag (P0, P1, P2, P3) and, when the tracker convention supports it, a category label sourced from the reviewer name.
• Length cap: when the composed body would exceed a tracker's body length limit, truncate with ... (continued in ce-code-review run artifact: /tmp/compound-engineering/ce-code-review/<run-id>/) and include the finding_id in both the truncated body and the metadata block so the artifact is discoverable.

The finding_id is a stable fingerprint composed as normalize(file) + line_bucket(line, +/-3) + normalize(title) — the same fingerprint used by the merge pipeline.

---

Failure path

When ticket creation fails at execution (API error, auth expiry mid-session, rate limit, malformed body rejected, 4xx/5xx response):

Interactive mode: surface the failure inline and ask the user using the platform's blocking question tool.

Stem:

Defer failed: <tracker name> returned <error summary>. How should the agent handle this finding?

Options:

• Retry on <tracker> — re-attempt the same tracker once more (useful for transient errors)
• Fall back to next sink — move this finding's Defer to the next tier in the fallback chain (e.g., from Linear to GitHub Issues)
• Convert to Skip — record the failure — abandon this Defer, note the failure in the completion report's failure section, and continue the walk-through or bulk flow

Non-interactive mode: do not prompt. Automatically fall through to the next tier. If every tier fails, record the finding in the failed bucket of the structured return and continue. If the chain exhausts with no sink ever available, the finding ends up in the no_sink bucket.

When a high-confidence named tracker fails at execution, the cached named_sink_available is set to false for the rest of the session. Subsequent Defer actions fall straight through to the next tier without retrying a confirmed-broken sink. any_sink_available is only downgraded to false when every tier has been confirmed broken — a failed Linear call that succeeds via gh keeps any_sink_available = true.

Only when ToolSearch explicitly returns no match or the tool call errors — or on a platform with no blocking question tool — fall back to numbered options and waiting for the user's reply (Interactive mode only).

---

Per-tracker behavior

Concrete behavior per tracker at execution time. The agent may invoke any of these through the appropriate interface (MCP, CLI, or API) — the choice depends on what is available in the current environment.

When uncertain, prefer "drop with explicit user-facing notice" over "pass through silently and hope." A Defer that produces no durable artifact and no user message is data loss.

---

Cross-platform notes

The question-tool name varies by platform. In Interactive mode, use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension)). In Claude Code the tool should already be loaded from the Interactive-mode pre-load step — if it isn't, call ToolSearch with query select:AskUserQuestion now. Fall back to numbered options in chat only when the harness genuinely lacks a blocking tool — ToolSearch returns no match, the tool call explicitly fails, or the runtime mode does not expose it (e.g., Codex edit modes without request_user_input). A pending schema load is not a fallback trigger. Never silently skip the question.

Non-interactive mode is platform-agnostic: it never prompts, so the platform's question tool is not relevant.