Prep a five-minute lightning talk on test automation for a developer conference

## Role and objective

You are a presentation designer and technical conference speaker. Prepare a five-minute lightning talk on test automation for developers attending a developer conference. Produce a concise slide plan and a separate speaking script, using only the confirmed topic and duration; do not invent a specific framework, programming language, organization, dataset or project experience. The output must give the audience a clear practical understanding of the talk's central point and an actionable takeaway. Completion means the proposed material can be delivered aloud within five minutes, contains one coherent storyline, and distinguishes on-slide text from spoken narration.

## Scope and given facts

In scope:
- The subject is test automation.
- The deliverable is a lightning talk for a developer conference.
- The available speaking time is five minutes.
- The audience is developers, but their seniority and technical background are unconfirmed.

Out of scope unless explicitly supplied: a full tutorial, implementation-specific code, a literature review, a product advertisement, a detailed testing strategy for a named codebase, or claims about a particular tool's superiority.

Use these confirmed facts exactly. Leave unconfirmed details as slots:
- [FILL IN: target testing context or technology stack] — supply the language, framework, application type or test tools to reference.
- [FILL IN: audience level] — supply the expected experience of the developer audience.
- [FILL IN: slide-count ceiling or event format] — supply any presentation-format restriction.
- [FILL IN: speaker’s intended takeaway] — supply the conclusion the speaker wants attendees to remember.

Do not fill the target testing context, audience level, slide-count ceiling or intended takeaway with plausible guesses.

## Working rules

Build the talk around one explicit takeaway. If the speaker’s intended takeaway is supplied, use it; otherwise formulate a narrowly scoped takeaway about the role, value or limits of test automation without attaching unsupported numbers or universal claims.

Use the developer-conference audience as the default audience description. If an audience level is supplied, adjust terminology and examples to it. If the testing context or stack is supplied, use only that context. If it is not supplied, keep examples technology-neutral and label any tool-specific suggestion as a slot rather than selecting a tool arbitrarily.

Organize the reasoning as context, problem, practical approach, evidence or illustrative example, and final ask. Keep correlation, anecdote and causal claims distinct: do not claim that automation caused a delivery improvement unless the input supplies evidence. Replace unsupported benefits such as “faster,” “safer” or “cheaper” with qualified language, observable mechanisms, or [FILL IN: supporting evidence].

State the practical boundary of automation: identify what should be automated, what may remain exploratory or manual, and the condition that determines the choice. Mention maintenance, flaky tests, feedback speed, test scope and failure diagnosis where relevant, but do not present any as measured facts without evidence.

For every example, mark whether it is a generic illustration or supplied project evidence. Never invent benchmark results, team size, defect counts, percentages, tool names or case studies.

For a five-minute talk, allocate time explicitly. If the planned content exceeds five minutes, remove secondary explanation or examples rather than instructing the speaker to talk faster. Follow western deck conventions: open with the executive takeaway, use one idea per slide, write sentence-case takeaway titles, and place narration in speaker notes.

## Output structure

Produce the following sections in order.

1. Slide-list table  
Include one row per proposed slide with:
- slide number;
- sentence-case title stating the takeaway;
- one key message;
- visual or diagram to include;
- estimated speaking time;
- whether the content is a fact, a generic illustration or a [FILL IN] item.

Keep the total estimated time at five minutes or less. If no slide-count ceiling is supplied, choose the smallest number of slides that supports the storyline and state the count.

2. Per-slide speaking script  
For each slide, provide:
- the spoken narration;
- the transition to the next slide;
- the approximate word or time allocation.

Keep the script distinct from on-slide text. Do not write dense slide paragraphs.

3. Opening and closing lines  
Give one opening that establishes the test-automation problem without an invented anecdote, and one closing that states a concrete action for the developer audience. If a specific action is not supported by the input, use [FILL IN: audience action].

4. Time allocation  
Show the total in minutes and seconds. Reserve enough time for the opening and closing. If any input slot prevents a precise example, preserve the timing and mark only the content as [FILL IN].

5. Evidence and source slots  
For every factual claim, add [FILL IN: source] unless the claim is directly supplied in the prompt. Do not fabricate citations, studies, metrics or tool documentation.

## Style rules

Use a hybrid style. Make the slide list, timing, claims, constraints and verification items itemized and scan-friendly. Make the speaking script narrative, natural and suitable for live delivery. Use a practical, technically literate register without hype. Avoid clichés such as “game changer,” “move fast and break things,” “quality is everyone’s responsibility,” and “automate everything.” Prefer precise language about feedback, coverage, maintenance and failure diagnosis.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a five-minute lightning talk, not a report, tutorial or implementation guide.
2. Confirm that every slide has one primary message and that the sequence follows a recognizable storyline from context to action.
3. Add the estimated slide times and verify that their total does not exceed five minutes.
4. Check that the topic remains test automation and does not drift into unrelated software-testing theory or tool promotion.
5. Identify every fact, metric, benchmark, case study, framework name or performance claim added beyond the user’s input; replace unsupported additions with a neutral statement or a [FILL IN] slot.
6. Check that the target testing context, audience level, slide-count ceiling and intended takeaway were not filled arbitrarily.
7. Confirm that on-slide text and speaking narration are separated for every slide.
8. Check that practical boundaries between automation and exploratory or manual testing are stated as conditional guidance rather than universal rules.
9. Confirm that any example is labeled as a generic illustration or supplied evidence.
10. Verify that source slots appear wherever the script makes a factual claim not present in the input.
11. Confirm that the opening and closing fit a developer-conference setting and do not rely on an invented personal story.
12. Check that no unsupported claim of improved speed, cost, reliability, coverage or defect reduction remains unqualified.