Using AI assistants with LLM packs

Learning outcomes

After having completed this chapter you will be able to:

Explain what an LLM pack is, and how it differs from the course chapters themselves
Decide when to use an AI coding assistant during this course, and when not to
Locate the LLM packs available for this course and the workflow stage each one covers
Set up an AI coding assistant with the packs, on the course server or on your own computer
Use a pack to get AI-assisted help on a dataset, while critically checking its output
Properly attribute a pack’s guidance when you use it in your own analysis

Exercises without, project work with

Do the exercises in the course chapters yourself, without an AI assistant. They are where you build the judgement this chapter relies on: an assistant’s output is only as useful as your ability to tell whether it is right.

The project work is where you can bring in an assistant, and the LLM packs described below — and, after the course, your own data.

What is an LLM pack?

So far, every chapter in this course has taught you how to analyse single-cell data. An LLM pack targets a different reader: an AI coding assistant — a tool that can read and write code in your project based on natural-language instructions — writing analysis code for you, on your project data during the course, and on your own data after it.

A pack is not a copy of the course material. It keeps the decisions, the guard rails and the failure modes of a workflow — the things you’d want an experienced colleague looking over your shoulder to catch — in a form an AI assistant can act on and be checked against, rather than in a form meant to teach a human step by step.

This course’s packs live in the llm-packs/ directory of the course repository. Each pack bundles:

pack.yml — what the pack covers, what it doesn’t, and when it was last checked against current package versions
SKILL.md — what the assistant should establish before writing any code
rules/ — the hard rules, written so they can be checked automatically
reference/pitfalls.md and reference/citations.md — worked failures, and a table mapping every substantive claim to its source
implementation/ — a tested reference implementation to adapt rather than reimplement from scratch
validate/ — a linter you can run yourself on any code an assistant writes for you

Packs available for this course

Pack	Covers	Source chapter
`scrnaseq-qc-filtering`	Loading 10x data, QC metrics, cell filtering	Analysis tools and QC
`scrnaseq-normalization-scaling`	Normalization, variable features, scaling	Normalization and scaling
`scrnaseq-dimensionality-reduction`	PCA, t-SNE, UMAP	Dimensionality reduction
`scrnaseq-integration`	Multi-sample integration (Seurat 5, CCA)	Integration
`scrnaseq-clustering`	Graph-based clustering, resolution selection	Clustering
`scrnaseq-cell-annotation`	Manual and automated (SingleR) cell type annotation	Cell annotation
`scrnaseq-differential-expression`	Cluster markers and cross-condition DE	Differential gene expression
`scrnaseq-enrichment-analysis`	ORA and GSEA (clusterProfiler)	Enrichment analysis

Every analysis chapter has a pack except trajectory/advanced analysis, left out as lower-priority bonus material. Check the llm-packs/README.md for the current status of each.

These are pilots

Every pack above is marked pilot, unreleased in its own pack.yml. That is not a formality: it means the pack has not yet been used and evaluated widely enough to be trusted the way you’d trust a published tool. Use them, but keep your own critical judgement switched on — the same judgement this course is trying to teach you in the first place. If something looks wrong, it might be.

Setting up an AI coding assistant

Many AI coding assistants support some notion of a reusable “skill”, “tool” or “context pack”: a folder of instructions and supporting files that the assistant consults automatically once it’s relevant, rather than something you have to re-explain every time. This course’s packs are written to work with that kind of mechanism. The exact name and folder convention differs between assistants, but the pack itself is just plain Markdown, YAML and R — nothing assistant-specific — so any assistant that can read project files and run R code can use one.

Choose the tab that matches how you follow the course:

The course server comes with an AI coding assistant already set up for you: goose, connected to a language model (DeepSeek V4.1 Flash) through the course. You don’t need an account or an API key, and all R packages for the course are already installed.

Your access has a fixed budget for the whole course. If goose reports that the budget is exceeded, ask a trainer.
It only works on the course server, and stops when the server is shut down after the course.
What you type, and the files goose reads, are sent to the model provider. Use it for the course and project data, not for your own unpublished or sensitive data.

1. Start goose in your project directory

Open the Terminal tab next to the Console (if there is none: Tools → Terminal → New Terminal), go to the directory you work in for your project, and start goose:

cd ~/my_project   # replace with your project directory
goose

Type your request at the prompt; type exit to leave goose. Before goose runs a command or changes a file that could do damage, it asks for your approval — read what it wants to do before you approve it.

2. Ask goose to fetch the packs

goose looks for skills in the .agents/skills/ directory of the project you start it in. Paste in this prompt:

Set up all of the LLM packs from the SIB single-cell transcriptomics course
(https://github.com/sib-swiss/single-cell-r-training) in this project,
without downloading the whole course repository:

1. In a temporary directory, sparse-clone only the llm-packs folder (not
   llm-packs/_dev, which is authoring material, not a pack), using
   `git clone --filter=blob:none --sparse` followed by
   `git sparse-checkout set llm-packs` and then excluding llm-packs/_dev.
2. In .agents/skills/ in this project (create it if it doesn't exist yet):
   - Copy each pack subfolder (every directory directly under llm-packs/
     except _dev) in as its own subfolder there, not merged together.
   - Also copy llm-packs/ENVIRONMENT.md as a plain file directly into
     .agents/skills/ (a sibling of the pack subfolders, not nested inside any
     one of them) - each pack's SKILL.md links to it with a relative path
     (../ENVIRONMENT.md) that only resolves correctly if it lands there.
3. Remove the temporary clone.
4. Confirm the packs and ENVIRONMENT.md are in place by listing .agents/skills/.

Making goose’s output easier to read

goose answers in Markdown, which can be hard to read in the narrow Terminal pane — especially tables.

Make the Terminal pane larger, or zoom out in your browser.
goose uses a light colour theme, to match RStudio’s default. If you use a dark RStudio theme, type /t in goose to switch to its dark theme; goose remembers your choice.
Ask goose to write tables to a CSV file instead of showing them, and open the file in R with View(read.csv("results.csv")).

1. Install an AI coding assistant

Follow the official installation instructions for whichever AI coding assistant you choose to use — goose, which the course server uses, is one free and open-source option. You will also need access to a language model for it, usually an API key or subscription from a model provider, and you pay for what you use. What you type, and the files the assistant reads, are sent to that provider, so check its terms before you use it on unpublished or sensitive data. You do not need anything beyond what the course already uses on top of that — your own R/Seurat setup (see Setup) and your own data.

Check that assistant’s own documentation for how it discovers reusable skills/tools/context packs, and where it expects to find them in a project — look for terms like “skills”, “custom tools”, “project rules” or “context packs”. You’ll need that answer for the next step.

2. Install the packages yourself, before involving your assistant

Do this yourself, in your own R console, rather than asking your assistant to do it — the same command from Setup:

install.packages("renv")
renv::restore(lockfile = "https://raw.githubusercontent.com/sib-swiss/single-cell-r-training/refs/heads/master/renv.lock")

This is the single biggest lever you have over how much of your conversation with the assistant gets spent on installation rather than your actual analysis. Every pack’s ENVIRONMENT.md tells the assistant what to do if it still hits a missing package, but an assistant that never hits one in the first place never produces — and you never have to read — a single line of compiler or download output. Do this before step 3, especially if this is a brand-new project with none of this installed yet.

3. Ask your assistant to fetch the packs

The packs live in this course’s GitHub repository, but you don’t need to clone the whole course material yourself, or even know any git commands. A real analysis usually moves through most of the pipeline — QC, then normalization, then dimensionality reduction, and so on — so the packs are designed to be fetched all at once: each one stays independently triggered by its own description, so having all of them in place just means your assistant automatically reaches for whichever one matches the step you’re on, with nothing extra to re-fetch as you move to the next step.

In the project directory where your own data lives, start your assistant and paste in this prompt:

Set up all of the LLM packs from the SIB single-cell transcriptomics course
(https://github.com/sib-swiss/single-cell-r-training) in this project,
without downloading the whole course repository:

1. In a temporary directory, sparse-clone only the llm-packs folder (not
   llm-packs/_dev, which is authoring material, not a pack), using
   `git clone --filter=blob:none --sparse` followed by
   `git sparse-checkout set llm-packs` and then excluding llm-packs/_dev.
2. In the location where you look for reusable skills/tools/context packs
   in this project (create that location if it doesn't exist yet):
   - Copy each pack subfolder (every directory directly under llm-packs/
     except _dev) in as its own subfolder there, not merged together.
   - Also copy llm-packs/ENVIRONMENT.md as a plain file directly into that
     SAME location (a sibling of the pack subfolders, not nested inside any
     one of them) - each pack's SKILL.md links to it with a relative path
     (../ENVIRONMENT.md) that only resolves correctly if it lands there.
3. Remove the temporary clone.
4. Confirm the packs and ENVIRONMENT.md are in place by listing that location.

Your assistant will likely ask you to approve the commands it runs (clone, copy, delete) along the way — that’s expected, and worth reading before you approve them. The end result is the same as copying every pack folder by hand, but you never had to type a git command yourself.

Only need one stage?

If you genuinely only ever need a single pack (say, you’re only doing QC on someone else’s already-processed data), you can ask for just that one instead — substitute step 1’s git sparse-checkout set llm-packs with git sparse-checkout set llm-packs/<pack-name> llm-packs/ENVIRONMENT.md, and copy both that one pack folder and ENVIRONMENT.md (as a sibling of it, same placement rule as above) in step 2. This fetches less, at the cost of having to repeat the whole fetch-and-copy process again the next time you need a different stage.

Working with your assistant

Describe your task in plain language

Start your assistant in that project directory and describe what you want to do, the same way you would ask a colleague:

“I have 10x Genomics data from 3 samples in course_data/count_matrices. Can you help me load it into Seurat and do QC and cell filtering?”

If the pack’s SKILL.md description matches your request, the assistant will consult it automatically. A well-written pack will then ask you things like which species and how many samples before writing any code — exactly the facts this course has taught you are important to establish first.

Check the output critically

This is the step a pack cannot do for you. Before you trust any code an assistant writes:

Read reference/pitfalls.md yourself. It describes, in the pack’s own words, exactly what can go wrong.
Run the relevant pack’s linter on the code you were given — and remember rule 1: that code has to exist as a file first (adjust the path to wherever the packs ended up; on the course server that is .agents/skills/):
```
Rscript path/to/scrnaseq-qc-filtering/validate/lint_code.R my_analysis.R
```
Check pack.yml:validity.last_validated — if it’s old or empty, the pack hasn’t been re-checked against current package versions recently, and the assistant should tell you this before giving advice.

Keep the attribution

A pack that follows this course’s conventions will stamp the course’s provenance onto the object it produces, and offer you a ready-to-paste methods sentence. Keep both — they are there so that using AI assistance doesn’t mean losing track of where your methodology actually came from.

Try it now

Exercise

Set up the packs in the directory you will use for your project, following the tab that matches your situation above. Then start your assistant there and ask it which skills it has available. It should list the eight scrnaseq-* packs from the table above.

Leave the analysis itself for the project work.

Using an assistant in your project

A good first task for your assistant is the QC and filtering of your project data, from the raw count matrices, without telling it which thresholds to use — it should reach for scrnaseq-qc-filtering on its own. You did the same step by hand in Analysis tools and QC, so compare what it asks you, and what it produces, with what you would have done.

Whatever you let the assistant do, you should be able to explain each step of your analysis, and why it is right for your data, in your project presentation. Mention where you used the assistant, and what you checked.

What to look out for

A pack that is working as intended should, among other things:

Ask you to confirm the species before writing any PercentageFeatureSet call, rather than assuming human
Refuse to present the thresholds it uses as “standard” or “default”, and instead show you the distributions first
Produce code you can run yourself, not just a description of what to do

If it does none of these, that’s useful information too — it’s a sign the pack (or the assistant’s use of it) still needs work, which is exactly why these are pilots.

Limitations and feedback

LLM packs encode this course’s decisions for this course’s workflows — they are not a general substitute for understanding single-cell analysis, and they will not catch every mistake. If you find a pack giving advice you think is wrong, outdated, or missing an important caveat, please open an issue on the course repository. That feedback is exactly what turns a pilot pack into a trustworthy one.