What got cheaper

The mechanics of analysis: code, pipelines, standard models, the first draft of a report. In the “near-perfect data” column this is all gain. A simple model was already enough there, and now it arrives faster.

What did not get cheaper

Knowing whether the answer is right. An AI system that is handed imperfect data still returns a fluent, well-formatted, confident result. “Garbage in, garbage out” has acquired a more dangerous cousin: garbage in, polished prose out. The lose-lose cell of the table now looks like a win on the surface, which makes the combination of imperfect data and imperfect science harder to spot than it was in 2013 or in 2022.

An example from the microbiome field

Microbiome research makes the point concrete. In a recent essay, Ran Blekhman reviews why AI keeps failing at microbiome prediction. In the largest benchmark he discusses, 156 modeling pipelines were compared across 83 gut microbiome cohorts and 20 diseases, and ridge regression and random forest came out on top, ahead of neural networks. In another study, a transformer trained on American Gut Project data was outperformed by a plain random forest on nearly every task. The reasons are scientific ones: the typical study has about 160 samples, more than half of the entries in an abundance table are zeros, and the signal linking microbes to disease is modest. In Blekhman’s words, “the bottleneck is biological, not algorithmic.”

The same essay shows where deep learning does help: generalizing across studies, and integrating the microbiome with metabolomics, host gene expression or clinical data. Knowing which of the two situations you are in is the science.

The 2026 edition of the table

• Near-perfect data + AI: the win-win, only faster.
• Imperfect data + AI without scientific direction: the new lose-lose, and a well-disguised one.
• Imperfect data + AI directed by science: still the real test of a data scientist, and now within reach of many more people.

Thirteen years after Jeff Leek’s post, the key word in data science is still science.

Why now

My old site ran on Hugo with the Academic theme, through the blogdown package in R. It served me well for years. By 2026, it had three problems.

The theme was frozen in time. My copy of the Academic theme dated from 2019 and was written for a version of Hugo from that year. The theme has since been renamed twice, and Hugo itself has moved far ahead. The site could be built only with old tools, and upgrading it meant redoing it.

It was heavy for what it did. The generated site had 1,078 files and weighed 48 MB. The home page fetched 16 files from third-party servers, including icon sets, a search library and a maps library, to display a biography. The menu had two items, and the site title still read “Hello, World!”.

Publishing was manual. Every change meant building the site on my laptop and pushing the generated pages by hand. That is enough friction to postpone a small edit for months, and months became years.

I am far from the first to make this move. Rob Hyndman, Nicola Rennie and Robin Lovelace have each described their own, and their posts make the case for Quarto well. In short, Quarto is the better tool for a site that is mostly writing, code and a CV, and that one person has to keep alive for years; Hugo remains faster and more flexible for large or highly customized sites. What I can add is an account of doing it in 2026, with an AI assistant doing most of the typing.

What I wanted

Four things: a site that looks good, loads fast, works on every device, and takes minutes to update.

What changed over the weekend

• The engine. The site is now a folder of plain text files built by Quarto. GitHub rebuilds and publishes it after every push, so updating the site takes three commands in a terminal.
• The design. One typeface, six colors, a dark mode, and a Laplace density curve under my name. The new site has about 100 files, and the home page loads its fonts and styles from the site itself.
• The pages. About, Experience, Papers, Software, Awards and Posts. Every published post kept its web address.
• The CV and the resume. Both are now built with Quarto, the same way as the site.
• The older posts. Several were refreshed, including the two tutorials on automating citation metrics and the list of student paper awards and travel grants, which grew from 17 awards to 74.

Who did what

I used Claude, with access to the site folder on my computer.

My part was the content and every decision: what the site says, how it reads, what stays, what goes, and when something is finished. The assistant’s part was the conversion from Hugo, the styling, the build scripts and the checking.

The habit that mattered most was asking for proof. Each page was rendered and checked at phone, tablet and desktop widths. The new CV was compared word for word against the old one before I retired the old files. An assistant that reports “done” is making a claim, and the claim is cheap to verify.

What went wrong

This is the part a tutorial leaves out.

1. The live site showed the README. After the first push, my domain displayed the repository’s README file. GitHub Pages was still set to publish from a branch. The fix is one setting: under Settings, then Pages, the Source must be “GitHub Actions”.

2. My phone showed the desktop layout. The new design was responsive, and my phone still displayed a shrunken desktop page. The cause had nothing to do with the site. My domain registrar was forwarding the address with a “masked” redirect, which wraps the site in a frame. Replacing it with proper DNS records for GitHub Pages solved it, and the security certificate arrived after a short wait.

3. The images lost quality. During the move, the assistant had resized and recompressed the pictures in my posts. I noticed that some looked soft. The fix was to restore 27 originals from the archived copy of the old site and to re-save six more from their sources. Keep your originals.

4. My CV disappeared from the internet. Quarto deletes the old PDF at the start of a build. My first build on my own computer failed, and the PDF behind the public CV link was gone until I restored it from the archive. If a public link points to a file that your build produces, a failed build takes it down.

5. The link preview cut my head off. When I shared the new site, the preview showed my shirt. Social networks crop preview images to a wide rectangle, and my home page was offering them a tall portrait. A dedicated wide image for link previews fixed it.

6. The assistant edited too much. Asked to refresh an old post, it rewrote my text. Asked to update a chart, it redesigned the chart. In both cases I had it restore my original and limit itself to what I had asked for. An assistant that edits fast also edits freely, and it helps to say at the start which parts are yours and must stay as they are.

7. Google Scholar turned the assistant away. The citation counts could not be fetched from the assistant’s cloud workspace. The script therefore runs on my own computer, saves the numbers it receives, and reuses them on days when Google Scholar declines to answer.

What I would tell a colleague

• Keep an archive of the old site. Several of the problems above were solved from it.
• Review every change before it goes live. A local preview takes seconds.
• Protect your own voice. Let the assistant handle the machinery, and keep the writing yours.
• Ask for proof. A check that fluent writing cannot get around is the best instruction you can give.

Use it yourself

The source of this site is a public template on GitHub. The README explains how to make it yours, with step-by-step prompts for doing so with Claude: replacing the content, changing the look, bringing old posts along, checking the result and publishing.

And yes, since every piece of text is now allegedly AI-written: the assistant helped me draft this post too. The weekend, the decisions and the mistakes are mine.

Feedback and pull requests are welcome :)

New year resolutions

One of my new year resolutions in 2020 was to write at least one piece of writing every month (technical or non-technical). This seemed like a lofty goal at the outset but I am glad that I was able to break this seemingly hard-to-attain goal into manageable chunks to make it a reality. In my mind, this was a monumental personal milestone as it allowed me to build a decent writing habit which has been difficult historically.

>10000 steps per day

Another seemingly unattainable habit (based on past experiences) was consistently hitting an average >10,000 steps a day for an extended period of time (i.e. more than a few weeks or months), which I was able to achieve despite the almost year round lockdown. Considering all the obstacles that stood in the way this year, it was a truly transformative experience to start 2021 on a lighter note!

Getting back into creative writing

Towards the end of the year, I was fortunate to enroll in a screenwriting class. Among other things, this was my best chance at getting back into creative writing. As a result of this experience, I was able to write a few short scripts in addition to a few amateur poems which was enough to eventually claw my way to get my writer’s groove back :)

Personal commit record

In the meantime, almost accidentally, I broke my own record of GitHub commits, which was more than all the previous years combined. I couldn’t be more happy about this unexpected milestone!

Personal peer-review record

By the same token, I couldn’t be more appreciative of the opportunity to give back to the scientific community through voluntary contributions in the form of peer-review activities. Consequently, I was able to break my own record of Publons-verified peer-reviews, which was again accidentally more than all previous years.

Apart from these, there have been a few first-of-its-kind professional highlights this year as well:

• Completed my first internship as a mentor
• Edited my first special issue as a lead editor
• Published my first Bioconductor package
• Delivered my first keynote presentation
• Organized my first JSM invited session (scheduled for JSM 2021)

With that note, I would love to hear your highlights from the year, so be sure to leave a comment :)

Wishing you and yours a safe, healthy, and prosperous new year! Onwards and upwards!

Featured image source: https://www.the-scientist.com/news-opinion/what-to-expect-in-the-publishing-world-in-2020--66882

What is new in 2026

The first version of this list had 17 entries and was last touched in 2021. Award pages move and deadlines shift every year, so by 2026 most of its entries pointed to an old page or an old date. The new version starts over:

• 74 awards in five groups: student paper awards and student travel awards (19), the ASA section competitions for JSM (20), early-career awards and travel grants (12), conference support in mathematics, machine learning, computational biology and R (17), and scholarships and other support (6).
• Three facts for every award: who can apply, what it covers, and when the call usually closes. The deadlines are general (for example “November 15” or “mid-October”), so the list stays useful from one year to the next.
• A student level for every award (undergraduate, master’s, PhD or early career), taken from the official page, and a separate list of the 17 awards open to undergraduates.
• A month-by-month calendar of deadlines at the bottom.
• The date of the last check, so you know how fresh the information is.

If you saved dates from the 2020 version, please check your calendar. Several have moved:

• The ENAR Distinguished Student Paper Awards now close on October 15.
• Most ASA section competitions now close on November 15, a student may enter at most two sections, and winners hear by January 15.
• The WNAR student paper competition now closes in early February.
• The ICSA student paper awards now close in mid-April.
• The IMS Lawrence D. Brown Ph.D. Student Award now closes on July 1.

The refresh itself was done with Claude, which checked each award against its official page and recorded the date of the check. I mention it because it changes what is realistic for a volunteer-run list: a full re-check of every entry is now an evening’s work, so the list can be kept current once a year.

How to contribute

While this is not intended to be a comprehensive overview of such opportunities, I would like this public repository to be an ongoing community effort with the hope that it serves the early-career data science community at large. There are now three ways to help, from quickest to most hands-on:

1. Fill in a short form. Suggest an award or report a correction. No Git knowledge is needed.
2. Edit the table in your browser. The whole list lives in one spreadsheet-like file, awards.csv. Click the pencil icon, change or add a row, and GitHub walks you through the rest.
3. Open a pull request the usual way.

Any of the following is welcome from the community members:

• New information you’d like to add (such as a new award not already listed)
• Inaccuracies in the content (e.g. deadline, eligibility, etc.)
• Information gaps in the content that need more details to be complete (e.g. broken links)
• Awards from societies outside North America, which the list barely covers today

The repository also has a “Help wanted” section with leads that could not be confirmed on an official page. If you know one of those awards, that is the most useful place to start.

I look forward to your suggestions and pull requests :)

Featured image source: perforce

Motivation

Similar to Part I, here are just a few things I would like to maintain:

1. Ability to edit CVs and resumes in LaTeX,
2. Without the need to learn a new language or markup syntax, and
3. Without falling back to a manual update which can be inconvenient.

As before, here are a few things we will need: (i) A CV or resume written in LaTeX (.tex), (ii) R, and (iii) RStudio (both are free, and the RStudio page walks you through installing them). This tutorial also assumes that you have an up-to-date Google Scholar profile. All files described in this tutorial, including a small example resume for each route, are publicly available.

Compared to the previous post, this tutorial is more straightforward, thanks to the well-developed Sweave function, that enables effortless integration of R code into LaTeX documents, allowing one to execute and embed the results of R computations and graphics within a LaTeX document.

Without further ado, here goes the quick 3-step solution.

Step 1: Customizing the LaTeX Document

First step is to convert the existing LaTeX (.tex) document into a Sweave file (.Rnw) by simply changing the extension.

Step 2: Adding a minimal R code

Next, add the following R chunk in your .Rnw document (anywhere between \begin{document} and \end{document}):

<<echo=FALSE>>=
library(scholar)
my_Google_Scholar<-get_profile('twbXG-wAAAAJ')
a<-my_Google_Scholar$total_cites
b<-my_Google_Scholar$h_index
c<-my_Google_Scholar$i10_index
@

In the above code, I have used my own Google Scholar ID twbXG-wAAAAJ. Please don’t forget to modify to yours. You also need to call out these extracted values (a, b, and c) using the \Sexpr command in the LaTeX document as follows:

Citations = \Sexpr{a}
h-index = \Sexpr{b}
i-10 index = \Sexpr{c}

That’s it. Now you can compile this file directly from RStudio by simply executing the Compile PDF button on the right:

For your reference, the snapshot above is from my own resume which can be downloaded from here.

One caveat I have learned since 2020: Google Scholar sometimes refuses automated requests for a few hours, and on such days the chunk above stops the whole document from compiling. A slightly longer chunk keeps a copy of the last numbers it received and uses that copy when a request fails:

<<echo=FALSE>>=
library(scholar)
saved <- "scholar_metrics.rds"
gs <- tryCatch(get_profile("twbXG-wAAAAJ"), error = function(e) NULL)
if (is.list(gs) && !is.na(gs$total_cites)) saveRDS(gs, saved) else gs <- readRDS(saved)
a <- gs$total_cites
b <- gs$h_index
c <- gs$i10_index
@

A complete small resume with this chunk is in the _example/sweave folder.

(Optional) Step 3: Automating with cron

Once the Steps 1 and 2 are in place, it’s as easy as pie to automate this further. In particular, you can follow the exact same steps from Part I tutorial to set up a cron job, using the following script (Update_Resume.R) in place of the one from Part I:

route <- "sweave"   # "sweave" or "quarto"

if (route == "sweave") {
  # Runs the R chunk, then LaTeX. Needs a LaTeX installation
  # (the quickest one to set up: install.packages("tinytex"); tinytex::install_tinytex()).
  utils::Sweave("Resume_Master.Rnw")
  tools::texi2pdf("Resume_Master.tex", clean = TRUE)
} else {
  # Needs Quarto (it comes with RStudio).
  status <- system2("quarto", c("render", "Resume_Master.qmd"))
  if (status != 0) stop("Quarto could not build the resume. Read the message above.")
}

invisible(file.copy("Resume_Master.pdf", "Resume_Final.pdf", overwrite = TRUE))
message("Wrote Resume_Final.pdf")

The code above assumes that Resume_Master is the master file that you intend to update and Resume_Final is the final document. After you execute these steps, a PDF named Resume_Final.pdf with the appended Google Scholar citation metrics will be produced. This script replaces the one in the 2020 version of this post, which I had not tested at the time. This one has been run on the example files for both routes.

The Quarto route, with a citation count for each paper (new in 2026)

Quarto is the successor to the Sweave and R Markdown family, and in October 2026 I moved my own CV and resume to it. The idea is the same as before: your LaTeX stays LaTeX, and a few lines of R fetch the numbers each time the PDF is built. Two things get better. The build survives the days when Google Scholar does not answer, and each paper can carry its own citation count.

The _example/quarto folder has three small files:

• Resume_Master.qmd: the text of the resume, still in LaTeX
• resume-template.latex: the LaTeX preamble (everything above \begin{document})
• scholar.R: the helper that talks to Google Scholar

To convert your own document, move your preamble into the template, and paste the rest between the two fences of the {=latex} block. The top of Resume_Master.qmd looks like this:

---
format:
  pdf:
    template: resume-template.latex
    pdf-engine: pdflatex
engine: knitr
---

```{r}
#| echo: false
source("scholar.R")
scholar_setup(
  id = "twbXG-wAAAAJ",                  # your Google Scholar profile
  min_citations = 30,                   # papers with at least this many citations show a count
  citation_format = "[Citations: %s]"   # how the count is written; %s is the number
)
```

```{=latex}
\section*{Publications}

Google Scholar citations = \GSCitations{}, h-index = \GSHIndex{}, i10-index = \GSIIndex{}

\begin{enumerate}
%% citation counts: on
\item \textbf{Mallick H}, Yi N (2014). \href{https://www.ncbi.nlm.nih.gov/pubmed/27570577}{A New Bayesian Lasso}. \textit{Statistics and Its Interface} 7(4):571--581.
%% citation counts: off
\end{enumerate}
```

Three names replace the \Sexpr calls of the Sweave route: \GSCitations{}, \GSHIndex{} and \GSIIndex{}. Every paper between the two %% citation counts lines is looked up on your Google Scholar profile by its title (the text inside \href{}{}), and its count is added at the end of the entry when it reaches the threshold. Click Render in RStudio and you get this:

The third paper has fewer than 30 citations, so it shows no count. Change min_citations to move that line.

A few details that make this pleasant to live with:

• The numbers are saved in a small file (scholar-cache.json) after every successful request and reused for 12 hours, so building a CV and a resume one after the other asks Google Scholar once.
• When Google Scholar does not answer, the saved numbers are used and the build log says so, with their date.
• Titles are matched with some tolerance, since the same paper is often worded a little differently on Google Scholar. Running scholar_check("Resume_Master.qmd") in the R console lists the well-cited papers on your profile that matched nothing in the document, which is how I caught two papers whose titles differed.

Doing this with Claude (new in 2026)

I did the conversion of my own 30-page CV with Claude. These are the prompts I would start from. Attach your .tex file (or point Claude at the folder) and send them one at a time.

1. Convert, and prove that nothing changed.

Attached is my CV in LaTeX. Convert it to a Quarto document that produces the
same PDF: keep my preamble in a template file and keep the text as LaTeX. Then
build both versions and confirm that the new PDF matches the old one word for
word, with the same number of pages and the same fonts.

2. Add the totals.

Show my Google Scholar citation count, h-index and i10-index in the heading of
the Publications section, fetched with the R scholar package each time the PDF
is built. My profile is <paste the address of your profile>. Save the numbers
after every successful request and fall back on them when Google Scholar does
not answer, so the document always builds.

3. Add a count to each paper.

After each paper with at least 30 citations, add its Google Scholar count as
[Citations: N]. Match papers by title, allow for small differences in wording,
and give me a list of the papers on my profile that you could not match.

4. Put it on a schedule.

I use a <Mac / Windows PC>. Give me the exact steps to rebuild the PDF once a
week and save it to my Dropbox folder under the same file name.

Three pieces of advice from doing this myself:

• Ask for the comparison in the first prompt. “Matches word for word” is a claim that a program can check, and that check is what makes a 30-page conversion trustworthy without rereading every line.
• Expect the first real numbers to arrive on your own computer. Claude’s cloud workspace could not reach Google Scholar when I tried. The matching was tested there on made-up numbers, and the real ones came in the first time I rendered the document myself.
• Read the list of unmatched papers. Mine had three entries. Two were my own papers under slightly different titles, which a looser match fixed. The third was a book I had contributed a chapter to, which is a judgment call a script should leave to you.

Happy Tuesday! I hope you find this tutorial useful :)

Motivation

There are just a few things my scientist colleagues wanted to achieve:

1. Ability to edit their CVs and resumes in Microsoft Word,
2. Without the need to learn a new language or markup syntax, and
3. Without falling back to a manual update which can be inconvenient.

Fortunately, the R community has already done much of the hard work, thanks to the awesome officer and scholar packages. Briefly, the officer package lets users manipulate Word documents without altering the contents, styles, and properties of the original document, while the scholar package provides handy functions to extract citation data from Google Scholar.

Among other things, I wanted this solution to be a bit more robust without being too complicated for future expansion. In particular, the possibility of adding other elements above and beyond citation metrics such as images, tables, and text from R as well as portability to other documents such as PowerPoint (*.pptx) was on the top of my list. Beyond everything, I wanted to make this exercise as seamless and efficient as possible for my scientist colleagues irrespective of their coding background.

Before getting started, here are a few things we will need: (i) A CV or resume written in Word (.docx), (ii) R, and (iii) RStudio (both are free, and the RStudio page walks you through installing them). This tutorial also assumes that you have an up-to-date Google Scholar profile. All files described in this tutorial are publicly available.

So, here goes the simple 3-step solution.

Step 1: Customizing the Word Document

For illustration purposes, I will use a template resume named Resume_Master.docx which is mostly empty at this point:

The first step is to add a bookmark where you want to insert your citation metrics. If you are unfamiliar with bookmarks in Word documents, I suggest reading the Microsoft Office tutorial which is pretty concise and hence skipped here. For our specific task, I want to define three bookmarks right after the Publications section as follows:

In particular, I intend to import total citation counts, h-index, and i10 index on these pre-defined bookmarks GS_a, GS_b, and GS_c respectively, as verified by the bookmark window on the right.

Step 2: Running a minimal R script

This step is actually pretty simple as long as you know how to run a script in RStudio (open the file and click Source). Here is the bare minimum script (Update_Resume.R):

scholar_id  <- "twbXG-wAAAAJ"        # the id in the address of your Google Scholar profile
input_file  <- "Resume_Master.docx"  # the resume you edit
output_file <- "Resume_Final.docx"   # the copy with the numbers filled in

for (pkg in c("officer", "scholar")) {
  if (!requireNamespace(pkg, quietly = TRUE)) install.packages(pkg)
}

# 1. Get the numbers. If Google Scholar does not answer, reuse the last saved ones.
saved <- "scholar_metrics.rds"
profile <- tryCatch(scholar::get_profile(scholar_id), error = function(e) NULL)
answered <- is.list(profile) && length(profile$total_cites) == 1 && !is.na(profile$total_cites)

if (answered) {
  metrics <- c(GS_a = profile$total_cites, GS_b = profile$h_index, GS_c = profile$i10_index)
  saveRDS(metrics, saved)
} else if (file.exists(saved)) {
  metrics <- readRDS(saved)
  message("Google Scholar did not answer. Using the numbers saved on ",
          format(file.mtime(saved), "%B %d, %Y"), ".")
} else {
  stop("Google Scholar did not answer and there are no saved numbers yet. Try again later.")
}

# 2. Write them at the bookmarks GS_a, GS_b and GS_c.
doc <- officer::read_docx(input_file)
absent <- setdiff(names(metrics), officer::docx_bookmarks(doc))
if (length(absent) > 0) {
  stop("Add these bookmarks to ", input_file, " first: ", paste(absent, collapse = ", "))
}
for (bookmark in names(metrics)) {
  number <- format(metrics[[bookmark]], big.mark = ",")
  doc <- officer::body_replace_text_at_bkm(doc, bookmark, number)
}
print(doc, target = output_file)
message("Wrote ", output_file)

A quick breakdown of what it does is as follows. First, it installs the required packages if they are missing. In the second chunk of the code, it extracts the relevant Google Scholar citation metrics (make sure you have an internet connection while executing this part). Here I have used my own Google Scholar ID twbXG-wAAAAJ (don’t forget to change to yours). Finally, it inserts these metrics into your input Word document (in this case Resume_Master.docx) and outputs an updated document called Resume_Final.docx.

Two things are new in the 2026 version of the script. Google Scholar sometimes refuses automated requests for a few hours, so the script keeps a copy of the last numbers it received (scholar_metrics.rds) and uses that copy on such days. It also checks that the three bookmarks exist and tells you which one is missing.

With my own humble contribution to science, the resulting file looks something like this (numbers retrieved on October 4, 2026):

When this post first appeared in February 2020, the same line read citations = 581, h-index = 12, i10 index = 14.

Please note that, this script assumes that all the associated files are co-located in the same directory. Please make sure to change the names of your input and output files in the first three lines as desired before executing.

The cool thing is that you can seamlessly edit your master file as you would normally do and run this script as frequently as you want to get the citations metrics inserted automatically.

That’s it! You have the exact same resume with the citation metrics inserted.

(Optional) Step 3: Automating with cron

Now, if you would like to further fine-tune this process without the hassle of running the script every other day, you can optionally do that thanks to the amazing cronR package (Mac and Linux; on Windows the sister package taskscheduleR does the same job). Fortunately, this step is dead easy as well, especially if you are already familiar with R.

In particular, once you are able to install the cronR package following instructions here, you can jump right into the RStudio add-in section of that tutorial.

As an example, if you want to execute the Update_Resume.R script hourly, all you have to do is the following before pressing the Create job button:

Once you schedule the job above, it will update every hour whenever your computer is switched on (you can change the schedule any time). Citation counts change slowly, so a daily or weekly schedule is plenty, and a gentler schedule also makes it less likely that Google Scholar turns your requests away. You can also save the resulting file in a shared or publicly accessible folder (such as Dropbox, Google Drive, and OneDrive) and easily embed it on your personal website if you would like.

Doing this with Claude (new in 2026)

When I wrote this post in 2020, the three steps above were the shortest path I could offer a colleague who does not code. In 2026 there is a shorter one: hand the job to an AI assistant. I use Claude, and the prompts below are the ones I would give a colleague today. Attach your resume and send them one at a time.

1. Set it up.

Attached is my resume in Word. I want my Google Scholar citation count, h-index
and i10-index to appear on one line under the Publications heading and to update
automatically. My Google Scholar profile is <paste the address of your profile>.
Add the three bookmarks to the document for me, write an R script that fills
them in with the officer and scholar packages, and tell me step by step how to
run it in RStudio. I have never used R.

2. Make it sturdy.

Google Scholar sometimes refuses automated requests. Change the script so that
it saves the last numbers it received and uses them when a request fails, and
so that it tells me in plain words when a bookmark is missing.

3. Put it on a schedule.

I use a <Mac / Windows PC>. Give me the exact steps to run this script once a
week without opening RStudio.

Three pieces of advice from doing this myself:

• Ask Claude for the code, and let the code fetch the numbers. A language model’s memory of your citation count was already out of date on the day it was trained. The script asks Google Scholar every time.
• Expect to run the script on your own computer. Claude’s cloud workspace could not reach Google Scholar when I tried, and the first real numbers arrived when the script ran on my own machine.
• Check the first result against your profile. It takes ten seconds, and after that the script has earned your trust.

The same approach carries over to LaTeX and Quarto documents, including a citation count next to each paper. That is the subject of Part II.

Happy automating! It’s not that difficult after all :)