Starting Meronq: Sprint 0 and the foundation
Every AI assistant that joins a software project starts from zero. It re-reads the repository, re-parses Git history, re-discovers conventions — and spends tokens on discovery instead of reasoning.
Meronq exists to change that. We are building an Engineering Intelligence Layer: a shared, evidence-backed model of a project that any AI client can use.
This is the first post in our development blog. It covers what Sprint 0 set out to do, what we shipped, and what comes next.
The problem we are solving
Modern teams already produce rich engineering signals every day:
- pull requests and code reviews
- issues and discussions
- ADRs and documentation
- compiler output and CI logs
- Git history
Most of that knowledge lives in disconnected tools. When an AI joins the project, it has to reconstruct context on its own — and every model does it differently.
Our hypothesis is simple: the missing piece is not a better LLM. The missing piece is a layer that translates engineering reality into engineering understanding before AI ever sees it.
See Product vision for the full framing.
Sprint 0 — make the repository the source of truth
Before writing product code at scale, we needed a place where decisions, direction, and history could live durably.
Sprint 0 goal: make the repository a reliable source of truth for the project.
What we completed:
- GitHub organization and repository
- Product vision and architecture overview
- ADR process (ADR-0000)
- Contribution guidelines and issue/PR templates
- Monorepo scaffold (TypeScript, pnpm workspaces)
- First implementation stack decision (ADR-0002)
- Local MCP server for dogfooding (
apps/local-mcp)
Sprint 0 is marked complete on the roadmap.
Architecture in one picture
Meronq sits between engineering systems and AI clients:
Engineering Systems AI Clients
(Git, GitHub, CI, Unity, …) (Cursor, Claude, ChatGPT, …)
│ │
└────────────┬───────────────────┘
▼
Meronq Core
(indexing, memory, agents,
workflows, permissions)
We are not replacing Git, GitHub, or your IDE. We preserve and expose project understanding so AI clients spend effort on reasoning, not rediscovery.
Core vocabulary — Project Context, Engineering Memory, Evidence, Agents, Workflows — is defined in ADR-0003.
Building with AI from day one
Meronq is being built with the help of AI. That is not marketing — it is the workflow.
The first concrete dogfooding surface is the handshake: structured onboarding for AI sessions. Instead of reading thousands of files, an agent receives vision, principles, current sprint, key ADRs, and recommended next steps — sourced from this repository.
apps/local-mcp exposes handshake, git, and pnpm tools to AI clients via MCP. We use it to develop Meronq inside Meronq's own repo.
This loop — document → handshake → build → document — is the pattern we want every team using Meronq to benefit from.
Repository today
apps/
cli/ Command-line interface (stub)
local-mcp/ Local development MCP server
mcp-server/ Product MCP server surface (stub)
packages/
core/ Core domain model
docs/ Vision, architecture, ADRs, roadmap, blog
Implementation is early. Most packages are stubs or planned. That is intentional: we are establishing vocabulary and boundaries before scaling code.
What comes next — Sprint 1
Sprint 1 goal: build the first local prototype that can read a project and answer basic questions about it.
Planned work:
- Define project indexing model
- Define memory model (Memory Model v0)
- CLI prototype: read repository files, summarize structure, store local notes
We will write about progress here as we go. Significant decisions will still land as ADRs.
Follow along
- Roadmap — sprint plan and checkboxes
- ADRs — architecture decisions
- Contributing — how to participate
- GitHub issues and pull requests on Meronq-dev/meronq
If you care about durable engineering memory and AI that understands your project — not just your last prompt — we are building for you.