recursive-mode wants to fix AI coding’s context rot in Git

With recursive-mode, long-running AI coding work gets written to your repo, not lost in chat logs. The open-source workflow persists requirements, decisions, and evidence as auditable files and guides teams through phase-based runs that loop until they pass review.

recursive-mode wants to fix AI coding’s context rot in Git

TL;DR

  • Repo as source of truth: Requirements, plans, decisions, and evidence persisted as files, not chat logs
  • Context rot mitigation: Prompts become short commands; agent reads durable docs instead of relying on chat history
  • Phase-based recursion: Each phase outputs a locked document; iterative loops draft → audit → repair → re-audit
  • On-disk artifacts: Stored under .recursive/ with RECURSIVE.md, STATE.md, DECISIONS.md, and per-run artifacts
  • “Chat is CLI”: Chat triggers/advances runs; details live in repo files; compatible across IDE, CLI, agents, models
  • Installable skills via npx: recursive-mode, recursive-worktree, recursive-debugging, recursive-tdd, recursive-review-bundle, recursive-subagent

Long-running AI-assisted coding sessions have a predictable failure mode: decisions, requirements, and partial plans end up trapped in chat logs until the context window fills, a session resets, or a different contributor steps in. recursive-mode is built around a simple countermeasure: make the repo the source of truth by persisting requirements, plans, decisions, and evidence as files—so the work survives across sessions and remains reviewable.

Solving “context rot” with repo-backed artifacts

recursive-mode is yet another attempt at solving context rot. Its approach is to move key development state into static documents stored in the repository. In practice, prompts become short commands rather than long specifications, because the agent reads the durable docs instead of relying on ephemeral chat context.

A phase workflow that loops until it passes audit

At the center of recursive-mode is a phase-based process where each phase produces a locked output document and the next phase consumes that output as input. Rather than treating a plan or summary as “good enough” once written, the workflow is explicitly recursive: phases revisit their own outputs and iterate until criteria are met.

For audited phases, the docs describe a loop: draft → audit → repair → re-audit. Closeout phases then feed validated lessons back into repository state and memory so subsequent runs begin with better context.

What gets written to disk (and where)

recursive-mode stores workflow material under a .recursive/ folder, including a structured memory bank and global ledgers that are updated across runs. The docs show a representative layout:

  • .recursive/memory/ for a structured memory bank
  • RECURSIVE.md as the canonical workflow spec
  • STATE.md for current repository state
  • DECISIONS.md as a decisions ledger
  • Per-run folders under .recursive/run/... with artifacts such as requirements, as-is analysis, to-be plan, implementation summary, test summary, and manual QA

The result is a set of human-readable and machine-readable artifacts designed for traceability. The docs also position the run documents plus a code diff as a dataset suitable for fine-tuning and self-distillation.

“Chat is CLI,” plus an open-source alternative to Missions

The workflow also narrows chat’s role: chat becomes a CLI for commands that trigger or advance runs, while the details live in files. The project is described as previously known as rlm-workflow, and positioned as a free, open-source alternative to Factory.ai’s Missions feature, with an emphasis on stronger recursion and broad compatibility across IDE, CLI, agents, and models.

What’s included and how it’s installed

recursive-mode ships as an installable set of skills:

  • recursive-mode for core workflow orchestration (phases, locked artifacts, durable memory)
  • recursive-worktree for isolating implementation in a dedicated git worktree
  • recursive-debugging for structured debugging with explicit root-cause analysis (Phase 1.5)
  • recursive-tdd for strict or pragmatic TDD with recorded RED/GREEN evidence
  • recursive-review-bundle for packaging delegated reviews into reproducible bundles
  • recursive-subagent for subagent handoff contracts and a self-audit fallback

Installation is done via npx, either as a full package:

npx skills add try-works/recursive-mode --skill '*' --full-depth

or by picking an individual subskill (for example recursive-tdd):

npx skills add try-works/recursive-mode --skill recursive-tdd --full-depth

Source: https://recursive-mode.dev/introduction?

Continue the conversation on Slack

Did this article spark your interest? Join our community of experts and enthusiasts to dive deeper, ask questions, and share your ideas.

Join our community