ClawHub

Multiple Language Coder

Other

Polyglot code converter and language architect. Use when input contains mixed, ambiguous, pseudo, or multi-language code fragments (Python+JS syntax blends, SQL embedded in shell, natural-language specs with code snippets, cross-stack pipelines) that must be converted into clean, idiomatic, production-ready code in the appropriate target language. Also use when starting a new project with no language chosen yet — selects the best language(s) based on domain (systems, web backend, frontend, data/ML, mobile, scripting, embedded, enterprise) and explains the choice. Keywords: convert code, translate language, mixed syntax, pseudocode, polyglot, language selection, port code, rewrite in.

Install

openclaw skills install multi-lang-coder

Multi-Language Code Converter and Language Architect

Convert mixed, pseudo, or multi-language input into idiomatic production code, and select the right language(s) when none is dictated by the project.

When to Use This Skill

  • Input mixes syntax from multiple languages (e.g., def and function in the same block, this. next to self., semicolons mixed with indentation-based blocks)
  • Input is pseudocode or natural language describing behavior plus code fragments
  • User asks to "convert", "port", "translate", or "rewrite" code into another language
  • A new project is starting with no language chosen and the user wants a recommendation
  • A specification mixes config (YAML/TOML), SQL, and procedural logic that must be split into the right files

Operating Phases

Work through these phases in order. Skip a phase only when its premise does not apply (e.g., skip Phase 2 if a target language is already obvious from the project or user).

Phase 1 — Detect Existing Context

Before choosing a language, scan for signals in this priority order:

  1. Explicit user instruction — Always wins. If the user says "in Rust", produce Rust.
  2. Project manifests — package.json, pyproject.toml / requirements.txt, Cargo.toml, go.mod, *.csproj, pom.xml / build.gradle, Gemfile, composer.json, tsconfig.json. The first one found generally dictates the target.
  3. Source file extensions — Dominant extension in the workspace (.ts, .py, .rs, .go, .java, .cs, .rb, .cpp, .kt, .swift).
  4. Open editor / active file — Match the language of the file the user is editing.
  5. Nothing found — Proceed to Phase 2.

Phase 2 — Select Language (New Projects Only)

Run this only when Phase 1 yields no target. Map the goal to a domain, then pick the best fit:

DomainStrong defaultAlternatives
Systems / performance-criticalRustC++, Go, Zig
Web backend / APITypeScript (Node)Go, Python, Java, C#, Ruby
Web frontend / UITypeScriptJavaScript
Data / ML / AIPythonR, Julia
Mobile (native)Swift (iOS) / Kotlin (Android)Dart/Flutter, React Native
Scripting / automationPythonBash (Unix), PowerShell (Windows)
Embedded / IoTC / RustC++, MicroPython
Enterprise / type-heavyJava / C#TypeScript, Kotlin

Decide single vs. polyglot:

  • Frontend + backend → always two languages (TS frontend + backend of choice).
  • Data pipeline + API → Python for data, Go/Node for API is a reasonable split.
  • Otherwise prefer a single language — every additional language costs maintenance.

State the choice briefly (2–3 sentences per language) before writing code. Include one tradeoff the user should know.

Phase 3 — Parse the Mixed Input

For each fragment in the input:

  1. Classify — Which language(s) does the syntax most resemble? Tag fragments (Python-like, JS-like, SQL, shell, config, prose intent).
  2. Extract intent — What is this fragment trying to do? What flows in/out? What are the side effects?
  3. Flag ambiguities — If intent is genuinely unclear, list assumptions explicitly. If an assumption materially changes the output, ask before generating.
  4. Map — For each fragment, identify the idiomatic equivalent in the target language.

Phase 4 — Generate Code

  • Use idiomatic syntax, formatting, and conventions for the target (PEP 8 for Python, rustfmt for Rust, gofmt for Go, Airbnb/standard for JS/TS, etc.).
  • Apply the language's native error-handling pattern (exceptions, Result, error returns, promises). Do not port one language's pattern into another.
  • Add types/type hints where the language supports or requires them.
  • Produce runnable units (correct imports, package declarations, module headers) unless the input is clearly a snippet.
  • If the input implies multiple files/modules, emit each as a separate labeled block.
  • List required dependencies with install commands (pip install …, npm install …, cargo add …).

Phase 5 — Respond in This Format

  1. Language decision (only if Phase 2 ran) — one short paragraph.
  2. Conversion notes — bullets covering: ambiguities, assumptions made, fragments that were restructured and why.
  3. Generated code — one labeled code block per file/module.
  4. Dependencies — install commands.
  5. Next steps (optional) — only if the input was a partial spec.

Gotchas

  • Never silently drop input logic. If a fragment cannot be cleanly converted (e.g., Python's GIL-dependent threading patterns into JS), call it out in conversion notes and propose an equivalent — do not omit it.
  • Never leave mixed syntax in output. If the output still contains def and function together, this and self together, or print and console.log together, the conversion has failed. Re-check before responding.
  • Do not auto-convert config/data files (JSON, YAML, TOML, XML). Treat them as context unless the user explicitly asks for conversion.
  • Error-handling idioms are not portable. Rewriting Python try/except as Go try/catch produces non-compiling code. Translate to the target's native pattern (if err != nil, Result<T,E>, etc.).
  • Indentation vs. braces. When converting from Python to a brace language (or vice versa), re-derive block structure from intent, not from the original whitespace — Python whitespace inside JS will silently change semantics.
  • Don't invent dependencies. If the input uses requests, the TS equivalent is fetch/axios — pick one and justify it; do not fabricate package names.
  • Honor explicit user language choice above all heuristics. Even if the project is Python, if the user says "give me this in Rust", produce Rust and note the mismatch.
  • Prefer one language over polyglot unless justified. Splitting a small script into "Python for data + Node for API" is overkill — state the tradeoff and recommend the simpler path.
  • Already-valid code in the right language ≠ conversion task. If the input is already clean code in the project's language, say so and offer style/quality improvements instead of rewriting it.

Mini Examples of Mixed Input This Skill Handles

  • Python import and if response.status_code == 200: inside a JS function () { … } wrapper with console.log — convert wholesale to one language.
  • Shell script containing free-form SELECT * FROM users and loop through rows prose — split into a real shell driver plus a real SQL file, or fold into one language with a DB client.
  • Class definition mixing def __init__(self), this.users, new ArrayList(), throw new Exception — pick one OO language and produce idiomatic class.
  • Pure natural-language spec ("POST /users, validate email regex, bcrypt cost=12, INSERT …, return 201") — treat as feature spec, generate full handler in target language.
  • YAML config with embedded if ENV == "production" and Math.max(5, cpu_count * 2) — split static config from runtime logic; emit a clean config file plus loader code.

References