OpenSpec

What was covered

• From chat to specs. Chat history is fragile and relevant details get lost, so the AI loses focus. OpenSpec sets up a contract, the specification, between developer and AI, which doubles as proof of what was implemented.
• Why it stands out. It is open source, tool-agnostic (Cursor, Claude Code and others), needs no API keys and costs nothing extra. It is repository-native: Markdown files tracked in Git, with one single source of truth for all specifications. That reduces the context each task needs.
• The workflow. Propose creates the proposal and the tasks. Apply has the AI work from the spec. When the review is done, the spec moves to an archive folder.
• Which models. Use a large or “thinking” model to write the spec, then a smaller, cheaper one for the tasks, because the spec carries enough context.
• Getting started. npm install, openspec init, then propose a feature.

What came up

• Switching models. Writing the spec with a big model and implementing with a cheaper one was the practical highlight for the room.
• Edit the file. You can change the spec by hand instead of arguing with the LLM, which is much faster.
• Does it learn your style? Yes, in a sense. Edited files and earlier specs become context, so new ones fit your way of working.
• No lock-in. If OpenSpec disappeared, the context lives in Markdown and works with other tools.

Takeaway

The workflow adopted was big models for specs and efficient models for task implementation.