AI pair programming has a process problem — here's what I built

TL;DR: I built ai-flow-anything — a markdown-native workflow generator that interviews your codebase, detects your project type, and produces design-first flows with a knowledge base that audits itself against your code. No build step, no CLI, no DSL — just markdown. Works with Claude Code, Cursor, GitHub Copilot, OpenCode, and Kimi Code. MIT licensed.

The problem I've been wrestling with:

AI coding assistants are incredible at writing code, but they're terrible at process . Every new task feels like starting from scratch — no design doc, no architecture context, no trace of why decisions were made. The AI codes before it thinks. And when you switch between Claude, Cursor, or Copilot, you lose all context. Another problem: when I move to a new project, I lose all the setup and skills I fine-tuned for the last one.

What I wanted:

- Design-first, enforced — no task code until a design is signed off, and every phase ends at an explicit [A]ccept / [F]eedback / [R]eject

gate. The AI never decides its own work is done.

- Works with any AI assistant (not locked to one tool)

- Auto-detects your project type and tailors workflows accordingly

- A knowledge base that stays true — not just docs that rot

- Tracks every task from design → implement → test → PR → deploy

How it works:

- Clone into your project: git clone https://github.com/yusufkaraaslan/ai-flow-anything.git .ai-workflow

- Initialize — your AI detects the project type (Unity, Godot, React, FastAPI, Flutter, …), interviews the codebase, and asks about your goals

- Get 9 tailored flows — design, implement, free (quick fixes), parallel-implement, PR, test, deploy, docs, and KB sync

The repo gives you two directories: .ai-workflow/ (the engine — instructions, universal rules, stack-specific profiles, and 9 rendered flow files) and flow-storage/ (the knowledge base — project architecture, team docs, and per-task records with immutable design docs, edge cases, diagrams, plans, and lessons learned).

How I developed it:

I use AI to develop my games. While I work, I look for patterns that keep repeating and I note them down. After collecting enough notes — say, across two or three tasks — I create a basic skill with Claude to automate part of the work I'm doing. Over time, those skills become fine-tuned and tailor-made to individual projects and different types of tasks. Then I move to a new game, extract the soul of the workflow, and repeat the process. Eventually, through trial and error, ai-flow-anything formed itself.

Battle-tested, including the failure:

I dogfooded an earlier version for four months on a Godot and unity games I'm building. The per-task side worked genuinely well — 16 features shipped through full design packages with rendered PlantUML diagrams, and the implementation plans drove real commits.

Two favorite bits: the AI implements independent work packets in parallel via git worktrees and merges them in dependency order, and designs are immutable after sign-off (deviations get recorded separately, so the record stays honest).

But the cross-task knowledge base quietly went stale — months in, it contradicted the live codebase (wrong test framework, a "hard" constraint that had been relaxed).

A stale KB is worse than an empty one, because the AI loads it as trusted context on every run. v1.0.0 exists because of that failure: every flow now spot-checks KB claims against reality before trusting them, a status command audits for drift, and a KB-sync flow walks every claim (claim → observed reality → proposed fix) and repairs the records at review gates.

The philosophy:

- AI is the engine — all instructions are prose markdown the AI reads and follows