Improve the Claude engine for SYCL generation

[mzweilin]

This pull request implements a significant refactor to generalize the concept of the optimized kernel runtime from being Triton-specific (triton_us) to a more flexible, DSL-agnostic field (custom_us). It also improves workspace generation by copying knowledge base directories instead of symlinking, introduces a new local settings file, and updates documentation and templates to reflect these changes.

Generalization of optimized runtime field:

• Replaces all uses of triton_us with a generic custom_us field throughout the codebase, including state management, CLI arguments, result recording, and reporting. This enables support for non-Triton DSLs and improves extensibility. (src/xe_forge/core/trial_manager.py [1] [2] [3] [4] [5]; src/xe_forge/pipeline.py [6]; src/xe_forge/skills/__init__.py [7]; src/xe_forge/skills/benchmark.py [8] [9]; src/xe_forge/skills/trial.py [10]

Workspace and knowledge base improvements:

• Changes the workspace generator to copy both common and DSL/device-specific knowledge base directories into the workspace, instead of creating a symlink. This increases portability and robustness of generated workspaces. (src/xe_forge/claude/generator.py [1] [2] [3] [4]

• Adds generation of a .claude/settings.local.json file with default permissions to the workspace. (src/xe_forge/claude/generator.py [1]; src/xe_forge/claude/templates/settings.local.json.j2 [2]

Documentation and template updates:

• Updates all relevant documentation and markdown/Jinja templates to use custom_us in place of triton_us, and to use the appropriate DSL name in command examples and profiling instructions. (src/xe_forge/claude/templates/CLAUDE.md.j2 [1] [2] [3]; src/xe_forge/claude/templates/tool-runner.md.j2 [4]

• Adds a conditional correctness constraint for Triton kernels in the CLAUDE.md template. (src/xe_forge/claude/templates/CLAUDE.md.j2 src/xe_forge/claude/templates/CLAUDE.md.j2R79-R81)

[sandlbn]

@danielfleischer could you look at it?

[danielfleischer]

Would changing the instructions in Claude.md.j2 from "triton" to SYCL" make Claude write SYCL kernels? are the skills Claude uses in the repo like analyze, benchmark, profile support non-Triton DSLs yet?

[danielfleischer]

Please don't create a settings.local.json for the user. If you want, you can create a settings.json and let the user override it with their own local file. Per the documented scope: https://code.claude.com/docs/en/settings#what-uses-scopes

I wouldn't allow anything; a few prompts and the user set these for themselves, with the understanding what is going on.

[mzweilin]

Good catch! I have changed it to settings.json in de564ae

I think these are all reasonable permissions that will make it easier for users to scale up the experiments.

[danielfleischer]

Ok, I guess these tools are mostly read-only, except the trial manager.

[mzweilin]

The agent also needs to write custom kernels into the workspace.

[danielfleischer]

The trial manager writes files by copying the generated candidates which are temp files into the workspace. The permission needed is to run python.

[mzweilin]

The "temp files" are something like t0.py in the workspace in my runs. The agent still needs the write permission to save to ./workspace/t<iter>.py before the trial manage kicks in.

I am afraid allowing Python is too broad, because an agent can use Python to do anything. That's why I only allow the xe-forge-skill toolset (shall we call them xe-forge-tools instead in the Claude Code context?).

Do you have use cases that Python must be allowed?

[danielfleischer]

I'm against this.

[mzweilin]

I can move the convenient configs to my local ~/.claude/settings.json for my own use if people don't want it in the repo. @sandlbn, what's your thought?

[mzweilin]

@danielfleischer
The tools Claude uses in the repo like analyze, benchmark works on the generated PyTorch-centric SYCL(*TLA) code.

I needed to add more context and examples in e5294ae to let Claude Code generate PyTorch-inline SYCL*TLA code.