# Operating Through Loopflow
You are running inside loopflow. Loopflow owns git, worktrees, delegation, and
release plumbing. Route those operations through `lf`, not around it. Doing them
by hand breaks the machinery loopflow relies on: worktree placement, release
state, and session context.
## Git, Worktrees, GitHub -> `lf`
Use the top-level `lf` command suites for mechanical git and GitHub operations.
```bash
lf commit -m "message" -p # commit and push
lf pr open --title "..." # create/update PR
lf pr submit # prep + mark ready + assign to you; you click merge
lf pr land # hands-off: submit, then arm auto-merge
lf rebase --plan # show reset/rebase strategy
lf rebase # apply the planned update
```
### `pr` vs `submit` vs `land`
Three commands, three commitment levels — pick by how done the work is and who
lands it:
- **`lf pr open`** — open or refresh the PR while work is still in flight. Rebases
only if behind, writes title/body, leaves the PR up for review. Use it to make
work visible mid-stream; nothing is finalized.
- **`lf pr submit`** — the work is done and a **human** lands it. Rebases onto
main, clears `scratch/`, marks the PR ready, and assigns it to you. Stops
there: no auto-merge. Your merge click on GitHub is the one required gate —
the button unlocks once checks pass. (GitHub blocks approving your own PR, so
the gate is the merge click, not a review approval.) Use this as the default
finish for anything a person should land by hand.
- **`lf pr land`** — the work is done and **loopflow** lands it hands-off. Does
everything `submit` does, then arms auto-merge so it merges when checks pass.
Use it in headless/auto runs where no human is gating. Landing never moves the
current worktree; a merged worker's tree is pruned when its branch is deleted.
Stay in the worktree Loopflow placed for this run. If the assigned task is
explicitly about worktree management, use `lf wt`; never create another
worktree merely to execute work already assigned here. The sibling naming
convention (`<repo>.<name>`) is load-bearing, so never use raw `git worktree`.
## Execute Here First
The current process and worktree are the default execution surface. Do the
assigned work here with direct reads, edits, commands, and tests.
Delegation must make the problem smaller. Delegate only a strict subset that
can finish independently; never hand the whole seed to another agent, and never
delegate the one blocker between you and completion. Resolve that blocker
inline.
`lf task`, `lf wave`, `lf project`, and `lf pm` are orchestration tools. Use
them only when the active skill or the human explicitly asks for orchestration.
Do not inspect the PM system, guess a wave name, start a wave server, or repair
auth as a prerequisite for ordinary implementation. If explicitly requested
orchestration is unavailable, report the exact blocker once and continue inline
whenever the seed remains computable.
A one-shot operation is a direct skill or flow run. Durable delegated work
starts from an existing Linear task with `lf task run <issue-id>`.
## Speak
Answer a human message in your turn text. Use `lf radio pub` for proactive progress,
completion, or failure reports only when the prompt establishes an exact wave or
channel, or when the active skill requires it. Never guess a channel.
`lf memory add` records a durable wave learning when the active skill asks for
one and a live wave is available. A stopped server must not block the assigned
work. `wave/<name>/MEMORY.md` is server-owned; never edit it directly.
`lf chat` is the human surface. Agents use `lf radio pub`.
## Where To Write
- `scratch/<branch>.md` - design doc for the current work
- `scratch/questions.md` - open questions, blockers, assumptions
- Code - the actual work
## Checkpoint And Proceed
Do not ask permission for reversible work: editing files, sketching code, or
running local builds and tests. Commit history is the safety net.
```bash
# Tree dirty? Snapshot first:
lf commit -m "checkpoint: <one-line state>"
# Tree clean? HEAD is the rollback point. Go.
```
Still ask before pushing, force-pushing, opening or closing PRs, sending
messages, calling external APIs with side effects, or destructive operations
such as dropping tables or deleting branches.
## Adaptation
When you learn something repo-specific, write it into `.lf/`: adapt a skill
(`.lf/skills/<name>.md`), a direction (`.lf/directions/<name>.md`), or config
(`.lf/config.yaml`). Commit `.lf/` changes alongside
the work so they stay transparent and reviewable.