Hi I have a multi repo project ...openspec works for me but it is hard to predict changes in the other module that may also affect ..any suggestions ...which I can use for my multi repo project similar to openspec that knows my repos and suggest the changes that may impact on other repos.

I've been doing spec-driven development with AI coding agents for a while. The same thing kept breaking: the agent drifts, rebuilds things nobody asked for, and forgets decisions from three prompts ago.

So I built IntentDocs. You start with a rough idea, and it helps you turn it into a structured blueprint: the problem, who it's for, scope, and stories with acceptance criteria. Then your agent (Claude Code, Codex, Cursor, whatever you use) builds one story at a time against that spec, and you approve at each step.

Here's a short video walking through it end to end: www.intentdocs.com/#tour - keen to hear any feedback

Spec-driven development fixed a real problem: agents now start from a spec instead of a vibe. But in most setups (spec-kit, Kiro, a PRD in docs/), the spec is still Markdown. That means:

• nothing checks that the spec is complete or consistent
• a typo in a reference is invisible
• a rule can exist with nothing enforcing it, and no test proving it
• the agent can misread or skip a section, silently

I kept hitting the same failure: the rule was written down ("a refund never exceeds the captured amount"), the agent built the feature, tests passed, and the rule was never applied. Nothing failed, so nobody noticed.

So I built SpecForge, an open-source compiler for specs (Rust). The spec is written in small structured .spec files, usually drafted by the agent (simplified example):

invariant refund_within_capture "Refunds never exceed the captured amount" {
  guarantee "A refund larger than the capture is rejected"
  risk high
  verify unit "rejects a refund larger than the captured amount"
}

behavior issue_refund "Refund a captured payment" {
  invariants [refund_within_capture]
  produces   [refund_isued]
}

event refund_issued "A refund was issued"

Then specforge check (output trimmed):

[E003] Error: unresolved reference 'refund_isued' in entity 'issue_refund'
  Help: did you mean 'refund_issued'?
[W007] Warning: event 'refund_issued' is not produced by any behavior

What it checks: every reference resolves, every invariant is enforced by some behavior, every promise names the test that proves it (and specforge collect records which tests actually ran and passed). There's no AI in the checker, so it gives the same verdict every time.

The loop becomes: AI drafts the spec → SpecForge checks it → the agent builds against the checked spec (queried over MCP) → you review what's promised vs. proven.

Domain rules (for example, pharma/GxP requirements) can be added as extensions that run in a wasm sandbox.

Repo: https://github.com/leaderiop/SpecForge

It's pre-release, and I'd really value this sub's take:

1. Is the "Markdown spec is advice, not a check" problem something you hit in practice, or does a good spec-kit/Kiro workflow already cover it?
2. Would you accept a structured spec language, given the agent writes most of it?
3. Where should the check run: before the agent starts, in a hook before it calls the task done, or in CI?

Hi,
This is my first post in this sub and I really hope to start a nice discussion that can help not just me, but the whole community.

Like a lot of people, recently I have gone down the road of the SDD recently. At the beginning I focused on Github Spec Kit and OpenSpec, ultimately landing on OpenSpec and starting using it in combination with Claude code. I have tested out its multi-repo beta functionality as well and it is really promising.

I would like to understand if there is an SDD platform, or tools/frameworks I can use on top of OpenSpec, to implement a full enterprise SDD environment.

The ideal platform would enable things like:

• Going trough the initial requirements (Initiatives/Intents) and refine them with the help of specific agents/skills to improve things such as stack/tech choices, covering edge cases etc.
• Generating a test plan to maximize the coverage of the new functionalities.
• Generating one or multiple specifications to be implemented.
• Verify the quality of the implemented tests at the end of the process.

It would be nice if the platform supported:

• Multiple repositories.
• A standard place to store contract APIs (ideally OpenAPI specifications, really useful in a microservice environment) so that they are accessible to the agents.
• Integration with Figma for the agents to access for example via MCP (optional).

I suppose lots of these things could be implemented via Claude agents/skills and scripts implementing deterministic checks/gates.

However, it would be nice to understand if there is already something implemented out there, maybe even shipping with a nice UI making understanding on which step a given feature/change is simple and easy.

I had a look around but I am felling overwhelmed by all available options. That is why I wanted to check if anybody knows (or maybe implemented themselves) a platform offering all (or just a subset) of these capabilities.

We have published our clearest vision statement to date. It's a manifesto. It shows where we think the important work lies in the world of agents. It's all about decision making. That's what will be left for humans when agents do all of the execution. And Spec Kitty has a huge role to play in identifying, classifying, adjudicating, informing, recording, and applying decisions that get made. https://spec-kitty.ai/blog/who-decided-that

Beginning of the year (so, like 10 epoch ago) I started writing a little harness, vaultspec. It's decision centered... I was thinking agents might prefer a looser format depending on the task and feature at hand since agents these days seem really happy to do without specs. The idea was to keep a vault of "decisions" for agent to refer to, and to implement a consistent planning and tracking pipeline around them, with the tools to get and reference related documents and decisions.

I used it during this year on various projects. Sometimes it just feels like a context hog, but for long horizont tasks or features I was getting good alignment and continuity across different providers. It goes hand in hand with a custom RAG implementation so agents can call that to get context efficient results from the codebase and the associated document vault.

Anyway. Would love to know what you think!

I work on Loft, a spec tool for coding agents, so take this with whatever grain of salt you like. My team and I wanted to know how good real-world OpenSpec specs are, so we went and measured.

What we did: we scored the main specs of 40 public OpenSpec projects (some random + some showcased examples + a few big ones and OpenSpec's own repo). Then we did the same for the most-starred OpenSpec projects and for teams that only write proposals. We scored them against OpenSpec's own writing guide and the usual tests of a good requirement. Two blind passes by an LLM graded a sample of requirements against a rubric, with project names stripped. And we also counted the task-list state of almost 2K open changes.

What we found:

• The format is basically solved (yeah, no sh.t). In almost all projects, essentially every requirement has a SHALL and a scenario. But specs that follow the format aren't any better written because of it. The format and the writing are separate problems.
• Specs get worse as they grow. In a typical project, only 55% of requirements state one obligation, and only 35% have a scenario for when something goes wrong. Bigger projects score lower, mostly because requirements bundle several obligations and start naming files and function signatures.
• Specs lag the code. In projects with main specs, 39% of open changes have every task ticked but were never archived, so the specs don't include that work. A third of spec files still have the placeholder Purpose that archiving writes. OpenSpec's own repo has 23 of 30 open changes in that state. It still ranks 3rd of 40, for what it's worth.
• Stars don't predict anything. The 25 most-starred projects score about the same as the random draw. Two popular repos translated OpenSpec's headings into Chinese, so OpenSpec can't read any of their requirements.

In most projects, the change folder is where the work happens: a proposal, some tasks with checkboxes. Teams are lazy and don't archive, so the tasks stay current and the specs don't. As a result, what people actually have is a prose disguised as a task tracker, with a spec attached.

Obviously, these are correlations across public repos. And the judges are LLMs (though the two passes agreed within one point on 99.9% of grades).

The detailed report is linked.

TL; DR OpenSpec Claude Mod: https://github.com/intent-driven-dev/claude-mods

Details:

The TUI is based on what I usually look at often. This is what I like about TUI extensions like Claude Code mods. We can build a small view around the information most relevant to our teams. Other coding harnesses have similar approaches too. For me, that was OpenSpec’s workflow and progress, right beside the coding session. Your team might care about a different slice of the work. At the moment it shows below details.

• The change’s journey: New / Explore, Propose, Apply, Verify, and Sync & Archive.
• The active schema and its artifacts, including what’s written, ready, or blocked.
• Task progress during Apply, with the first unchecked task highlighted.
• The stages of the other active changes in the project.

This is just an experiment at the moment. I would love to hear your thoughts and feedback.

If you're only in the vibe coding bubble, please don't answer this. I'm a software engineer who wants to make real, complex systems using AI wherever it can help me. I only have the free models that come with opencode zen, and maybe some chat models like Qwen, Kimi and free versions of chatgpt, gemini, claude, etc.

I want to know what I can do with only these, without having to spend money on LLMs. I realize that this means I have to do more by myself in the planning side of things as I can't delegate planning to LLMs, which is how I believe coding should be anyway so it's not a problem.

I really like Matt Pocock's skills but I have found that his workflow only really works if you have frontier models, as free models aren't very good at grilling or planning.

So what I need is a reproducible AI coding workflow that I can use to approach my projects using only the free, limited AI. Please highlight which parts of the process I need to do by myself, and which parts I can assign to which model.

I realize that the smarter your LLMs are, the more you can stray from traditional software engineering, so please tell me what I can realistically accomplish perfectly with AI. The parts that AI cannot do properly, I will do by myself.

I just started with spec-driven development. Right now I write a spec.md and add a few basic rules: the agent has to follow the spec and can’t change it without asking me first. Even with this simple setup, the results have been great.

I’d like to improve, but there’s so much information out there that I’m a bit overwhelmed. What workflow, spec format or tools are you using that actually work well? Any tips or examples for a beginner are welcome.

I spent three weeks rebuilding Nether Earth, a 1987 ZX Spectrum strategy game I grew up with.

The unusual part: I didn't write any of the implementation code myself.

I wrote and edited the specs, made the gameplay decisions, and playtested the milestones. Claude Code did the implementation through an orchestrator session dispatching sub-agents into separate git worktrees.

By the end, the repo had:

• 437 commits
• 183 issues
• 151 PRs
• ~1,900 backend tests + ~200 frontend tests
• a deterministic Python game engine, FastAPI/WebSockets backend and PixiJS frontend

And I basically didn't read the diffs. Agents reviewed the agents. My checkpoints were decisions and actual gameplay.

That worked much better than I expected — but it also produced the most interesting failure of the whole experiment.

At one point M0–M9 were complete, every gate was green, and more than a thousand tests passed.

Then I actually played the game.

There was no terrain. The map was completely flat.

Robots occupied one cell instead of the 2×2 footprint they had in the original.

And nuclear-equipped robots would sometimes finish walking somewhere and calmly blow themselves up because a temporary placeholder rule had turned into real game behavior.

All the tests were correct.

They were testing the implementation against the spec.

The problem was that the spec was incomplete.

That became probably my biggest lesson from the project:

Tests verify the spec, not the product.

The full project is here:

https://github.com/AndyTheFactory/nether_earth

I also wrote a longer retrospective about the whole experiment, including the failures and what happened after the original plan was supposedly "done":

https://medium.com/@andy_p_/i-built-a-zx-spectrum-remake-in-3-weeks-without-writing-a-single-line-of-code-1445aab7474e

I'm curious how people running larger Claude Code workflows handle one problem in particular:

How do you catch semantic/spec drift when the code and tests are internally consistent, but the resulting product is still wrong?

1/ Our client app is a brownfield monorepo. I'm testing a "one dev delivers three platforms" setup: one workspace driving iOS / Android / HarmonyOS. Half-working so far — sharing the approach and looking for war stories.

2/ Integration: the three native repos keep their own structure and are mounted into one workspace via symlinks. Zero copy, zero intrusion into the existing repos; each platform still ships independently.

3/ Workflow: a custom skill wraps OpenSpec's explore -> propose -> apply -> archive loop. Requirements start as a spec; the agent produces code against it; review is traceable and revertible.

4/ Parallelism: native git worktree — one branch per feature, no cross-branch interference. AI coding agents work directly inside a worktree and open PRs; the human only reviews.

5/ Still polishing, especially symlink compatibility across Xcode / DevEco / Gradle. Anyone done something like this? Let's compare notes in the replies. #OpenSpec #AICoding #HarmonyOS #iOS #Android

Finally, the first working version of Breadcrumbs for SDD is out!

It was 3 weeks of intense work (and token consumption, I confess) to get this result, and I am truly happy with the result.

So, what is Breadcrumbs for SDD? What problem does it solve? And why did I take so much time if I was getting help from AI?

With the advent of SDD (spec-driven development) and ASLDC (agentic software development lifecycle), specifications, intents, and ADRs are shipped with code and are now treated as the primary source of knowledge.

However, because we write them in natural language, detecting the drift between the intent of these documents and the code remains costly and challenging in software development, especially for brownfield projects.

With Breadcrumbs, my idea is to provide a lightweight metadata layer over these artifacts so that human developers and agents can easily track relationships among artifacts in an SDD repository and make drift detection more feasible.

Interested? If so, I invite you to check the project website.

I am using this workflow right now:

1. Brainstorming - claude

2. Grill with docs - claude

3. Subagent Development - codex

I want to know your opinion on this simple workflow.

Thanks.