research-presenter
Turn research findings into presentation outlines with narrative arc, data visualization suggestions, audience adaptation, and slide design guidance. Use when creating research presentations, conference talks, or findings briefings.
What this skill does
# Research Presenter
Structured frameworks for transforming research findings into compelling presentations across academic, industry, and executive contexts.
## Presentation Structure Template
### Standard Research Presentation (15-20 minutes)
```
PRESENTATION OUTLINE:
1. TITLE SLIDE (30 seconds)
- Clear, specific title (not clever, not vague)
- Author(s) and affiliation
- Date and venue
- Funding acknowledgment (if applicable)
2. OPENING HOOK (1-2 minutes)
- Start with a problem, question, or surprising fact
- Make the audience care before explaining the method
- Connect to their world (industry relevance, real impact)
3. BACKGROUND AND CONTEXT (2-3 minutes)
- What is known (brief literature positioning)
- What is NOT known (the gap)
- Why this gap matters (so what?)
- Your research question (single, clear statement)
4. METHODS (2-3 minutes)
- Study design overview (visual diagram preferred)
- Key methodological decisions and rationale
- Sample / data description
- Analysis approach (high-level, not every step)
5. RESULTS (5-7 minutes — the core)
- Lead with the main finding (not chronological)
- One key finding per slide
- Visualize data rather than tables of numbers
- Build complexity gradually
- Highlight what is new or surprising
6. DISCUSSION (2-3 minutes)
- What does this mean? (interpretation)
- How does it fit with existing knowledge?
- Limitations (honest, but don't dwell)
- Implications (practical, theoretical, policy)
7. CONCLUSION (1-2 minutes)
- 2-3 key takeaways (memorable statements)
- Future directions (what comes next)
- Call to action (if applicable)
8. ACKNOWLEDGMENTS AND Q&A (remaining time)
- Thank collaborators and funders
- Display contact information
- Open for questions
```
### Short Talk Structure (5-7 minutes)
```
LIGHTNING TALK FORMAT:
Slide 1: Title + one-sentence summary of finding
Slide 2: The problem (why should anyone care?)
Slide 3: What we did (one visual of method)
Slide 4: Main result (one chart, one takeaway)
Slide 5: Supporting result (optional, only if critical)
Slide 6: So what? (implications + next steps)
Slide 7: Contact info + key reference
RULE: One idea per slide. No more than 7 slides.
If you cannot explain it in 7 slides, you do not
understand it well enough yet.
```
## Narrative Arc Framework
### Story Structure for Research
```
NARRATIVE ARC:
CLIMAX (Main Finding)
/ \
/ \
RISING ACTION FALLING ACTION
(Methods, Build-up) (Discussion, Context)
/ \
/ \
HOOK ─────────────────────────────────────── RESOLUTION
(Problem/Question) (Takeaways/Future)
IMPLEMENTATION:
ACT 1 — SETUP (25% of time)
"Here is a problem that matters to you..."
"Previous attempts have tried X, Y, Z but..."
"The question we asked was..."
ACT 2 — CONFRONTATION (50% of time)
"We approached this by..."
"What we found was..." [build tension with supporting data]
"The surprising part was..." [climax — main finding]
ACT 3 — RESOLUTION (25% of time)
"This means that..."
"The limitation is..."
"Going forward, we plan to..."
"What you can do with this is..."
```
### Narrative Transitions
| From | To | Transition Phrase |
| --- | --- | --- |
| Hook | Background | "To understand why this matters, let me give you some context..." |
| Background | Research question | "This brings us to the question we set out to answer..." |
| Research question | Methods | "Here is how we investigated this..." |
| Methods | Results | "So what did we find?" |
| Result 1 | Result 2 | "Building on this, we also discovered..." |
| Results | Discussion | "What does this tell us?" |
| Discussion | Limitations | "Before we get too excited, there are important caveats..." |
| Limitations | Conclusion | "Despite these limitations, the evidence suggests..." |
| Conclusion | Call to action | "Here is what I hope you take away from this..." |
## Audience Adaptation Matrix
### Tailoring Content by Audience
| Element | Academic Conference | Industry/Practitioner | Executive Briefing | General Public |
| --- | --- | --- | --- | --- |
| **Opening** | Literature gap | Business problem | Bottom-line impact | Human story |
| **Methods depth** | Detailed, justify choices | High-level summary | Skip or one slide | Avoid jargon |
| **Results focus** | Statistical rigor | Practical applications | ROI / impact numbers | What changed |
| **Visualizations** | Detailed charts, tables | Clean charts, dashboards | Summary metrics only | Infographics |
| **Jargon level** | Field-specific terms OK | Industry terms OK | Plain language required | Everyday language |
| **Slides per minute** | 1-1.5 | 1-2 | 2-3 (fast pacing) | 1-1.5 |
| **Takeaway format** | Future research | Action items | Recommendation | Memorable insight |
| **Q&A depth** | Methodological debate | "How do I apply this?" | "What should we do?" | "What does this mean?" |
### Audience Assessment Checklist
```
BEFORE DESIGNING YOUR PRESENTATION:
1. WHO is in the audience?
- Expertise level: [ ] Expert [ ] Knowledgeable [ ] General
- Role: [ ] Researchers [ ] Practitioners [ ] Decision-makers [ ] Mixed
- Size: [ ] Small (<20) [ ] Medium (20-100) [ ] Large (100+)
2. WHAT do they already know?
- Background in your field: [ ] Deep [ ] Some [ ] None
- Familiarity with your methods: [ ] High [ ] Low [ ] None
- Prior exposure to your topic: [ ] Extensive [ ] Limited [ ] First time
3. WHY are they here?
- [ ] Required (conference, class, meeting)
- [ ] Voluntary (interested in topic)
- [ ] Decision-making (evaluating your work)
4. WHAT do they need from you?
- [ ] Rigorous evidence and methodology
- [ ] Practical recommendations
- [ ] Strategic implications
- [ ] Inspiration or awareness
5. WHAT is their attention span?
- [ ] High focus (small seminar, engaged group)
- [ ] Moderate (conference session, last day)
- [ ] Low (after lunch, end of long day, virtual)
Adjust: pacing, interactivity, slide density
```
## Slide Design Guidelines
### Content Rules
```
SLIDE DESIGN PRINCIPLES:
1. ONE IDEA PER SLIDE
If a slide requires more than 6 seconds to understand,
it has too much content. Split it.
2. ASSERTION-EVIDENCE STRUCTURE
Title: A complete sentence stating the slide's message
Body: Visual evidence supporting that assertion
Example title: "Treatment group showed 40% faster recovery"
NOT: "Results" or "Figure 3"
3. TEXT LIMITS
- Title: 1 line, max 10 words
- Bullet points: max 3-4 per slide, max 8 words each
- Body text: avoid entirely (speak it, do not display it)
- Font size: never below 24pt (28-36pt recommended)
4. VISUAL HIERARCHY
- Most important element is largest
- Use contrast (color, size, weight) to direct attention
- White space is not wasted space — it aids comprehension
- Consistent alignment (left-align text, center figures)
5. COLOR USAGE
- Maximum 3-4 colors total
- One accent color for emphasis
- Sufficient contrast (check for colorblind accessibility)
- Dark text on light background (or vice versa consistently)
```
### Slide Type Templates
| Slide Type | Layout | When to Use |
| --- | --- | --- |
| **Title** | Large title, subtitle, author, affiliation | Opening slide |
| **Section divider** | Single word or phrase, full-bleed | Transition between major sections |
| **Assertion + chart** | Sentence title + single chart | Presenting a finding |
| **Assertion + image** | Sentence title + photo/diagram | Context, methods, examples |
| **Comparison** | Side-by-side panels or split screen | Before/after, two conditions |
| **Build slide** | Progressive reveal (animation) | Complex concepts, step-by-step |
|Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.