Reuse the mechanics. Spend model work on the content.

Start with plans, research comparisons, and technical explainers. Use the public links in real conversations. Add a feature when a document exposes a specific need.

I would spend the next iteration improving the usefulness of the output. Hosting already works. A large document platform would slow down the learning you wanted from this MVP.

Current capability

The skill creates self-contained HTML, retains a local copy, publishes through authenticated Cloudflare MCP to Pages, and checks the served bytes before returning a link. Astro builds the host. Published documents are public.

Implicit invocation is enabled in the skill metadata. A directory junction exposes the project in the user skill directory without duplicating the files. Configuration is verified; correct selection in a fresh conversation remains a usage test.

Hosted revisions, private access, feedback capture, and an artifact library are future work. The complete encoded publishing bundle has a local 256 KiB budget across all retained documents, not per document.

Your first use cases

Use case	Natural request	A useful result
Implementation plans	“Turn this automation idea into a roadmap I can review and share.”	Sequence, open decisions, and acceptance criteria. Suggestions stay distinct from approved work.
Research comparisons	“Make a decision brief comparing these agent tools for my workflow.”	Source-backed differences tied to your tasks, with dates and visible uncertainty.
Power Platform explainers	“Explain this SharePoint and Power Automate approval flow as a document.”	Triggers, data movement, failure paths, and responsibility. Start with fictional or publishable examples.
Client scope briefs	“Create a shareable scope brief for this public demo.”	Outcomes, exclusions, and decisions a client can understand. Creating a document does not send a message or submit a proposal.
Technical handoffs	“Make a handoff explaining what changed and how it was checked.”	Evidence and reproducible checks. Use public code or a sanitized example while hosting is public.
Progress reports	“Turn these notes into a short progress report with evidence.”	Facts, blockers, and follow-up actions. Start manually; scheduling is a separate choice.

These are proposed trials for your development, Microsoft 365, and consulting work. They are not claims that every format has already been tested.

Update: spend model work on the content

The next priority is to reuse instructions and executable code. The model should decide what the document needs to say. Scripts should assemble the HTML, check it, prepare publication, and verify the result. These are proposals for the next version, not features implemented by this roadmap update.

Instructions alone do not make execution free. If the agent reads a long recipe and rewrites the same CSS or deployment code on every run, it still spends model context and output. A script saves that repetition only when the agent runs it and receives a short result.

What already exists

The skill already has staging, packaging, and verification scripts. The largest remaining opportunities are repeated HTML authoring, ad hoc browser checks, and publication coordination. The current publisher embeds the entire document collection in one request. Passing that request between tools inside an orchestration call can avoid printing it into the conversation; it does not reduce its network size.

Three proposals

Proposal	What becomes reusable	Model work and tradeoff
A. One reusable document shell	Store CSS, layout, and accessibility defaults in `assets/document.html`. Add a renderer that inserts a title and body into that shell. Keep the existing publishing scripts.	The model writes the body content and any special diagram. Less layout code is generated, but body HTML can still vary. This is the smallest first step.
B. Structured document renderer. Recommended target.	The model writes a small JSON document. A script renders supported paragraphs, lists, tables, sources, and collapsible notes using a shared stylesheet. Fixed checks validate the output.	The model concentrates on synthesis and selects blocks. Routine markup and CSS disappear from generated output. Unusual layouts need an explicit custom-HTML path.
C. Local publishing tool	Expose one tool accepting a local document path. It renders, stages, publishes, waits, verifies, and returns the public URL plus a short check result.	This can remove repeated orchestration turns. It also creates an integration to maintain. Prove access to the existing authenticated Cloudflare connection first; a normal Node script cannot automatically call the host's MCP tools.

I recommend A as one small change, then B after testing it on a plan and a comparison report. C should wait until publishing coordination is a measured source of model usage. No savings percentage is claimed without a baseline.

How proposal B would work

You ask for a roadmap or report naturally. The short skill entrypoint selects the document workflow and reads only the relevant format guidance.
The model gathers evidence and writes a document specification. Existing approved content can be reused rather than rewritten.
The renderer escapes text and builds the page from reusable blocks. Scripts run checks and produce concise diagnostics. The model returns only to fix substantive content or reported problems.
The existing Cloudflare MCP connection publishes the prepared request. A verification step checks the actual artifact, then the agent gives you its URL.

{
  "title": "Approval flow rollout",
  "sections": [
    {
      "heading": "First milestone",
      "blocks": [
        { "type": "paragraph", "text": "Test one fictional request." },
        { "type": "list", "items": ["Submit", "Approve", "Verify notification"] }
      ]
    }
  ]
}

This is an illustrative input contract. The first implemented schema should include only blocks required by the first two real documents. Unsupported block types should fail with a useful message rather than disappear. Free-form diagrams remain a deliberate exception.

A small skill package

Location	Proposed responsibility
`SKILL.md`	Short triggers, content responsibilities, one normal command, and links to conditional references. Keep implicit invocation enabled.
`references/`	Plan or research-specific guidance, read only for the current document type. Publication troubleshooting loads only on failure or setup.
`assets/`	A document shell and stylesheet used as output assets. The model need not read their full contents for ordinary documents.
`scripts/`	Render and check commands. Reuse the existing hosting scripts rather than maintaining duplicate implementations.
`hosting/`	Astro app, staged artifacts, target configuration, and current publishing helpers. Keep dependency folders outside the discoverable skill package.

The current whole-project junction exposed a dependency's unrelated skill in discovery. A small installed skill directory linked only to its entrypoint, references, assets, and scripts would avoid that. Its publication reference can resolve the separate hosting project explicitly. This packaging correction is proposed alongside A.

What scripts should check

Input schema, escaped text, valid section links, and missing required fields.
Document size and staging collisions, without removing old artifacts to make room.
Browser overflow, broken controls, and console errors, with screenshots available for visual review.
Deployment completion and exact hosted content before reporting a ready link.

Scripts cannot establish that a comparison is fair, a source supports a claim, or an implementation sequence makes sense. Those remain model and human review tasks. Passing structural checks must not imply factual verification.

Publishing without loading every document into context

Keep generated payloads in local files. Use orchestration to read a payload, pass it directly to Cloudflare MCP, and return only the deployment ID and status. Do not print the full request and ask the model to reproduce it. That pattern is already possible with the current tools.

A later single-command publisher requires a supported authenticated MCP client or host bridge. Do not extract OAuth credentials, introduce a second login silently, or make a public upload endpoint to avoid that integration work. Until the bridge is proven, keep the small agent-to-MCP handoff.

The 256 KiB cap was an arbitrary local guard, not a Cloudflare limit. Reusable templates may reduce authoring tokens but do not solve the growing all-document bundle. Treat payload limits as a separate transport decision. Replace the cap with a measured limit after testing the real transport, and eventually publish individual assets if collection size warrants it.

Revised next steps and success checks

Measure the current path. Use one plan and one comparison brief. Record available input/output token counts, tool calls, elapsed time, model-written markup, and correction rounds. If token counts are unavailable, label tool calls and output size as proxies, not token savings.
Implement A and fix discovery packaging. Reuse one shell and a fixed check command. Verify no unrelated dependency skills are discovered. Keep the current hosted documents and URLs unchanged.
Trial B on those document types. Write a minimal schema and renderer. Compare with the baseline on equivalent supplied content. Accept it only if measured usage falls without losing facts, citations, accessibility, or useful layouts.
Consolidate the normal workflow. Save deterministic checks as scripts and return compact summaries. Retry only the failed stage. Reuse staged bytes and record deployment state so a timeout cannot trigger a blind duplicate upload.
Consider C from evidence. Prove an authenticated path-to-URL tool on one artifact. If integration work outweighs the coordination savings, retain B and the existing MCP handoff.

Feedback capture, revisions, private access, and an artifact library remain later options. A real need can change their order. This update proposes the work; it does not implement the new renderer, tools, or revision policy.

What the earlier research contributes

Source	Lesson to borrow	When it helps
Effective HTML	Separate plans, diagrams, wireframes, and prototypes. Preserve source commitments and load format-specific guidance only when needed.	Improve document types after actual use. Consult focused online references without installing the full collection.
The unreasonable effectiveness of HTML	Its examples include comparisons, explainers, reports, and editors that export decisions. Interaction should help the reader inspect or decide something.	Try a process diagram first. Later test one small decision editor with text export.
Plannotator	Visual annotation and feedback to the agent provide a model for document review.	Borrow that workflow when feedback loses context. Avoid rebuilding its broader review system for this MVP.

The earlier thread discussed Theo's HTML plan workflow but did not establish that a public package was his exact private skill. This roadmap uses the public sources above. “System effectiveness” appears to refer to Thariq's HTML effectiveness examples.

Automatic invocation in practice

Ask naturally, for example, “Make a roadmap for this project and give me a link.” The description targets substantial roadmaps, plans, research briefs, comparisons, and technical explainers that benefit from a durable document.

Quick factual answers stay in chat. Requested Markdown or Word output keeps that format. Private or local-only requests override public publishing. Implicit selection allows the agent to choose the skill; it does not guarantee selection for every matching prompt.

First discovery tests

Request a shareable roadmap in a fresh conversation without naming the skill. Expect HTML and a verified public link.
Ask a one-line factual question. Expect a direct answer.
Request a local-only plan. Expect a local file and no deployment.
Request a Markdown roadmap. Expect Markdown.
Request a revision to a hosted document. Expect local edits and an explanation that hosted revisions are deferred.

Keep the next build small

Keep application prototypes and wireframes in the dedicated design workflow for now. Publishing those outputs can become a later integration once the artifact contract and size budget support them. Postpone accounts, dashboards, automatic scheduling, and a large template library until use shows a need.

Use the skill for a week of actual work. Then pick the failure that cost you the most time. Let that determine the next change.