Grow through documents you actually use
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.
Roadmap ordered by evidence
- Now. Run a small usage trial. Create five real documents across at least three use cases. Include a fresh conversation without naming the skill. Record the request, whether the skill activated, whether the link opened, corrections needed, and whether you reused the output. Pass when every hosted link works and the documents preserve the supplied facts.
- Next. Fix recurring writing and layout problems. Add a narrow instruction or reference for a repeated failure. Plans should preserve commitments, research should retain citations, and explainers should expose relationships. Add diagram guidance when a real explanation needs it. Pass when the next document of that kind needs less correction without becoming a rigid template.
- When chat review loses context. Add feedback export. Start with section links and a small feedback form that exports text to paste into the conversation. Make clear that feedback stays in the page until exported. Add server storage only if that manual step repeatedly gets in the way. Pass when feedback identifies the right section and transfers accurately to the agent.
- When you need to update a shared document. Decide revisions. Reopen the deferred choice between stable URLs and separate version links. Agree how readers identify the current version before implementing replacements. Test previously shared links against that decision. Until then, retain the hosted original and edit locally.
- When publishing or retrieval becomes limiting. Improve storage. Inspect bundle size after builds. A proposed planning trigger is 192 KiB, before the 256 KiB cap. Prove a larger MCP-compatible upload method live before moving content out of the embedded module. Preserve all artifact paths. Add a simple index when finding documents through conversations becomes frustrating, then search only if the index is insufficient.
- When confidential material is needed. Add private access. Verify the chosen hostname and alternate Pages URLs with signed-in and signed-out tests before using private client notes. Consider Astro Starlight if the documents grow into a maintained knowledge base with navigation, ownership, and regular editing.
The order is conditional. Confidential work moves private access earlier. A small document collection can keep the current publishing method. These milestones are recommendations, not scheduled commitments.
What the earlier research contributes
Source | Lesson to borrow | When it helps |
|---|---|---|
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. | |
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. | |
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.