About
What a skill is
A skill is a folder of Markdown that an agent runtime loads when a task matches its description. This one triggers when someone asks for online publishing, human feedback, version history, or a revision of existing SecondPage work. It is model-neutral: Claude, ChatGPT, Codex, Gemini, and custom MCP clients can all use it. Availability depends on the organization's plan, and SecondPage is for adults aged 18 and over.
When an agent should reach for SecondPage
- The user asks for a page, report, deck, guide, dashboard, or any shareable output.
- The output needs review, comments, edits, approval, reuse, or a stable URL.
- The work is a revision of an existing Page: read it and update it instead of creating a duplicate.
- The work depends on data, files, or organization context that should stay attached to the deliverable.
How this fits with the connect page and the docs
Connecting is separate from authoring. The connect page explains how an agent reaches SecondPage over MCP and signs in. This page explains what the agent should do once connected. The agent docs explain the same product to people. When they disagree, the skill wins for agent behaviour, because it is versioned and served live through load_secondpage_skill.
- For AI agents, connect over MCP
- Agent docs, the product explained for people
- This page, the authoring rules, versioned and served live
Core contract
Every agent loads this first. It is what load_secondpage_skill returns for topic core, and it is embedded in SKILL.md so an installed copy carries it too.
A Page is an exact static file bundle at a stable URL, with immutable versions and human comments. Validate your HTML before publishing; SecondPage serves the files you supply.
Choose the input
Use exactly one content mode per create_page or update_page call:
The server does not render, rewrite, or autofix the submitted source. Decks receive a separate bounded compatibility assessment after publication; that assessment does not repair source or make malformed files safe.
- One self-contained HTML document: pass
htmlas plain text, at most 512 KiB of UTF-8 bytes. It becomesindex.html; inline CSS and JavaScript are allowed. No encoding or model-generated assets are needed. - Several files, with HTTP available: pass
upload_fileswith path, content_type, byte_size and SHA-256 per file. PUT only files markedupload_requiredto their returned URLs with the required headers. Complete using the same tool andupload_session_id. - Several files, without HTTP available: pass the complete
filesarray with a relativepath,content_base64containing each file's original bytes, and optionalcontent_type. Encode text files as UTF-8 before base64 encoding; preserve binary bytes.
Never mix html, files, upload_files, or upload_session_id. A manifest is optional for the default index.html route; supply one for custom entrypoints or multiple routes. File paths cannot start with /, contain .., backslashes, or control characters. Load topic: "publishing" for upload and export details.
Create or revise
Use list_pages with query to find Pages by title or slug; follow next_cursor with the same query until has_more is false. Confirm the organization with get_organization_context if uncertain.
Use create_page for new work. Target matching runs before upload URLs are issued. target_review_required means nothing was uploaded: use the returned evidence to identify the existing Page, or retry target_choice: "create_separate" only when the user confirms a separate Page. Do not invent another match score.
For every revision:
read_page({ page_id })gives the currentbase_version_idand metadata.- If
file_bundleis null, useexport_page({ page_id, export_type: "html" }). Read every returned file according to its encoding (utf8, base64, or reference). Verify reference bytes against the returned sha256; on mismatch re-export. Use the exported version_id as your base and preserve its manifest (entrypoint and routes) in both upload calls. Custom routes require upload mode; hand off the upload if your client cannot PUT files. - Edit the complete bundle and call
update_pagewithpage_id, requiredbase_version_id, one content mode, and a usefulupdate_reason.
Updates replace every file, never patch a subset. html also replaces the whole bundle with index.html. A concurrent change returns version_conflict: read/export again, reapply the intended edit, and retry with the fresh base. Do not retry old files under a new base without reconciling the intervening change.
Upload completion must retain the original title/create intent or page_id/update base and metadata. Never attach a new base to an old update upload session. no_change means the effective content and requested Page state already match; return the existing URL. A rename with identical files is still a real update.
Visibility and handoff
New Pages default to organization (workspace members); use public for external sharing or private for a draft. MCP agents cannot change an existing Page's visibility, including with OAuth. For revisions, omit visibility or repeat its current value; direct the human to Sharing to change it.
Return the Page URL and who can see it. If publishing returns warnings, resolve them before calling the Page finished.
Errors and pending work
Check isError and branch on the stable JSON error code. Follow recovery when present, or the existing next_action. Do not match message wording. Fix invalid fields; wait for retry_after_seconds for throttles. Reopen expired upload sessions. Shrink bundles that exceed returned limits. Do not blindly retry permanent failures.
For newly authored slides, call prepare_deck with the title, ordered { id, html } slides, optional shared CSS/assets, and optional canvas. It returns a normal inline bundle and does not publish, call a model, or prove readiness. Publish the returned bundle with presentation: { "intent": "deck" }; assemble larger decks locally and use signed uploads.
For an existing deck export, preserve its files and publish them directly with deck intent. Publication and presentation readiness are separate: only ready verifies controls for that exact version. Follow pending presentation_follow_up guidance with a compact version-bound read_page, and stop on a terminal status. Creation may set presentation policy; updates preserve policy, which a Page manager changes in Share settings.
Queued uploads or refreshes are pending, not completed. For live data load topic: "live-data-connections": configure a spec, keep its revision identity, and preview that revision only when ready. CSV is refreshed by human upload.
Comments and decks
Read a specific Page's queue with read_comments({ page_id, queued_only: true }). Read/export its latest bundle, revise it, then reply with add_comment to close the loop. Use read_page_analytics when readership evidence would help.
Only slide-based documents use <html data-sp-document-type="deck"> and stable data-sp-frame attributes on slide roots. Ordinary scrolling Pages do not use deck markers. When generating new markup, give major editable regions stable id and data-review-target-id values. Preserve exact user-supplied files when that was requested. Report publishing warnings and, for decks, the separate presentation status; a live URL proves publication, while ready proves presentation compatibility.
Also at /skills/coreraw Markdownload_secondpage_skill { "topic": "core" }
References
Each reference is one Markdown file inside the skill folder. Two of them can be loaded on their own over MCP; the rest arrive with topic all or as files in the download.
Publishing
- Publishing, uploads, and revisions
- Signed uploads, exports, complete-bundle updates, custom routes, and executable examples for create_page and update_page.
- publishing-shapetopic: "publishing"raw .md
Live data
- Live data connections
- Connected Pages that refresh from approved data sources: FetchSpec, revisions, previews, and CSV.
- live-data-connectionstopic: "live-data-connections"raw .md
Design
- File bundle cookbook
- Minimal working file bundles: a single page, a multi-file app, semantic edit targets, and a deck.
- section-cookbookraw .md
- The four-tier design system
- The four-tier vocabulary an agent uses to decide how much visual treatment a Page deserves.
- visual-tiersraw .md
- Long-form visual treatments: essay vs memo vs magazine
- Three treatments for prose-heavy Pages, essay, memo, and magazine, and how to choose between them.
- long-form-themesraw .md
- Asset handoff: media and rich content in a Page bundle
- How images, video, charts, and data files get into a Page: bundled assets versus direct media uploads.
- asset-handoffraw .md
Workflows
- Design onboarding notes
- When and how to ask a user about design preferences, and how to carry the answers into the files you author.
- design-onboardingraw .md
- Organization stewardship
- Maintaining an organization's Pages over time: look before you publish, update in place, and tend the comment queue.
- organization-stewardshipraw .md
- Codex comment queue stewardship
- Comment-queue maintenance from Codex when a task authorizes it.
- codexraw .md
- Claude Cowork comment queue polling
- Scheduled comment-queue polling from Claude Cowork.
- claude-coworkraw .md
Orientation
- SecondPage overview
- A short orientation for agents: what a Page is, how organizations and entitlements work, and which topic to load next. Served by the topic API, not bundled.
- overviewraw .md
Install
Install the complete skill folder in a runtime that supports Markdown skills. Otherwise, provide SKILL.md as instructions and load its references when needed. Connect to SecondPage separately through MCP.
Claude Code and any runtime that reads ~/.claude/skills (adjust the target folder for Codex: $CODEX_HOME/skills or ~/.codex/skills)
mkdir -p ~/.claude/skills && curl -fsSL https://secondpage.cc/publishing-with-secondpage.zip -o /tmp/publishing-with-secondpage.zip && unzip -o /tmp/publishing-with-secondpage.zip -d ~/.claude/skills- Claude Code
- Save
SKILL.mdand references/ under~/.claude/skills/publishing-with-secondpage/. Usereferences/organization-stewardship.mdfor requested maintenance. - Codex
- Save the complete publishing-with-secondpage folder under
$CODEX_HOME/skills, or~/.codex/skillswhen CODEX_HOME is unset. Usereferences/codex.mdfor requested comment queue work. - Claude Cowork
- Install the skill using the runtime-supported flow. Use
references/claude-cowork.mdwhen scheduled comment queue polling is requested and available. - Claude.ai
- Download https://secondpage.cc/publishing-with-secondpage.zip and upload it in Claude.ai under Settings > Capabilities > Skills.
- OpenClaw and similar Markdown-skill runtimes
- Save the complete skill folder, including its references, using the runtime's supported installation flow.
- Runtimes without an installable skill system
- Provide
SKILL.mdthrough the runtime-supported instruction mechanism. Load references on demand from the bundle orGET /api/skills/<topic>, which returns JSON containing Markdown content. Publishing requires an authorized SecondPage MCP connection.
Entry points
Stable URLs for agents that fetch instead of installing. Every response under these paths carries the X-SecondPage-Skill-Version header, so an agent can compare before downloading.
| Entry point | URL | Response |
|---|---|---|
| Skill page (HTML) | / | text/html, this page |
| Topic page (HTML) | / | text/html, one rendered page per topic |
| Topic Markdown | / | text/markdown, the same topic as raw source |
| Skill file | / | text/markdown, the canonical SKILL.md |
| Reference file | / | text/markdown, one file per bundled reference |
| Topic JSON | / | application/json with { topic, content }; also accepts publishing and all |
| Bundle JSON | / | application/json with skill_md, references, and install_guidance |
| Bundle zip | / | application/zip, the installable skill folder |
| MCP endpoint | https:/ | Streamable HTTP; load_secondpage_skill topics core, publishing, live-data-connections, all |
| Agent quickstart | / | text/plain, how to connect and what to call |
| Site index | / | text/plain, every agent-facing URL on the site |
/skills and /skills/<topic> also return Markdown when the request's Accept header prefers text/markdown over text/html, so an agent mid-task does not need a second URL.