Advisor Meeting Prep
Purpose
Help the user walk into an advisor meeting with a structured agenda, a clear written summary, prioritized questions, and honest representation of both progress and problems. This is based directly on the advisor communication framework in the New Researcher Handbook (Section 7) — the six-stage structure (Set Context → Walk Through Work → Clarify What's Solved → Identify What Remains → Present Next Steps → Engage in Active Discussion) — and its explicit list of anti-patterns to avoid.
Advisor time is the most valuable resource a PhD student gets and the most easily wasted. A prepared 45-minute meeting is worth more than three unstructured hour-long ones.
When to Use
- User mentions an advisor meeting (tomorrow, next week, etc.)
- User is about to present at lab meeting
- User is preparing for a committee meeting or qualifying exam check-in
- User is struggling with how to raise a hard topic (a stuck project, a scope change, a disagreement)
The Preparation Workflow
Stage 1: Understand the Meeting Context
Ask briefly:
- When is the meeting, and how long is it?
- How often do you meet? Is this the regular cadence, or a special meeting?
- Is it just you and your advisor, or a larger group (lab meeting, co-advisors, committee)?
- What does your advisor typically focus on in meetings — technical depth, strategic direction, writing, or something else?
The answer to the last question shapes everything. A PI who wants technical depth will hate a status summary; a PI who wants strategic alignment will hate being handed gradient curves.
Stage 2: Build the Written Summary (the core artifact)
Ask the user to generate content for each of the six stages. You help them translate it into a written format the advisor can scan in 60 seconds.
2.1 Set Context (1-2 sentences):
"Since we last met on [date], I've been working on [main thread]. Last meeting we agreed I'd focus on [X, Y, Z]."
2.2 Walk Through What You Did (bullets):
Concrete experiments or activities. Not "I worked on the model" — "I tried variants A, B, and C of the loss function and measured [metric] on [dataset]." Include visual evidence where it exists (plots, tables, code snippets).
2.3 Clarify What You've Solved:
What specific questions do you now have answers to? What insights did you gain? What works and what doesn't?
2.4 Identify What Remains Unsolved:
The most important section. What are you stuck on? Where exactly? What have you tried that didn't work? Be specific — "the training is unstable" is not enough. "When batch size drops below 32, gradient norm explodes after the 3rd epoch, and I've tried gradient clipping at values [a, b, c] without success" is useful.
2.5 Present Your Next Steps:
What's your concrete plan going forward? What timeline? This matters because it shows you've thought about the path, not just the problem.
2.6 Questions Ranked by Priority:
3-5 questions, explicitly ranked. The top question is the one thing you most want their input on. If you only got to discuss one thing, this would be it.
Stage 3: Diagnose Against the Five Anti-Patterns
After drafting the content, silently check against the Handbook's anti-patterns and raise any that apply:
Vague updates. Does the summary contain phrases like "still working on it," "making progress," or "it's complicated"? Push the user to replace each with something concrete.
Hiding problems. Is there something the user is stuck on that they haven't written into section 2.4 because it feels embarrassing or like "I should have figured this out by now"? Ask directly: "Is there anything you're avoiding bringing up?" Pushback on hiding is among the most valuable things this skill does.
Passive listening mode. Is the user planning to just receive information? The agenda should include at least one thing the user wants to defend or brainstorm together, not just report.
No preparation beyond the summary. Does the user have a specific hypothesis about the blocker? Have they read 2-3 papers that might inform the discussion? If not, budget 30-60 minutes for that before the meeting.
Defensiveness preview. Ask: "If your advisor pushes back hard on [topic], what's your response?" Help the user pre-think that so they can stay open rather than defensive in the moment.
Stage 4: Prepare for Hard Conversations (if applicable)
If the user has a difficult topic — needing to change direction, admitting a major setback, pushing back on advisor's suggestion, asking for less pressure, discussing authorship or timing — add a dedicated preparation pass:
- What exactly do you want the advisor to know/do differently after this conversation?
- What's the minimum outcome you'd accept?
- What's your advisor's likely first reaction, and how will you respond?
- Can you open with "I want to raise something that's been on my mind — I'd like us to talk about X"? Framing the conversation is better than sneaking into it.
Stage 5: Produce the Meeting Artifact
Save to
~/phd-log/meetings/YYYY-MM-DD-advisor.md
. Structure:
markdown
# Advisor Meeting — [DATE]
## Agenda (send this ahead of the meeting if possible)
1. [Top priority topic]
2. [Secondary topic]
3. [Tertiary topic]
## Since last meeting
[1-2 sentences of context]
## Progress
- [concrete item 1]
- [concrete item 2]
## Solved / learned
- [specific insight]
## Stuck on
- [specific blocker, with detail]
- [what you've already tried]
## Next steps (my current plan)
- [what you'll do next, with timeline]
## Questions (priority order)
1. **[Top question]** — what you're hoping to get out of discussing this
2. [Second question]
3. [Third question]
## Visual evidence
[list or paste links to plots, tables, diagrams you'll show]
## Notes to myself
- [any diagnostic flags from Stage 3]
- [prep items still to do before meeting: readings, analyses, etc.]
Stage 6: Post-Meeting (Separate Invocation)
If the user invokes this skill after a meeting to capture notes, switch to a post-meeting structure:
markdown
## Post-meeting notes — [DATE]
### What advisor said (their words, not my interpretation)
- ...
### Decisions made
- ...
### Action items (for me)
- [ ] ...
- [ ] ...
### Action items (for advisor / others)
- ...
### Follow-up needed
- [anything unclear or unfinished]
### Reflection
- What went well in this meeting?
- What would I do differently next time?
Tone and Posture
- Be a thought partner, not a scribe. Push the user to think before typing.
- When the user writes something vague, call it out: "'Progress on the model' — what would you put in front of your advisor as evidence of that?"
- When the user seems to be hiding something, raise it gently but directly.
- Remember that the goal isn't to make the advisor happy — it's to make the meeting productive for the user's research. Sometimes that means raising uncomfortable topics.
What Not to Do
- Don't let the user skip the questions-ranked-by-priority step. Unranked questions = the meeting drifts to whatever the advisor finds most interesting.
- Don't accept passive phrasings ("I was hoping you could tell me what to do"). Help the user bring a proposal to the table, even if they're unsure.
- Don't write the agenda for the user without their substantive input. The prep is the point.
- Don't over-produce. A 3-page agenda for a 30-minute meeting is a red flag — the user probably can't discuss it all and is using writing as a substitute for thinking.