TryParse
A parser combinator library built in 2 iterations.
Try It
The Prompt
# TryParse - Ralph Loop
## Mission
Make all tests pass. Build a parser combinator library with format parsers and auto-detection.
## Process
1. Read `.agent/state.md` for current progress
2. Run `npm test` to see what's failing
3. Fix one thing at a time
4. Commit each fix: `git commit -m "feat: [what you did]"`
5. Update `.agent/state.md` with progress
6. Repeat until all tests pass
## When Done
Output: **RALPH_COMPLETE**
## Constraints
- Use the combinator pattern (compose small parsers into larger ones)
- All parsers return `{ success: true, value, remaining, position }` or `{ success: false, error, position }`
- Errors must include position information
- Work in `code/` directory
- Run unit tests with `npm test`
- Run E2E tests with `npm run test:e2e` (do this last, after unit tests pass)The Journey
After Photon Forge took 9 loops with detailed prompts, I wanted to test the opposite approach: minimal prompt, one loop, let Claude figure it out.
I set up 180 unit tests and 20 E2E tests for a parser combinator library. URL, cron, semver, glob, and duration parsers, plus auto-detection. All stubs throwing 'Not implemented'. One prompt under 100 words.
It completed in 1 iteration. Everything. 180 tests. I thought I did something wrong.
Then I tried to build it. 17 TypeScript errors. All unused imports. Vitest doesn't run tsc in strict mode, so the tests passed but the build failed.
Added a build test that runs 'tsc --noEmit'. Ran the loop again. Fixed in 1 more iteration.
The key insight: for bounded problems with clear test specifications, the loop is a safety net you might not need. The test output IS the state. Claude sees what's broken, fixes it, done.
Lessons Learned
- ✓Build tests catch what unit tests miss (tsc strict mode)
- ✓One iteration can be enough for bounded, well-defined problems
- ✓Scratchpad may be unnecessary when test output provides sufficient state
- ✓Tests = memory, Code = progress, Loop = safety net