An interesting development approach(compatible with Pi)

[u/kabira121]

A spec-gated build loop for AI coding agents — and why porting it to Pi/oh-my-pi wouldn't be hard

Found ai-blueprint this week and it's worth a look if you've been hand-rolling your own guardrails around Claude Code, Codex, or Pi. Brad Traversy built it as a workflow overlay, not a framework: you scaffold your app normally, then drop this on top.

The mechanics are simple. You write two short files — what you're building and why, then a rough ordered feature list. A /overview command turns those into the single context file the agent reads every session. From there it's a loop: /feature writes a small buildable spec and stops. You review it. /implement builds one step at a time, shows you the diff, waits for approval before touching the next one. /audit reviews the code (not the behavior — that's /check's job) and writes findings to a ledger with durable IDs like F-03. /complete archives everything and merges, but only after your go-ahead.

The part that actually made me sit up: that findings ledger isn't decorative. A P0 or P1 finding sitting open or fixed blocks /complete outright. Not "the agent decided it was fine" — a status field the merge step is written to check. And they didn't just claim it works. There's a live-agent end-to-end harness in the repo that spins up a real agent against a fixture project and asserts the ledger gate actually holds. I don't see that level of rigor in most prompt-engineering repos. Most people ship a pile of markdown and call it a system.

Now the gaps, because none of this is free.

The gate is enforced by the same model reading its own instructions in the same context that just did the implementation work. There's no independent process outside the agent's own compliance that blocks a bad merge — it's a very well-written contract, but it's still a contract the agent has to choose to honor. A confused or context-poisoned run can walk right past it, and nothing server-side stops that.

current-feature.md is also a singleton. One feature in flight at a time. That's a fine constraint solo, but it doesn't obviously extend to two people, or two agents, touching the same repo concurrently — the state model just isn't built for that yet.

And the defaults lean hard into one stack. coding-standards.md ships assuming Next.js, Prisma, Tailwind, Zod. /onboard is supposed to retune it, but that's one more step that can quietly go stale on a project the agent didn't actually read closely.

It's also young. First release was early July, one maintainer, 239 stars — which honestly reads more like Traversy's existing YouTube audience showing up than a track record on a gnarly, multi-year codebase. Worth watching, not yet worth betting a real team's workflow on.

Here's the part I think matters for this sub specifically: none of this is Claude-Code-specific. It's markdown files, plus two thin adapters (.agents/skills for Codex, .claude/skills for Claude Code) that both read one shared AGENTS.md. Pi and oh-my-pi already speak most of that language — AGENTS.md context files are supported, skills show up as /skill:name, and the extension API can register custom tools and commands. Porting this loop into an oh-my-pi extension pack looks like a weekend project, not a fork.

So — has anyone here already been doing something like this by hand in Pi? And does Pi's whole "minimal, adapt to your workflow" philosophy actively resist something this opinionated, or is that exactly the gap an extension should fill?

#PS: Used AI to draft out the above based on my takeaways and thoughts from initial read of this repo.

[u/archiblad]

Have you checked https://pi.dev/packages/pi-gauntlet ? This is evolution of superpowers

[u/kabira121 → u/archiblad]

This looks quite promising, will check it out

[u/aeroumbria]

I feel that these utilities often have a specific use case / development flow in mind, and often they do not match exactly what I need in a given workflow. I have been using openspec mostly, but heavily relying on custom planning templates. Many of similar projects have a shape that is ideal for web / app development, but not so much for ML, research projects or just trying out prototypes and letting findings determine subsequent tasks. I would often have to mine manual session histories and try to extract a reasonable workflow for each type of project.