From a03ca4a4d29d5759ae7248b3a4a1962974a16948 Mon Sep 17 00:00:00 2001 From: jhauga Date: Sat, 16 May 2026 00:54:01 -0400 Subject: [PATCH] new skill multi-lang-coder --- docs/README.skills.md | 1 + skills/multi-lang-coder/SKILL.md | 106 +++++++++++++++++++++++++++++++ 2 files changed, 107 insertions(+) create mode 100644 skills/multi-lang-coder/SKILL.md diff --git a/docs/README.skills.md b/docs/README.skills.md index e9ec5e802..0baf49998 100644 --- a/docs/README.skills.md +++ b/docs/README.skills.md @@ -236,6 +236,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to | [model-recommendation](../skills/model-recommendation/SKILL.md)
`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)
`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`
`references/python.md`
`references/typescript.md` | | [msstore-cli](../skills/msstore-cli/SKILL.md)
`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)
`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)
`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)
`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`
`references/relaycommand-cookbook.md`
`references/source-generators.md`
`references/troubleshooting.md`
`references/validation.md` | | [mvvm-toolkit-di](../skills/mvvm-toolkit-di/SKILL.md)
`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` | diff --git a/skills/multi-lang-coder/SKILL.md b/skills/multi-lang-coder/SKILL.md new file mode 100644 index 000000000..21a353db0 --- /dev/null +++ b/skills/multi-lang-coder/SKILL.md @@ -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`, 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): +- GitHub Linguist (language detection heuristics): +- Benchmarks Game (cross-language performance reference): +- TIOBE Index (language popularity):