Get Updates
Advanced Tier - Article 2 of 5

Creating Skills: Reusable Workflows for Research

Skills are recipe cards for research tasks. Write the steps once, save them in a file, and Claude Code follows those instructions whenever needed.

This article builds on: Spawning Agents: When to Delegate, which covers separate context windows and the Task tool.

Some tasks appear in our research workflow over and over. Documenting variables with consistent metadata. Running robustness checks across specifications. Preparing replication packages before submission. Each time, we explain the same steps, apply the same standards, and verify the same criteria. The repetition adds up.

Skills solve this problem. Think of a skill as a recipe card for a research task. We write down the steps once, save the instructions in a file, and Claude Code follows those instructions whenever we need that task done. No re-explaining, no improvising from scratch.

This article covers what skills look like, how to create our first one, and patterns that make them effective. By the end, we will have a clear path to building a personal library of saved research workflows.

1. What Are Skills?

A skill is simply saved instructions that tell Claude Code how to perform a specific task. We write these instructions in plain English and save them in a text file. Think of skills as lab protocols: purpose, inputs, steps, and success criteria, all written down so the same process runs consistently every time.

When we run /robustness-check, Claude Code does not guess at our specification preferences. It reads the robustness-check skill file, follows the documented workflow, and produces output matching our established patterns. The skill encodes our decisions so we make them once, not every session.

Skills differ from one-off prompting in a key way: they are persistent. A well-designed skill captures methodological knowledge that survives context resets. We develop the workflow once, refine it based on real use, and then deploy it indefinitely.

Common research skills include:

  • /lit-search - Systematic paper gathering and organization
  • /data-doc - Variable documentation with standardized metadata
  • /robustness-check - Running standard robustness specifications
  • /citation-verify - Verifying citations exist and match sources

These are not magic commands built into Claude Code. They are text files we create and maintain. Anyone can create skills for their own research workflows. No programming knowledge required. For how these fit into the broader picture, see Building Our Research System.

2. Where Skills Live: Project vs. Global

Before diving into skill files, we need to understand an important distinction: project-local skills live in a specific research project, while global skills apply across all our work. This distinction matters because different skills belong in different places.

Project-Local Skills

These live inside a specific research project folder:

research-project/
├── .claude/
│   └── skills/
│       ├── balance-table.md      # Specific to this project's data
│       ├── main-regression.md    # This project's specification
│       └── sensitivity-check.md  # Tests for this identification strategy
├── code/
├── data/
└── ...

Project-local skills encode workflows specific to one research project. A balance table skill for a minimum wage study uses different variables than one for a SNAP analysis. A sensitivity check for a DiD design differs from one for an RDD. These skills should stay with the project they serve.

When to use project-local: When the workflow depends on project-specific details like variable names, data structure, identification strategy, or sample definitions.

Global Skills

These live in our home folder and apply everywhere:

~/.claude/skills/
├── lit-review.md         # Same process for any topic
├── citation-verify.md    # Same checks for any paper
├── reg-table.md          # Same formatting standards
└── style-pass.md         # Same writing guidelines

Global skills encode workflows that do not depend on project specifics. Literature review follows the same process whether we are studying minimum wages or food security. Citation verification applies the same checks regardless of topic. These skills should be global so we write them once and use them everywhere.

When to use global: When the workflow is the same regardless of project. General research practices, writing standards, and verification procedures typically belong here.

How Claude Code Finds Skills

When we run /robustness-check, Claude Code searches in this order:

  1. Current project's .claude/skills/ folder
  2. Global ~/.claude/skills/ folder

This means project-local skills override global ones with the same name. We can have a global robustness-check.md with general guidelines and a project-specific version that adds tests relevant to our current identification strategy.

The naming is straightforward: a skill we run as /robustness-check lives in a file called robustness-check.md.

A basic skill file needs three sections:

  1. Purpose - What does this skill accomplish?
  2. Workflow - The ordered sequence of steps
  3. Outputs - What does successful completion look like?

Optional but valuable additions include:

  • Prerequisites - What must be true before running?
  • Triggers - Phrases that should activate this skill
  • Parameters - Options that customize behavior
  • Examples - Sample uses and results

3. Inside a Skill File

Let's look at what a skill actually contains. Here is a simplified /data-doc skill:

# Data Documentation Skill

## Purpose

Create standardized variable documentation that follows our project conventions.
Documentation includes variable names, descriptions, units, sources, and
transformations applied.

## Prerequisites

- Dataset exists in the data directory
- Variable list or codebook is available

## Workflow

1. **Load dataset:** Read the data file to extract variable names
2. **Check existing docs:** Look for any existing documentation
3. **For each variable:**
   - Record original name and cleaned name
   - Document unit of measurement
   - Note source and collection method
   - List any transformations applied
4. **Format output:** Generate markdown table with standardized columns
5. **Present for review:** Show the documentation before saving
6. **Save to data folder:** Write to `data/documentation/` directory
7. **Verify:** Confirm all variables are documented

## Documentation Format

| Variable | Description | Unit | Source | Transformations |
|----------|-------------|------|--------|-----------------|
| ln_wage | Log hourly wage | log(USD) | CPS 2022 | Winsorized at 1/99 |

## Success Criteria

- All variables documented
- No missing descriptions
- Sources verified
- Transformations recorded

Notice the structure: purpose establishes what we are doing, prerequisites define starting conditions, workflow provides ordered steps, and success criteria tell us when we are done.

The workflow section deserves special attention. Each step is explicit and verifiable. "Load dataset" specifies reading the data file. "Present for review" creates a checkpoint where we confirm before proceeding. These details matter because Claude Code will follow them literally.

This is just a text file with some headers and bullet points. We are writing instructions in plain English, the same way we might write a research protocol or lab procedure.

4. Creating Our First Skill

The best first skill encodes something we already do manually. Identifying a repeated workflow is the starting point. What task do we explain to Claude Code at least once a week? What process has steps we sometimes forget?

Here is a practical approach:

Step 1: Document what we actually do

Before writing the skill, spend one session doing the task manually while noting every step. Not the idealized version, the real one. If we always check sample sizes before running regressions, that goes in. If we sometimes forget to cluster standard errors and regret it, that goes in too.

Step 2: Write the instructions

Take those notes and organize them into the skill format:

# Robustness Check Skill

## Purpose

Run standard robustness checks on regression specifications.
Apply our preferred sensitivity tests and document results.

## Prerequisites

- Main specification estimated and saved
- Estimation data loaded in memory
- Outcome and treatment variables defined

## Workflow

1. **Load main results:** Read the baseline specification
2. **Alternative controls:** Re-estimate adding/dropping control sets
3. **Alternative samples:** Re-estimate on subsamples
4. **Alternative clustering:** Re-estimate with different clustering levels
5. **Alternative functional forms:** Test log vs. level specifications
6. **Compile results:** Create comparison table across specifications
7. **Flag discrepancies:** Highlight coefficients that change sign or significance
8. **Generate summary:** Present findings with interpretation

## Success Criteria

- All standard robustness tests completed
- Results compiled in comparison table
- Any concerning changes flagged
- Summary interpretation provided

Step 3: Save the file

Save this as robustness-check.md in the .claude/skills/ folder within the project. That's it. The skill is ready to use.

Step 4: Test with real tasks

Run the skill on actual research. Does it catch what it should? Does it miss things? Does the workflow order make sense?

Step 5: Refine based on results

Skills improve through use. If we find ourselves always needing to add a test, add it to the skill. If a check produces irrelevant output, refine the criteria. The skill should get better each time we use it.

5. Running Skills

Running a skill is straightforward. We just type the skill name with a forward slash:

/robustness-check

That's the most common pattern. Claude Code looks up the skill file and follows the instructions.

Adding options lets us customize behavior:

/lit-review --database scopus
/robustness-check --cluster state
/reg-table 3

Options pass through to the skill workflow, which can reference them in its steps. A literature review skill might search different databases depending on the option.

Automatic triggers can activate skills when we use certain phrases. A skill file might specify:

## Triggers

- "run robustness checks"
- "check the specification"
- "sensitivity analysis"
- before any results marked as final

When we say "run robustness checks," Claude Code recognizes this matches a skill trigger and runs the skill automatically.

Skill chaining connects skills in sequence. A pre-submission workflow might run citation verification, then robustness checks, then replication package preparation:

/pre-submission

Where the pre-submission skill internally runs:

## Workflow

1. Run `/citation-verify` on the manuscript
2. Run `/robustness-check` for main specifications
3. If both pass, run `/replication-package` to prepare materials

Discovering available skills is easy. Asking "what skills are available?" prompts Claude Code to list the skills folder contents with their purposes.

6. Example Skills

Let's look at several skills to build intuition for effective patterns.

The Literature Search Skill

# Literature Search Skill

## Purpose

Systematically gather papers on a specified topic. Ensures consistent
search process and organized materials for the researcher to review.

## Prerequisites

- Research topic or question defined
- Access to academic databases available
- Citation manager file exists or will be created

## Workflow

1. **Define scope:** Confirm topic, time range, and inclusion criteria
2. **Search databases:** Query Google Scholar, SSRN, NBER, RePEc
3. **Screen titles:** Filter by relevance to research question
4. **Read abstracts:** Further filter to candidate papers
5. **Extract bibliographic information:**
   - Authors, year, journal
   - Data source mentioned
   - Methodology used
   - Sample size if stated
6. **Generate citation map:** Show which papers cite which
7. **Organize by search term:** Group papers by how they were found
8. **Present materials:** List papers with extracted fields for review

## Success Criteria

- All specified databases searched
- Papers organized with consistent metadata
- Citation relationships mapped
- Materials ready for researcher to read and interpret

This skill solves the consistency problem in literature searches. Instead of hoping we remember all search sources, the skill makes systematic searching part of the workflow. The researcher still reads the papers and writes the synthesis.

The Regression Table Skill

# Regression Table Skill

## Purpose

Format regression results into publication-ready tables following
journal conventions and our house style.

## Parameters

- `table_number`: Which table to format
- `--format`: Output format (latex, markdown, html)
- `--journal`: Style guide to follow (aer, qje, restud)

## Workflow

1. **Load estimates:** Read regression output files
2. **Extract coefficients:** Pull point estimates and standard errors
3. **Apply formatting:**
   - Round to appropriate decimals
   - Add significance stars (*, **, ***)
   - Format standard errors in parentheses
4. **Add statistics:** Include N, R-squared, fixed effects indicators
5. **Generate table:** Create formatted output
6. **Add notes:** Include significance levels, clustering, sample info
7. **Review alignment:** Check column alignment and spacing
8. **Output file:** Save to tables directory

## Formatting Standards

- Three decimal places for coefficients
- Standard errors in parentheses below coefficients
- Stars: * p<0.10, ** p<0.05, *** p<0.01
- Fixed effects marked with "Yes" or "No"

The Citation Verification Skill

# Citation Verification Skill

## Purpose

Verify citations in research writing before submission.
Catch incorrect years, misspelled author names, and phantom citations.

## Prerequisites

- Manuscript with citations exists
- Citations follow consistent format
- Access to academic databases for verification

## Workflow

1. **Extract citations:** Find all referenced sources in text
2. **Verify each citation:**
   - Search for paper in Google Scholar or database
   - Confirm author names match exactly
   - Verify publication year
   - Check journal name and volume
3. **Flag issues:** Report citations that cannot be verified
4. **Check quotes:** For direct quotes, verify page numbers
5. **Cross-reference bibliography:** Ensure all citations appear in references
6. **Check for orphans:** Flag bibliography entries not cited in text
7. **Summarize:** Present verification results

## Critical Rule

Never assume AI-generated citations are correct. Verify independently
using academic databases.

7. Skill Design Patterns

Effective skills share several characteristics. Understanding these patterns helps us create skills that work reliably.

Single purpose. Each skill should do one thing well. A skill that reviews literature and runs regressions and formats tables is three skills pretending to be one. When a skill grows beyond its original scope, split it.

Verification steps. Good skills include checks that confirm success. The data documentation skill confirms all variables are covered. The robustness check skill flags concerning changes. Verification catches cases where steps appeared to work but did not.

Clear success criteria. How do we know the skill succeeded? Define this explicitly. "All variables documented" is clear. "Documentation is complete" is not.

Documented prerequisites. What must be true before the skill runs? If the robustness skill needs a baseline specification, say so. If the literature review skill expects a defined topic, document that. Prerequisites prevent wasted runs.

Flexible options. Skills often need to handle variations. Rather than creating robustness-ols, robustness-iv, and robustness-did as separate skills, create one robustness skill that accepts an estimator option.

Checkpoint confirmations. For skills that make changes, include confirmation points before executing. "Here's the commit message. Proceed?" gives us a chance to adjust before the action is irreversible.

Error handling. What happens if a step fails? Good skills specify what to do: stop and report, skip and continue, or retry with different parameters.

Building Our Skills Library

The exercises below move from identification through implementation:

Exercise 1: Audit repeated work. Over the next week, keep a log of tasks we explain to Claude Code repeatedly. Note the steps, the preferences we specify, and the verification we do. This log becomes our candidate skill list.

Exercise 2: Create the first skill. Choose the most frequently repeated task from our log. Write the skill file following the structure in Section 3. Start simple; we can add complexity later.

Exercise 3: Test and iterate. Use the skill on three real tasks. After each use, note what worked and what did not. Update the skill file based on observations.

Exercise 4: Add options. Once the basic skill works, identify variations. Add options that handle different cases without creating duplicate skills.

Exercise 5: Build the library. Create a second and third skill. Look for opportunities where one skill might invoke another. Begin thinking about our skills as a system rather than isolated tools.

Skills Improve Through Use

A skill is never finished on the first draft. Like any research tool, skills improve through iteration.

The first version of a skill captures what we think the workflow should be. After running it three or four times on real tasks, we discover gaps. The literature review skill needed a step for checking citation counts. The robustness check skill should flag coefficient sign changes, not just significance changes. The data documentation skill works better when it shows existing documentation first.

This is normal and expected. Write the skill, use it, refine it based on what we learn. The investment pays off because refinements persist. Fix a gap once, and every future invocation benefits.

Some practical habits:

  • After each use, note one thing to improve. Did the skill miss something? Was a step unclear? Add a bullet point to a "refinements needed" list.
  • Batch refinements periodically. Every few weeks, review the refinement notes and update the skill files. Small changes accumulate into significant improvements.
  • Version control skills. Keep skill files in git. Track what changed and why. This is methodology documentation; it deserves the same rigor as analysis code.

The goal is not a perfect skill from day one. The goal is a skill that improves with every use, eventually encoding our actual workflow rather than an idealized version of it.

What Comes Next

Skills encode workflows we choose to run. But some automation should happen without our asking: data validation before analysis, documentation when datasets change, verification when results are flagged as final. Article A3: Hooks covers automation that triggers automatically, adding another layer to our personal AI infrastructure.

Suggested Citation

Cholette, V. (2026, March 4). Creating skills: Reusable workflows for research. Too Early To Say. https://tooearlytosay.com/research/methodology/creating-skills/
Copy citation