| name | hook-generator |
| description | Generates strong opening lines for a topic or page using curiosity, contrast, story, and data-driven angles while avoiding unsupported clickbait. Use when the user asks for a hook, intro, lead, headline, first sentence, or attention-grabbing opener for a post, article, video, newsletter, ad, or landing page. |
| author | surfmind |
| metadata | {"icon":"Zap","tags":["content","marketing","writing"]} |
Hook Generator
Generates several strong opening lines for your topic or page, each taking a different angle, while staying honest to the source instead of reaching for clickbait.
- Identify the audience, promise, tension, novelty, and concrete subject from the selection, request, and source.
- Generate hooks using different angles such as problem, surprise, contrarian, story, benefit, data point, or question. Put the key specifics (the figure, name, or result) inside the hook line itself, not only in your commentary around it.
- Cross-check every hook against the source. Before you use any number, name, or claim, re-read the exact sentence it comes from and keep its scope: a figure that holds only for some cases (a team size, a date range, a single cohort) carries that qualifier with it, and a number means only what the source says it means — never repurpose "70% of the gain came from X" into "a 70% improvement." Never introduce a percentage, statistic, or figure that is not in the source.
- Always finish with a "Proof needed" pass that names the weakest hook and the evidence it would take to publish it safely. Dropping a caveat counts as an unsupported claim, so flag it. "Nothing to flag" is allowed only when every hook restates a fact stated verbatim in the source — and even then, say so explicitly rather than staying silent.
Return the hook options labeled by angle, then call out the best fit and the proof still needed. Be specific without overclaiming, preserve important names, numbers, and links, avoid unverifiable numbers, and do not create clickbait the content cannot satisfy. If the visible context is insufficient, say what is missing and give the best supported next step.
Example
For a blog post about a team that cut its build time from 20 minutes to 90 seconds:
- Problem: "Every push meant a 20-minute coffee break no one asked for."
- Data point: "We took our CI from 20 minutes to 90 seconds — here's the one change that did most of the work."
- Contrarian: "Faster builds didn't come from a bigger machine. They came from deleting code."
- Best fit: Data point — it leads with the concrete result the post delivers.
- Proof needed: The "one change" claim — confirm the post attributes the bulk of the gain to a single fix before publishing.
