SecondPage skill

The SecondPage skill for AI agents

publishing-with-secondpage is the instruction set an AI agent reads before it publishes or revises a SecondPage Page: a report, deck, guide, dashboard, brief, or files you hand it. It covers what to send, how to update work in place instead of making copies, how visibility works, and how to handle comments and errors. You do not need to read it. Your agent does, and it makes those calls for you.

publishing-with-secondpageVersion sha256:f5adc127609810 referencesSKILL.mdBundle JSON.zip

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.

  1. One self-contained HTML document: pass html as plain text, at most 512 KiB of UTF-8 bytes. It becomes index.html; inline CSS and JavaScript are allowed. No encoding or model-generated assets are needed.
  2. Several files, with HTTP available: pass upload_files with path, content_type, byte_size and SHA-256 per file. PUT only files marked upload_required to their returned URLs with the required headers. Complete using the same tool and upload_session_id.
  3. Several files, without HTTP available: pass the complete files array with a relative path, content_base64 containing each file's original bytes, and optional content_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:

  1. read_page({ page_id }) gives the current base_version_id and metadata.
  2. If file_bundle is null, use export_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.
  3. Edit the complete bundle and call update_page with page_id, required base_version_id, one content mode, and a useful update_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.md and references/ under ~/.claude/skills/publishing-with-secondpage/. Use references/organization-stewardship.md for requested maintenance.
Codex
Save the complete publishing-with-secondpage folder under $CODEX_HOME/skills, or ~/.codex/skills when CODEX_HOME is unset. Use references/codex.md for requested comment queue work.
Claude Cowork
Install the skill using the runtime-supported flow. Use references/claude-cowork.md when 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.md through the runtime-supported instruction mechanism. Load references on demand from the bundle or GET /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.

Skill entry points, their URLs, and response types
Skill page (HTML)/skillstext/html, this page
Topic page (HTML)/skills/<topic>text/html, one rendered page per topic
Topic Markdown/skills/<topic>/index.mdtext/markdown, the same topic as raw source
Skill file/skills/publishing-with-secondpage/SKILL.mdtext/markdown, the canonical SKILL.md
Reference file/skills/publishing-with-secondpage/references/<file>.mdtext/markdown, one file per bundled reference
Topic JSON/api/skills/<topic>application/json with { topic, content }; also accepts publishing and all
Bundle JSON/api/skill-bundleapplication/json with skill_md, references, and install_guidance
Bundle zip/publishing-with-secondpage.zipapplication/zip, the installable skill folder
MCP endpointhttps://mcp.secondpage.cc/mcpStreamable HTTP; load_secondpage_skill topics core, publishing, live-data-connections, all
Agent quickstart/skill.mdtext/plain, how to connect and what to call
Site index/llms.txttext/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.