Break-This-Repo: The Story Engine That Treats a Novel Like a Patch Queue
A chaotic GitHub repo hides a disciplined AI writing system, where characters have visibility rules, editors apply JSON operations, and an Inspector AI resolves contradictions before the next scene lands.
This repository automatically merges pull requests without conflicts. All text is subject to edits via PR and shouldn't be trusted.
- Break-This-Repo is more interesting as a narrative engine than as an auto-merge prank.
- Its core trick is patch-based storytelling, where a GM applies surgical text operations instead of rewriting chapters wholesale.
- An Inspector AI acts like a validator, catching contradictions and arbiting story state before changes persist.
- The outer GitHub automation is a shell around a much stranger idea: collaboration governed by roles, visibility rules, and failure modes.
The joke in this repository is that the most visible part is the least interesting part. Yes, it auto-merges pull requests. But the deeper system treats fiction like state: characters have perception limits, scenes are edited with operations, and an Inspector AI checks whether the story still makes sense before the next move lands.
This Repo Has Two Personalities
At the top level, Break-This-Repo behaves like an invitation to poke at a vulnerable repo. Under that skin sits novel_sendbox, a multi-agent storytelling system built around Python, Flask, flat-file JSON storage, and custom LLM adapters. One layer courts disruption. The other layer is obsessed with control.
Why Narrative-as-Code Is the Real Trick
The novelty is not that an AI writes prose. The novelty is that the repo treats prose as something you can validate, patch, and merge. The GM does not just regenerate a chapter. It emits structured edit operations like replace, insert, and delete, which makes the story behave more like a document under source control than a blank page under prompt pressure.
Inside the Multi-Agent Story Pipeline
The pipeline is built around role separation. The dialogue agent receives the user, the context pack decides what a character can see, the character model speaks from that constrained view, the GM converts the result into text operations, and the Inspector AI decides whether the update survives.
That design matters because the system is defending continuity, not just generating text. The repository’s code includes fog-of-war logic, dormant character handling, and name-collision checks, all of which shrink the context window into something usable without pretending the rest of the world does not exist.
# Conceptual shape of the story update loop
context = build_context_pack(project, speaker)
response = character_ai.chat(context)
patch = gm_edit_generator(response, chapter_text)
result = apply_operations(chapter_text, patch["operations"])
verdict = inspector_ai.validate(project_state, result)
if verdict["approved"]:
save_chapter(result)
else:
retry_with_feedback()The adapter layer is equally practical. Instead of leaning on a heavy orchestration stack, the repo implements its own provider wrappers with retry logic and streaming support. That makes the system feel less like a framework demo and more like a working editor that had to survive real API failures.
The Outer Layer: A Repo Designed to Be Merged
The auto-merge layer is not a toy detail. It is a defensive GitHub Actions workflow that checks file paths and blocks tampering with .github. In other words, the project invites change while protecting the mechanism that lets it stay changeable.
| Axis | Break-This-Repo auto-merge | GitHub auto-merge / Mergify / Kodiak |
|---|---|---|
| Goal | Create a controlled opening that lets safe PRs flow through | Reduce merge friction and keep branches clean |
| Trigger condition | No merge conflicts, plus repository-specific safeguards | Status checks, rules, labels, or queue policies |
| Safety model | Intentional vulnerability with guardrails around the guardrails | Operational safety and branch hygiene |
| What gets automated | Merge acceptance itself | Merging, rebasing, queueing, and policy enforcement |
| Who controls the outcome | The repo, the workflow, and anyone submitting a conflict-free PR | Maintainers and bot rules |
| What makes it unusual | Automation is being used as a narrative device | Automation is being used as infrastructure |
That contrast is the point. Standard tooling tries to make merges boring. This repo makes the merge policy itself part of the story, then turns that policy into a pressure test for both code and collaboration.
What It Suggests About LLM Collaboration
This project reads like a prototype for governed co-writing. One model generates dialogue. Another model edits with surgical precision. A third model adjudicates contradictions. The repository itself acts like policy, deciding what can change and what must stay intact.
That is a more interesting model than a single all-purpose chatbot. It treats collaboration as a layered system of permissions, perception, and review. The result is not just a story engine. It is a small operating model for how agentic software might work when correctness and continuity matter.
