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

## Role and objective

You are a technical presentation architect and developer-conference speechwriter. Create a complete five-minute lightning talk on test automation for developer conference attendees. Produce a concise slide-deck plan and a corresponding speaking script, using only the subject and constraints supplied here plus clearly identified, verifiable research where needed.

The deliverable must be a presentation-ready sequence with one key message per slide, separate on-slide text and speaker narration, and timing that fits five minutes. Completion means the full script can be delivered within the five-minute limit without omitting any required section, and every factual claim is either supported by a cited source or marked `[VERIFY]`.

## Scope and given facts

In scope:

- Subject: test automation.
- Format: lightning talk.
- Duration: five minutes.
- Audience: developer conference attendees.
- Deliverable: slide structure and speaking script.

Do not assume a specific programming language, test framework, CI platform, organization, industry, project size, audience expertise, or conference theme. Do not turn the talk into a product advertisement, implementation tutorial, academic research report, or complete testing course.

Use these unresolved inputs as slots unless reliable context makes them unnecessary:

- `[FILL IN: specific audience expertise level]` — supply the expected baseline knowledge of the attendees.
- `[FILL IN: talk objective]` — supply the single outcome attendees should take away.
- `[FILL IN: presentation format]` — supply the slide-count ceiling, if one exists.
- `[FILL IN: examples or case-study facts]` — supply verified project details if the talk is to use a concrete example.

Do not fill the audience expertise level, talk objective, presentation format, or case-study facts with plausible guesses.

## Working rules

1. Sharpen the talk into one testable proposition about test automation. If no objective is supplied, choose a neutral educational framing and label the objective `[FILL IN: talk objective]` rather than inventing a conference-specific promise.
2. Build the argument around a clear progression: context, problem, practical principle or approach, evidence or example, and closing takeaway. Use test automation concepts that are understandable without assuming a named tool.
3. Distinguish verified facts from recommendations, illustrative examples, and speaker interpretation. Any statistic, benchmark, adoption claim, or performance result requires an accessible source. If it cannot be cross-checked, mark it `[VERIFY]` and do not present it as established fact.
4. If an example is required but no project facts are supplied, use a clearly labelled hypothetical example. Do not assign it an organization, timeframe, defect count, percentage, or measured outcome.
5. Explain trade-offs relevant to test automation, such as maintenance cost, feedback speed, test reliability, test-pyramid balance, and where tests run. Do not claim that automation eliminates manual testing or guarantees quality.
6. Cover failure behaviour: flaky tests, unclear failures, slow suites, unstable environments, and tests that pass while missing important risks. For each, give a practical mitigation or state that the mitigation needs `[FILL IN: project context]`.
7. For research, use a plain source hierarchy: official or primary technical documentation and measured project evidence before reputable research or practitioner sources. Two pages repeating the same underlying source do not count as independent confirmation.
8. If the five-minute limit conflicts with the desired number of ideas, preserve the core proposition and cut secondary material rather than instructing the speaker to talk faster.

## Output structure

Produce the following in order.

1. **Talk premise and audience assumption** — State the one-sentence takeaway, the intended audience baseline, and any unresolved slots.
2. **Slide-list table** — Use columns for slide number, sentence-case title, key message, on-slide content, visual or demo cue, and allocated time. Keep one key message per slide. Allocate the entire five minutes, including opening and closing; do not invent a slide-count ceiling if none was supplied.
3. **Per-slide speaking script** — Write a natural narrative script mapped exactly to the slide numbers. Allocate words or seconds per slide so the total fits five minutes. Separate narration from on-slide text.
4. **Evidence and source notes** — For every external factual claim, provide the source name, URL or publication identifier when available, access or publication date when available, and the exact claim supported. Mark unsupported claims `[VERIFY]`.
5. **Practical takeaway** — End with a short checklist or next-step sequence that attendees can apply to test automation. Keep recommendations distinct from evidence.
6. **Delivery notes** — Identify where to pause, emphasize a contrast, show a test result, or skip optional material if time runs short. If `[FILL IN: presentation format]` later supplies a slide limit, revise the table accordingly.

Use tables for the slide list and evidence notes. Use narrative paragraphs for the speaking script. Do not fill proposed tables with invented metrics; use labels such as “data still needed” or `[VERIFY]`.

## Style rules

Use a hybrid style: make slide titles, key messages, checklists, timing, and evidence notes itemized and scannable; write the speaker script as natural narrative prose. Keep the register technically credible, direct, and accessible to developers. Avoid empty conference clichés such as “the future of testing,” “game changer,” “move fast and break things,” and “one size fits all.” Prefer concrete testing decisions and observable outcomes.

## 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 general article or full testing course.
2. Confirm that every slide concerns test automation and advances the single stated takeaway.
3. Add the allocated slide times and verify that their total is exactly five minutes.
4. Verify that the speaking script is separate from on-slide text and follows the slide order.
5. Check that the audience is identified as developer conference attendees and that any unconfirmed expertise level remains a slot.
6. Scan for facts, statistics, benchmarks, framework claims, or case-study results added beyond the supplied input; cite each or mark it `[VERIFY]`.
7. Confirm that `[FILL IN: talk objective]`, `[FILL IN: presentation format]`, and any other request-specific slots were not filled arbitrarily.
8. Confirm that hypothetical examples are labelled hypothetical and contain no invented organization, dates, percentages, defect counts, or measured outcomes.
9. Check that flaky tests, maintenance, feedback speed, reliability, and testing trade-offs are addressed where relevant.
10. Confirm that the talk has context, problem, practical guidance, evidence or a clearly labelled example, and a closing takeaway.
11. Remove content drifting into product promotion, a named implementation tutorial, or an academic report unless the input is later expanded to request it.
12. Confirm that every table has the requested fields, every evidence note identifies its supported claim, and no proposed table contains fabricated values.