| name | htmlbin-publish |
| description | Use when the user asks to publish a drop to htmlbin, make a page or preview for content, or share something as a quick HTML URL. Consults htmlbin's pattern library to shape the artifact before any HTML is authored. |
htmlbin-publish
htmlbin publishes a single HTML file to a public URL. The htmlbin CLI ships
with a pattern library — markdown design briefs that describe how to compose
a drop for a given use case (PR writeup, plan/spec, summary roundup, etc.). The
pattern must shape the HTML before it is written. By the time htmlbin publish runs, the artifact already exists and the pattern can no longer help.
When this skill applies
Trigger phrases include:
- "publish a drop to htmlbin"
- "publish to htmlbin"
- "make a page / drop / preview for this"
- "share this as an htmlbin"
- "put this online" when the context implies an htmlbin
Workflow (in order, no shortcuts)
1. Ensure the CLI is available
htmlbin --version
If the command is not found, substitute npx @htmlbin/cli everywhere htmlbin
appears below. No global install is required.
2. List patterns; install them if absent
htmlbin patterns list
If no patterns are listed:
htmlbin patterns init
This installs the official pattern catalog locally. The bundled set today is
summary-roundup, pr-explainer, plan-spec-explainer.
3. Match the task to a pattern
Map the user's request to one of the listed patterns using each pattern's
description. If nothing fits, say so out loud ("No matching pattern —
proceeding pattern-free with neutral defaults") and skip to step 5. Do not
silently improvise.
4. Read the chosen pattern before authoring
htmlbin patterns list prints a path for each entry. Read the entire file at
that path. The pattern document includes a content checklist, layout direction,
and brand-sensing rules. The pattern's job is to shape both what's on the page
and how it's laid out.
5. Author the HTML, then publish or update
Write a single self-contained HTML file to a temporary path.
Before running any htmlbin command, decide: revision of an existing drop, or a
new one?
Update (same URL, new version) — the default when the user references a
prior result, a URL or slug from earlier in this session, or says "update /
revise / re-publish / the [X] doc":
# Slug known (from earlier in the session):
htmlbin update <slug> --file <file>
# Tagged with metadata on first publish (idempotent — no slug needed):
htmlbin publish <file> --upsert --metadata doc=<stable-id>
matched:true in the response means an existing drop was updated; its absence
means a new drop was created.
Publish new (new URL) — only when the user says "new / fresh / separate /
another", wants an immutable snapshot that won't change on future edits, or it
is a genuinely different document. If unsure, default to update.
htmlbin publish <file> --metadata doc=<stable-id>
Tag every new publish with --metadata doc=<stable-id> (e.g.
doc=opus-rules). Future revisions can then use --upsert without needing to
remember the slug.
The command prints the URL. That URL is the deliverable.
Hard rules
- Never publish a file the user has not seen described. Surface the chosen
pattern (or "pattern-free") before authoring.
- Never run
htmlbin publish first and pick a pattern after. The artifact
is what gets published; you cannot retro-shape it.
- Do not invent patterns. Only use what
htmlbin patterns list returns.
- Pattern-free is allowed but must be declared. Do not quietly skip step 3.
- Never use
htmlbin publish for a revision. If a drop for this content
already exists in this session, use htmlbin update <slug> or
htmlbin publish --upsert --metadata doc=<id>. Running publish on a
revision mints a new URL and leaves a duplicate in the system.
References
