Spec driven development is great in theory, but it has a lot of issues, I rant about them here: https://sibylline.dev/articles/2026-01-28-problems-with-spec...

I'm working on a tool that uses structured specs as a single source of truth for automated documentation and code generation. Think the good parts of SpecKit + Beads + Obsidian (it's actually vault compatible) + Backstage, in a reasonably sized typescript codebase that leverages existing tools. The interface is almost finalized, I'm working on polishing up the CLI/squashing bugs and getting good docs ready to do a real launch but if anyone's curious they can poke around the github in the meantime.

One neat trick I'm leveraging to keep the nice human ergonomics of folders + markdown while enforcing structure and type safety is to have a CUE intermediate representation, then serialize to a folder of markdown files, with all object attributes besides name and description being thrown in front matter. It's the same pattern used by Obsidian vaults, you can even open the vaults it creates in Obsidian if you want.

This structure lets you lint your specs, and do code generation via template pattern matching to automatically generate code + tests + docs from your project vault, so you have one source of truth that's very human accessible.

▲

Jarwain 2 hours ago | parent | next [-]

This sounds quite interesting!

I've been exploring spec driven workflows, but from a different angle.

I've been thinking about how to describe systems with a standard format, recursively. Instead of one 10 page doc, you might get 10 one pagers, starting from the highest level of abstraction and recursing down into the parts and subsystems, all following the same format. Building out this Graph of domains provides certain reusable nodes/bits of context.

This then extends to any given bit of software, which is a system in itself composed of the intersections of a lot of different domains and subsystems.

Cue looks interesting and is something I'll be digging into more

	▲	CuriouslyC an hour ago \| parent [-]
		This is my approach. I use the C4 software model, it's pretty general. Entities can be represented either by markdown files, or folders with README.md files (sort of like an index.js or __init__.py). Folder hierarchy gives you a basic project object model.

▲

4b11b4 2 hours ago | parent | prev | next [-]

Arbiter is looking nice. I like the composability. Pretty tough for anything except a developer to author it though, which was maybe an accepted tradeoff.

	▲	CuriouslyC 2 hours ago \| parent [-]
		Thanks. My philosophy with it is to be minimal and adaptable to people's existing workflows, I went through a lot of iterations to land on something that was both expressive and "human." The Obsidian compatibility was a sign for me that I was on the right track.

▲

2 hours ago | parent | prev [-]

[deleted]