Machine Learning Engineer | running, solving, thinking beyond the usual | here occasional off-the-cuff thoughts and a few mental bookmarks | alum @TUEindhoven
that is a good point... was thinking of adding a questionnaire before invoking it to create the artifact… although in my workflow it never let me down so far... it understands the context and intent... but I see your point and perhaps in the future I will perhaps look into asking the user first at least from those 9 predefined kinds :)
human-html initially shipped with nine kinds. plan, review, postmortem, etc, each with the sections the doc has to have.
there is a dynamic mode now. the agent decides how to lay the information out so a human follows what the report is actually about, instead of filling in whichever of the nine came closest.
it is still sandboxed... plain summary up top, a diagram in every comparison. the shape is its call now, the styling is not.
this is inspired by Anthropic recently pulling about 80% of the Claude Code system prompt out. their point about examples stays with you, examples constrain the model, because it is more imaginative than the examples you hand it.
nine kinds constrain it the same way, and mostly that is what you want. this week's status report should look like last week's, so the difference is the part that stands out.
so dynamic mode is not about fewer rules... it is letting it decide when the skeleton is the wrong tool, with a floor underneath so it cannot decide to be unreadable for the reader.
npx skills add rhnfzl/human-html
An agent writes you a plan or an incident postmortem as markdown
you skim it, approve it, and miss the assumption buried in paragraph nine.
markdown is fine for the agent's own notes.
but a doc a human has to act on gets read when it's one HTML page, plain-language summary up on top, a diagram in every before/after, risks color coded, a checklist.
rendering one page is easy.
keeping every doc that readable, in your repo, across agents, is the part that needs a validator:
no summary, it fails.
a before/after with no diagram, it fails.
a postmortem with no timeline, it fails.
so I built human-html. nine kinds, files in your own repo, same skill in Claude Code, Codex, Cursor, and other agents.
npx skills add rhnfzl/human-html
@SlowbrewedS per agent and per model right now, no task-type field... though if the model tracks the job, that split is already the task view. plan and code both on sonnet will merge, but there is a project column in there so per-repo is available.
Every coding agent already writes its token usage to disk. What is thin is anything that reads it back and turns it into a view of the value created.
A proxy will not close that gap. Claude Code, Codex and Cursor log in with a subscription, not an API key, so there is no traffic to intercept.
Hence agent-usage-tracker (aut), it reads the logs those tools already write, normalises every turn into one event, and ships it to a sink on your own homelab.
how much of each prompt came from cache, how much came back per instruction given, and how both moved month over month. Any dollar number is what that usage would have cost through the API, not what was actually paid.
Zero runtime deps, runs on a timer, macOS, Linux and Windows.
@hwhjones not today... the local logs carry token counts, not plan state, so the percentage is simply not in the file.. the whole idea was to keep it local as much as possible. they do expose it behind an authenticated endpoint though, one GET each with the creds the cli already wrote.
this is not a page you render once.
it is a standard every doc passes, checked the same way each time.
the files live in your repo, version controlled, public if you want, and the same skill runs across agents.
An agent writes you a plan or an incident postmortem as markdown
you skim it, approve it, and miss the assumption buried in paragraph nine.
markdown is fine for the agent's own notes.
but a doc a human has to act on gets read when it's one HTML page, plain-language summary up on top, a diagram in every before/after, risks color coded, a checklist.
rendering one page is easy.
keeping every doc that readable, in your repo, across agents, is the part that needs a validator:
no summary, it fails.
a before/after with no diagram, it fails.
a postmortem with no timeline, it fails.
so I built human-html. nine kinds, files in your own repo, same skill in Claude Code, Codex, Cursor, and other agents.
npx skills add rhnfzl/human-html
and there isn't one harness for all this.
it changes with the kind of SaaS you're building on.
that's the part i keep finding interesting, the memory piece especially, which is where most of my time goes right now.
A question I keep wrestling with PM and Managers:
If coding agents like Claude Code and Codex are this capable, why can't the AI you build on top of a SaaS product behave the same way?
From the outside it's the same thing, an LLM with tools.
It isn't. They run on different physics.
one more, an architecture call.
the business logic belongs in the MCP layer, not the AI layer.
ideally you could keep it in the AI side, but then your MCP is useless to anyone who wants it without your platform.
so the AI stays thin from business logic, the MCP stays the source of truth.
So the answer was never a bigger model.
It was giving the system a real memory of what is true.
I call it a Belief State.
I will break down how it works in the future posts.
A question I keep wrestling with PM and Managers:
If coding agents like Claude Code and Codex are this capable, why can't the AI you build on top of a SaaS product behave the same way?
From the outside it's the same thing, an LLM with tools.
It isn't. They run on different physics.
The usual comeback: isn't the chat history just the filesystem?
Not really. A transcript is what was said, not what is true.
A file read returns truth, a transcript returns claims.
And checking the truth on a SaaS means a round trip.