I built a setup called Meridian to address some structural issues I was running into when using Claude Code for real development work.
Claude is good at writing code, but it doesn’t maintain long-lived project state. In practice, this led to problems: context loss after compaction, forgotten decisions, repeated mistakes, and drift from coding standards. Code it generated often wasn’t connected to any task history, and behavior varied depending on session state.
Meridian gives Claude a persistent working environment inside the repository, without requiring the developer to change how they interact with it. The goal was zero workflow friction.
Some details:
• Structured tasks
Every approved plan becomes a `TASK-###` folder with a brief, the approved plan, and running context notes. Claude is required to keep these up to date.
• Durable project memory
Important architectural decisions and recurring problems are stored in a `memory.jsonl` file. Claude reads it automatically and never edits it directly; updates go through a script.
• Session-stable coding standards
A baseline `CODE_GUIDE.md` and optional add-ons (for hackathon/standard/production/TDD modes) load automatically on each session.
• Compaction recovery
When a session is compacted, hooks re-inject the system prompt, coding guides, task backlog, memory, and any relevant project docs. Claude must review them before tools are allowed.
• Enforced correctness
Before stopping, Claude must ensure tests/lint/build pass and task/memory/doc updates are complete.
The setup tries to make Claude’s behavior deterministic across sessions while keeping the developer workflow unchanged. You just talk to Claude normally; the structure happens around it.
If anyone is curious about implementation details: the reliability comes from Claude Code hooks (startup, reload, stop guards, etc.) rather than prompt engineering. The system prompt matters, but the deterministic behavior comes from the hooks enforcing required actions at specific moments.
I built a setup called Meridian to address some structural issues I was running into when using Claude Code for real development work.
Claude is good at writing code, but it doesn’t maintain long-lived project state. In practice, this led to problems: context loss after compaction, forgotten decisions, repeated mistakes, and drift from coding standards. Code it generated often wasn’t connected to any task history, and behavior varied depending on session state.
Meridian gives Claude a persistent working environment inside the repository, without requiring the developer to change how they interact with it. The goal was zero workflow friction.
Some details:
• Structured tasks Every approved plan becomes a `TASK-###` folder with a brief, the approved plan, and running context notes. Claude is required to keep these up to date.
• Durable project memory Important architectural decisions and recurring problems are stored in a `memory.jsonl` file. Claude reads it automatically and never edits it directly; updates go through a script.
• Session-stable coding standards A baseline `CODE_GUIDE.md` and optional add-ons (for hackathon/standard/production/TDD modes) load automatically on each session.
• Compaction recovery When a session is compacted, hooks re-inject the system prompt, coding guides, task backlog, memory, and any relevant project docs. Claude must review them before tools are allowed.
• Enforced correctness Before stopping, Claude must ensure tests/lint/build pass and task/memory/doc updates are complete.
The setup tries to make Claude’s behavior deterministic across sessions while keeping the developer workflow unchanged. You just talk to Claude normally; the structure happens around it.
Repo: https://github.com/markmdev/meridian
Feedback is welcome.
If anyone is curious about implementation details: the reliability comes from Claude Code hooks (startup, reload, stop guards, etc.) rather than prompt engineering. The system prompt matters, but the deterministic behavior comes from the hooks enforcing required actions at specific moments.