Write and revise developer blog posts or run a humanizer / humanization pass on existing drafts using the AI anti-pattern catalog, structural audits, and reusable personal and explicitly selected corporate writing identities.
72
91%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
An abstract says what the talk is about, with enough intrigue that a reader wants the rest. It is not a summary, not a script, and not a transcript of the session.
Two readers, two artifacts:
Writing either one into the other is the most common failure this skill exists to prevent.
Never write copy over an undefined session. Find out which case applies.
A delivered talk. The speaker's own delivered words are the best source available, and they outrank any previous abstract. Look for a transcript of a real delivery, a published recording, or the speaker's own notes, and build the body from what they actually said on stage. Their phrasing, their jokes, their objects.
If a rhetoric vault or delivery analysis is available, read it for how the speaker works a room — it tells you which devices are theirs. Its observations about a past delivery are never content. "At JavaZone ten percent of the hands went up" belongs to nobody but the speaker's own notes.
A new talk. A talk nobody has given may have no spine yet, and no amount of prose will supply one. Ask one question, with concrete options drawn from the material that does exist, and wait. Drafting an abstract for an undefined talk produces copy that slides around under every review, because there is nothing underneath it.
Say what it is about. The subject, the claim that reframes it, and the reason an hour is worth spending. A body that withholds the subject to preserve mystery has failed; the reader must finish it able to say what the talk argues.
Withhold the mechanism. How the failure is fixed, what the demo does next, which technique wins — those are what the room is for. Name the problems; keep the answers.
Keep out of the body:
Keep in the body: the reader's own recognizable failure, named problems, the speaker's real signature phrases, and the promise of the format when it carries risk — a live demo that may fail is a feature and belongs in the copy.
Ground every figure. A number in the body must be checkable: a public repository, a published recording, a cited study. Name the artifact when it is public; anonymity is weaker than evidence. Figures from one run are labelled as one run, in the note.
Length. 150-250 words is the working range, and the shorter end usually wins. Check the submission form's cap before writing. Prerequisites and outlines, where the form has fields for them, are separate artifacts and do not belong in the body.
Same field order every time, so a chair reading hundreds can scan yours:
When one talk's argument has run under two titles, say so and offer the alternative. A chair who discovers it independently reads it as double submission.
Ask or omit. All of them are plausible, invisible in review, and wrong:
Use the scoped route in skills/blog-writer/references/scoped-edit.md with the catalog
in skills/blog-writer/references/ai-anti-patterns.md and the sweep contract in
skills/blog-writer/references/sweep-review.md. Abstract-specific dispositions:
.tessl-plugin
skills
blog-writer
cfp-abstract
create-corporate-identity
create-personal-identity
references