init

Set up an automatic PyTorch performance run

step 0: how much MLSys the user knows, so you can talk to them in their language. step 1: the repo, the environment, and the script to optimize. step 2: the instrumentation that keeps the optimization loop correct. step 3: anything else you and the user find worth preparing. step 4: init ends.

Write what you prepare into a contract.md, using the template at <plugin root>/template/contract.md, where the plugin root is the directory two levels above this SKILL.md, which Claude Code also exposes as ${CLAUDE_PLUGIN_ROOT}. It records what you and the user agreed on. The user reads it too, so keep it short.

During init, do not change code logic, do not build a worktree, and do not run experiments unless the user tells you to. They expect init to finish quickly.

The user has very little attention to spare. Say what you need in the most direct and shortest wording you can.

Let the user see which step of init they are standing in.

Step 0: how much MLSys the user knows

Before you ask anything about the job, ask how well the user knows ML systems. Give them two examples to place themselves against:

• "I am an MLSys engineer. I could do these optimizations myself, I would rather not spend the time."
• "I am an algorithm engineer. I do not know systems, and I will not recognise most of your optimization techniques."

Anything in between is fine. Write the answer into the reader line of contract.md, in their words.

Write for that reader for the rest of init, and in every report they read later. An MLSys engineer wants the technique and the number and no explanation. An algorithm engineer wants to hear what the change does to their training, in the words they already use: batches, steps, memory, loss. Explain a systems term the first time it comes up, or leave it out. If you are unsure whether they followed, ask once; do not check after every message.

Step 1: the repo, environment, script, and hardware

• Infer the repo, environment, script, and hardware from context first, then have the user confirm them. The user is the one who guarantees that the script and environment run and that the hardware is free.
• Ask the user for anything you cannot infer, for instance in a fresh session.
• If the checkout is dirty, talk it through with the user. What you decide has to fit the worktree layout used later.
• Once the user hands over the script: if it was written for real training, use the convert-to-benchmark-script skill to turn it into one that suits performance work, and have the user confirm the changes. The run line in the contract names that converted version.