Multiple Language Coder

SKILL.md

---
name: multi-lang-coder
description: '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.'
---

# 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:

| Domain | Strong default | Alternatives |
|--------|----------------|--------------|
| Systems / performance-critical | Rust | C++, Go, Zig |
| Web backend / API | TypeScript (Node) | Go, Python, Java, C#, Ruby |
| Web frontend / UI | TypeScript | JavaScript |
| Data / ML / AI | Python | R, Julia |
| Mobile (native) | Swift (iOS) / Kotlin (Android) | Dart/Flutter, React Native |
| Scripting / automation | Python | Bash (Unix), PowerShell (Windows) |
| Embedded / IoT | C / Rust | C++, MicroPython |
| Enterprise / type-heavy | Java / 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>