uw-ssec/ai-research-workflows
Skills-first research workflows for Research Software Engineers and Researchers: research, plan, experiment, implement, validate, reproduce, harden, and handoff — interactive when you want collaboration, direct when you don't.
Use when work context must transfer to another session or person. Triggers: create a handoff, hand off this work, summarize context for the next session, prepare a handoff.
Use when a result, experiment, or analysis must be reproducible by others or by a future session. Triggers: make this reproducible, capture provenance, pin the environment for this result, why can't I reproduce X.
Use when research or scientific code must be trustworthy — verifiably correct, regression-safe, and numerically stable. Triggers: harden this code, is this numerically correct, add regression tests vs known results, make the research code robust.
Use when an approved implementation plan (a docs/rse/specs/plan-*.md file) exists and the next step is writing the code. Triggers: implement the plan, execute the plan, start building, run the plan.
Use when an existing implementation plan needs changes before or during execution. Triggers: update the plan, change the plan, add a phase, revise scope, incorporate experiment results.
Use when a feature, refactor, or multi-file change needs to be designed before coding. Triggers: plan X, design the implementation, how should we build X, create an implementation plan.
Use when you need to understand how an existing codebase works and/or survey external prior work (papers, methods, tools) before planning or changing something. Traces function call paths, maps module dependencies, searches academic papers and documentation, compares library alternatives. Triggers: research the codebase, how does X work, where is X implemented, what tools or libraries exist for X, prior art on X, has this been done before, survey approaches to X.
Use when the best technical approach is genuinely uncertain and a head-to-head prototype comparison is needed before committing to a design. Triggers: should I use X or Y, compare approaches, benchmark, which is faster or simpler.
Use when starting or continuing ANY research-software task — understanding or modifying code, surveying prior art, planning, experimenting, implementing, validating, reproducing, or hardening — and before reading code to "just check", before editing, or before answering "how does X work". Triggers: research workflow, which skill should I use, where do I start, guide me through the workflow, structured development.
Use when an implementation is (claimed) complete and must be checked against its plan before shipping. Triggers: validate the implementation, verify it matches the plan, is the implementation correct, check before PR.