The DunnLab Plugin
The conventions in this manual are also packaged as a Claude Code plugin, so Claude applies them while you work instead of you having to remember them and restate them in every session.
That is the point of the thing. A convention in a document is one somebody has to read and recall; a convention in a skill is one that gets applied. This chapter documents what is in the plugin and how to run it.
You do not need the plugin to use anything else in this manual, and the skills are readable as plain markdown whether or not you install it. If you are at another institution, the parts that assume Yale are dunnlab-hpc and the cluster settings example; everything else stands on its own.
What a plugin contains
| Component | What it is | How it fires |
|---|---|---|
| Skills | Instruction sets Claude loads into context when relevant | Automatically when the task matches, or explicitly with /dunnlab-code:<name> |
| Commands | Slash commands that trigger a specific behavior | You type them |
| Hooks | Shell scripts bound to lifecycle events | On the event. None are defined here yet |
| Assets | Files distributed alongside, for you to copy | You copy them |
Plugin skills are namespaced, so the full name is /dunnlab-code:dunnlab-coding-defaults. The bare /dunnlab-coding-defaults also works unless something else has claimed that name.
The skills
Each has a markdown entry point, with references for substantial conditional details, at skills/<name>/SKILL.md in the repository. Reading them is the authoritative answer to “what does this actually do” — this table is a map, not a substitute.
| Skill | What it settles |
|---|---|
dunnlab-coding-defaults | Preferred languages, coding style, dependency management, focused tests, and version-control conventions. |
dunnlab-workflow-design | Computational structure from the first exploratory runs: readable commands, explicit dependencies, shared implementation, provenance, valid output reuse, and reproduction instructions. |
dunnlab-bioinformatics | Biological methods and tool recipes: identifiers, format checks, phylogenetic inference with IQ-TREE (including replicate searches and constrained-tree AU tests), sequence orientation, annotation, paralog resolution, and quality assessment. |
dunnlab-release-cycle | When a project outgrows working directly on main: development and issue branches, a plan with gates an agent can work through, a changelog, and a repeatable release procedure. |
dunnlab-research-lifecycle | Planning, exploration, distillation, and validation of scientific analyses. Tracks decisions and readiness for the selected scope, with publication handoff guidance when needed. |
dunnlab-new-project | Repository, environment, and documentation scaffolding, then a handoff. Resumable setup can use .agent/new-project-progress.yaml; ongoing scientific work belongs to lifecycle. |
dunnlab-hpc | YCRC cluster reference — partitions, storage quotas, SLURM batch templates, GPU inventory, Snakemake integration, and running coding agents on Bouchet’s agent partition. Yale-specific; see Computing at Yale. |
dunnlab-codereview | Review and verification using the relevant skill’s standards, with feedback that distinguishes blocking issues from suggestions. |
dunnlab-manuscript | How a manuscript is organized and built: a paired manuscript repository, Quarto source, numbers, tables, and figures staged by the analysis repository and synced in with their commit, PDF and Word builds, and co-author edits. |
dunnlab-biblio | Verified manuscript, data, and software citations, claim support, and BibTeX conventions; never invents missing metadata. |
Workflow design applies across lifecycle phases. Exploration uses the same reusable computation with provisional configurations and lightweight evidence. Distillation selects the analysis set, preserves its history, and completes the verification and documentation needed for reporting. Bioinformatics adds biological choices to this shared foundation; it does not prescribe a separate workflow architecture.
Several skills work with the plan documents described in Working Effectively. dunnlab-new-project can create dev_docs/overview.md during setup, and dunnlab-research-lifecycle develops the scientific plan in that same document. dunnlab-release-cycle keeps a separate release plan in dev_docs/PLAN.md, sequencing issues into releases with a gate on each step. Invoking a skill does not by itself add an approval step: an already actionable, authorized plan proceeds without a new review. Ask for a review before implementation when you want that decision point.
Skills are loaded on demand, so the body of one costs you nothing until it is used. What is always in context is the one-line description of each, which is how Claude decides whether a skill applies — see Managing Context for the budget that governs this.
Commands
| Command | What it does |
|---|---|
/dunnlab-code:dunnlab-check | Confirms the plugin is loaded and lists the skills it provides |
Assets
Files in assets/ are not loaded by Claude. They are there for you to copy.
settings.json— A restrictive Claude Code configuration built for the Bouchet cluster, with a cluster quick reference in its comments. On the clusters we now run Claude Code through YCRC’s sandbox module instead; see Computing at Yale.tmux/— A shared tmux configuration and cheat sheet for working over SSH, including clipboard support that works without X11 forwarding.
Installing and keeping it current
claude plugin marketplace add caseywdunn/dunnlab_code
claude plugin install dunnlab-code@dunnlab
Then confirm it loaded:
/dunnlab-code:dunnlab-check
Updates do not arrive on their own. Auto-update is off by default for third-party marketplaces like this one, so nothing changes under you — and nothing improves either. To pick up a new version:
/plugin update dunnlab-code@dunnlab
You can turn auto-update on for this marketplace under /plugin → Marketplaces if you would rather not think about it.
To switch it off without uninstalling:
/plugin disable dunnlab-code@dunnlab
/plugin enable dunnlab-code@dunnlab
Working from a local copy
To run the plugin from a working copy — useful when changing it:
git clone https://github.com/caseywdunn/dunnlab_code.git
claude --plugin-dir ./dunnlab_code
This loads it for that session alongside anything already installed. Edits take effect in the next session, or immediately after /reload-plugins. Plugin skills are not picked up live the way personal and project skills are, so that reload is necessary.
Changing a skill
Skills are markdown. Editing one is editing a text file, and that is deliberate — the barrier to fixing a convention should be low enough that people actually do it.
If a convention is wrong, or you have settled a question the skills do not cover, change it rather than working around it. dev_docs/contributing.md covers the branching model, the checks that run on every change, and the release process. Note that a change only reaches anyone if the version is bumped — the release ritual there explains why.
For building skills of your own, Managing Context covers the format and the tooling for evaluating whether one actually helps.