CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/blog-writer

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

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

SKILL.mdskills/cfp-abstract/

name:
cfp-abstract
description:
Write, rewrite, or review a conference talk abstract and its notes for the program committee. Use when asked to "write a CFP abstract", "fix my abstract", "submit this talk", "write the talk proposal", "notes for the program committee", "shorten the abstract", "make the abstract less AI", or when a conference submission form, session description, or talk pitch is the artifact being edited. Also use when adapting a delivered talk into a new submission, or turning a talk idea into a proposal. Not for blog posts, which belong to the blog-writer skill.

CFP Abstract

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:

  • The body is read by someone standing in a hallway choosing which room to enter.
  • The notes for the program committee are read by a chair deciding whether to accept, and they are where every fact, figure, link and risk belongs.

Writing either one into the other is the most common failure this skill exists to prevent.

Step 1 — Establish what the talk is

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.

Step 2 — Write the body

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:

  • Stage directions and beat-by-beat structure. "Then a second demo fixes it" gives away the shape of the session.
  • Interaction mechanics: shows of hands, votes, polls, and anything running in the background. Devices work in a room, not on a page.
  • Delivery history, measured results, and prior-delivery observations. All of it belongs in the note.
  • Any sentence that only lands for someone who has watched this speaker before. A reference to another of their talks, a callback to a stage moment, a "the same trick as my other session" comparison. Apply the test literally: if the reader has never seen this speaker, does the sentence still work? A framework the talk actually uses is content and stays. A pointer to the speaker's back catalogue is not.
  • Framing the author gave you to explain the talk ("Goldratt instead of Kahneman", "it's the sequel to my testing talk"). That is guidance for the writer, never copy.
  • Audience homework the author did not ask for. Do not invent what attendees should bring.

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.

Step 3 — Write the notes for the program committee

Same field order every time, so a chair reading hundreds can scan yours:

  1. Format and audience. Duration, solo or co-presented, who it is for, prerequisites, and any real flexibility about length.
  2. What actually happens in the room. The structure, the demos, the interaction. This is where the plot the body withheld gets told, because a chair is deciding, not attending.
  3. Track record. Where it has run and a link to video or shownotes. Count deliveries from the authoritative source — a talk-analysis directory, the speaker's site, their submission history — never from the previous abstract's prose, which is where undercounts propagate.
  4. What the session needs, and what could break. Network for live agents, a co-presenter's travel, unbuilt material. State the recorded-fallback practice when one exists; it is the single most reassuring line available to a live-demo talk.
  5. Honest caveats. Fictional scenarios, thought-experiment assumptions, one-run figures, sections that are new delivery work. These build more trust than any adjective, and a chair who finds them out later will not forgive the omission.

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.

Step 4 — Never fabricate these

Ask or omit. All of them are plausible, invisible in review, and wrong:

  • Duration flexibility and what is droppable to compress a session.
  • Recorded fallbacks, backup plans, or AV practices not evidenced.
  • Ratings, attendance figures, and audience-response claims.
  • Delivery counts and venue lists beyond what a source states.
  • Anything about what the speaker "will" do on stage that they have not said they do.

Step 5 — Run the anti-AI pass

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:

  • Talk titles keep their own capitalization; that is catalog structure, not a heading.
  • Future-tense promises are correct for a proposal and are not preamble announcements.
  • The committee note is metadata; sweep it, but its register is denser than prose.
  • Run the delete test over clauses you wrote, not only over watchlist words. A line written for effect arrives at the check labelled "deliberate", and that label is not a disposition.
  • A genre the author requested — a trailer, a punchy open — supplies the draft's likeliest matches. Name the conflict; do not resolve it silently.

Checklist before delivering

  • The reader can state what the talk is about, and cannot state how it ends.
  • No stage directions, no interaction mechanics, no vault observations.
  • No sentence that requires having seen this speaker before.
  • Every figure checkable; every unverifiable claim removed or asked about.
  • Note carries format, room, track record with link, risks, caveats — in that order.
  • Sweep run on body and note; every retained hit has a recorded reason.

README.md

tile.json