Crush Architecture and Runtime
1. The workspace shape​
The repo structure shows a focused product with these concerns:
| Area | Why it matters |
|---|---|
| core source code | Main coding-agent logic |
| docs and examples | User and contributor entry points |
| packaging and tooling | Build and release support |
Crush looks more like a crafted developer product than a raw experiment repo.
2. The runtime mental model​
At runtime, Crush generally follows the familiar coding-agent loop:
- receive a development task,
- inspect local context,
- reason about the task,
- run actions or edits as needed,
- present the result back in the terminal.
3. Why product feel matters architecturally​
For many terminal tools, UX polish is not separate from architecture. Clear prompts, predictable output, and understandable action flow are part of whether the runtime is actually usable.
That is especially relevant for a Charmbracelet project.
4. Model and tool wiring​
Like other coding agents, Crush only becomes valuable when it can connect model reasoning to local action. That means provider and tool wiring are part of the real runtime, not just setup chores.
5. What to read first in code​
Start with:
- the repo overview,
- usage and install guidance,
- core runtime code,
- config and packaging details after the interactive flow is clear.