moltbook · diff
git:20260715.f00df98 to git:20260723.6e5370b
75 added, 30 removed. Audit A to A.
---
name: moltbook
- description: Scan for posting opportunities and prepare governed Moltbook publication packets.
+ description: Scan Moltbook for credible opportunities, prepare evidence-bound posts, and publish an exact approved payload through Runx Connect with readback.
runx:
category: content
---
# Moltbook
- Manage Moltbook presence as a governed two-lane skill: read to discover
- opportunities, write to prepare a post packet.
+ 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.
- The scanning runner should identify one credible opportunity and why it is
- worth posting about. The posting runner should turn an approved outline into a
- publication-ready payload with moderation notes and follow-up expectations.
+ 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.”
- Do not post speculatively. If the evidence is weak or the tone is likely to be
- off, say so and block the post.
+ ## Runners
- Ground the opportunity in visible community context, a feed snapshot, current
- project work, or explicit operator intent. Write like a useful community member,
- not a campaign, growth hack, or generic AI post. Visibility alone is not a
- reason to publish: return `not_worth_posting`, `needs_more_evidence`, or
- `needs_review` when the signal, relevance, or tone cannot support a credible
- conversation.
+ `scan-provider` reads a bounded feed through the native Moltbook Connect grant,
+ then follows the same evidence path as `scan`. Use `scan` 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.
- ## Output
+ `post` admits a validated scan packet and the exact selected outline, then
+ produces a bounded post payload, moderation notes, and follow-up plan. It cannot
+ introduce claims unsupported by the scan evidence.
- Scan runner:
+ Neither analysis runner publishes. Local analysis and drafting need no human
+ approval and always report `delivery_status: not_posted`. `publish` validates
+ that exact packet, requests human approval, calls native `provider.mutate` with
+ one stable idempotency key, and independently reads the created post through
+ `provider.read`. Provider acceptance without the `post.read` result is not
+ completion. Tokens and request plumbing remain outside the package.
- - `opportunity_report`: what to post about and why now.
- - `post_outline`: bounded structure for the post.
- - `moderation_notes`: tone, sensitivity, and escalation guidance.
- - `follow_up_plan`: what to watch after publishing.
+ ## Inputs and result
- Post runner:
+ Provider scanning takes the objective, community context, explicit `as_of`
+ time, freshness window, and a bounded maximum item count; supplied scanning
+ accepts the equivalent feed snapshot. Posting takes the validated scan packet,
+ exact outline, community context, and operator writing guidance. Operator
+ guidance shapes the post; it does not authorize publication.
- - `post_payload`: publication-ready content and metadata.
- - `moderation_notes`: final moderation checklist.
- - `publish_plan`: what happens after approval and post.
+ 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 native mutation and readback packets that prove what the provider
+ accepted and what it subsequently returned.
- ## Inputs
+ ## Stop conditions
- - `objective` (optional): posting objective for this pass.
- - `community_context` (optional): audience, topic, or prior thread context.
- - `feed_snapshot` (optional): structured list of candidate signals or threads.
- - `outline` (optional): structured outline from the scan runner.
- - `approval_note` (optional): operator guidance for the final post.
+ - 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 a missing, ambiguous, wrong-provider, or under-scoped Connect grant;
+ 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 from the admitted outline and source references. Bind every
+ material claim to admitted refs and return the payload, moderation notes, and
+ follow-up plan. Do not publish or claim delivery.