How to install a Claude Code Skill — Methods drafter walkthrough

Installing a Claude Code Skill on your computer makes it load automatically in every Claude Code session, in any project, without you re-pasting or re-explaining it. This note walks through the install end to end, using the Methods section drafter Skill from the first Skills note as the worked example — past tense, passive voice, every software parameter spelled out, missing details flagged.

It's a small install — one Markdown file in a standard location (~/.claude/skills/methods-drafter/SKILL.md). But it's the difference between a Skill you have to remember and a Skill that's just there.

What you'll learn

• Where on your machine Claude Code looks for Skills, and how to install one there with a single mkdir and a file save.
• How to verify the Skill is loaded in a brand-new Claude Code session — including how to list every Skill currently active.
• The difference between user-level Skills (one place on your machine, available in every project) and project-level Skills (.claude/skills/ checked into a repo), and when to choose each.

What you'll have when you're done

• A SKILL.md file installed at ~/.claude/skills/methods-drafter/SKILL.md.
• A Methods drafter that activates in any Claude Code session — paste your scattered notes, ask "draft the Methods section from these notes", and get back a paragraph in publication voice with missing details flagged as [Missing: ...].
• A repeatable pattern for the next Skill you install — same directory, same name: / description: shape, same two-step install.

Skills vs tools

Skills and tools are two distinct ways to customise what Claude does, and they're easy to confuse. A Skill is a rule — instructions Claude follows automatically once loaded into context, like style guides for writing or conventions for analyses. A tool is a function Claude can call mid-conversation when it needs fresh data or deterministic computation (a database lookup, a stats test, today's date). Skills give Claude rules; tools give Claude functions. The two layers compose; for the tool side, see Your first reusable Claude tool — PubMed search.

A Claude Skill is a Markdown file at a known location that Claude Code reads on session start. It contains a name, a description of when to load it, and a body of instructions. When your prompt semantically matches the description, the body silently becomes additional guidance for that conversation.

Methods drafting is a textbook Skill-shaped problem:

• The rules don't change. Past tense, passive voice, every parameter, no invented values. Same across every Methods paragraph you'll ever write.
• The work is repeated. Every project has a Methods section. Every Methods section has the same shape.
• You want consistency across sessions. Without a Skill, every new conversation starts from "default Claude voice" and you re-steer toward Methods style by hand.

What gets installed on your computer

~/.claude/skills/methods-drafter/
└── SKILL.md           # the rule Claude Code loads automatically

One file. That's the entire install — there are no .py modules to write, no PYTHONPATH to configure, no API calls to make. Skills are deliberately simple: one Markdown file with a description telling Claude when to load it.

You build it in two steps below (write the file, install it), then verify in two ways: by listing your active Skills in a new Claude Code session, and by asking for a Methods section and watching the rules apply.

Write the SKILL.md file at ~/.claude/skills/methods-drafter/

Copy this complete file into ~/.claude/skills/methods-drafter/SKILL.md. This is the same SKILL.md we built rule-by-rule in the first Skills note — if you want the walkthrough of why each block is there (style rules, anti-hallucination clause, multi-paragraph form, output format), that's the place to look. The YAML frontmatter (between the --- lines) is what Claude Code reads to decide whether to load the Skill; the Markdown body below is what it follows once loaded.

---
name: methods-drafter
description: Use when the user pastes lab-notebook bullets, README snippets, script header comments, or analysis shorthand and asks for a Methods section. Activates for any "draft methods" / "write up the methods" request.
---

# Methods drafter

You are a senior computational biologist drafting Methods sections for top-tier journals (Nature, Cell, Genome Biology).

When the user gives you shorthand notes — bullets, README excerpts, Snakefile params, script comments, an email thread — rewrite them as a single flowing Methods paragraph (or one paragraph per sub-analysis if multiple are present).

## Style rules

- Past tense, passive voice (standard for Methods)
- Include every software name, version, and parameter the user mentioned
- Make implicit details explicit ("BH" → "Benjamini–Hochberg procedure")
- Expand abbreviations on first use (DEG, FDR, PCA, GSEA)
- No editorialising, no praise, no "we believe", no "interestingly"
- No bullet points in output — flowing prose only

## Anti-hallucination (load-bearing)

If the user's notes omit a normally-required detail (reference genome version, statistical test, sample size, library prep, alignment parameters), note it at the end as `[Missing: ...]`. **Never invent values.**

## Multi-paragraph form

If the user gives you several sub-analyses, draft each as its own paragraph under a `### <subheading>`. The reader should be able to copy the whole block straight into a manuscript skeleton.

## Output format

Return ONLY the Methods paragraph (or paragraphs + subheadings) plus the `[Missing: ...]` line if anything is missing. No preamble, no explanation, no "here is your Methods section."

Three parts shape the file:

• name: — the slug Claude Code uses internally. Match it to the directory name (methods-drafter).
• description: — the single most important field. Claude Code reads every Skill's description, compares each one semantically against the user's prompt, and silently loads the body if there's a match. Be specific about when the Skill applies — enumerate realistic input shapes (bullets, README excerpts, etc.) and the natural-language triggers ("draft methods" / "write up the methods"). The wider the description, the more reliably Claude picks the Skill up.
• The Markdown body — what Claude actually follows once the Skill loads. Use sections, mark load-bearing rules, be specific. The body counts toward the session's input tokens (~250 here) but at that size it's cheap.

The anti-hallucination section is the single most important rule. Methods sections that invent a software version cause real harm. The [Missing: ...] convention turns a likely failure ("model makes up a number") into a visible flag ("model tells you it didn't know").

Install the Skill in ~/.claude/skills/

mkdir -p ~/.claude/skills/methods-drafter

# Open ~/.claude/skills/methods-drafter/SKILL.md in your editor and
# paste the Skill block above (everything between the triple-backtick
# markdown fence, NOT including the fences themselves). Save.

Sanity check:

ls ~/.claude/skills/methods-drafter/
# Should show: SKILL.md

That's the install. One file, one standard location. Every Claude Code session you start on this machine from now on will see this Skill and load it whenever a prompt matches the description.

Verify the Skill loaded — run /skills in a new Claude Code session

Open a fresh terminal — any folder, any project. Run:

claude

Inside the Claude Code session, first check the Skill is registered:

/skills

methods-drafter should appear in the list. If it doesn't, the directory name, file name, or YAML frontmatter is off — re-check that the path is exactly ~/.claude/skills/methods-drafter/SKILL.md and the file starts with the --- ... --- block.

Then paste a Methods request with shorthand notes:

Please draft the Methods section from these notes.

RNA-seq DEG analysis (2026-04-15)
- 24 samples, 6 conditions, 4 reps each
- aligned with STAR v2.7.11 to GRCh38 + GENCODE v45
- gene-level expression with RSEM (v1.3.3)
- DESeq2 v1.42, alpha=0.05, BH for multiple testing
- pre-filtered: drop genes with sum<10 across all samples
- sequencing batch as covariate
- 3 outliers dropped on PCA (PC1 > 2 SD)

Expected output (wording will vary):

Total RNA-seq reads from 24 samples (six conditions, four biological replicates each) were aligned to the human reference genome (GRCh38) using STAR v2.7.11 with the GENCODE v45 transcript annotation. Gene-level expression was quantified using RSEM (v1.3.3). Genes with fewer than 10 reads across all samples were removed prior to analysis. Three samples identified as outliers based on principal component analysis (PCA; PC1 > 2 standard deviations) were excluded. Differential expression was assessed using DESeq2 (v1.42), with sequencing batch included as a covariate. Significance was called at a false discovery rate (FDR) of 0.05 using the Benjamini–Hochberg procedure.

Past tense, passive voice, every parameter you wrote down, no invented values. The Skill loaded automatically — you did not type /use methods-drafter, you did not add a --use-skill flag, you wrote a plain-English request. Claude Code's planner read your prompt, matched it semantically against the description: field of every Skill in ~/.claude/skills/, and silently loaded the Methods drafter body as additional guidance for the session.

This is the key difference between Skills and tools: tools wait to be called explicitly; Skills load contextually based on what you're asking. You teach the rules once, and from then on the right rules attach themselves to the right conversations.

The same Skill, used three ways

Three realistic prompts that hit the Methods drafter from different angles. Each runs in any Claude Code session on a machine where the Skill is installed.

Bulk RNA-seq DEG analysis — clean notes, full paragraph

The verification example above is the canonical case: clean shorthand notes covering everything a reviewer would want, in. Clean Methods paragraph out. Same input shape as anything you'd write down in your own analysis log.

scRNA-seq with deliberate gaps — paragraph + [Missing: ...]

These notes leave out several details a real Methods section would need: reference genome / transcriptome, Chromium chemistry, QC thresholds, normalisation method, batch correction. The Skill should produce a clean paragraph for what's there, and a [Missing: ...] line for what isn't.

scRNA-seq:
- 10x Genomics Chromium
- Cell Ranger v8.0
- Seurat v5.1 clustering, resolution 0.6
- 8 samples, 2 donors x 4 timepoints

Methods section please.

Expected output (paragraph + an honest [Missing: ...]):

Single-cell RNA-sequencing libraries were generated on the 10x Genomics Chromium platform across eight samples (two donors at four timepoints each). Reads were aligned and quantified using Cell Ranger v8.0. Downstream clustering was performed in Seurat v5.1 with a graph-based community-detection resolution of 0.6.

[Missing: reference genome and transcriptome version used by Cell Ranger; Chromium chemistry version; cell- and gene-level QC thresholds; normalisation method (LogNormalize / SCTransform); number of variable features; number of PCs retained; batch correction or integration strategy; cell-type annotation approach.]

The [Missing: ...] line is the load-bearing piece. The Skill is honest about what you didn't tell it, so you can either fill in those details or accept that the draft is incomplete.

Multi-step project — ### <subheading> per sub-analysis

A real bioinformatics project rarely has a single Methods paragraph. The Skill's multi-paragraph rule handles this directly: give it all the sub-analyses in one paste, get back named subsections that drop into a manuscript skeleton.

Section 1: Alignment & quantification
- aligned with STAR v2.7.11 to GRCh38 + GENCODE v45
- RSEM (v1.3.3) for gene-level expression

Section 2: DEG
- DESeq2 v1.42, BH FDR < 0.05
- batch covariate; 3 outliers dropped

Section 3: Pathway enrichment
- GSEA via clusterProfiler v4.10
- MSigDB Hallmark v2023.2.Hs
- 10,000 permutations, FDR < 0.05

Expected output — three named subsections, each a clean Methods paragraph with [Missing: ...] where the notes were thin. Each subsection is paste-ready for a manuscript skeleton.

User-level vs project-level Skills

Where you put the SKILL.md decides who can use it:

You can have both at once; project-level rules override user-level when they conflict. A project-level Skill named methods-drafter for a specific paper supersedes your global Methods drafter for that repo only.

How Skills compose with tools

Skills give Claude rules; tools give Claude functions. The two compose at the conversation layer: a Skill can teach Claude Code to call a tool you wrote, and a tool can supply the fresh data a Skill needs in order to follow its rule.

A worked example of the bridge lives in the tools install note: a Skill at ~/.claude/skills/pubmed-tools/SKILL.md tells Claude Code that pubmed_count and pubmed_search live at ~/claude-tools/pubmed_tools.py, and instructs Claude to invoke them via Bash + python -c "..." when a literature question comes up. The Skill is the rule; the tool module is the code; together they make the toolkit available to any Claude Code session on the machine.

Each layer keeps its scope, and they cover different jobs.

Two upgrade paths worth knowing

Per-journal variants. Methods conventions differ between Nature, Cell, and Genome Biology in ways a reviewer will catch. Once you've shipped a paper to a journal and noticed which conventions matter, fork the global Skill into a journal-specific variant — ~/.claude/skills/methods-drafter-nature/SKILL.md, ~/.claude/skills/methods-drafter-cell/SKILL.md. Claude picks the right one based on the description (which is why you put the journal name in the description as a trigger phrase).

The same rules outside Claude Code. Skills are a Claude Code feature; they don't apply when you call the Anthropic API directly from a notebook. If you want the same Methods drafter behaviour via the API, paste the body of SKILL.md (everything below the frontmatter) into a system= prompt on client.messages.create(...). Same content, same effect, different transport. The companion notebook for this series shows the pattern.

Quick reference, cost, and what this Skill won't do

Install (one-time):

mkdir -p ~/.claude/skills/methods-drafter
# Paste the SKILL.md block above into ~/.claude/skills/methods-drafter/SKILL.md

Use it: open Claude Code (claude in any terminal). Paste your shorthand notes with a prompt like "Please draft the Methods section from these notes." The Skill loads automatically.

Verify: inside Claude Code, run /skills. methods-drafter should appear in the loaded list.

Tweak when needed: edit ~/.claude/skills/methods-drafter/SKILL.md. Changes take effect in the next session.

Cost. The Skill file itself adds nothing — it's just text on disk. When it loads, the body counts toward the session's input tokens (~250 tokens here). A single Methods paragraph is roughly 300 input + 300 output tokens. Drafting five sub-analyses costs a few cents. Compared to the hour it replaces, it's effectively free.

What this Skill won't do:

• It won't fetch your software versions. If you don't write the STAR version into your notes, the Skill will flag it in [Missing: ...] and leave it blank. That's the design — flagging is safer than guessing.
• It won't enforce journal-specific style automatically. Customise the body for your target journal once you know it (the "per-journal variants" upgrade path above).
• It won't replace a reviewer. This is a first-draft tool. The reviewer still catches the things the Skill (and you) missed.
• It won't run outside Claude Code. Skills are a Claude Code feature. If you want the same rules in a notebook calling the API, paste the body into a system prompt (see "Two upgrade paths").

Where the Skill came from

The SKILL.md you just installed is the same file we built rule-by-rule in Your first Claude Skill — a Methods section drafter. That post is where to look if you want to understand why each rule is there before you customise it for your own writing — what makes a Skill description match reliably, why the anti-hallucination clause is load-bearing, and how the multi-paragraph rule keeps the output paste-ready for a manuscript skeleton.