| name | ghostwrite |
| description | Turn evidence and operator intent into publication-ready drafts and handoff packets. |
| runx | {"category":"content"} |
Draft Content
Write one bounded piece of content from available evidence and a clear objective.
This skill is for drafting useful public artifacts: ecosystem briefs, trust
reports, release notes, maintainer updates, or social posts. It should never
hallucinate evidence. If the evidence is thin, say so and narrow the claims.
Keep the content grounded in a specific audience, channel, and objective. The
job is not to sound expansive. The job is to be useful and publishable.
Drafting rules
Write the artifact as the human maintainer or operator responsible for it:
- lead with the reader's problem, decision, or next action, not the evidence
collection process
- turn evidence into claims, examples, and concrete wording; do not dump raw
receipts, issue threads, amendments, or machine packets into the public body
- match the target project's vocabulary and voice instead of defaulting to
generic AI, launch, preview, migration, or adoption language
- never describe the work as machine output, agent output, or AI-generated
content; the surfaced draft should read like a maintainer-owned artifact
- prefer one sharp page, brief, or update over several thin sections
- if the evidence is not strong enough to publish, return a narrow handoff or
needs_more_evidence state instead of filling the gap with plausible prose
Output
Draft runner:
content_brief: framing for audience, angle, and constraints.
draft: the main draft text or structured sections.
review_checklist: what must be checked before publication.
distribution_notes: channel-specific packaging guidance.
Package runner:
publish_packet: channel-ready payload and metadata.
qa_checklist: final quality gates for handoff or publishing.
handoff_notes: operator notes, caveats, and next actions.
Handoff runner:
handoff_packet: approved outward packet with the exact delivery surface.
boundary_state: explicit boundary semantics so external handoff does not
masquerade as internal review completion.
follow_up_contract: who acts next, whether acknowledgement is expected,
and what should retrigger the lane.
Inputs
objective (optional): what the content should accomplish.
audience (optional): intended reader or viewer.
channel (optional): blog, newsletter, GitHub comment, status post,
advisory, Moltbook, or other outlet.
evidence_pack (optional): structured evidence object from research or
another skill.
voice_guide (optional): tone or brand constraints.
draft (optional): existing draft text when packaging or revising.
packet (optional): already-packaged outward payload when moving through the
explicit handoff boundary.
target (optional): thread locator or repo/thread summary for the outward
move.
boundary_kind (optional): boundary type such as external_maintainer.