Thread Truncated (Cap Enforced)
Only the first 20 tweets are unrolled into slides to ensure reliable PDF exporting and high server performance.
Canvas & Ratio
Choose your destination platform format
Layout Template
Choose a content structure for your slides
Preset Themes
Typography & Sizing
Brand Kit Customization
AGENCYConfigure brand assets for headers & footers
Outro Slide CTA
Customize your closing call-to-action slide
Background Pattern
Build Your Carousel
Drag and drop any post card below onto a slide, or use the quick buttons to insert content/images instantly!
Most setups run agents once and hand you whatever comes out. A team that runs in loops keeps going until the work actually passes.
Below is the setup in 3 files: the agents, the loop that drives them, and the rules that tell them when to stop.
Here's the full setup 👇
Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: <b><a target="_blank" href="https://t.me/zodchixquant" color="blue">https://t.me/zodchixquant</a></b>🧠
## Why a one-shot team isn't enough
A team that runs once is a relay race with no finish line check. The writer writes, the tester tests, the reviewer reviews, and then it all lands on you, broken parts included.
A looping team closes that gap. When the tester finds a failure, it doesn't just report it and quit. The loop sends it back to the writer, who fixes it, and the cycle runs again. You only step in when everything actually passes, or when the team hits a wall it can't get past.
The setup is 3 files: the agents, the loop, and the stop rules.
## File 1: the agents
Two specialists, each with one job. Drop into <b>.claude/agents/.</b>
<b>builder.md:</b>
<pre><code lang="yaml">--- name: builder description: Writes and fixes code. Invoke to implement a task or to fix failures the checker found. tools: Read, Write, Edit, Glob, Grep, Bash model: sonnet --- You build and you fix. Nothing else. - On a new task: implement it, matching existing style. - On a fix request: read the failure, find the cause, fix that cause only. - Never weaken a test to make it pass. Fix the code. - Report what you changed in one line.</code></pre>
<b>checker.md:</b>
<pre><code lang="yaml">--- name: checker description: Runs all checks and reports what failed. Invoke after the builder. Never edits code. tools: Read, Grep, Glob, Bash model: sonnet --- You check, you never fix. Run all three, in order: 1. Tests: `npm test` (or `pytest -q`, `cargo test --quiet`) 2. Types: `npx tsc --noEmit` (or `pyright`, `cargo check`) 3. Lint: `npm run lint` (or `ruff check`, `cargo clippy`) Then report in this exact format: - All pass: "ALL GREEN" - Any fail: "FAILED" then each cause as `file:line - what broke - which check caught it` Never paraphrase a failure. Copy the real error. The builder fixes from your report, so a vague report wastes a whole cycle.</code></pre>
## File 2: the loop
This is the orchestrator that drives the cycle. Drop into <b>.claude/commands/loop.md:</b>
<pre><code lang="yaml">--- description: Run the builder and checker in a loop until all checks pass argument-hint: <task> allowed-tools: Read, Grep, Glob, Bash, Task model: opus --- Run this task as a loop: $ARGUMENTS 1. Write a one-line brief: goal, files in scope, definition of done. 2. Dispatch the builder to implement the task. 3. Dispatch the checker to run all checks. 4. If checker says ALL GREEN: stop, show me the result. 5. If checker says FAILED: send the failures to the builder to fix, then go back to step 3. 6. Repeat up to 5 cycles. Track the cycle count out loud. Stop conditions are in CLAUDE.md. Follow them exactly.</code></pre>
The loop is the whole idea: build, check, and if it failed, build again.