xuzhougeng/analysis-workflow
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.
npx skills add https://github.com/xuzhougeng/wisp-science --skill analysis-workflow
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.
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.
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 thecanonical 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.
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:
figure-style;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.
Record direct dependencies used by the module:
packageVersion("<package>") for named packages and sessionInfo() forthe runtime context.
importlib.metadata.version("<distribution>"); use the project lockfile when it is the authoritative environment record.
date plus endpoint/source.
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.
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.
Take xuzhougeng/analysis-workflow from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.