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 defaultAlternativesSystems / performance-criticalRustC++, Go, ZigWeb backend / APITypeScript (Node)Go, Python, Java, C#, RubyWeb frontend / UITypeScriptJavaScriptData / ML / AIPythonR, JuliaMobile (native)Swift (iOS) / Kotlin (Android)Dart/Flutter, React NativeScripting / automationPythonBash (Unix), PowerShell (Windows)Embedded / IoTC / RustC++, MicroPythonEnterprise / 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#

• Tree-sitter (multi-language parsing reference): https://tree-sitter.github.io/tree-sitter
• GitHub Linguist (language detection heuristics): https://github.com/github-linguist/linguist
• Benchmarks Game (cross-language performance reference): https://benchmarksgame-team.pages.debian.net/benchmarksgame
• TIOBE Index (language popularity): https://www.tiobe.com/tiobe-index