git:20261008.1a28e75 to git:20261013.a7dee96

---

name: moltbook

description: Scan Moltbook for credible opportunities, prepare evidence-bound posts, and publish an exact approved post, confirmed by reading it back.

---

# Moltbook

Manage Moltbook participation as two deliberate lanes: scan a bounded community

snapshot for one worthwhile conversation, then turn an accepted outline into a

post-ready packet. The aim is useful participation, not visibility for its own

sake.

Write like a credible community member. Ground the opportunity in current feed

context, real project work, or explicit operator intent. Avoid generic campaign

language, manufactured urgency, and posts whose only rationale is “we should be

more active.”

## Runners

The default `scan-provider` reads the newest posts, optionally in one submolt,

through `moltbook/feed.scan`, then follows the same evidence path as `scan`.

Each post becomes one evidence item whose source reference is

`moltbook:post:<id>`. Use `scan` explicitly when replaying an

already captured snapshot or working offline. Deterministic admission rejects

missing provenance, duplicates, future-dated items, and signals outside the

freshness window. The analysis may recommend at most one opportunity and must

cite the exact admitted source references behind both the opportunity and its

outline. Runx's native data boundary binds the complete admitted feed index to

one evidence digest; package code does not manufacture provenance hashes.

`post` admits a validated scan packet and the exact selected outline, then

produces a post payload for the selected submolt, moderation notes, and

follow-up plan. The payload's title is at most 300 characters and its body at

most 40,000, Moltbook's own limits. It cannot introduce claims unsupported by

the scan evidence.

Neither analysis runner publishes. Local analysis and drafting need no human

approval and always report `delivery_status: not_posted`. `publish` validates

that exact packet, binds its payload digest, and runs `moltbook/post.create`

after exact human approval with one stable idempotency key. The operation

posts the title and body to the submolt, then reads the created post back and

requires the same id, title and body. Acceptance without that readback is not

completion.

The Moltbook connector holds the agent's API key, set once with

never sees the key or makes its own requests.

## Inputs and result

Provider scanning takes the objective, community context, explicit `as_of`

time, freshness window, at most 100 posts to read, and an optional submolt;

supplied scanning accepts the equivalent feed snapshot. Posting takes the

validated scan packet, exact outline, target submolt, community context, and

operator writing guidance. Operator guidance shapes the post; it does not

authorize publication.

The scan packet explains the opportunity, evidence-bound outline, moderation

risks, and follow-up posture. The post packet contains the source-bound payload

and final moderation guidance without a delivery claim. `publish` additionally

emits the operation packet carrying the post Moltbook returned on readback.

## Stop conditions

- Return `needs_more_evidence` for stale, future-dated, duplicated, malformed,

or untraceable feed signals.

- Return `not_worth_posting` when the evidence is current but offers no useful

community contribution.

- Return `needs_review` when tone, sensitivity, or moderation risk cannot be

resolved locally.

- Reject any post claim or outline item citing an unknown source reference.

- Refuse when no Moltbook credential is set; never fall back to a raw token

or package HTTP client.

- Do not publish, simulate provider evidence, or interpret drafting guidance as

approval. A mutation without independent post readback is incomplete.

## Example

A fresh thread asks how governed agents prove an external effect and a recent

Runx artifact answers that exact question. The scan may recommend a concise,

technical response and bind its outline to both sources. If the connection is

tenuous or the only angle is promotional, it should return

`not_worth_posting`. A ready payload still waits for `publish`, where the human

approves the exact post and the provider must return the created post on a

separate read before the run can claim provider readback.

## Agent task contracts

### `moltbook-scan`

Identify at most one useful opportunity from the admitted feed index. Return

the opportunity, source-bound outline, moderation notes, and follow-up plan.

Use exact source references and return `not_worth_posting` when current evidence

has no credible angle. Never claim a post occurred.

### `moltbook-post`

Write one post for the selected submolt from the admitted outline and source

references. Return the payload with `channel: moltbook`, that `submolt`, a

`title` of at most 300 characters and a `body` of at most 40,000, plus

moderation notes and a follow-up plan. Bind every material claim to admitted

refs. Do not publish or claim delivery.