A read-only mission control panel for the local-Markdown SDD workflow

[Zziy-Q]

Hi all — long-time user of the Skills here, first-time poster. I wanted to show a small companion tool I built for my own use, in case it's useful to anyone else running the local-Markdown tracker.

The itch: the SDD loop (spec → architecture gate → to-tickets → implement) is rigorous, but its state lives scattered across Markdown files. Mid-project I kept asking: which ticket is next? why won't 03 start — a missing dependency or an invalid architecture binding? and done on a ticket doesn't mean accepted or delivered, so which of these 16 checkboxes are actually still open? The workflow knew the answers; I just couldn't see them.

What I made: Matt Dev View — a read-only, zero-dependency, fully local web panel that reads your project's specs, tickets, and architecture records and answers three questions at a glance: where are we, what's next, what still needs review. It runs in the Codex right panel or a browser.

It is deliberately not a replacement for any part of the workflow — it plans nothing, creates no tickets, approves no architecture, and writes nothing to your project. The Skills do the work; this just makes the work legible. A few constraints I held to:

• Read-only, always. It's a window, not a lever.
• Zero third-party runtime deps. Plain Node 24, ~1,700 lines, no npm install, no build.
• Local & honest. Binds 127.0.0.1, GET-only, no auth by design — don't expose it publicly.
• Markdown stays the source of truth. No remote GitHub/Linear sync.

It renders the SDD stages, a ticket list and a collapsible Archify dependency graph, an "executable frontier" (a ticket starts only when ready + dependencies complete + valid architecture binding when required), keeps acceptance [ ]/[~]/[x] strictly separate from delivery, and watches .scratch/ over SSE so the panel updates as the agent works.

Try it:

git clone https://github.com/Zziy-Q/matt-task-view.git
cd matt-task-view
node src/cli.mjs serve --port 0

Happy to answer questions, and genuinely open to feedback on whether it matches how you think about your own projects. If it ever seems worth listing wherever the community keeps companion tools, I'd be glad to open a PR. Thanks for the excellent Skills — this exists because the workflow underneath it was worth making visible.