Slide Deck For Lab Meeting

Scope Boundary

This skill is for structuring lab-meeting or project-review slide decks, not for inventing data, pretending unfinished work is complete, or turning a research update into a conference talk.

It is appropriate for:

• weekly lab meetings,
• project-review decks,
• PI update decks,
• analysis progress reviews,
• method troubleshooting meetings,
• manuscript-preparation project updates,
• translational or biomarker project updates,
• multi-omics or computational progress decks,
• validation planning updates.

It is not for:

• inventing missing project progress,
• forcing every deck into a polished story arc,
• turning uncertain work into resolved conclusions,
• replacing missing data with generic background,
• or pretending a deck is ready when the research status is still unclear.

Important Distinctions

This skill must clearly distinguish:

• lab-meeting deck vs conference presentation,
• progress report vs final polished narrative,
• decision-relevant result vs interesting side output,
• open problem vs failed project,
• next-step proposal vs already committed plan,
• current interpretation vs confirmed conclusion.

Reference Module Integration

Use the reference files actively when producing the output:

• references/clarification-first-rule.md

  • Use before any long-form slide structuring.
  • If the project status, meeting goal, or available material is unclear, ask for the missing information first.

• references/meeting-goal-selection-rules.md

  • Use to determine whether the deck is mainly for:
    • progress reporting,
    • troubleshooting,
    • decision seeking,
    • manuscript alignment,
    • or next-step planning.

• references/slide-priority-rules.md

  • Use to decide how much weight to give:
    • background,
    • current data,
    • unresolved problems,
    • limitations,
    • and next steps.

• references/data-honesty-boundary-rules.md

  • Use to prevent the deck from overstating incomplete or uncertain results.
  • Keep progress-report language aligned with what is actually done.

• references/next-step-structuring-rules.md

  • Use to turn open problems into concrete, discussion-ready next-step slides without pretending those steps are already decided.

• references/logic-reporting-rule.md

  • Use to explain why the slide order and emphasis were chosen.

• references/hard-rules.md

  • Apply throughout the entire response.
  • These rules override presentation polish and storytelling pressure.

Input Validation

Before producing a long output, determine whether the user has clearly supplied enough information about:

• the project topic,
• the current research stage,
• the meeting goal,
• what data or figures already exist,
• what unresolved problems remain,
• and whether the deck is for internal discussion, PI review, or broader project review.

If these are not clear enough, do not jump into a full slide structure.
First tell the user what information is missing and what additional inputs would materially improve accuracy.
When helpful, explicitly recommend uploading:

• a project summary,
• figure list,
• progress notes,
• manuscript outline,
• or current deck draft.

Sample Triggers

Use this skill when the user asks things like:

• “Help me structure my lab meeting slides.”
• “How should I organize this project update for my PI?”
• “What should I show in a weekly research progress deck?”
• “How much background versus data should I include?”
• “Please help me structure the next-step discussion slides.”
• “How do I make this deck more focused for a lab meeting?”

Core Function

This skill should:

1. identify the meeting objective,
2. determine the right slide balance,
3. select the most useful progress elements,
4. keep open problems visible,
5. frame next steps clearly,
6. explain the slide-structuring logic,
7. request missing information when needed,
8. and protect the user from presenting a misleadingly complete story.

Execution

Step 1 — Clarify before structuring

If the user provides only a broad project title or a vague request to “make lab meeting slides,” do not immediately produce a full deck structure.
First explain what is missing, ask focused follow-up questions, or recommend uploading the current materials.

Step 2 — Identify the meeting goal

Determine whether the deck is mainly for:

• progress reporting,
• getting feedback,
• troubleshooting,
• deciding between next experiments or analyses,
• updating the PI,
• or preparing for a manuscript-facing internal review.

Step 3 — Identify the project stage

Determine whether the project is in:

• background and framing stage,
• early data generation,
• intermediate analysis,
• validation / replication,
• interpretation and synthesis,
• or next-step decision stage.

Step 4 — Select the slide balance

Decide how much emphasis the deck should give to:

• background,
• research question,
• methods or workflow,
• current data,
• interpretation,
• open problems,
• limitations,
• next steps.

Step 5 — Build the slide flow

Design the most defensible and discussion-useful order of slides, such as:

• project question and motivation,
• current status and workflow,
• key results,
• unresolved issues,
• interpretation and decision points,
• next-step proposal.

Step 6 — Frame open problems honestly

State where uncertainty, weak data, inconclusive results, or blocked progress should be shown directly rather than hidden behind generic slides.

Step 7 — Structure the next-step section

Turn open questions into a practical next-step slide sequence that is concrete enough for discussion but does not pretend those steps are already finalized.

Step 8 — Explain the structuring logic

For major choices, explicitly explain:

• why the deck leads with certain content,
• why some background was reduced,
• why some side results were omitted,
• why certain open problems need explicit slides,
• and what wasted-discussion or confusion this prevents.

Step 9 — Produce the final structured output

Follow the mandatory output structure below.

Mandatory Output Structure

A. Input Match Check

State whether the provided material is sufficient for high-confidence lab-meeting deck structuring. If not, clearly say what is missing.

B. Meeting Context Understanding

State your current understanding of:

• project topic,
• project stage,
• meeting goal,
• current progress status,
• and key unresolved issues if known.

C. Main Structuring Risks

State the main problems that could make the deck weak, such as:

• too much background,
• too much raw data,
• unclear main question,
• buried decision point,
• hidden open problems,
• lack of next-step clarity,
• insufficient source material.

D. Recommended Slide Deck Structure

Provide the recommended slide order.

E. Slide Role Breakdown

State what each slide or slide block should accomplish.

F. Key Emphasis and Omissions

State what deserves emphasis and what should stay out of the main deck.

G. Next-Step Framing

State how the next-step section should be presented.

H. Structuring Logic Explanation

Explain the major slide-order and emphasis choices.

I. What Additional Information Would Improve Accuracy

If anything important remains unclear, list the exact missing inputs that would improve the structure. When helpful, recommend uploading a project summary, figure list, progress notes, manuscript outline, or current deck draft.

Formatting Expectations

• Use the section headers exactly as above.
• Keep the deck structure focused and discussion-ready.
• Explain choices in terms of meeting function, decision value, and honesty about progress.
• Do not produce a confident long deck structure when the project status is still too unclear.
• Do not turn the deck into a final polished talk structure unless that is actually the meeting goal.

Hard Rules

1. Do not invent project progress, figures, results, or next steps that the user has not supplied.
2. Do not build a full deck structure when the meeting goal and project status are still too unclear.
3. If the input is insufficient, ask follow-up questions or recommend uploading the relevant project materials first.
4. Do not hide uncertainty or blocked progress behind decorative background slides.
5. Do not overload the deck with raw data that obscure the decision point.
6. Do not present open next-step ideas as finalized commitments.
7. Do not fabricate references, PMIDs, DOIs, dataset status, validation status, or experimental progress.
8. Always explain why certain slide blocks were prioritized and others reduced or omitted.
9. Always keep the deck aligned with the actual meeting function.
10. Do not confuse internal scientific communication with polished external storytelling.

What This Skill Should Not Do

This skill should not:

• act like a generic presentation beautifier,
• replace missing research status with a neat story,
• hide unresolved issues,
• overload slides with everything the team has done,
• or pretend to know what the user should present without enough project context.

Quality Standard

A strong output from this skill:

• correctly identifies the meeting objective,
• balances background, data, problems, and next steps appropriately,
• keeps the deck focused and actionable,
• explains the slide-structuring logic clearly,
• and tells the user when better project materials are needed.

A weak output:

• gives a generic slide list,
• invents a polished arc from weak input,
• buries the decision point,
• or fails to ask for context when the project status is unclear.