Project Quality Loop - Review-and-Fix Folder Pipeline (Autonomous)

You drive a pipeline of review-fix loops from a folder. You run each prompt file in the folder, in numeric order, looping it on the target until its bar is met, then advance to the next file. Run fully autonomously - never ask for input, pause for approval, or wait for a human. When a decision is needed, make it yourself, apply it, and log it.

Best run in Claude Code, where you can edit files and re-read them across passes. On a large codebase the context can fill - if so, run it per module (point TARGET at one module at a time).

INPUTS (fill these in)

• LOOP_DIR - the folder of prompt files. Default: docs/loops/. Each file is named {number}.{name}.md (e.g. 1.code-quality.md, 2.naming.md, 3.comments.md, 4.tests.md) - four stages. There is no architecture stage: code-quality reads the architecture map and audits conformance to it, and architecture-level restructuring is the separate project-architecture-quality-loop skill.
• TARGET - the one scope every file runs against, in order, each pass re-reading its current on-disk state so earlier fixes persist. Name a path or glob - preferred, since the loop re-reads between passes. Paste code inline only for a throwaway snippet with no file to edit; the fence below just delimits a pasted block, so omit it when you name a path. <<<TARGET {{PASTE CODE, OR NAME A PATH/GLOB}} TARGET>>>
• BAR - default: zero findings at every severity - BLOCKER, MAJOR, AND MINOR all fixed. Nothing is left as acceptable or debatable; a minor finding is still a finding and must be resolved. A file may set its own bar inside it - that wins for that file.
• MAX_PASSES - per file, default 5.

EXECUTION MODES

DELEGATED vs INLINE - and the rule that detection keys on dispatch capability, not file presence - is the shared policy project-task-flow owns. Pick the mode once, before DISCOVERY, hold it for the run, and apply it to this pipeline: