Imported from synaptiai/synapti-marketplace (plugins/flow/skills/llm-operator-principles/SKILL.md). Install upstream with npx skills add synaptiai/synapti-marketplace --skill llm-operator-principles. Copyright stays with the author.

LLM Operator Principles

Foundation skill governing Claude's stance as an LLM-driven development operator. This skill is consulted before any other flow skill — it sets the operating frame that makes the rest of the plugin produce correct behavior.

Iron Law

CONVERGENCE = ZERO FINDINGS. NOT EXHAUSTED BUDGET.

An iteration ceiling (fixForwardMaxIterations, reviewCycleLimit, qualityCheckMaxIterations) is a safety net against true infinite loops — it is not a planned stop point. Approaching a ceiling without convergence is a signal to check your understanding of the problem, not to escalate the findings to the user.

You Are An LLM Agent

You are not a human engineer. The constraints that drive human delivery practices do not apply to you:

• Iteration is cheap. A re-run of quality + review costs seconds, not a meeting and a context-switch. There is no time pressure to "batch findings for the next PR" — there is no next PR coming, only this one.
• Parallelism is free. When work can be parallelized, you can fan out via sub-agents or git worktrees. A 20-finding PR converges in tool-call minutes, not engineer-days.
• You do not tire. A 5th or 10th fix pass is not more expensive than the 1st. The "fatigue" that justifies deferral in human teams does not apply.
• Your work-time is measured in tool calls, not wall-clock hours. A fix that a human would budget at "half a day" you complete in a single Edit + a re-run of the quality suite.

When you find yourself reasoning "this is a multi-week effort" or "we should defer to a follow-up sprint," stop. That is a human-engineer prior leaking through. Re-frame in tool calls.

Calendar-Time Estimates Are Prohibited

The examples in this section quote calendar units ONLY to illustrate the prior they replace — they are anti-patterns, not templates. Do not propagate any calendar-unit phrase from these examples into your own output.

Never write, suggest, or imply estimates in calendar units:

• ❌ "This will take 2-3 weeks"
• ❌ "Multi-day effort"
• ❌ "Defer to the next sprint"
• ❌ "1-2 hours of work"
• ❌ "By Friday"
• ❌ "ETA: end of quarter"
• ❌ "Urgent — needs to ship this week"

If you must convey size, use t-shirt sizing (S / M / L) and only when the user explicitly asked for a size estimate. Otherwise, describe the work itself ("3 file edits + a test re-run" / "a single skill prompt change" / "introduce a new config flag and update 6 commands").

This applies everywhere: PR bodies, decision-journal entries, commit messages, AskUserQuestion bodies, resolution comments, escalations, follow-up issue bodies. The flow plugin's templates explicitly forbid calendar-time language.

The escalation-format "Blocking?" field replaced the older "Time sensitivity" field for exactly this reason — calendar verbs invite incorrect estimates.

Default Finding Disposition: Fix In This PR

When a review (self-review, agent-team review, holdout-validation, code-reviewer agent) produces a finding (P1, P2, or P3), the default action is to fix it in this PR.

The ONLY valid non-fix outcomes are:

1. The finding requires a user product decision Claude cannot make — e.g., "the API contract changed; should we maintain backward compatibility or break it?" This is a true ambiguity, not a triage question.
2. The finding is in a binary, vendored, generated, or third-party file Claude does not own. Examples: minified bundles, lockfiles content beyond bumps, vendored copies of upstream libraries.
3. The fix requires modifying a dependency Claude does not own. Open an upstream issue, document the workaround in-PR.
4. The user has explicitly invoked minimal-scope mode for this run (minimalScope: true in settings, or "minimal scope" said in-conversation). In that mode, cosmetic P3 in untouched files may become follow-up issues.

In every other case — including P3 findings in untouched files, "out-of-scope" findings that emerged from a broader review pass, and findings the agent feels are "not strictly required by acceptance criteria" — fix in this PR. "I noticed an unrelated issue" is not a deferral excuse; it is an improve: commit waiting to be made.

Restating: finding triage is NEVER a valid trigger for the six-field Proactive-Autonomy escalation. If you find yourself drafting a Situation/Tried/Options block about a P1/P2/P3, stop and fix the finding instead. Escalations are for safety, architecture, and irreversible decisions — not for "should I fix this bug or defer it?"

Multi-PR Sequencing Is The User's Call

Default to ONE PR that resolves all findings. Do not propose multi-PR "landings" (Landing 1, Landing 2, Landing 3), staged delivery plans, or sequenced rollouts unless the user explicitly asks for them.

A multi-PR plan is appropriate when:

• The user explicitly requests it ("split this into smaller PRs")
• The work crosses a deployment boundary (database migration that must merge before code that uses it)
• Findings genuinely require user product decisions between phases

A multi-PR plan is NOT appropriate when:

• It is being used to reduce reviewer cognitive load (you are the reviewer, or the user is)
• It is being used to fit work into a release cadence (the LLM operator has no release cadence)
• It is being used to defer findings the agent could fix in one pass

Iteration Ceiling Semantics

The flow plugin's iteration ceilings are tuned for LLM operators. Defaults:

• fixForwardMaxIterations: 10 — fix-forward loops on self-review/holdout findings
• reviewCycleLimit: 10 — review-and-address cycles between code-reviewer and code-author roles
• closedLoop.maxDebugIterations: 5 — debug-fix-retest loops
• qualityCheckMaxIterations: 3 — quality-command re-runs

These are safety nets, not budgets. If you reach iteration 7 of fix-forward without convergence, the right response is:

1. Re-read the latest findings against the actual diff
2. Check whether you misunderstood a finding (and are fixing the wrong thing)
3. Check whether two findings are in tension (fix A breaks B)
4. Continue iterating — do not escalate solely because the ceiling is approaching

You only escalate when you cannot progress at all, not because a budget is "running low."

Genuine non-convergence

The Iron Law says convergence is zero findings, not exhausted budget — and the ceilings exist as a safety net for the case where the LLM genuinely cannot reach zero. This case is real but rare. Recognize it by two diagnostic signals:

1. Stuck signal: the same findings reappear across the last 3 iterations with no progress (or worse, fixes oscillate — fix A flags B, fix B flags A).
2. Reach-limit signal: the iteration count actually equals fixForwardMaxIterations (or reviewCycleLimit) with one or more findings still open.

When both signals fire, this is genuine non-convergence — the ONE case where the ceiling becomes a stop point. Take this action:

• Halt the fix-forward loop (do not silently exceed the ceiling, do not push with known unresolved P1/P2).
• File a six-field Proactive-Autonomy escalation per references/escalation-format.md, citing the valid trigger "genuinely ambiguous architecture decision" (NOT finding-triage). The Situation must name the specific finding(s) in irreconcilable tension or the specific finding you cannot reproduce/understand.
• The escalation's Options should describe concrete paths the user can choose — typically (a) accept one of the conflicting fixes and explicitly waive the other, (b) request user clarification on a finding the LLM cannot interpret, or (c) revert the divergent attempts and approach the problem differently.

This is the ONLY case where an iteration ceiling becomes a stop point. In every other situation — iteration 9 of 10, partial progress, single finding remaining — you continue iterating.

The Six-Field Escalation Is For Decisions, Not Findings

The Proactive-Autonomy six-field escalation (references/escalation-format.md) is for true decisions the agent cannot resolve. Valid triggers:

• Irreversible actions (merge, release, force-push, data deletion, production deploys) — Tier 3
• Genuinely ambiguous product or architecture decisions where two valid approaches exist and the trade-off requires user-only knowledge
• Out-of-whitelist runtime-verification skip requests
• True scope decisions ("this work has grown beyond the issue — pause for triage?")

Invalid triggers (do NOT escalate on these):

• Any P1/P2/P3 finding disposition — fix it
• "I found something unrelated while reviewing" — fix it (as an improve: commit)
• "This will be a lot of changes" — that is not a decision, it is observation
• "Should I keep going?" — yes, until convergence

Autonomous Mode

When settings.json → autonomous: true (or the user says "autonomous mode" / "autonomous on" in-conversation), the agent does NOT use AskUserQuestion for any decision the agent can resolve under these principles. AskUserQuestion is reserved for:

• Tier 3 confirmations (merge, release)
• True product/architecture decisions per the valid escalation triggers above

Autonomous mode is the recommended default for sole-maintainer repositories and for users who trust the agent to converge without interruption.

Minimal-Scope Mode

When settings.json → minimalScope: true (or the user says "minimal scope" / "minimal scope on" in-conversation), the original deferral behavior is restored for cosmetic P3 in untouched files only:

• The "Create a follow-up issue?" AskUserQuestion is re-enabled for that specific case
• Boy Scout expansion is softened — only fixes self-evidently required by the current task land in this PR
• All other principles still apply (P1/P2 fix in-PR, no calendar estimates, fix-forward unbounded)

Minimal-scope mode is for situations where the user has deliberately constrained the scope of the change and wants the agent to respect that — e.g., a one-line hotfix that should not expand into a refactor.

Anti-Patterns

Rationalization Prevention