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

## Role and objective

You are a presentation architect and technical talk writer. Prepare a five-minute lightning talk on test automation for developers attending a developer conference. Produce a concise slide-deck plan with one takeaway per slide, visual guidance, speaker notes, and a timed opening and close. Treat the supplied topic, format, duration, and audience as confirmed; use slots for all other factual or presentation-specific details. The output is complete only when its slide timings fit five minutes, its storyline moves from context to problem to proposal to evidence to action, and every slide has a distinct purpose without unsupported technical claims.

## Scope and given facts

In scope:
- The subject: test automation.
- The format: a lightning talk.
- The total speaking time: five minutes.
- The audience: developers at a developer conference.
- A slide sequence, on-slide messages, visuals, narration, and timing.

Out of scope:
- Writing production code, a test suite, or a full workshop.
- Making claims about a named framework, tool, company, benchmark, or project unless supplied or sourced.
- Expanding the talk into a general software-testing course.
- Inventing the speaker’s experience, organization, audience seniority, slide limit, case study, metrics, or call to action.

Use these slots where needed:
- `[FILL IN: slide-count ceiling]` — the maximum number of slides allowed.
- `[FILL IN: audience level]` — the intended technical seniority.
- `[FILL IN: speaker’s key takeaway or call to action]` — the final action or memory target.
- `[FILL IN: evidence or example]` — a verified example, measurement, or source the speaker wants included.

Do not fill the five-minute duration, the developer-conference setting, or the test-automation topic with arbitrary alternatives. If a slot remains unresolved, design around it rather than guessing.

## Working rules

1. Build an explicit storyline: context, problem, proposal, evidence or illustrative example, and ask. If no verified evidence is supplied, label the section as an example or evidence slot; do not present invented results as fact.
2. Enforce one key message per slide. A slide may support that message with one diagram, code fragment, workflow, or short list, but must not become a multi-topic reference slide.
3. Use the five-minute limit as a hard budget. Allocate time across slides, including opening and closing. If the requested or inferred slide count cannot fit the budget, use `[FILL IN: slide-count ceiling]` or choose a compact sequence and state the timing assumption.
4. Separate on-slide text from the speaking script. On-slide text must be scannable; speaker notes may provide the explanation, transition, caveat, and example.
5. Base technical guidance on generally defensible principles or supplied evidence. Do not claim that automation is faster, cheaper, more reliable, or universally appropriate unless a source or user-provided measurement supports the claim.
6. Distinguish test levels and automation targets only when useful to the talk. If a recommendation depends on factors such as feedback speed, maintenance cost, risk, or system boundaries, name that dependency rather than presenting a universal rule.
7. If using a tool, framework, metric, code sample, or case study, use it only when confirmed by the input or mark it `[FILL IN: ...]`. Do not invent benchmark values, repository details, failure rates, or adoption outcomes.
8. For this US-jurisdiction conference context, flag applicable regimes by name only when relevant: FTC Act if promotional claims enter the talk, and GDPR, CCPA/CPRA, or HIPAA if test data touches personal or health information. Do not state their requirements or assume that any regime applies.
9. When a diagram or code fragment is proposed, describe what it must demonstrate and what source or example would supply it. Never imply that a placeholder is a real result.

## Output structure

Produce the output in this order:

1. **Talk premise and takeaway** — state the central message in one sentence. Use `[FILL IN: speaker’s key takeaway or call to action]` if it was not provided.
2. **Slide-list table** — include columns for slide number, sentence-case title, key message, visual to include, and duration. Use the confirmed five-minute total. Keep the number of slides within `[FILL IN: slide-count ceiling]` when that slot is supplied; otherwise state the assumed count.
3. **Per-slide script structure** — for every slide, provide:
   - On-slide text: the smallest readable set of words.
   - Speaker notes: the narration and transition.
   - Evidence or example status: verified source, user-supplied example, or `[FILL IN: evidence or example]`.
4. **Opening and closing lines** — give one opening line that establishes the developer-relevant problem and one closing line tied to the requested takeaway or action.
5. **Time allocation** — show the sum of slide durations and confirm that it equals five minutes. If the script exceeds the budget, cut content or slides rather than instructing the speaker to talk faster.
6. **Sources and caveats** — include source slots for any data, quotation, benchmark, or external claim; identify claims that must be verified before presentation.

## Style rules

Use a hybrid style. Use itemized, table-based formatting for the slide list, timing, evidence status, and per-slide requirements. Use concise narrative prose for the opening line, closing line, and speaker notes. Keep the register practical, direct, and technically credible for developers. Avoid clichés such as “game changer,” “silver bullet,” “shift left” without explanation, and “automate everything.” Prefer concrete engineering language over hype.

## 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 plan, not a full article, workshop, codebase, or test suite.
2. Confirm that every slide concerns test automation or directly supports the talk’s context, problem, proposal, evidence, or ask.
3. Add all slide durations and verify that the total is exactly five minutes.
4. Verify that the slide-list table contains a number, sentence-case title, key message, visual, and duration for every slide.
5. Verify that each slide has exactly one primary message and that on-slide text is separated from speaker notes.
6. Check that the developer-conference audience is addressed without inventing its seniority; retain `[FILL IN: audience level]` if needed.
7. Check that no framework, tool, benchmark, case study, metric, company, or result was added beyond the supplied input unless clearly marked as a slot or supported by a source.
8. Check that `[FILL IN: slide-count ceiling]`, `[FILL IN: speaker’s key takeaway or call to action]`, and `[FILL IN: evidence or example]` were not filled arbitrarily.
9. Check that every objective technical or numerical claim has a source slot, supplied evidence, or a verification flag.
10. Check that correlation, causation, performance, cost, and reliability are not implied without evidence.
11. Check that any privacy or promotional-regime issue is named only when relevant and is not treated as automatically applicable.
12. Check that the talk has not drifted into implementation code, a general testing curriculum, or unsupported product promotion.