open source · MIT

Mikoshi Construct

An open-source tool for AI-assisted development — a fixed purpose and strict rules of evidence, with a toolset that adapts to the repository it works in

Mikoshi-construct is our open-source tool for AI-assisted development in a repository. Its purpose and its rules of evidence are fixed; the tools it works with are not. Published on npm under the MIT license

what it is

Mikoshi is not a closed toolbox. The better picture is an octopus: one purpose, a few invariants it does not break, and whatever tools the environment offers — picked up where they help, dropped when they stop helping

The purpose stays the same: understand the repository, choose the tools that fit, do the work, and prove the result. The tools change. Through the coding agent it runs in, they can be the repository’s own harness and test runner, a browser, an MCP server, a project script — or something that does not exist yet

Mikoshi does not need to know every tool in advance. It needs to know how to use the tools it has

what it does today

The CLI is mikoshi-construct. Inside a repository it adds two commands to the coding agent:

  • /plan turns a feature into a handful of tasks, each with acceptance criteria that a harness run can confirm — and that are shown failing before the implementation exists
  • /implement takes a task up a ladder of evidence: low → low → medium → high. An implementer agent writes the change, a separate harness agent runs the gate against the working tree and returns the verdict, and an architect agent designs only at the top of the ladder or after a blocked attempt

That ladder is where today’s adaptation is visible: how much reasoning a task gets is decided by what the harness shows, not fixed up front

two modes

Init — a repository Mikoshi owns. Mikoshi builds its working environment there: rules, a quality harness, agent instructions, and a record of what it wrote so it can keep them current as its templates evolve. The harness is green before the first line of product code:

npx mikoshi-construct init
pnpm install && pnpm run quality

Hijack — someone else’s repository. Mikoshi does not turn it into a Mikoshi repository. It brings /plan, /implement, its agents and the ladder, works with the checks the repository already has, and leaves:

npx mikoshi-construct attach    # jack in
npx mikoshi-construct detach    # jack out

Jack in → operate → jack out. The foreign repository stays foreign: attach never touches a tracked file, and detach removes exactly what attach recorded and nothing else. The difference between the modes is ownership — in one, Mikoshi shapes the repository; in the other, it is a guest, and every decision about the codebase stays with its owners

what does not bend

Adaptive does not mean loose. Whatever tools are in play, the same rules hold:

  • A witness has to be able to fail. A check goes red before the change and green after it. A criterion never seen failing is intent, not evidence
  • Self-reported success is not evidence. The agent that writes the code is not the one that checks it
  • The cheapest loop that still produces the proof. Work starts at low effort under strict constraints; reasoning goes up only when the evidence shows it is needed

These are the principles the organism works by, not the whole of what it is

how it grows

New capabilities come from a factory — how we build Mikoshi, not something it needs at runtime, and not the product itself. The factory turns a tool or an experimental mechanism into a repeatable capability: it works out how the tool is invoked, what role it plays, how its work can be checked, whether it can run in parallel, and what evidence it gives. Once a capability produces a repeatable result, it ships, and Mikoshi can choose it, combine it with others and adapt how it uses it. Real use shows where it breaks, and it gets fixed

  1. factory
  2. repeatable capability
  3. ship
  4. real use
  5. observe
  6. fix
the loop repeats — shipping is not the end of validation

Presets are not what the factory makes. init offers node-backend, node-frontend, node-library and monorepo today — current starting strategies for how Mikoshi puts its capabilities together, not the boundary of what it is. If Mikoshi solves a problem correctly and cheaply, which preset or capability it chose does not matter

The preset is a strategy. The organism is the product

where it stands

Published on npm under the MIT license, with the source on GitHub. It is still before 1.0 — its commands and the files it writes can change between releases, and today’s presets are all for Node repositories

The direction is a general repository filter: take a repository, understand what is available, choose tools, build the checks the work needs, and return a proven result cheaply. That is where it is heading, not what 0.x does today

Let's talk

Your contact info is sent!

We will contact you soon!