dsh-gh-pages-artifacts

dsh plugin --profile web add dsh-gh-pages-artifacts

dsh-gh-pages-artifacts

A DeepSeek Harness (dsh) plugin that lets agents publish artifacts (HTML pages and Markdown documents) as shareable links on GitHub Pages.

Ask the agent for a report, dashboard, chart, or write-up "as a page". It writes the file, publishes it, and replies with a link like https://you.github.io/dsh-artifacts/q3-report-k3x9ab/. Later it can update the same artifact in place, so the link never changes. It can also list, read back, and delete artifacts.

Published artifacts are public. GitHub Pages sites are reachable by anyone with the link. On GitHub Free the repository must be public too, and git history keeps old versions even after deletion. The plugin asks before publishing or deleting (except in Full access sessions, see [Behaviour details](#behaviour-details)), adds noindex, and refuses hidden files and content that looks like a credential, but you decide what gets shared.

What the agent gets

Tool · What it does · Approval

artifact_publish · Create an artifact from a workspace file (path) or inline content, or update one in place (id). Markdown is rendered to a clean page with light and dark themes; HTML is served as-is. Extra files (images, CSS, JS, data) go in assets. · yes

artifact_list · List artifacts, newest first, with ids, titles, URLs; filter with query. · no

artifact_read · Read an artifact's source (or another text file of it) in windows. · no

artifact_delete · Delete an artifact. Its id is never reused, so an old link can't show new content. · yes

artifact_status · Diagnose the setup (token, repository, Pages settings) and check whether a deployment or artifact is live. · no

artifact_repository · Show or change where new artifacts go: link an existing repository (owner/name or a remote URL), unlink it, or switch between the shared and per-artifact strategies. · no

The plugin also adds:

• a short system-prompt section so the model knows when to use the tools, and
• a bundled artifact-pages skill with page-design guidance. Users can invoke it as /artifact-pages, and a same-named skill in ~/.dsh/skills or the project overrides it.

Repository strategies

• shared (default): every artifact gets a folder in one repository, at https://<owner>.github.io/<repo>/<id>/. The repository is, in order: one you linked at runtime ("publish my artifacts to github.com/me/team-pages", which the agent does with artifact_repository link), the repository option (owner/name or a remote URL such as git@github.com:me/team-pages.git), or owner/repo.
• per-artifact: each new artifact gets a new repository of its own, <owner>/<repoPrefix><id> (default artifact-<id>), served at https://<owner>.github.io/artifact-<id>/. The plugin creates the repository, publishes the page at its root, turns on GitHub Pages, tags it with the dsh-artifact topic, and sets the page URL as the repository's homepage. This needs a token that may create repositories (see the token section).

Set it on the plugin's settings page, with the repoStrategy option, or in chat ("from now on, put each artifact in its own repo"). A choice made in chat is saved into the same settings, so the settings page and your profile file always show what is in effect. (Without dsh's settings service, for example in a custom composition, the choice is kept in the registry instead and overrides the configuration.) Existing artifacts always stay where they were published; updates, reads, and deletes find them through the registry.

Tracking what was published

Click Artifacts in the dsh sidebar (Web and Desktop) to see every published page and document, newest first. Each entry shows its title, link, description, repository, and last update. Links open in a new browser tab (on Desktop, in your default browser). Refresh also checks GitHub for artifacts published from another machine. To delete one, hover its row, click the trash icon, and confirm. The plugin commits the removal of its files from the repository and tombstones its id, and the page returns 404 once GitHub Pages redeploys (usually within a minute). Because you confirmed in the panel yourself, the agent approval prompt does not apply here.

Every publish, update, and delete is recorded in a local registry at $DSH_HOME/gh-pages-artifacts/registry.json (option registryDir). Next to it, index.html lists every artifact with clickable links to its page and repository, its kind, revision, last update, and whether it is live or deleted. artifact_list returns the same list as Markdown links, across all repositories and strategies, and adds artifacts it finds in the shared repository that were published from another machine. Ask "what have you published?" or "show me the artifact index" (the agent can present the index page in the side panel).

How it works

• The repository holds the content. Each artifact lives in its own folder on the Pages branch (or at the root of its own repository with the per-artifact strategy) (<id>/index.html, plus source.md for Markdown and any assets). A manifest .dsh-artifacts.json at the branch root records ids, titles, descriptions, kinds, revisions, and timestamps. With siteDir: '' (the default) the manifest is served too, so anyone who knows the site URL can list every artifact. Publish from /docs (siteDir: docs) to keep it unlisted.
• Every change is one atomic commit. The commit is built with the Git Data API (blobs → tree → commit) and applied with a fast-forward-only ref update. If another writer (a second dsh window, another machine) moved the branch, the change is rebuilt on the new head and retried. Nothing is lost, and nothing is force-pushed.
• .nojekyll is committed so Pages serves files exactly as written. The plugin refuses to write into an existing Jekyll site (one with

…(truncated)