pi-gauntlet 4.2.0 → 4.2.1
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 +13 -0
- package/README.md +11 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,18 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## v4.2.1 - 2026-07-04
|
|
4
|
+
|
|
5
|
+
Each tagged release now gets GitHub Release notes automatically, sourced from the
|
|
6
|
+
CHANGELOG rather than an LLM or external API.
|
|
7
|
+
|
|
8
|
+
- **`release.yml` posts release notes.** A new `release-notes` job (`needs: publish`,
|
|
9
|
+
`contents: write`) extracts the top `CHANGELOG.md` section with `awk` and publishes
|
|
10
|
+
it as the GitHub Release body via `gh release create` (falling back to `gh release
|
|
11
|
+
edit`). Deterministic and key-free - the curated summary + key-takeaways bullets
|
|
12
|
+
already live in the CHANGELOG. Takes effect on the next tag push.
|
|
13
|
+
- **Docs.** `README.md` gains a `## Why` section; `AGENTS.md`'s release-workflow
|
|
14
|
+
description now covers the notes job.
|
|
15
|
+
|
|
3
16
|
## v4.2.0 - 2026-07-04
|
|
4
17
|
|
|
5
18
|
Documents become first-class origin requirements, the post-execution review stack
|
package/README.md
CHANGED
|
@@ -1,6 +1,16 @@
|
|
|
1
1
|
# pi-gauntlet
|
|
2
2
|
|
|
3
|
-
A workflow library for the [pi coding agent](https://github.com/badlogic/pi-mono): opinionated skills, ready-to-use subagent personas, and three runtime extensions.
|
|
3
|
+
A workflow library for the [pi coding agent](https://github.com/badlogic/pi-mono): opinionated skills, ready-to-use subagent personas, and three runtime extensions that turn "run the agent in a loop" into a gated pipeline from idea to merge.
|
|
4
|
+
|
|
5
|
+
## Why
|
|
6
|
+
|
|
7
|
+
The agentic loop everyone's excited about - point an agent at a problem, let it iterate until done - is the easy part. A bare loop has nothing to aim at, nothing to stop it shipping the wrong thing, and no check that the output matches the ask. It holds up on narrow tasks and falls apart on everything open-ended.
|
|
8
|
+
|
|
9
|
+
pi-gauntlet is the scaffolding that makes the loop hold: **brainstorm → plan → implement → verify → ship**, each stage a gate the next one can't open until it closes.
|
|
10
|
+
|
|
11
|
+
**A gate here is an automated check, not a signature to collect.** Most are machine-enforced - a multi-model spec critique, an adversarial code review, a conformance check that confronts the finished diff against your original ask, and an extension that blocks a commit or push until verification has actually passed. The agent can't wave itself through, and you're not rubber-stamping each step. Human judgment is spent on the two decisions that need it - *what to build* up front and *how to land it* at the end - while the middle (plan → execution, task → task) runs without pausing for you.
|
|
12
|
+
|
|
13
|
+
The spec and docs it produces get committed to the repo, so the next change starts from ground truth, not a blank slate. The loop is the easy 5%; the gated system around it is the whole job - that's what this is.
|
|
4
14
|
|
|
5
15
|
A diverged reinterpretation of [obra/superpowers](https://github.com/obra/superpowers) (Claude Code), by way of [coctostan/pi-superpowers-plus](https://github.com/coctostan/pi-superpowers-plus), rebuilt for pi with enforced gates, a spec council, conformance review, and parallel execution waves. See [Lineage](#lineage) for what changed.
|
|
6
16
|
|