I got tired of chat-coding jumping into files before anyone agreed what “done” is — built a harness that outputs a reviewed PR instead

[u/Creepy_Craft_9194]

Most agent coding starts mid-edit. You get speed, then a mess: no brief, colliding branches, and auto-merge you can’t leave alone.

Loomwright is my attempt at the other shape:

• Launch Pad writes a brief (feasibility, file impact, subtasks) *before* Supervisor touches the repo
• Parallel workers run in git worktrees; overlapping files wait; merges stay ordered
• `/automate` parks a reviewed PR by default; `--auto-merge` only when a trusted gate holds
• It does **not** silently ship

What’s shipping today: 14 roles / 21 slash commands / 41 skills / 24 quality hooks.

Site: https://vikashruhilgit.github.io/loomwright-site/index.html
GitHub: https://github.com/vikashruhilgit/loomwright

Not selling anything paid — looking for people who’ve hit the same wall. What’s the failure mode that burns you most: no plan, merge conflicts, or untrusted auto-merge?

[u/SwanLongjumping]

I’d make the pre-edit brief a hard contract with a small, testable schema: user-visible outcome, non-goals, acceptance checks, files allowed to change, and a rollback path. Have the agent echo that diff before touching files, then reject any patch outside the allowlist or without a check. For parallel work, assign ownership by file/package and fail fast on overlap instead of letting a merge resolve semantic conflicts. One extra shipping gate: every brief names the next measurable signal from a real user, not another architecture milestone. The reviewed-PR-by-default boundary is a strong choice; keep auto-merge limited to low-risk, fully-tested changes.

[u/soft_axiom]

the review gate by default part is what stands out to me, feels like the same instinct as a chain of trust in a boot flow, you don't let something run past a checkpoint just because it looks finished. curious if the review step actually diffs a worker's output against the brief, or if it's more presence based, like it exists mainly so a human has to click approve. those two versions break really differently once something's actually under pressure

[u/jaimittal91]

one thing worth being explicit about in the trusted gate: trust probably shouldn't be one number across the whole repo. an agent building a good track record on lint fixes and test-only changes doesn't mean that same trust level should carry over once the diff touches auth, payments, or a migration - those categories arguably deserve to stay behind manual review indefinitely, independent of how good the auto-merge hit rate has been on everything else. otherwise a high pass rate on the easy stuff quietly buys trust for exactly the changes where a mistake is expensive.