Wen's Runbook

Needs
- A preprint source with a search feed or API, plus a way to run a script daily at 7am and call a Claude model.
- Ask your person for: their gene list, key methods, a one-line summary of chapters 2 and 3, and the PI's contact route for drafts.

Build
1. Schedule a script for 7am daily. Pull the last 24 hours of preprints and keep those matching any listed gene or method.
2. For each match, ask the model: "Write a two-line summary, then score 1 to 5 how much this overlaps chapter 2, chapter 3, or neither. Say whether methods and conditions match separately. Do not guess beyond the abstract."
3. Write summaries to a daily list. For scores of 4 or above, draft a short note to the PI naming the worrying figure.
4. Never send the note. Hold it as a draft until your person confirms they have read the full paper.

Check
- First run should list screened count, summaries, and scores. Test with a known paper on a nearby topic and confirm it scores low when conditions differ.

Needs
- A booking system for the microscope that can be polled or exported, and a phone notification route.
- Ask your person for: the protocol's imaging time and setup time, their usable days and hours, and the booking system login method.

Build
1. Schedule a script every 10 minutes to read the instrument's bookings and compare with the previous snapshot to spot cancellations.
2. For each new free slot, compute whether it covers imaging time plus setup (default 20 minutes) and fits the person's calendar and prep schedule.
3. Send a phone alert for slots that fit, showing the slot, the time needed, and a claim link. Label slots that do not fit as skipped and keep them in a log.
4. Do not claim a slot automatically. The person taps to claim.

Check
- Cancel a test booking and confirm an alert arrives within 10 minutes. Test a slot that is too short and confirm it is not alerted.

Needs
- Bench logs and plate-reader exports in a consistent folder, a Python environment with stats and plotting libraries, and a scheduler.
- Ask your person for: their statistical tests per experiment type, the lab's figure style (fonts, colours, sizes), a minimum replicate count, and any equipment logs such as incubator events.

Build
1. Schedule the pipeline for Friday 4pm. Parse the week's logs and exports into one table per experiment.
2. Run the same tests every time. Flag any experiment below the minimum replicate count or power threshold (default: n under 3, or effect size too small for the observed variance) as underpowered.
3. Flag any replicate differing from the others beyond a set threshold (default: 2 standard deviations) and check equipment logs for events near that run.
4. Draft figure panels in the lab style into a weekly folder.

Check
- First output: one summary per experiment plus panels. Test with a deliberately odd replicate and confirm it is flagged with any matching equipment event.

Needs
- A lab inventory sheet with item, quantity and usage rates, a team chat workspace with a bot, and a script runner.
- Ask your person for: their planned experiments for the next three weeks with reagents each needs, the lab's purchasing format, the preferred supplier, and the grant code.

Build
1. Schedule a script for Wednesdays. Read current stock from the sheet.
2. Sum reagent needs across planned experiments over three weeks and compare to stock. List anything short.
3. For each shortage, draft an order in the lab's purchasing format with quantity, supplier and grant code pre-filled.
4. Post each draft to the lab channel through the bot for the PI to approve with an emoji. Place no order until the PI approves.
5. Log any item borrowed from another lab in the sheet.

Check
- First run should list shortages with quantities needed and held. Test by lowering one item's stock and confirm a draft appears and nothing is sent.

Needs
- A slide template file, a running narrative document, the week's compiled figures, a scheduler, and a Claude model.
- Ask your person for: which weeks they present and the order of sections in their talks.

Build
1. Schedule a script for Sunday evening, only on presenting weeks (read a list of dates, or ask your person to set a flag).
2. Place the week's compiled figures into the template in chronological order, using the narrative document as the spine for titles and notes.
3. Where interpretation belongs, leave an empty slide area labelled as a hole. Ask the model: "List the options my person noted in the narrative doc for this hole. Do not write the claim."
4. Save the deck to the person's folder. Do not share it.

Check
- The skeleton should hold figures, titles, and labelled holes with noted options. Test that no interpretive text has been written into any hole.

Needs
- A reference manager with an API or import route, a Claude model, and a Saturday morning schedule.
- Ask your person for: their chapter outlines, their tagging scheme, and the key claims in each chapter.

Build
1. Schedule the workflow for Saturday morning. Search recent autophagy and stress-signalling literature.
2. Ask the model: "From these candidates, pick at most five that cite or contradict the claims in these chapters. For each, say which claim and whether it supports or contradicts, in one sentence."
3. File chosen papers in the reference manager with the person's tags. Put contradicting papers in a contradictions folder.
4. Produce a digest listing contradictions first.

Check
- First digest should hold five papers or fewer, each tied to a named claim. Test by including a known contradicting paper and confirm it lands in the contradictions folder.

Needs
- A Claude project with the month's compiled experiments, literature digests, and the narrative document, plus the committee's one-page format.
- Ask your person for: the format template, the committee chair's preferences, and any milestones or dates.

Build
1. Schedule a reminder for the last Friday of each month to run the project.
2. Feed in the month's summaries, literature changes, and narrative document.
3. Instruct the model: "Draft the one-page note in the committee's format. State progress as counts (for example conditions completed of total). Use no adjectives of success. Mark any anomaly with its documented cause and decision. Flag claims you cannot support from the inputs."
4. Save as a draft. The person edits and sends it. Nothing goes to the committee without them.

Check
- The draft should fit one page and give progress as numbers. Test by scanning for adjectives and unsupported claims.

Needs
- Bench logs where deviations are noted consistently, a Python environment, and a scheduler.
- Ask your person for: the protocol names with their specified values, and the words or markers they use to note deviations.

Build
1. Schedule a script for the first Sunday of each month.
2. Scan logs for deviation notes covering timing, concentration, and substitutions. Group them per protocol.
3. For each protocol, compare logged values with the specification. Report range, count, and any correlation with outcome measures if available.
4. Where a deviation recurs (default: three or more runs), propose a decision: standardise, revise the protocol, or keep as is. Record the decision in a protocol change log.

Check
- First report should list deviations per protocol with counts. Test by planting a log entry with a changed timing and confirm it appears under the right protocol.

Needs
- A Claude project with access to funding newsletters or alerts, and a monthly schedule.
- Ask your person for: their year of study, citizenship, field, and any eligibility limits, plus past award rate sources if they have them.

Build
1. Schedule a mid-month run. Collect funding calls from the newsletters.
2. Instruct the model: "Keep only calls whose eligibility rules match this person's year, citizenship and field. For each, give the deadline, an effort estimate in hours, and last year's award rate if published. Say unknown if it is not published."
3. Output a short list of eligible calls, normally under five, with reasons for exclusions in a separate log.
4. Do not start any application without the person's say.

Check
- First output should show eligible calls with deadline, effort and award rate. Test with a call the person is clearly ineligible for and confirm it is excluded.

Needs
- A Claude project with a few approved example legends from the lab, the lab's style rules, and the target journal's stats formatting rules.
- Ask your person for: the figure, a short note of what it shows, and sample size details.

Build
1. Load the example legends and style rules into the project as reference.
2. When a figure and note are supplied, instruct the model: "Write a legend in this lab's house style. State panels, sample sizes, error bars and the statistical test in the journal's format. Use only facts in the note and ask if something is missing."
3. Return the legend with a list of any gaps to fill.
4. The person checks every number before it goes to the PI.

Check
- The legend should match the examples in structure and include a stats sentence. Test by omitting the sample size and confirm the model asks for it rather than inventing one.

Needs
- A Claude project and the reviewer's comments paired with the person's first-draft responses.
- Ask your person for: the manuscript's key claims and any points they have decided not to concede.

Build
1. Paste each comment with the draft response into the project.
2. Instruct the model: "Rewrite the response in a courteous, professional tone. Keep every substantive point. Then list any place the draft agrees to new work, experiments or changes that the reviewer did not clearly require, and say what the reviewer actually asked."
3. Return the rewrite and the list of possible over-concessions separately.
4. The person decides on every concession and sends nothing without reading the final text.

Check
- The output should have a rewritten response plus a concessions list. Test with a draft that promises extra experiments and confirm it is flagged.

Needs
- A spreadsheet of rubric scores per report, a script runner, and a Claude model.
- Ask your person for: the rubric, the borderline score band, and the course's feedback format.

Build
1. Run on demand after grading. Compile scores per student into one sheet and compute totals.
2. Flag reports within the borderline band (default: within 2 points of a grade boundary) for the person's own judgement.
3. Count how many reports share each common mistake from the rubric comments, using anonymous IDs only.
4. Ask the model: "Write one paragraph of feedback per common mistake, with no student names or identifying details."
5. The person reviews the feedback before posting it to the section.

Check
- Output should include compiled scores, a borderline list, and feedback per mistake with counts. Test that no student name appears in the drafts.

Needs
- A shared calendar with the person's and their partner's availability, and a small script or calendar automation.
- Ask your person for: which protocols cannot be left unattended, the travel time to the wall, and a buffer (default 10 minutes).

Build
1. On request, read the person's incubation windows and the partner's free times.
2. Mark protocol steps that need attention. Only offer windows where no such step falls inside the session, with travel time and buffer added both ways.
3. Propose matching sessions with start, end, and a timer for the return.
4. Do not create or send any invitation to the partner without the person's approval.

Check
- Output should list sessions that fit with the buffer. Test with an incubation that has a timed step in the middle and confirm that window is rejected.