Analysis Workflow Agent Skill

Organize multi-step scientific analyses into reproducible, self-contained modules. Use for workflows such as QC→PCA→DEG→GSEA that produce scripts, inputs, figures, tables, and methods. Creates a stable module layout, records exact inputs/parameters/package and database versions in each module README, keeps large data as references instead of copies, and verifies outputs before completion.

1k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

859

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/xuzhougeng/wisp-science --skill analysis-workflow

The instruction itself

7 sections, as written by the author

Reproducible Analysis Modules

Use this skill for a scientific workflow with two or more analysis stages or

when a stage produces scripts plus result files. It defines project

organization and methods capture; load figure-style as well whenever a stage

creates or revises a plot.

1. Plan module boundaries

Before writing outputs, list the modules and the dependency edges between them.

Use stable ASCII names. Conventional acronyms such as QC, PCA, DEG, and

GSEA may stay uppercase; otherwise prefer a short kebab-case name.

Respect a compatible layout that already exists. Do not reorganize unrelated

user files merely to impose this convention.

2. Default module layout

Create only directories the module actually needs:

<module>/
├── scripts/
├── input/
├── output/
│   ├── figures/
│   └── tables/
└── README.md

scripts/ contains the executable source for this module.
input/ contains small module-specific inputs or a manifest/reference to the

canonical data. Do not duplicate a large dataset by default.

output/figures/ contains rendered figures from this module only.
output/tables/ contains machine-readable results from this module only.
README.md is the module's reproducibility record and methods source.

Shared immutable/raw data may live in project-level data/. A downstream module

references an upstream output by a project-relative path; it does not silently

copy or rename that output.

3. Make outputs attributable

Every output must have one producing script or recorded command. Use

deterministic filenames that identify the analysis and content. Keep temporary

files outside the final output directories or name them clearly as temporary.

Before completing a module, verify:

every declared output exists and is non-empty;
every table can be parsed in its declared format;
every figure was rendered and visually inspected using figure-style;
README input and output paths resolve from the project root;
reported thresholds and parameters match the actual script.

4. Update README.md at module completion

Create or update these sections:

# <Module>

## Purpose
<scientific question and role in the workflow>

## Inputs
- `<project-relative path>` — source, upstream module, checksum or version when available

## Methods
<method in prose, including transformations, statistical tests, correction method,
thresholds, seeds, and other result-changing parameters>

## Software and data sources
- R/Python package: exact version
- External API/database: release or access date
- Wisp/model/runtime metadata: exact recorded value when available

## Commands and scripts
- `<project-relative script>` — how it was executed

## Outputs
- `<project-relative path>` — meaning and format

## Limitations
<assumptions, exclusions, and unresolved reproducibility gaps>

Write methods from executed code and recorded parameters, not from a generic

template. Do not claim a package, database, model, OS, or version that was not

actually used or observed.

5. Capture exact versions without dumping the world

Record direct dependencies used by the module:

R: packageVersion("<package>") for named packages and sessionInfo() for

the runtime context.

Python: importlib.metadata.version("<distribution>"); use the project lock

file when it is the authoritative environment record.

External databases/APIs: release identifier when available, otherwise access

date plus endpoint/source.

Wisp version and model profile: use runtime/session metadata only when it is

available. Write unavailable rather than guessing.

Do not paste an entire global pip freeze into every module. If a complete

environment export is useful, save it once as a separate artifact and link it

from the README.

6. Finish the workflow

After all modules pass their checks, summarize the dependency chain and link the

module READMEs. Treat those READMEs as the first-version source of truth.

Generate a root METHODS.md only when the user asks for it or a deterministic

project tool can derive it from the module records; do not maintain a second

hand-edited copy that can drift.

Other skills for the same job

different authors, same section of the catalogue

Mobile Design

by ComeOnOliver

×2

Mobile-first design and engineering doctrine for iOS and Android apps. Covers touch interaction, performance, platform conventions, offline behavior, and mobile-specific decision-making. Teaches principles and constraints, not fixed layouts. Use for React Native, Flutter, or native mobile apps.

Design experiments and studies BEFORE data is collected — choosing a design, randomizing, blocking, and laying out treatment combinations so results are interpretable. Use whenever someone is planning a study, asks how to assign subjects/samples to groups, mentions randomization, blocking, stratification, controls, factorial or fractional-factorial designs, design of experiments (DOE), screening many factors, response-surface optimization, crossover or repeated-measures or split-plot designs, cluster/group randomization, Latin squares, plate layouts, batch/run-order effects, replication vs. pseudoreplication, or sequential/adaptive/group-sequential designs. Trigger even for informal phrasings like "how should I set up this experiment", "how do I avoid confounding", "what's the best way to test these 6 factors", or "assign these mice to conditions". For computing the sample size or power once the design is chosen, use statistical-power; for analyzing data already collected, use statistical-analysis.

Design systems, plan implementations, review architecture decisions - Use when you need to plan a complex feature, design system architecture, or make high-level technical decisions.

2k tokens

Analyze Feature Requests

by phuryn

Analyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk. Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions.

>- Plans, configures, and manages core GKE cluster networking. Covers private clusters, VPC-native configurations, DNS, node egress, Dataplane V2, and IP planning. Use when designing GKE networking layouts, configuring private clusters, setting up Dataplane V2, planning GKE IP ranges, or managing VPC- native cluster modes. Don't use for application ingress, load balancing, or service networking (use gke-service-networking instead).

Read this before adding or importing a component; follow the workflow instead of guessing. Explains how to add a new component to an azldev distro, covering inspecting the upstream spec, the inline-versus-dedicated-file decision, and validating with render, diff-sources, and build. Triggers include add component, new package, import package, create comp.toml, new component.

998 tokens

Open Knowledge Pack Plain Notes

by inkeep

How to work in a Plain Notes project (the `plain-notes` starter pack): a flat notes/ folder plus a daily/ journal. The 'I just want to write' layout. Read when the project has these folders, OR when asked to jot a note, capture a quick thought, or write today's journal entry. Carries the linking habit and daily-entry behavior so templates and folder descriptions stay minimal. Complements the platform `open-knowledge` skill; does not replace it.

498 tokens

Open Knowledge Pack Worldbuilding

by inkeep

How to work in a Worldbuilding project (the `worldbuilding` starter pack): a fiction encyclopedia of characters, settings, themes, factions, and lore. Read when the project has these folders, OR when asked to add a character, setting, faction, or piece of lore, or to check the world for internal consistency. Carries the auto-stub and consistency behaviors so that guidance does not live inside template bodies or folder descriptions. Complements the platform `open-knowledge` skill; does not replace it.

758 tokens

How to use it

Copy the folder

Take xuzhougeng/analysis-workflow from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.