pi-loopflows 0.1.1 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +5 -0
- package/README.md +1 -29
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,10 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.1.2 - 2026-06-22
|
|
4
|
+
|
|
5
|
+
- Tighten README positioning around loopflows as LEGO-like subagent workflows.
|
|
6
|
+
- Remove the dedicated Launch Control README section while keeping it listed as a bundled workflow.
|
|
7
|
+
|
|
3
8
|
## 0.1.1 - 2026-06-22
|
|
4
9
|
|
|
5
10
|
- Polish product README and usage guidance for public release.
|
package/README.md
CHANGED
|
@@ -2,9 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Build deterministic AI workflows out of Pi subagents.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
`pi-loopflows` ships with a production-ready **Launch Control** loopflow out of the box, and it is also a flexible constructor for your own workflows.
|
|
5
|
+
Think of **loopflows** as LEGO for subagents. You take small specialist agents, connect them into a process, add gates where decisions matter, and let the workflow move forward, branch, loop back, or stop based on explicit results. Instead of one giant prompt, you get a reusable structure for how agents collaborate: steps, feedback loops, stop rules, and saved evidence.
|
|
8
6
|
|
|
9
7
|
## Why loopflows
|
|
10
8
|
|
|
@@ -65,32 +63,6 @@ loopflow_run({
|
|
|
65
63
|
- `build-review` — small generic build → review → fix loop for scoped implementation tasks.
|
|
66
64
|
- `plan-review` — planning loop that lets a reviewer reject vague or unsafe plans before implementation.
|
|
67
65
|
|
|
68
|
-
## Built-in: Launch Control
|
|
69
|
-
|
|
70
|
-
Launch Control is bundled because it is the clearest example of why loopflows exist. It turns a plan into a controlled implementation process:
|
|
71
|
-
|
|
72
|
-
```text
|
|
73
|
-
context-builder
|
|
74
|
-
→ planner
|
|
75
|
-
→ loop max 3:
|
|
76
|
-
worker
|
|
77
|
-
reviewer gate
|
|
78
|
-
approved -> continue
|
|
79
|
-
changes_requested -> repeat
|
|
80
|
-
blocked -> stop
|
|
81
|
-
→ final audit
|
|
82
|
-
```
|
|
83
|
-
|
|
84
|
-
Use it when drift, skipped validation, PR correctness, or multi-step delivery risk matter.
|
|
85
|
-
|
|
86
|
-
Example:
|
|
87
|
-
|
|
88
|
-
```text
|
|
89
|
-
/loopflow launch-control -- Implement the auth migration plan in docs/auth-plan.md
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
Launch Control is not hard-coded. It is just a `.loopflow.json` file. You can copy it, change the agents, change the prompts, adjust max iterations, add stricter gates, or create a project-specific version in `.pi/loopflows/`.
|
|
93
|
-
|
|
94
66
|
## Loopflows as a constructor
|
|
95
67
|
|
|
96
68
|
Think of loopflows as LEGO for agent processes. A loopflow can use any available Pi subagent role:
|
package/package.json
CHANGED