Spec-first series
Spec to codeCode like MicheWork visuallyDurable assetClaude has /skills
Let your agent do what it does best

Claude has /skills.
DecisionGraph knows when to use them.

Skills are capability. The graph is timing. Your agent knows how to do everything. It just doesn't know when.

See how it works
The gap

A skill has no sense of occasion.

Claude Code ships with skills: /spec-it writes specifications. /certify runs a QA gate. /review checks the build. They are static capability — they do exactly what it says on the tin.


What a skill does not know is when. It does not know that a story moving to review is the moment to run the certification skill — that the build is done and it is time to check the work against the spec. That timing lives in your head, and you supply it via prompt, the same way you supply every other unwritten thing.


The unwritten-spec problem and the unwritten-timing problem are the same problem. Both are things the agent is waiting for you to know first.

Your agent knows how to do everything.
It just doesn't know when.

The mechanism

Status transitions are the conductor's downbeat.

A story in DecisionGraph moves through a lifecycle: backlog → in development → review → done. Each transition is a moment. The graph knows what moment it is.

1
The build finishing is the occasion for review.
When the coding agent completes its work on a story, the story moves to review. That status transition is the signal — not a human prompt, not a separately maintained trigger. The graph registers the moment and the next skill is queued.
2
Review is the occasion for certification.
A story moving to review is the signal to run the certification skill — code review, QA gate, acceptance criteria check. The spec, the lineage, the acceptance criteria are already on the story. No prompt engineering required to assemble the context.
3
Context attaches automatically.
Right skill, right lifecycle moment, right context. The spec. The acceptance criteria. The lineage back to the feature it belongs to. Orchestration as a byproduct of the status model — not a new mechanism layered on top of it.
Reported process vs. derived timing

Their orchestration is scripts.
Ours is the lifecycle itself.

Atlassian gives you automation rules. Someone writes a trigger: “when an issue moves to Review, notify the QA team.” That rule is a maintained artifact — it was written by a human, it lives somewhere in the config, and it drifts the moment process changes. The rule describes what should happen. It does not derive it.

Atlassian automation
Automation rules written and maintained by hand
Triggers describe process; drift when process changes
Reported process — the rule is your word that the process runs this way
Skill invocation is an additional layer on top of workflow
DecisionGraph
Timing derived from status transitions — no rule to write
The lifecycle itself is the trigger; it cannot drift from process
Derived timing — the graph knows the moment from the model
Context attached to the node, not assembled at prompt time

The axis is the same one that runs through everything here: reported truth vs. derived truth. An automation rule reports that orchestration is happening. A status transition derives it.

What the graph knows

The graph knows what moment it is.

Status transitions are not just state changes. They are declared moments in a lifecycle. DecisionGraph's model treats each transition as an occasion with a known context: the story's spec, its acceptance criteria, its lineage back to the feature it serves.

Skills are static. Occasion is structural.

A skill loaded into Claude Code does not expire. It runs the same way every time. What changes is when to call it — and “when” is what the lifecycle knows. The graph is not smarter than the skill. It just knows when.

Context travels with the node.

When certification runs on review, it does not have to ask for the spec. The spec is lodged to the function. The acceptance criteria are on the story. The lineage is the graph. The skill arrives already briefed — not because anyone assembled a prompt, but because the work was connected when it was done.

Skills know how. The graph knows when.

The graph is timing

AI gives you speed.
DecisionGraph remembers why.

Every status transition is a downbeat. Every skill invocation lands at the right moment. Every context is already attached. The agent has always known how. Now it knows when.

The spec-first series

Code like Miche

Let the agent rough out the work so your time goes to the details only you can make perfect.

Read → /apprentice

The spec is a durable asset

The prompt-stream spec dies with the session. The written spec keeps working after ship.

Read → /durable

Your mockup is half a spec

Here's the half that's missing — and why the agent needs both.

Read → /visual

From spec to developer-ready code

The whole loop — spec, decompose, build, verify — start to finish.

Watch → /spec-to-code