I’d been having the same conversations repeatedly. Explain context, provide files, give instructions, iterate on results. Each time, the same overhead. Workflows were too heavy. Chat was too manual. Commands became the middle ground – structure without full automation.
Evaluation framework defined. Common templates created. Quality levels clear. Time to systematically evaluate every workflow file and bring them all to exceptional quality. Dozens of files across multiple workflows. Different patterns for coordinators, workers, and documentation.
Evaluation identified gold standard files – the exceptional examples. But gold standards were specific implementations. To make those patterns reusable for new workflows, I needed to extract what made them exceptional into common templates that any workflow could follow.
After weeks of refinement, I had a problem. When do I stop? How do I know when a file is good enough? I needed objective criteria to measure quality. Three levels emerged: good, excellent, exceptional.
I’d built standards files weeks ago. The architecture was clear: workers execute, standards provide context. But clear/concise/precise refinement revealed the truth – workers had gotten bloated with context that belonged in standards. Time to enforce the delegation architecture I’d already designed.
All my agents were using Sonnet. Every single one. Complex analysis agents and simple command-running agents. Same model. Then I started wondering if some agents might benefit from different models. Claude helped me understand when to use each model and analyzed every agent to recommend which should use Haiku and which should use Opus.
Testing revealed instruction problems everywhere. Inconsistent results. Workers interpreting the same instructions differently. I needed a methodology to systematically identify what was wrong and how to fix it. The answer came from work I’d been doing on other projects: ask if every file is clear, concise, and precise.
The batch scripts worked beautifully. But they were slow. I tracked the timing and found the bottleneck: git commits taking two minutes each. The solution wasn’t optimization. It was recognizing I’d chosen the wrong tool entirely.
I had a working script for the first workflow. Three more workflows needed scripts. And I already knew I’d need a master script to run them in sequence. Claude wrote the second script. When I reviewed it, I found missing pieces and different approaches. That’s when I realized: this needed shared code.
Background execution was fast and consistent. But I had no idea what actually happened until I checked the logs. I needed systematic logging, timing data, automated commits, PR creation—the full testing workflow. Claude wrote me a shell script. That script became the foundation for testing at scale.