Replacing spec-driven development with just facts

The antidote to fluffy specs.

Models matter. Context matters more. Give your agent a plan.

Spec Driven Development approach allows to squeeze more from coding agents thanks to few strong concepts: - decomposition across two dimensions. first you generate specs in multiple steps (requirements, code analysis, design), than you split task into multiple subtasks and implement them one by one - you clear context between every step - after spec generation and after subtask implementation. this helps keep cost low and context clear and focused which boost performance - specs written to disk help with information persistency - delivering specs layer by layer help to catch early when agent…

I've worked on several projects writing and implementing specifications (particularly CLN): I've found the specs I write are much better when I quote them in the implementation, so I can see what implementers need to know. Also, when specs change in development, it's almost trivial to find where to update the code. This project is a formalization of my various hacky scripts which ensure the requirements are accurately quoted, and give coverage if any are missing. Not a major Opus, but I hope someone else finds it useful!

I'm Guy, the founder behind Snyk — now building Tessl, a package manager for agent skills. We’ve recently witnessed that most teams still treat skills as static artifacts: markdown files, created or copied from repo to repo. This approach offers a strong initial boost, but quickly creates debt: - Skills are duplicated, and updates never roll out. - Poor quality skills go unseen, misguiding agents instead of helping. - Skill knowledge grows stale, and don’t keep up with the systems and practices they describe. Without a way to evaluate skills, teams have no clear way to understand how good a…

Hi HN, I built my first project using an LLM in mid-2024. I've been excited ever since. But of course, at some point it all turns into a mess. You see, software is an intricate interwoven collection of tiny details. Good software gets many details right; and does not regress as it gains functionality. My bootstrapped startup, ApprovIQ (https://approviq.com) is trying to break into a mature market with multiple fully featured competitors. I need to get the details right: MVP quality won't sell. So I opted for Test-Driven Development, the classic red/green/refactor. Writing…