Your first Claude Skill — a Methods section drafter

If you're using Claude Code, and vibe-coding some compbio work along the way, you've probably noticed how fast things are evolving. One of the most useful new features that can quietly make your life easier is Claude's Skills (also called Agentic Skills), which Anthropic launched in late 2025.

You may also have noticed yourself re-typing the same instructions across sessions: "draft this in past tense, passive voice, include every parameter, never invent missing details." Claude doesn't carry those rules between sessions; every new conversation forgets the preferences you set up before. Skills fix this. They're a way to teach Claude a persistent set of rules that auto-load whenever a relevant task comes up.

Methods matter

A good Methods section, whether it's going in a paper, an internal report, a project handoff, or a documentation page for the next person picking up the analysis, is the part of the document a reproducibility-minded reader trusts most. It's where the science you can actually rerun lives. But writing one well is mostly mechanical work: turning notes you already took into clean prose without missing anything. And the catch is that the details are usually scattered across GitHub repos, email threads, Markdown, and notebooks, so pulling them together into a review-ready Methods section can take hours.

This note builds the smallest but most useful first Skill: one that drafts a Methods section from those scattered notes. We'll set it up and use it inside Claude Code.

What's a Claude Skill?

A Skill is a Markdown file with a name, a description of when it should activate, and a body of instructions.

For example, the smallest viable Methods-drafter Skill looks like this:

---
name: methods-drafter
description: Use when the user asks to draft a Methods section from shorthand notes.
---

# Methods drafter

Rewrite the user's notes as a Methods paragraph.

Rules:
- Past tense, passive voice.
- Include every software name, version, and parameter the user mentioned.
- If a normally-required detail is missing, end the output with `[Missing: ...]`.
- Do not invent values.

Three parts: the name (methods-drafter), the description (what tells Claude when to load it), and the body (what to do once loaded). The full version we'll build below adds more rules, but the shape is the same.

Claude Code reads the description, decides if it matches the current context, and silently loads the body as additional guidance for that session.

You can set up a Skill in two ways, depending on where you put the file:

The mental model: a Skill is a system prompt you wrote once and forgot about. It loads when relevant, doesn't get in the way when it isn't.

When to use a Skill

Three things make a problem a good fit for a Skill:

1. The rules don't change. Same instructions across many uses.
2. The work is repeated. You come back to it across projects and sessions.
3. You want consistency. Output should look the same every time.

Where Skills are wrong: any task that needs Claude to actually run code or fetch fresh data. Those need a different mechanism:

• A tool is a function Claude can call (e.g., a Python function that runs a SQL query or computes a statistic).
• An MCP server is a long-running service Claude can talk to (e.g., a server that wraps the Open Targets or NCBI API).
• A script is for anything fully deterministic that doesn't need an LLM in the loop at all.

Skills can give Claude rules but cannot give it new data or new abilities. We'll cover tools and MCP servers in later notes in this series.

Why a Methods drafter is a good fit

Methods drafting hits all three criteria above:

• Rules don't change. Past tense, passive voice, include parameters. Same across every Methods paragraph you'll ever draft.
• Work is repeated. Every project has a Methods section. Every Methods section has the same shape.
• Consistency across sessions matters. Without a Skill, every new conversation starts from "default Claude voice" and you have to re-steer toward Methods style.

The Skill, in full

Here's the entire file. Copy it as ~/.claude/skills/methods-drafter/SKILL.md:

---
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."

Walking through the additions

The minimal example earlier had two rules and one trigger. This full version is meaningfully longer. Each addition earns its keep:

A more specific description. Instead of just "Use when the user asks to draft a Methods section," the description now enumerates the realistic input shapes (bullets, README, Snakefile params, script comments, email threads) and the natural-language triggers ("draft methods" / "write up the methods"). The wider the description, the more reliably Claude Code recognises when to load the Skill.

A role identity ("You are a senior computational biologist..."). This sets quality expectations. Without it, Claude's default voice is helpful-assistant; with it, the output reads as if a colleague at the next desk wrote it.

Explicit input-shape handling. Real notes never come in one tidy format. The "when the user gives you shorthand notes" sentence tells Claude to expect that mess and not push back asking for cleaner input.

Style rules expanded with reasons. The minimal version said "past tense, passive voice." The full version adds the choices a manuscript reviewer actually notices:

• Make implicit details explicit ("BH" → "Benjamini–Hochberg procedure"). Skills authors often forget that journal Methods sections require expanded jargon.
• Expand abbreviations on first use (DEG, FDR, PCA, GSEA). Standard manuscript convention.
• No editorialising / no praise / no "we believe". The most common AI-tone failure mode. Methods sections are dry on purpose.
• No bullet points in output. The Skill body uses bullets to give Claude rules, but the rule itself says: do not output bullets. Flowing prose only.

Anti-hallucination as its own section, marked "load-bearing". This is the single most important rule. Methods sections that invent a software version or a sample size cause real harm. The [Missing: ...] convention is the lever that turns a likely failure ("model makes up a number") into a visible flag ("model tells you it didn't know"). Pulling it into its own section emphasises the priority.

Multi-paragraph form. Real projects have several sub-analyses. The explicit ### <subheading> rule gives Claude a predictable shape to use, so the output is drop-in for a manuscript skeleton rather than one giant paragraph.

Output format. The "Return ONLY..." section prevents the most annoying AI quirk: pre-amble like "Here is your Methods section based on your notes:" or post-amble like "Let me know if you'd like me to adjust the tone." Skills are most useful when their output is paste-ready.

Installation

Create the folder and paste the file in:

mkdir -p ~/.claude/skills/methods-drafter
# Open ~/.claude/skills/methods-drafter/SKILL.md in your editor
# and paste the Skill block above. Save.

How to use it

Open Claude Code in any terminal:

claude

Then paste your request, with the shorthand notes inline:

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)

Notice what you did NOT do. You did not call any tool. You did not type /use methods-drafter. You did not add a --use-skill flag. You wrote a plain-English request.

Here is what happened under the hood. Claude Code's planner reads your prompt, compares it semantically against the description: line of every Skill in ~/.claude/skills/, and silently loads any that match. The Skill description says "Use when the user asks to draft a Methods section from shorthand notes"; your prompt says "draft the Methods section from these notes." That is a clean semantic match, so the Skill body loads as additional guidance for the session. It's the same outcome as if you had pasted those rules in by hand, except now you don't have to.

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

Verifying the Skill loaded. Inside the Claude Code session, run:

/skills

methods-drafter should appear in the list of active Skills for the session. If it does not, the most likely cause is that the description in the YAML frontmatter does not match the wording of your prompt closely enough. Tighten the description, or use the trigger phrase ("draft the Methods section", "write up the methods") explicitly in your prompt.

Verifying the Skill is working. Compare two responses: one in a session where the Skill is loaded, one in a new session where it is not. The Skill-loaded response should be in past tense, passive voice, with every parameter you mentioned, and any missing details flagged in a [Missing: ...] line at the bottom. The default response will be looser, may add commentary, and may invent values.

Worked example 1: bulk RNA-seq DEG analysis

You paste in Claude Code:

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)

Draft the Methods section for this.

You get back (wording will vary; this is one realistic draft):

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.

Every parameter you wrote down is there, in the right tense and voice. Two minutes of work that used to be an afternoon.

Worked example 2: scRNA-seq with deliberate gaps

These notes deliberately leave out several details a real Methods section would need: the reference genome / transcriptome version, the Chromium chemistry, cell- and gene-level QC thresholds, the normalisation method (LogNormalize vs SCTransform), and any batch correction or integration strategy. The Skill should produce a clean paragraph for what is there, and a [Missing: ...] line for what isn't.

You paste in Claude Code:

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.

You get back (a 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.

Worked example 3: multi-step project

A real bioinformatics project rarely has a single Methods paragraph. Most analyses have several distinct sub-steps (alignment and quantification, differential expression, pathway enrichment, etc.), and the Methods section in a manuscript has a subsection for each. The Skill's multi-paragraph rule handles this directly: give it all the sub-analysis notes in one paste, and get back named subsections you can drop straight into the manuscript.

You paste in Claude Code, a stack of sub-analyses:

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

You get back three named subsections, each a clean Methods paragraph:

### Alignment and quantification

Sequencing reads were aligned to the human reference genome (GRCh38) using
STAR (v2.7.11) with the GENCODE v45 transcript annotation. Gene-level read
expression was quantified with RSEM (v1.3.3).

[Missing: STAR alignment parameters; RSEM strandedness setting.]

### Differential expression

Differential expression analysis was performed using DESeq2 (v1.42).
Sequencing batch was included as a covariate. Three samples identified as
outliers were excluded. Significance was assessed at a false discovery rate
of 0.05 using the Benjamini–Hochberg procedure.

[Missing: design formula; sample size and condition structure; outlier
detection criterion.]

### Pathway enrichment

Gene set enrichment analysis (GSEA) was performed using clusterProfiler
(v4.10), with the MSigDB Hallmark gene sets (v2023.2.Hs). Significance was
assessed using 10,000 permutations and an adjusted p-value threshold of 0.05.

Each subsection is paste-ready for a manuscript skeleton. Same input shape, same output shape, scalable to any number of sub-analyses.

Quick reference

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.

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. Nature, Cell, and Genome Biology all have idiosyncratic Methods conventions. Customise the SKILL.md body for your target journal once you know it.
• 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 via the API, paste the SKILL.md body into a system prompt. That works equivalently. See the companion notebook.

What to try next

• Add a polish pass. A second prompt that tightens redundancy. We'll cover the two-pass pattern in a later note.
• Per-journal variants. ~/.claude/skills/methods-drafter-nature/SKILL.md, ~/.claude/skills/methods-drafter-cell/SKILL.md. Claude picks based on the description.
• Combine with a DEG-reviewer Skill. The next note in this series teaches Claude to review analysis code; this one teaches it to write up the result. Together they cover the boring half of every paper.

Companion notebook

On GitHub: tensoromics/notes: the runnable companion. It writes the same SKILL.md you'd drop into ~/.claude/skills/, then verifies the rules via the Anthropic API across three worked examples. Clone the repo, or view on nbviewer to render without cloning.

Cost

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