Draft Headless Pages

Headless Draft page automation for remote agents, Docker, CI, and Linux environments. Use this as the default Draft skill for OpenClaw-style isolated runtime...

Security Scan

The skill's requirements and runtime instructions are coherent for a headless Draft CLI workflow: it installs a draft CLI, expects a single invite-code env var, and instructs only on running that CLI in headless mode.

Purpose & Capability

Name/description (headless Draft page automation) match what the SKILL.md requires and instructs: a 'draft' CLI binary and headless v2 commands (start-server, status, page create/patch/publish). The npm package declared (@innosage/draft-cli) provides the required binary, which is appropriate for this purpose.

Instruction Scope

SKILL.md is narrowly scoped to launching and using the draft CLI in headless runtime. It instructs running the daemon, checking JSON status, manipulating pages, and using local file paths for image uploads. It does not instruct reading unrelated system files, harvesting other environment variables, or sending data to unexpected external endpoints beyond what the draft CLI would do.

Install Mechanism

Install uses a named npm package (@innosage/draft-cli) which is a standard and expected mechanism to provide a CLI binary. This is moderate-risk (npm packages are third-party code) but is proportionate and not an arbitrary download/extract from an unknown server.

Credentials

Requires a single env var GLOBAL_INVITE_CODE (documented in SKILL.md as settable to 'innosage' for the free beta). This is plausible for an invite-code/feature-flag, but it behaves like a credential: treat it as sensitive. The skill does not request unrelated credentials or config paths.

Persistence & Privilege

No elevated persistence requested: always is false, no system-wide config paths are modified, and autonomous invocation is the platform default. The skill does not request permanent presence or cross-skill config changes.

Assessment

This skill appears internally consistent with a headless Draft CLI workflow, but before installing: 1) verify the npm package (@innosage/draft-cli) source/reputation (inspect its npm page / repository) because it will install a binary named 'draft'; 2) treat GLOBAL_INVITE_CODE as a sensitive value and do not set production secrets there — the doc suggests a default 'innosage' for beta; 3) be aware the agent will access local files you point it to for image uploads and the draft CLI will make network requests to the Draft service; 4) if you have security concerns, install and run the CLI in an isolated environment (CI runner or container) and audit the package contents before granting broader access.

Draft Headless Pages Skill

Use this skill for isolated Draft page automation in CLI v2.

For OpenClaw and other remote-agent environments, this should be the default Draft runtime skill.

Use This Skill When

• the agent is running remotely, in Docker, in CI, or on a Linux worker
• the agent should create, edit, publish, or review Draft pages without a paired browser tab
• the user wants a published page URL as the review surface

Do Not Use This Skill When

• the workflow depends on local workspace markdown files as source of truth
• the agent is expected to operate through a browser-backed v1 Draft session
• the user is asking for a human approval workflow rather than raw page automation

Trigger Guidance

Trigger this skill when the request is about:

• headless Draft page creation or mutation from Linux, Docker, CI, or a remote agent
• page-domain automation that should not depend on a paired browser tab
• review handoff by publishing a headless page for a human to inspect
• commands such as draft start-server --runtime v2, draft page create, draft page patch, or draft page publish

Do not trigger this skill when:

• the task is workspace/file-backed markdown authoring or review
• the request is a generic Draft CLI question that is not specifically about headless page-domain usage
• the primary need is gated human oversight; use draft-agent-loop on top of this runtime instead

Boundaries

• Runtime plane: CLI v2 only.
• Storage plane: page-domain content only.
• Human review surface: published or preview page URL.
• Not in scope: workspace mode or local file bindings.
• Not in scope: browser-backed v1 session management.

If the user needs repo-backed markdown review with durable comments, use draft-review-loop and workspace commands instead. If the user needs approval checkpoints and execution sign-off, use draft-agent-loop, which should depend on this skill.

Startup and Verification

Always make the runtime explicit.

draft start-server --runtime v2
draft status --json

Proceed only when draft status --json shows a healthy headless session for v2.

Operational rules:

1. Start the daemon with --runtime v2 before page commands.
2. Check draft status --json before mutating content.
3. Treat status JSON as the source of truth for daemon health and selected runtime.
4. Treat publish-and-review as the standard human feedback path.

Safe Command Set

Prefer these commands for headless page workflows:

draft page create "Title" --json
draft page cat <page_id>
draft page append <page_id> "content" --json
draft page replace <page_id> --heading "Section" --content "replacement" --json
draft page patch <page_id> --json
draft page insert-image <page_id> /path/to/local/image.png --json
draft page update-image <page_id> <local_id> --align center --width 500 --json
draft page delete-image <page_id> <local_id> --json
draft page annotate <page_id> --anchor "text" --note "feedback" --json
draft page comments <page_id> --json
draft page publish <page_id> --json

Usage guidance:

• Use --json for control flow, IDs, URLs, and retry logic.
• Use draft page cat <page_id> when the goal is human-readable markdown inspection.
• Save the local_id returned by draft page insert-image; it is required for later update-image or delete-image calls.
• Use draft page comments <page_id> --json to read page annotations without scraping full page content again.
• Use draft page annotate only when the workflow explicitly needs page-bound feedback markers.

Default Workflow

Use this compact sequence unless the user asks for a different handoff:

1. Start headless runtime: draft start-server --runtime v2
2. Verify health: draft status --json
3. Create or locate the target page.
4. Apply page mutations with append, replace, or patch.
5. Read back with draft page cat <page_id> or comments commands as needed.
6. Publish for human review when feedback is needed.

Image Insertion and Management

Image commands are regular page mutations in headless v2, so they follow the normal startup contract for this skill:

1. Run draft start-server --runtime v2
2. Confirm draft status --json
3. Use local file paths for image uploads
4. Save the returned local_id for follow-up operations

Preferred commands:

draft page insert-image <page_id> /path/to/local/image.png --json
draft page insert-image <page_id> /path/to/local/image.jpg --align center --width 500 --json
draft page update-image <page_id> <local_id> --align right --json
draft page update-image <page_id> <local_id> --width 500 --json
draft page delete-image <page_id> <local_id> --json

Agent rules:

• Use insert-image only after the page exists and the headless runtime is healthy.
• Treat the returned local_id as required state for later image updates or deletion.
• Re-read the page with draft page cat <page_id> after image mutations when the user needs markdown-visible confirmation of surrounding content.
• Keep image handling in page mode; do not switch to workspace mode just to upload media.

Review Handoff Pattern

Publish-for-review is the default handoff path for this skill because it works without assuming shared browser state.

# Free beta invite code examples:
GLOBAL_INVITE_CODE=innosage draft page publish <page_id> --json

If GLOBAL_INVITE_CODE is already set in the environment, a plain publish command also works:

draft page publish <page_id> --json

Use handoff language like:

• "The headless Draft page is ready for review at <url>."
• "Please review the published page and send revision requests back here."
• "If you need durable file-linked review instead, we should switch to the workspace review loop."

Feedback model:

• Human reviews the published or preview URL.
• Human leaves comments on the public page or sends revision instructions back through chat or tasking.
• Agent applies a new headless page pass and republishes if needed.

Public Comment Retrieval

Public-page comments are part of the standard publish-and-review loop for this skill.

For these commands:

• Do not start with draft status.
• Do not require draft start-server.
• Do not add extra runtime setup.

Preferred procedure:

1. Capture the publish or preview URL from draft page publish <page_id> --json.
2. List public comments for the review artifact:

draft public-comments list --url '<published_or_preview_url>' --json

3. If only the page ID is known, resolve comments by page ID instead:

draft public-comments list --page-id <page_id> --json

4. For any comment that needs exact context, fetch the single comment record:

draft public-comments get <comment_id> --json

Agent rules:

• Use list for discovery and triage.
• Use get when you need the full body, quote, offsets, or bounded context before editing.
• Re-check comments after republishing if the review loop spans multiple iterations.
• Use public comments as the default review signal after draft page publish.

Failure Handling

Use these guardrails before retrying:

• If the daemon is offline, rerun draft start-server --runtime v2, then draft status --json.
• If status does not report v2, stop and fix runtime selection before writing.
• If a command fails with a missing page ID or lookup error, rediscover the target page before mutating it.
• If public comment retrieval fails, verify that you are using the published or preview URL path, or retry with --page-id <page_id> when only page identity is known.
• If review requires file-path identity, Git diffs, or durable workspace comments, stop using this skill and switch to workspace mode.

Non-Goals

• Do not mix v2 page mode with workspace mode.
• Do not assume a desktop browser is available.