← ClaudeAtlas

fused-executelisted

Best practices for running code with `fused code run`. Use when writing or reviewing code you will execute through the fused CLI — covers how to structure user code, choose a data library, handle results, write outputs to the file store, pick a project venv, fan out, and what caching `code run` applies. For static scanning, spec checks, and testing see fused-verify. If this is part of building or running a project, load `fused-projects` first for the end-to-end model.
fusedio/skills · ★ 5 · Testing & QA · score 65
Install: claude install-skill fusedio/skills
# Running code via fused > **Part of the Fused skill set — don't work from it alone.** Fused is `workspace ⊃ > project ⊃ UDF`. If the task is part of building or running a project (not a > one-off snippet), load **`fused-projects`** for the end-to-end model. See > **`fused-guide`** for the full set. Code runs through the CLI (there is no MCP `execute_code` tool any more): ```sh fused code run my_udf.py # a file fused code run -c "result = 1 + 1" # inline cat my_udf.py | fused code run # stdin fused code run my_udf.py --input-file ./points.parquet # stage a local file (repeatable) fused code run my_udf.py --entrypoint compute # call a named function fused --env prod code run my_udf.py # pick the environment explicitly ``` Output: the code's stdout, then stderr, any `warning: …` lines, and finally `result: <value>` — or `result (<media_type>, status N):` followed by the body when the code returns a `fused.Response`. Runtime errors (tracebacks) appear on stderr. On AWS, a CloudWatch monitoring snapshot is printed to stderr every `--monitor-interval` seconds (default 10) while the Lambda runs. ## Core principle: code should do one thing The code passed to `code run` should be as focused as possible: - One clear task per execution - No boilerplate, no CLI argument parsing, no `if __name__ == "__main__"` guards - Return the result from a `@fused.udf`-decorated function (preferred), or assign it to a top-level `resu