Thanks for this. Architecture drift was exactly what pushed me to build it. I wanted a way to keep the system picture accurate without anyone needing to manually update diagrams. Keeping everything in plain text with Mermaid felt like the simplest way to make it fit naturally into long-lived projects. Go and Rust support are high on the list.
It is straightforward. You run npx specmind setup <your-ai-tool> in your project so the slash commands are added, then open your AI assistant and run the /analyze command. The CLI parses the entire codebase with Tree-sitter and generates the system.sm file from what already exists. No code changes or prep work needed.
Integration with AI tools like Claude and Cursor is core to how SpecMind works. It runs as slash commands inside those tools, so you can analyze, design, and implement features directly through your AI coding assistant without any heavy setup. Everything stays lightweight since the logic runs through the CLI, and the AI just triggers those commands.
Yes, absolutely. The VS Code extension is only for previewing the .sm files since they use Markdown and Mermaid diagrams. Everything else works through the CLI and slash commands, so you can use SpecMind completely without VS Code.
Thanks! I started building this after running into the problem myself. On one project we had five developers, each using AI tools, and everyone ended up structuring things differently. After a few weeks the codebase felt like five mini-projects stitched together.
I wanted something that kept the architecture consistent without everyone having to stop and redraw diagrams all the time. That’s how SpecMind started. We’ve been using it in real projects, and it’s been much easier to keep track of how everything fits together.
SpecMind works by combining static code analysis with AI generated specs. It uses Tree-sitter to parse the entire codebase and build a structured model of services, layers, entities, and dependencies.
When you run analyze, it creates .specmind/system.sm which includes multiple diagram types such as system view, per service architecture, sequence flows, and entity relationships.
design <feature> creates a spec showing proposed changes, and implement <feature> updates the architecture once the feature is built, keeping the spec and code aligned.
All files are text based and versioned in the repo. The goal is to make architecture a living part of the codebase rather than something updated later in Confluence or diagrams.
Next steps include code-to-spec validation, PR diff integration, and more language support.
Happy to answer any technical questions or hear how others deal with architecture drift in fast moving projects.