I have worked with AI assistants for a while, and while I am really excited about it, there were times when I felt really frustrated. LLM would end up in a loop with no end.

This is when I started experimenting with creating work plans. Initially simple todo list, but it felt like "product vibing", so a bit more sophisticated later on. I started seeing value in it.

The one day it hit me. Why not use the same GitOps principles to managing product tickets? I started playing with that and really liked the way it worked.

After a chat with a friend of mine, I realised that a standard or a spec would be something really useful. You could then create all sort of tooling around this.

I took an inspiration from the way kubernetes yaml are used, cause I find it quite neat.

You can view examples here: https://spec.productascode.org/draft/#sec-Epic-Example-YAML-

Key design decisions so far:

1. YAML over JSON: Human-readable, git-diff friendly, excellent tooling ecosystem 2. Hierarchical structure: Epics → Tickets → Tasks (matches development workflow) 3. Atomic tickets: Each ticket = one branch = one PR (prevents scope creep) 4. ISO 8601 timestamps/durations: Machine-parseable time data

If I manage to create an epic with a bunch of tickets in backlog, then my favourite part of work is to tell Claude Code: "Close the current ticket, and start another one".

Here is the link to the post which has links to draft spec and GitHub repository.

Currently working on v0.1.0 and I would love to hear your thoughts.

https://mantcz.com/blog/introducing-product-as-code/