DEV Community: Meronq

Sprint 7 closed: Engineering Agents

Meronq — Wed, 01 Jul 2026 23:14:37 +0000

Sprint 7 is closed.

The goal was specialized engineering agents — architecture, code review, documentation, debugging, and onboarding — built on skills, memory, and MCP. Agents gather evidence and return structured briefings; they do not call external LLMs.

What Sprint 7 delivered

@meronq/agents — types, registry, context gathering, runner
Five built-in agents — architecture, code_review, documentation, debugging, onboarding
MCP + CLI — agent_list, agent_run, meronq agent run
Handshake — available_agents[] for discovery

Product MCP v1.2.0. Local MCP v1.18.0. agent_run is read-only in v0.

CLI

meronq agent list
meronq agent run onboarding
meronq agent run debugging --symptom "pnpm test fails"
meronq agent run code_review --pr 12

How it fits

Skills answer how (build, test, ADR). Agents answer when and why, with checklists, system guidance, and recommended skills.

Sprint 8 — Productization

Desktop app, cloud backend, team workspace, auth, and billing exploration.

Follow along

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 6 closed: Skills and Workflows

Meronq — Wed, 01 Jul 2026 22:39:12 +0000

Sprint 6 is closed.

The goal was to introduce reusable procedural engineering knowledge — versioned Project Skills that offload deterministic workflows from LLM prompts into inspectable project code. See ADR-0006.

What Sprint 6 delivered

Every item on the roadmap is checked off:

Project Skill format — JSON schema with inputs, steps, safety, and evidence rules
project.build — run build via detected package manager
project.test — run test suite
adr.create — write a new ADR from template (title, optional context)
Workflow execution — sequential steps with fail-fast and structured results

Local MCP is now v1.16.0 with skill_list and skill_run. Product MCP and CLI expose the same skill surface.

New package: `@meronq/skills`

Module	Role
`listSkills()` / `getSkill()`	Built-ins + `.meronq/skills/*.skill.json` overrides
`runSkill()`	Execute steps through injected `SkillExecutionContext`
`buildAdrDraft()`	ADR numbering, slug, and markdown template

Built-in safety cannot be weakened by project overrides. Custom skills in v0 support create_adr steps only; command steps remain built-in exclusive.

Surfaces

meronq skill list
meronq skill run project.build
meronq skill run adr.create --title "My Decision" --context "Why we need this."

MCP tools: skill_list, skill_run. Handshake returns available_skills[] so assistants discover workflows without guessing shell commands.

Execution context lives in @meronq/server-core (createSkillContext) to avoid circular dependencies between skills and runtime.

Permission hardening

Post-sprint review added MERONQ_ALLOW_FILE_WRITE=true for skills that write files (e.g. adr.create) on the product MCP server. Runtime skills still require MERONQ_ALLOW_RUNTIME=true. Local MCP and CLI run skills without those gates for dogfooding and local use.

Pipeline

Intent (skill name + inputs)
  → getSkill / safety checks
  → createSkillContext (package manager, paths, runCommand)
  → sequential step execution
  → SkillRunResult (steps, output, action id)

Evidence recording into CEM/memory is planned; the schema is ready in skill definitions.

Sprint 7 — Agents

Sprint 7 goal: specialized engineering agents — architecture, code review, documentation, debugging, and onboarding — built on skills, memory, and MCP.

Procedures are now deterministic. Agents will decide when and why to invoke them.

Follow along

Sprint 5 made Meronq portable. Sprint 6 makes engineering procedures reusable across AI clients.

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 5 closed: MCP Server

Meronq — Wed, 01 Jul 2026 22:38:25 +0000

Sprint 5 is closed.

The goal was to expose Meronq capabilities through MCP so AI assistants can use Meronq as a product tool layer — not only when developing Meronq itself. GitHub data and local memory from earlier sprints now ship through a dedicated product server with an explicit permission model.

What Sprint 5 delivered

Every item on the roadmap is checked off:

MCP tool surface — handshake, scan, memory, GitHub, runtime, and git read tools
Product server — apps/mcp-server v1.1.0 for any Meronq-enabled repository
Shared server core — @meronq/server-core (handshake, permissions, runtime, CEM sync)
Memory search — memory_search and memory_stats over SQLite
Safety model — runtime and network gates via environment variables

Local MCP refactored onto @meronq/server-core (v1.15.0) while keeping dogfooding tools: git write, social distribution, and extended allowlists.

Product vs local MCP

Surface	Use when
`apps/mcp-server`	Connecting assistants to your project
`apps/local-mcp`	Developing Meronq itself (social, git write, dogfooding)

Point either server at a repo with MERONQ_PROJECT_PATH (or MERONQ_PATH).

New package: `@meronq/server-core`

Shared logic extracted from local MCP:

Module	Role
`buildHandshake()`	Onboarding payload with CEM, memory, GitHub, sprint context
`buildAndSyncCem()`	Scan + optional GitHub fetch → SQLite
`ProjectRuntime`	Package manager and git command execution
`permissions`	`MERONQ_ALLOW_RUNTIME`, `MERONQ_ALLOW_NETWORK`, git write

Product MCP exposes 14 tools including memory_search, github_sync, project_build, and allowlisted commands. Git write stays off the product surface by design.

Permission model

MERONQ_ALLOW_RUNTIME=true   → build, test, install/dev allowlist
MERONQ_ALLOW_NETWORK=true   → GitHub API refresh (or set GITHUB_TOKEN)

Read-only git tools (git_status, git_diff) work without extra flags. See MCP server guide for Cursor configuration.

Memory search

memory_search queries entities in .meronq/local/memory.db with optional type filters. Access events are recorded when results are returned — aligned with ADR-0005.

# MCP: memory_search { "query": "github", "limit": 10 }

Sprint 6 — Skills and Workflows

Sprint 6 goal: introduce reusable procedural engineering knowledge — project.build, project.test, and adr.create as versioned Project Skills callable from MCP and CLI.

The product MCP surface is live; Sprint 6 adds deterministic workflows on top of it.

Follow along

Sprint 4 connected GitHub. Sprint 5 makes project intelligence portable. Sprint 6 teaches assistants how to run repeatable engineering work.

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 4 closed: GitHub Integration

Meronq — Wed, 01 Jul 2026 20:41:01 +0000

Sprint 4 is closed.

The goal was to connect Meronq to GitHub as the first external engineering system — reading metadata, issues, and pull requests, then translating that data into CEM and local memory.

What Sprint 4 delivered

Every item on the roadmap is checked off:

Repository metadata — stars, branch, description
Issues and PRs — GitHub REST API
CEM translation — issue:owner/repo#N, pull_request:owner/repo#N
Summaries — issue and PR text summaries
Doc draft — markdown from git log + GitHub

Local MCP v1.13.0 — github_sync, github_status, github_summarize, github_doc_draft.

New package: `@meronq/github`

scanProject → CEM → fetchGitHubSnapshot → appendGithubToCem → SQLite memory

Auth: GITHUB_TOKEN (PAT). Cache: .meronq/local/github-snapshot.json.

CLI

meronq github sync
meronq github status
meronq github summarize issue 3
meronq github doc

Sprint 5 — MCP Server

Expose Meronq as a product MCP surface with handshake, memory search, and permissions.

Follow along

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 3 closed: Memory Engine v0

Meronq — Wed, 01 Jul 2026 20:08:43 +0000

Sprint 3 is closed.

The goal was to persist CEM entities, relations, and evidence locally — so project understanding survives between sessions. The new @meronq/memory package, CLI commands, and an upgraded handshake now read and write engineering memory in SQLite.

What Sprint 3 delivered

Every item on the roadmap is checked off:

SQLite schema — entities, relations, evidence, access/reinforcement events
Full CEM sync from scanner output into .meronq/local/memory.db
Access and reinforcement events — lifecycle signals per ADR-0005
Handshake from memory — scan refreshes DB; CEM returned from the store

Local MCP is now v1.12.0 with memory_sync and a memory block in handshake.

New package: `@meronq/memory`

Module	Role
`MemoryStore.open()`	Open `.meronq/local/memory.db`
`syncFromSnapshot()`	Full CEM replace from live scan
`loadSnapshot()`	Read CEM back from SQLite
`recordAccess()` / `recordReinforcement()`	Lifecycle events

Uses Node built-in node:sqlite — Node ≥ 22.5 required.

Handshake pipeline

scanProject → indexToCemSnapshot → syncFromSnapshot → loadSnapshot → handshake.cem

Handshake still scans for freshness; CEM is served from SQLite with access events recorded.

CLI

meronq memory sync    # scan + sync CEM to SQLite
meronq memory stats   # row counts

Stable entity IDs

Project ids canonicalize across Windows and WSL (project:c:/...). Components use paths: component:apps/cli, component:packages/memory.

Sprint 4 — GitHub Integration

Connect Meronq to GitHub: issues, PRs, and metadata translated into CEM. Memory becomes the merge target for external data.

Follow along

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 2 closed: Local Project Intelligence

Meronq — Wed, 01 Jul 2026 19:30:35 +0000

Sprint 2 is closed.

The goal was to build the first local prototype that can read a project and produce structured project understanding. The scanner package, CLI commands, and an upgraded handshake now turn repository layout into a ProjectIndex and a CEM snapshot — not just directory names.

What Sprint 2 delivered

Every item on the roadmap is checked off:

Project indexing model — ProjectIndex in packages/scanner
CLI prototype — meronq scan and meronq info (apps/cli)
Repository scanning — apps, packages, docs flags, ADRs, blog posts
Package manager detection — pnpm, npm, yarn
Structure summary — human-readable one-liner per project
Local notes — scan output saved to .meronq/local/project-index.json

Local MCP is now v1.11.0 with project_scan and project_index in handshake.

New package: `@meronq/scanner`

Module	Role
`scanProject()`	Walk repo → `ProjectIndex`
`indexToCemSnapshot()`	ProjectIndex + git log → CEM
`saveProjectIndex()` / `loadProjectIndex()`	Persist under `.meronq/local/`

Example summary:

meronq: pnpm monorepo=true · 4 app(s), 2 package(s) · 8 ADR(s), 3 blog post(s)

CLI

meronq scan    # write .meronq/local/project-index.json
meronq info    # print summary (--json for full index)

Handshake pipeline

scanProject(root) → ProjectIndex → indexToCemSnapshot() → handshake.cem

Still read-only from disk — Sprint 3 adds SQLite persistence.

Sprint 3 — Memory Engine v0

Persist entities, relations, evidence, and events locally. Handshake reads from memory with optional refresh.

Follow along

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 1 closed: Canonical Engineering Model wired into handshake

Meronq — Wed, 01 Jul 2026 18:50:09 +0000

Sprint 1 is closed.

The goal was to define the first Meronq language primitives — the Canonical Engineering Model (CEM) — that every runtime, memory, scanner, and translator component will share. That vocabulary now exists in code, in tests, and in the handshake AI clients receive at session start.

What Sprint 1 delivered

Every item on the roadmap is checked off:

Entity, Relation, Evidence, Event, Action, and Result models in packages/core
Factory functions, type guards, and branded IDs
First core domain API export from @meronq/core
Test suite for primitives and a minimal graph linking example

From types to runtime: handshake + CEM snapshot

Before closing Sprint 1, we addressed seven review gaps:

CEM in handshake — entities, relations, evidence from the workspace
Fresh sprint hints — open roadmap tasks drive recommended_next_steps
Single vision source — docs/product/vision.md
Portable project path — auto-discovery via pnpm-workspace.yaml
Docs aligned — architecture status, ADR index
Social tools isolated — opt-in distribution module
Git write gate — MERONQ_ALLOW_GIT_WRITE=true required

Local MCP is now v1.10.0.

Sprint 2 — Local Project Intelligence

Scanner + CLI prototype. CEM entities from real project structure.

Follow along

Blog
GitHub

Read the full post on meronq.pages.dev · Source on GitHub

Sprint 0 closed: foundation complete, Sprint 1 begins

Meronq — Wed, 01 Jul 2026 14:10:59 +0000

Sprint 0 is closed.

When we started Meronq, the goal was simple: make the repository a reliable source of truth before scaling product code. That foundation is now in place.

What Sprint 0 delivered

Every item on the roadmap is checked off:

GitHub organization and repository
Product vision and principles
Architecture overview and ADR process
Contribution guidelines and issue/PR templates
Monorepo scaffold (TypeScript, pnpm workspaces)
Local MCP server for dogfooding (apps/local-mcp)
Handshake prototype for structured AI onboarding

Along the way we also shipped:

Public site at meronq.pages.dev — landing page and this development blog
First blog post documenting Sprint 0 goals and architecture
Distribution channels — Discord, Telegram, dev.to, and Hashnode for building in public

Sprint 0 was never about features at scale. It was about vocabulary, boundaries, and a place where decisions and history live durably.

What we learned

Three patterns are already paying off:

Document before you scale code. ADRs, vision, and architecture docs gave AI assistants (and humans) a shared starting point.
Dogfood early. The local MCP server and handshake let us develop Meronq inside Meronq's own repo — fewer repeated explanations, more time on real work.
Build in public. Publishing the blog, site, and updates across channels keeps us honest and invites early feedback.

The hypothesis from day one still holds: the missing piece is not a better LLM. Teams need a layer that turns engineering reality into engineering understanding before AI sees it.

Sprint 1 — Canonical Engineering Model

Sprint 1 goal: define the first Meronq language primitives that all runtime, memory, scanner, and translator components will use.

Planned work:

Define Entity, Relation, Evidence, Event, and Action/Result models
Export the first core domain API from packages/core
Add tests for core primitives

This is the vocabulary everything else will build on. Significant decisions will land as ADRs; progress updates will appear here.

Follow along

Roadmap — sprint plan and checkboxes
ADRs — architecture decisions
Contributing — how to participate
Development blog — build log
GitHub: 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. Sprint 0 is done. Sprint 1 starts now.

Read the full post on meronq.pages.dev · Source on GitHub

Starting Meronq: Sprint 0 and the foundation

Meronq — Tue, 30 Jun 2026 09:45:30 +0000

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.

Read the full post on meronq.pages.dev · Source on GitHub

DEV Community: Meronq

Sprint 7 closed: Engineering Agents

What Sprint 7 delivered

CLI

How it fits

Sprint 8 — Productization

Follow along

Sprint 6 closed: Skills and Workflows

What Sprint 6 delivered

New package: @meronq/skills

Surfaces

Permission hardening

Pipeline

Sprint 7 — Agents

Follow along

Sprint 5 closed: MCP Server

What Sprint 5 delivered

Product vs local MCP

New package: @meronq/server-core

Permission model

Memory search

Sprint 6 — Skills and Workflows

Follow along

Sprint 4 closed: GitHub Integration

What Sprint 4 delivered

New package: @meronq/github

CLI

Sprint 5 — MCP Server

Follow along

Sprint 3 closed: Memory Engine v0

What Sprint 3 delivered

New package: @meronq/memory

Handshake pipeline

CLI

Stable entity IDs

Sprint 4 — GitHub Integration

Follow along

Sprint 2 closed: Local Project Intelligence

What Sprint 2 delivered

New package: @meronq/scanner

CLI

Handshake pipeline

Sprint 3 — Memory Engine v0

Follow along

Sprint 1 closed: Canonical Engineering Model wired into handshake

What Sprint 1 delivered

From types to runtime: handshake + CEM snapshot

Sprint 2 — Local Project Intelligence

Follow along

Sprint 0 closed: foundation complete, Sprint 1 begins

What Sprint 0 delivered

What we learned

Sprint 1 — Canonical Engineering Model

Follow along

Starting Meronq: Sprint 0 and the foundation

The problem we are solving

Sprint 0 — make the repository the source of truth

Architecture in one picture

Building with AI from day one

Repository today

What comes next — Sprint 1

Follow along

New package: `@meronq/skills`

New package: `@meronq/server-core`

New package: `@meronq/github`

New package: `@meronq/memory`

New package: `@meronq/scanner`