Glacius-Labs/Markitect

Markitect is model-first development with delegated realization. You maintain one canonical YAML model of your project's intended world under .markitect/: its concepts, rules, boundaries, responsibilities, checks and dependencies. Source code, tests, configuration and prose remain ordinary files in the adopting project; they realize the model.
You change the model, usually in conversation with your coding agent, and Markitect has the change applied. It compiles the model, derives the affected Managers and files, and lets recursive Managers implement the change with independent review, integration, fixed-candidate verification and guarded Apply. Markitect reports evidence for the checks performed; project owners retain decisions about semantic acceptance and release. Markitect in brief explains why and how to judge it.
Quick navigation
| Goal | Start here |
|---|---|
| Build the model-first workflow from this source checkout | Run the current source |
| Create a new adopting project | Start a model-first project |
| Model an existing repository | Brownfield workflow |
| Understand the workflow and tool boundaries | Project workflow, Project operations, and Architecture |
| Install the published compatibility CLI | Install Markitect and distribution guidance |
Run the current source
The model-first markitect workflow is available in this development source checkout; it is not included in the published v0.14.1 binary. Building from source does not publish a release or change a project's existing version pin.
For Windows, use Git and Go 1.27.1 or later. From this Markitect source checkout, build a separate development executable:
Keep the source checkout for development. Configure the adopting project's runtime with config, then connect the outer coding client to its repository-local Markitect MCP server. Manager, reviewer and verifier roles use the supported Codex App Server runtime by default. Setup can give each role class its own provider, model, effort and cost mode, including a bring-your-own process executor; an executor that Markitect cannot price runs unmetered, and its cost is reported as unknown, not zero. See Provider adapters for connection, role profiles and execution boundaries.
Start a model-first project
Initialize your target Git repository on a feature branch, then create its scaffold:
Review the onboarding preview and apply it with the returned digest:
Choose claude or both for those contributors. Onboarding previews repository-local entrypoints and discoverable skills, preserves custom content, and points contributors to the shared workflow. It does not register MCP or change global account/provider settings. Connect the selected client using Provider adapters.
Then give your agent an ordinary request, for example:
> Build a small shop where creating an order reserves stock and cancelling it restores the reserved stock exactly once. Include tests and explain the project through its generated documentation.
Use the Project workflow to inspect the model, record scope and acceptance, update canonical intent when needed, establish readiness, and continue the same operation through execution, verification, and guarded Apply. The Project operations reference documents exact interfaces and recovery. The Shop example provides a runnable model and finite tests.
Example adopting-project layout
The tree below illustrates a repository that uses Markitect. It describes a target adopting project, not this Markitect source repository. In this source checkout, implementation is under src/, product documentation is under docs/, and adopting-project examples are under examples/.