Skills and templates

What a skill is for

A good PostMantis skill helps an AI client:

• choose the right tool or API call
• follow the normal draft, schedule, publish, and readback flow
• avoid unsafe assumptions about profiles, delivery success, or when async work has finished
• stay inside the API key scope it already has

What a skill should not do

Good rules for a PostMantis skill

Use rules like these when you write a skill or reusable template for an AI client:

• list profiles before creating a post if destination IDs are not already known
• default to creating a draft unless the person explicitly asks to publish now or schedule
• use delete_draft for drafts and cancel_post for scheduled posts
• use remote media URLs or upload sessions instead of expecting raw file uploads through MCP
• read the post again after publish or schedule actions to inspect deliveries[]
• treat completed as workflow completion, not automatic proof that every delivery succeeded
• use post readbacks instead of assuming an accepted write has already finished

Use skills in OpenClaw

OpenClaw supports AgentSkills-compatible SKILL.md folders and can install published skills from ClawHub.

A simple workflow looks like this:

1. install a published skill into your workspace with openclaw skills install <skill-slug>
2. confirm that OpenClaw can see it with openclaw skills list --eligible
3. start a new session so the updated skill set is loaded

If you are writing your own skill instead of installing one from ClawHub, keep it in one of the normal OpenClaw skill locations such as:

• <workspace>/skills
• ~/.openclaw/skills

The skill itself should stay small. It should teach the client when to use PostMantis tools, not duplicate the full product docs.

Example: draft-first skill

You help operate PostMantis through MCP.

When profile IDs are unknown, call postmantis.list_profiles first.
Default to creating drafts unless the person explicitly asks to publish or schedule.
If a draft should be discarded, use postmantis.delete_draft.
After publish actions, call postmantis.get_post and inspect deliveries[] before reporting success.

Example: scheduling skill

You schedule content in PostMantis.

Confirm the requested publish time, then create or publish the post with a future schedule.
If the request is ambiguous, ask for the exact time instead of guessing.
If the post is already scheduled and should not be sent, use postmantis.cancel_post.

Example: delivery follow-up skill

You summarize PostMantis outcomes.

List or load the target posts, then inspect delivery status and errors for the relevant post IDs.
Separate accepted writes from final delivery results.
If a post is still pending, say that clearly instead of reporting it as complete.

Useful ideas

• Editorial assistant: create drafts for review, but never publish without explicit approval
• Campaign scheduler: batch-create scheduled posts for one profile or provider scope
• Ops assistant: inspect recent failed deliveries, summarize common errors, and suggest next steps
• Delivery assistant: gather recent completed or failed posts and produce a short operational recap

Keep the wrapper thin

The safest long-term pattern is:

1. keep the product semantics in HTTP, OpenAPI, and MCP
2. keep skills and templates small and reusable
3. update the wrapper when the real contract changes

That keeps automation helpful without letting prompt text drift away from the real product behavior.

Related

• Automation Overview
• MCP Server
• SDKs
• Authentication
• API Reference