Simooo45/bottle
9 stars · Last commit 2026-09-04
Lets Claude Code drive complex, multi-session projects while you stay at the helm: small markdown files (rules, backlog, roadmap, changelog) it reads in full every time, so nothing gets relearned. Out of credits with an idea? Jot it in BACKLOG.md for next time.
README preview
<p align="center"> <img src="bottle.png" width="200" alt="Bottle logo: a message in a bottle"> </p> <h1 align="center">Bottle</h1> <p align="center"> <em>A message in a bottle: something you write for a future reader you will never meet in person.</em> </p> <p align="center"> <img src="https://img.shields.io/github/license/Simooo45/bottle?style=flat-square&color=111111&cacheSeconds=3600" alt="License"> <img src="https://img.shields.io/badge/claude%20code-plugin-111111?style=flat-square" alt="Claude Code plugin"> </p> Every [Claude Code](https://claude.com/claude-code) session starts from zero. That is the part that really costs you time. Claude can read your whole codebase in seconds, but it does not remember what an earlier session already tried, fixed, or learned the hard way. So the same bugs come back, and you answer the same questions twice. Bottle fixes this with a few small markdown files that every new session reads first. They are short enough to read in full, so nothing important gets lost, and you never have to explain it all again. This is what makes it possible to build something big through normal conversation, not just quick one-off edits. You describe what you want in everyday language, and Claude can carry a real, multi-step project forward across many sessions, while you stay in charge: you see the plan, you approve the direction, and you decide what happens next, instead of losing track of the project or re-explaining it every time. Write down one big, messy request, and Claude splits it into separate, simpler tasks on its own, so nothing gets lost inside one oversized item. This is the difference between vibecoding and real engineering: not just prompting your way to something that happens to work and hoping you remember why, but real tracked requirements, a real changelog, and a real roadmap, a written record you can check the project against instead of just a feeling that it's fine.