Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/README.skills.md
Original file line number Diff line number Diff line change
Expand Up @@ -236,6 +236,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
| [model-recommendation](../skills/model-recommendation/SKILL.md)<br />`gh skills install github/awesome-copilot model-recommendation` | Analyze chatmode or prompt files and recommend optimal AI models based on task complexity, required capabilities, and cost-efficiency | None |
| [msgraph-sdk](../skills/msgraph-sdk/SKILL.md)<br />`gh skills install github/awesome-copilot msgraph-sdk` | Integrate Microsoft Graph SDK into any project — .NET, TypeScript/JavaScript, or Python. Covers auth patterns (client credentials, OBO, managed identity), SDK setup, calling Graph APIs, batching, delta queries, change notifications, throttling, and permission scopes. Use when accessing Microsoft 365 data (users, mail, calendar, Teams, files, SharePoint) from any application type. | `references/dotnet.md`<br />`references/python.md`<br />`references/typescript.md` |
| [msstore-cli](../skills/msstore-cli/SKILL.md)<br />`gh skills install github/awesome-copilot msstore-cli` | Microsoft Store Developer CLI (msstore) for publishing Windows applications to the Microsoft Store. Use when asked to configure Store credentials, list Store apps, check submission status, publish submissions, manage package flights, set up CI/CD for Store publishing, or integrate with Partner Center. Supports Windows App SDK/WinUI, UWP, .NET MAUI, Flutter, Electron, React Native, and PWA applications. | None |
| [multi-lang-coder](../skills/multi-lang-coder/SKILL.md)<br />`gh skills install github/awesome-copilot multi-lang-coder` | 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. | None |
| [multi-stage-dockerfile](../skills/multi-stage-dockerfile/SKILL.md)<br />`gh skills install github/awesome-copilot multi-stage-dockerfile` | Create optimized multi-stage Dockerfiles for any language or framework | None |
| [mvvm-toolkit](../skills/mvvm-toolkit/SKILL.md)<br />`gh skills install github/awesome-copilot mvvm-toolkit` | CommunityToolkit.Mvvm (the MVVM Toolkit) core: source generators ([ObservableProperty], [RelayCommand], [NotifyPropertyChangedFor], [NotifyCanExecuteChangedFor], [NotifyDataErrorInfo]), base classes (ObservableObject / ObservableValidator / ObservableRecipient), commands (RelayCommand / AsyncRelayCommand), and validation. Companion skills: mvvm-toolkit-messenger for pub/sub, mvvm-toolkit-di for Microsoft.Extensions.DependencyInjection wiring. Works across WPF, WinUI 3, MAUI, Uno, and Avalonia. | `references/end-to-end-walkthrough.md`<br />`references/relaycommand-cookbook.md`<br />`references/source-generators.md`<br />`references/troubleshooting.md`<br />`references/validation.md` |
| [mvvm-toolkit-di](../skills/mvvm-toolkit-di/SKILL.md)<br />`gh skills install github/awesome-copilot mvvm-toolkit-di` | Wire CommunityToolkit.Mvvm ViewModels into Microsoft.Extensions.DependencyInjection. Covers the .NET Generic Host composition root, constructor injection, service lifetimes (Singleton / Transient / Scoped), IMessenger registration, resolving ViewModels in Views, keyed services, testing seams, and the legacy Ioc.Default escape hatch. Use across WPF, WinUI 3, .NET MAUI, Uno, and Avalonia. | `references/dependency-injection.md` |
Expand Down
106 changes: 106 additions & 0 deletions skills/multi-lang-coder/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
---
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>
Loading