loopflow ยท diff
git:20261022.c0617ec to git:20261027.142e096
42 added, 19 removed. Audit A to A.
---
name: loopflow
- description: Launch agents, run Skills and Graphs, manage Sessions, worktrees and PRs with Loopflow; use Task and Wave APIs when requested or already associated.
+ description: Hand changes off as Loopflow Tasks that each end in a pull request; check on, steer, resume and land them; run the repository's Skills and Graphs with lf.
---
- # Use lf
+ # Work through lf
+ `lf` launches coding agents and keeps their sessions. Hand work off through it,
+ and keep this conversation free to talk.
+
+ ## Hand off changes as Tasks
+
+ When the person asks for a change that should end in a pull request, make it a
+ Task and run it, one Task per reviewable outcome:
+
```bash
- lf --version
- lf help <command-or-skill>
+ lf task create --title "<outcome in the person's words>" # prints the Task ID
+ lf task run <ID> # own worktree and branch; returns once running
+ lf open --task <ID> --link --format markdown # the link to give back
```
- Install only when requested. Use the requested Skills, Graphs, worktree and PR
- operations, following the user's tools and repository conventions.
- Do the requested work in
- this checkout; preserve existing contributions and authored Graph boundaries.
+ Give back each Task's link and say what it will deliver. Questions, reading
+ code and one-line fixes the person wants here happen in this checkout, without
+ a Task. When unsure whether something is one Task or several, propose the split
+ and ask.
- For work using Tasks, Waves or Projects, read `lf help skill work` in this conversation.
- That skill is the work API contract, also preloaded for work-associated launches.
- Continue an existing Task when one is supplied; unrelated repository Tasks do
- not select work. Operator skills are explicit procedures, not a consequence of
- having a Task. Desktop and custom clients use the same work APIs.
+ ## Keep track
- An external harness acts for its user; launching through lf supplies Session and
- process identity. Never invent Work identity or claim another caller's authority.
- Answer here rather than creating another Session to reach the user. Use supplied
- names in persisted artifacts and preserve unknown attribution.
+ ```bash
+ lf task list # open Tasks
+ lf task status <ID> # its run, its PR, what it needs from the person
+ lf comment <ID> "<direction>" # reaches the run before its next step
+ lf resume --task <ID> # the Task's conversation, for the person
+ lf land --wait-and-fix # only when the person asks to land
+ ```
- Command and skill help is the current reference. Documentation is available at
- https://loopflow.studio/docs/agent-api.md and https://loopflow.studio/llms.txt.
+ Report what status says. A finished run is not a merged PR, and a merged PR is
+ not a completed Task; say which happened.
+
+ ## Skills and Graphs
+
+ The repository's own Skills and Graphs come first. Find them with `lf list`,
+ read one with `lf help <name>`, then run it: `lf <skill>` here, or
+ `lf task run <ID> <graph>` on a Task.
+
+ ## Boundaries
+
+ - Use the agent, account and machine the person names (`-a`, `--account`,
+ `--machine`); otherwise lf's defaults.
+ - One run per Task at a time: check `lf task status <ID>` before starting another.
+ - Never invent a Task identity or act on a Task nobody named.
+ - `lf help <command>` is the current reference; check it before using a command
+ for the first time. Docs: https://loopflow.studio/docs/agent-api.md