Build a Hook Generator in Python That Checks the First Three Seconds

A script can be short on the page and still miss the opening shot. “Before you replace your old desk mat, try this” feels concise until you read it aloud, pause before the reveal, and discover the product has not appeared yet.

This tutorial builds a deliberately small Python hook generator: three templates, a transparent scoring function, and a few tests. It does not predict virality. It catches avoidable production problems before someone records a batch of openings that are too long, too vague, or based on claims the product cannot support.

I work on UGCfy AI. The code here is a standalone teaching implementation, not a copy of its production system, an unofficial API client, or an ad-performance model. The examples use a hypothetical desk mat. None of the scores below come from an advertising campaign.

Separate writing from permission to make a claim

Start with a brief, not a prompt that says “make this viral.” For our fictional desk mat, the brief contains a problem: a mat that slides while someone types. The desired outcome is a steadier keyboard. The demonstration is a side-by-side push on the actual desk. The product team still needs to establish that the advertised mat does what the demonstration implies.

The brief should also list forbidden claims. No invented customer counts. No “sold out again” without inventory evidence. No first-person testimonial unless the speaker actually had that experience. A template can make a fabricated statement sound casual; that does not make it acceptable.

I keep a candidate's wording separate from its review flags. The program cannot look at a sentence and know whether the product really passed a test. Someone has to check the evidence and mark the claim supported. Making that judgment explicit is better than hiding it inside a keyword match that rewards any hook containing “proven.”

For a production tool, store the evidence reference next to the flag: a test recording, a reviewed product specification, or an approved claim document. A boolean is sufficient for this tutorial, but it is not a substitute for a traceable review.

Generate a small, inspectable candidate set

There is no language-model dependency in this version. Templates make it easy to see where every phrase came from and to test the same brief repeatedly. That is useful when the goal is learning the pipeline rather than maximizing variety.

import re def words(text): return re.findall(r"[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*", text) def generate(problem, outcome, action): fields = (problem, outcome, action) if not all(isinstance(x, str) and x.strip() for x in fields): raise ValueError("nonempty brief fields required") return [ f"Still dealing with {problem.strip()}?", f"Want {outcome.strip()}? Watch this.", f"Before you {action.strip()}, try this.", ] 

Those templates cover a problem call-out, a desired outcome, and an interruption before an action. They are structures, not guarantees of quality. A poorly chosen problem will remain a poorly chosen problem after the function adds a question mark.

Notice the grammar contract. problem should be a noun phrase such as “a sliding desk mat,” not a complete sentence. action should be a verb phrase such as “replace your desk mat.” If the caller passes “your mat keeps sliding,” the first template becomes awkward. In a larger tool, document that contract or store structured phrase types instead of accepting arbitrary strings.

The tokenizer is intentionally English-oriented. It counts contractions and hyphenated expressions as one token. That choice keeps the example consistent, but it does not establish actual pronunciation length. A long product name, a number, or an unfamiliar acronym can take longer to say than its token count suggests.

Turn three seconds into a budget, not a slogan

A word cap is only a rough timing proxy. Here the configurable speaking-rate assumption is 160 words per minute. At that assumed pace, eight words occupy three seconds before any pauses. That is arithmetic, not a measured average for creators or a platform rule.

The estimate is 60 × word_count / words_per_minute. A different speaker, language, or delivery changes the budget. If the creator pauses for emphasis or the opening needs a visual demonstration, fewer spoken words may be appropriate. Do not speed the voice up merely to satisfy the score.

I assign forty points to fitting the estimated window, twenty-five to specificity, twenty to having a matching opening shot, and fifteen to supported claims. Those weights are editorial choices. There is no training set behind them. The full explanation travels with the score so a reviewer can disagree with a rule rather than treating a number as authority.

def score(text, *, specific, visual, supported, wpm=160): if wpm <= 0: raise ValueError("wpm must be positive") count = len(words(text)) seconds = 60 * count / wpm points, reasons = 0, [] checks = ( (0 < count and seconds <= 3, 40, "fits estimated three seconds"), (specific, 25, "specific audience problem or outcome"), (visual, 20, "matching opening shot available"), (supported, 15, "claims supported by brief"), ) for passed, weight, label in checks: if passed: points += weight reasons.append(label) return dict( text=text, words=count, estimated_seconds=round(seconds, 2), score=points, eligible=bool(count and supported), reasons=reasons, ) 

Eligibility is separate from ranking. Unsupported claims are not rescued by a good length score. An empty string is also ineligible even if someone has accidentally checked the “supported” box. Only compare eligible candidates, and still review them before recording.

Specificity and visual availability are human inputs here. Passing True is an annotation, not something the function discovered. That distinction matters when showing results to a teammate who might otherwise assume the program watched the footage or understood the product.

The test run, including the awkward candidate

The complete executable file is saved as hooks.py beside this draft. I ran it using the following hypothetical brief:

hooks = generate( "a sliding desk mat", "a steadier keyboard", "replace your old desk mat", ) results = [ score(h, specific=True, visual=True, supported=True) for h in hooks ] 

For this fixture, all three review flags were deliberately set to true. That makes it a test of generation and timing arithmetic, not an independent review of a real product.

The third candidate fails the timing check. That is useful behavior: generation does not force every output through the same length mold, and scoring gives a specific reason to revise one. “Desk mat sliding? Try this.” is a possible edit, but it needs its own read-through and matching shot.

The script also asserts that an unsupported claim is ineligible and that an empty hook is ineligible. Those assertions passed in the same run. They establish a few code invariants; they say nothing about click-through rate, early retention, cost per thousand impressions, or sales.

A score of one hundred means only that a candidate satisfied this rule set under the supplied annotations. It does not mean a perfect advertisement. Two candidates can tie while producing very different experiences on screen.

Review the opening as a shot, not just a line

For “Still dealing with a sliding desk mat?”, the first frame should make the sliding mat legible. If the video opens on a face, then cuts to a wide room view, then finally shows the mat, the spoken line and the visual are competing instead of cooperating.

Write a tiny shot specification beside each candidate. Record the first image, the action, any on-screen text, and the point where the product becomes identifiable. A useful specification might say: close crop on typing hands; the old mat shifts; no text covering the movement; the replacement enters in the next shot.

Test the opening without sound. Can a viewer identify the problem? Then listen without the picture. Does the sentence still make sense? You do not need both channels to explain everything independently, but an essential detail should not depend on tiny text that disappears before anyone can read it.

Finally record a rough take. Use the actual speaker and intended delivery. A stopwatch or waveform replaces the speaking-rate estimate at this stage. If the line takes too long, cut words or redesign the reveal. The point of the estimate is to make that correction cheap, not to overrule the recording.

Where a hosted generator fits

If you want a wider candidate pool without maintaining templates, UGCfy AI's hook generator takes a product description and platform choice and returns hook suggestions with their associated psychological angles. It is an alternative writing surface; the review process still belongs to you.

Do not treat any generated first-person story, social-proof line, or before-and-after statement as automatically approved. The same evidence check applies whether the words came from a template, a language model, a freelance writer, or a brainstorm in a meeting. The tool proposes language; your brief determines what you can responsibly say.

Replace the heuristic with an experiment, carefully

Shortlist openings that communicate genuinely different angles. Changing “still” to “always” rarely teaches as much as comparing a visible problem against a clear desired outcome. Keep the script body and offer consistent enough that you can interpret the opening change.

Define the outcome before the test. Early retention can help diagnose attention; qualified visits or purchases answer different business questions. A dramatic opening may earn a pause while attracting the wrong audience. Record both the attention signal and the downstream outcome relevant to the campaign.

Keep the platform's actual metric definition in your notes. A view is not interchangeable across placements or reporting interfaces. Avoid declaring a winner from a handful of events, and do not interpret unequal automated delivery as a clean randomized experiment. The delivery system may be selecting audiences as well as allocating impressions.

The practical result is a short audit trail: the brief, generated wording, reviewer flags, estimated duration, recorded duration, first shot, and observed campaign results. The Python score belongs near the beginning of that trail. Its job is to reject obvious problems before production, not to impersonate evidence from the end.