# Operating Through Loopflow
Loopflow owns git, worktrees, delegation, and release plumbing. Use `lf` for
those operations so placement, release state, and execution authority stay
consistent. Read-only inspection and ordinary edits/tests run directly here.
## Execute Here First
Stay in the worktree supplied for this run. Do the assigned work here; do not
create another worktree or launch another worker merely to execute it. When
worktree management is the task, use `lf wt`, never raw `git worktree`.
Use orchestration only when the user or selected skill calls for it. Do not
guess a Wave, inspect PM, or repair auth as a prerequisite for ordinary work.
If an explicitly requested service is unavailable, report the exact blocker
and continue whatever can be completed locally.
## Git and delivery
```bash
lf commit -m "<what changed and why>" # local checkpoint
lf sync --plan # inspect integration strategy
lf sync # apply it
lf pr publish --title "..." # push and create/update PR
lf pr submit # prepare for the user's merge click
lf pr arm # prepare and request auto-merge; return
lf pr land # watch CI, repair, and finish merged
```
Publish makes a PR ready for review; it does not sync. Submit is
for a reviewer to land; arm/land request auto-merge. Bare land keeps the Task open;
`-c` completes it after merge, and `--next <slug>` rotates its PR chain. Use the
selected delivery skill for preparation and recovery. `lf pr open` creates or
updates a draft and opens its page; use it when the user asks to see the PR.
It preserves an existing PR's readiness. Publish/submit/arm/land make drafts ready.
Preserve existing work before editing. Checkpoint coherent changes with
`lf commit`; never include another active contribution just because it is dirty.
Do not ask permission for reversible edits or local tests. Ask before pushing,
PR mutations, external messages or other external side effects, and destructive
operations unless already authorized by the user or selected workflow.
## Checks and Flow boundaries
Implement and compress do basic build/focused-test sanity checks. Gate owns
verification once; CI owns its matrix. Checks must run headless. Leave unavailable
checks to a capable later step and human judgment to demo/review; neither blocks
earlier work. Record a one-line result in scratch, not a verification ledger.
Fix actual failures and revise assumptions when observations contradict them.
Delegate only when authorized and when an independent subset makes the problem
smaller. Keep the main blocker inline. A supplied Flow is an instruction;
follow its authored order and review boundaries.
## Speak and inspect
Write in language the user would use themselves. In persisted artifacts—Tasks,
PRs, docs, memory, reports, and decision summaries—refer to people by name.
For example, if Maya made the request, write “Maya requested the prototype path.”
In conversation with Maya, write “You requested the prototype path.”
A stored transcript remains conversation;
a summary extracted from it uses names. Refer to other participants by name.
Use names supplied in context or by the person; never infer a requester from
the machine owner, account, or Task assignee. If a necessary name is unknown,
ask when possible or leave the attribution explicitly unresolved. Do not write
“the human,” substitute an ambiguous “you” in an artifact, or claim someone's
approval without evidence.
Answer the user in this conversation. Never open another
session merely to reach them. Headless, `lf ask "<request>"` opens a durable
session and waits for completion. Respect existing authorization.
A `human: true` Flow step uses the same Session surface: Complete returns
review feedback to the next step; a following loop-decide chooses navigation
through its authored edge. Readiness alone does not release the caller.
When asked about Loopflow state, use `lf wave list --json`, `lf wave status <wave> --json`,
or `lf roadmap --json`. Do not reconstruct shared state from processes or
worktrees. Detailed placement, Task supervision, and recovery belong to the
`loopflow` and `wave/operate` skills.
Use `lf screenshot SOURCE -o OUTPUT` for unattended HTML or URL captures;
never launch a GUI browser executable for capture. Keep credentials out of
terminal output, logs, and chat; follow the repository's secret-management policy.
## Context and durable knowledge
Keep agent progress in local working notes and the final Run response. Do not
post routine progress to Linear: Task comments are for new direction from people.
Agent comments published through `lf task comment` carry a progress marker and
are excluded from steers. Use `--steer` only for deliberate new direction.
Preserve `<!-- loopflow-progress:... -->` provenance
when writing progress through another integration.
Launch context has explicit budgets. An excerpt names its complete local source;
read relevant omitted sections before acting, rather than rereading whole archives.
Read the supplied repo guide and existing design before deriving another plan.
Recursive Markdown under `scratch/` enters this worktree's runs; selected Wave
context belongs to that Work. A path in another checkout does not transfer its
contents. Treat earlier drafts as evidence, not automatic approval.
Write designs to `scratch/<branch>.md` and open assumptions to
`scratch/questions.md`. Delivery preparation clears scratch: preserve useful
conclusions in their durable owner before shipping.
Put repeatable task instructions in the skill that exercises them; repo-wide
conventions in the repo agent guide; configuration in `.lf/config.yaml`.
Curate Wave decisions in `wave/<name>/MEMORY.md` through `realign`. Do not create
miscellaneous `.lf/` handoff notes or copy maintainer instructions into customer
skills.