Plugin commands¶
The plugin adds five slash commands. Most of the time you won't need them explicitly — the
oryxflow skill activates on its own inside a project — but they're the fast path for the common
setup and maintenance jobs.
Set up and maintain a project¶
/oryxflow:init-project— set up a ready-to-run project structure in an empty directory, so you start writing tasks straight away instead of building the folders, files, and conventions by hand./oryxflow:migrate— restructure an existing ad-hoc analysis (monolithic notebooks, linear scripts, hardcoded paths) into a cached, parameterized oryxflow pipeline, one task at a time — so you get reproducibility and caching without a risky big-bang rewrite./oryxflow:init-gitlfs— putdata/under Git LFS, so you version and share your data as easily as your code — teammates clone the repo and get the exact datasets each run produced./oryxflow:update-project— bring an older project up to the current project structure, so you pick up the latest conventions and layout without a manual migration./oryxflow:check-standards— check names, style, and docstrings against the house standards, so the codebase stays consistent and easy for teammates (and the AI) to navigate and extend.
Measure a prompt change¶
Four more commands, in the separate oryxeval plugin, turn "is this prompt better?" into a number you can defend. They are one
pipeline, in this order — each reads what the one before it wrote, and you can stop after any
of them and pick up later:
/oryxeval:eval-plan— step 1 of 4. Decide what the eval measures before any code exists: what counts as better, what must not get worse, what you're comparing against, and which cases. Writes the plan, spends nothing./oryxeval:eval-init— step 2 of 4. Scaffold the eval from that plan intoevals/<name>/, so you fill in judgement calls instead of boilerplate. Ends in a three-call smoke run that proves the wiring without a bill./oryxeval:eval-cases— step 3 of 4. Grow the three placeholder cases into a real 15-25, harvested from your own material and worked across the axes that matter — so the case set is evidence rather than whatever came to mind first./oryxeval:eval-run— step 4 of 4. Run it and read the verdict: which arm won, whether the gap beats the run-to-run noise, and whether the winner broke the guardrail. The projected bill prints before anything is spent.
These four ship in the separate oryxeval plugin (/plugin install oryxeval@oryxintel), and need
the library (pip install oryxeval). Every cell is cached, so a re-run of an
unchanged arm costs nothing and editing a prompt re-runs only the arms that read it.
Scaffold an LLM eval walks through all four, and documents the files they write.
The migration path most people want¶
If you already have a notebook or script that works, /oryxflow:migrate is the on-ramp. It
converts the analysis into tasks incrementally — each step becomes a cached, parameterized task
with its dependencies wired — so at every point you have a working pipeline, not a half-rewritten
one. The end state is reproducible and lineage-tracked, and the expensive steps stop rerunning on
every edit.
See the companion guide Turn a messy notebook into a reproducible pipeline for what that transformation looks like step by step.
After scaffolding¶
Once the project exists, the skill takes over automatically — it keeps the wiring consistent, verifies your edits actually reran the tasks you expected, and answers staleness warnings the right way. That ongoing discipline is the subject of Trustworthy AI data analysis and Why library + plugin is a matched pair.
The init-project scaffold and the graduated path a growing project follows are covered in
data-science project structure; the naming, code-organization, and
docstring conventions check-standards enforces are in
data-science coding standards.