# Rune Multi Lang

> Generate implementations and tests from a single RUNE spec in multiple programming languages. Use when a user needs the same function in several languages with identical behavior and error messages. Use when this capability is needed.

- Skill: `tomevault-io/rune-multi-lang` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/rune-multi-lang`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/rune-multi-lang/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/rune-multi-lang

---


## How to Use

When given a RUNE spec and a list of target languages, generate an implementation + test file for each language, ensuring all implementations produce identical behavior.

Input: a RUNE spec + list of target languages.
Output: one implementation file + one test file per language.

---

## Language Adaptation

Any programming language is supported. When generating for a target language, adapt:

- **Naming convention** — follow the language's standard (snake_case, camelCase, PascalCase, etc.)
- **Error handling** — use the language's idiomatic mechanism (exceptions, error returns, Result types, pattern matching)
- **Testing framework** — use the language's standard or most common framework
- **Type system** — map types to native equivalents

---

## Process

### Step 1: Analyze the Spec

Read the RUNE spec and extract:
- Function purpose (from INTENT)
- Input/output contract (from SIGNATURE, even if language-specific)
- All behavior rules (from BEHAVIOR)
- All test cases (from TESTS)
- Constraints and edge cases

### Step 2: Adapt Signature Per Language

Convert the SIGNATURE to each target language's syntax and conventions.

**From a spec with:**
```yaml
SIGNATURE: |
  def calculate_discount(price: float, percentage: int) -> float
```

**Generate:**

| Language | Adapted Signature |
|----------|------------------|
| Python | `def calculate_discount(price: float, percentage: int) -> float` |
| TypeScript | `function calculateDiscount(price: number, percentage: number): number` |
| Go | `func CalculateDiscount(price float64, percentage int) (float64, error)` |
| Rust | `fn calculate_discount(price: f64, percentage: i32) -> Result<f64, String>` |
| Java | `public static double calculateDiscount(double price, int percentage)` |

**Adaptation rules:**
- Follow each language's naming convention (snake_case, camelCase, PascalCase)
- Map types to native equivalents (`float` -> `f64`, `number`, `double`)
- Add error return channels where idiomatic (Go returns `error`, Rust returns `Result`)
- Use the language's exception/error mechanism for BEHAVIOR error rules

### Step 3: Adapt Error Handling

Each language handles errors differently. Adapt the BEHAVIOR error rules:

| Spec says | Python | TypeScript | Go | Rust |
|-----------|--------|------------|-----|------|
| `raise ValueError("msg")` | `raise ValueError("msg")` | `throw new Error("msg")` | `return 0, fmt.Errorf("msg")` | `return Err("msg".to_string())` |

Preserve the exact error messages across all languages.

### Step 4: Generate Implementations

For each language, generate the implementation following these rules:
- Implement ALL BEHAVIOR rules in order
- Use idiomatic patterns for the target language
- Preserve the logic flow from the spec
- Match error messages exactly
- Handle all EDGE_CASES
- Add a docstring/comment from INTENT

### Step 5: Generate Tests

For each language, generate a complete test file:
- Convert every TESTS entry to the language's test framework
- Expand `[...]` into concrete fixtures per language
- Use language-idiomatic assertion style
- Group tests by category (happy path, boundary, error)

### Step 6: Cross-Language Verification Table

After generating all implementations, produce a verification table:

```markdown
## Cross-Language Verification

| Test Case | Python | TypeScript | Go | Rust |
|-----------|--------|------------|-----|------|
| `(100.0, 20) -> 80.0` | `calculate_discount(100.0, 20)` | `calculateDiscount(100.0, 20)` | `CalculateDiscount(100.0, 20)` | `calculate_discount(100.0, 20)` |
| `(-10.0, 20) -> error` | `raises ValueError` | `throws Error` | `returns error` | `returns Err` |
| ... | ... | ... | ... | ... |

All implementations must produce **identical outputs** for identical inputs.
Error messages must be **character-for-character identical** across languages.
```

---

## Output Structure

Generate files organized by language:

```
<function_name>/
├── python/
│   ├── <function_name>.py
│   └── test_<function_name>.py
├── typescript/
│   ├── <function_name>.ts
│   └── <function_name>.test.ts
├── go/
│   ├── <function_name>.go
│   └── <function_name>_test.go
└── VERIFICATION.md          # cross-language verification table
```

Or if adding to an existing project, follow the project's directory structure.

---

## Type Mapping Reference

Common mappings for popular languages. Any language is supported — adapt types to its native equivalents following the same pattern.

| RUNE / Python | TypeScript | Go | Rust | Java |
|--------------|------------|-----|------|------|
| `str` | `string` | `string` | `String` / `&str` | `String` |
| `int` | `number` | `int` / `int64` | `i32` / `i64` | `int` / `long` |
| `float` | `number` | `float64` | `f64` | `double` |
| `bool` | `boolean` | `bool` | `bool` | `boolean` |
| `list[T]` | `Array<T>` / `T[]` | `[]T` | `Vec<T>` | `List<T>` |
| `dict[K, V]` | `Record<K, V>` | `map[K]V` | `HashMap<K, V>` | `Map<K, V>` |
| `tuple[A, B]` | `[A, B]` | `(A, B)` via struct/returns | `(A, B)` | custom class |
| `None` / `null` | `null` / `undefined` | `nil` | `None` (Option) | `null` |
| `Optional[T]` | `T \| null` | `*T` | `Option<T>` | `Optional<T>` |

For languages not listed (C#, Ruby, Swift, Kotlin, Elixir, Haskell, PHP, etc.), map each type to its closest native equivalent.

---

## Rules

- All implementations must pass the same logical tests
- Error messages must be identical across languages (same string)
- Use idiomatic patterns per language — do not write "Python in Go"
- If a RUNE feature cannot be directly expressed in a language (e.g., tuples in Java), use the closest idiomatic equivalent and document the adaptation
- Always generate the cross-language verification table
- If the spec has `language: <specific>`, ask the user which additional languages they want
- If the spec has `language: any`, ask the user which languages to target (or default to Python + TypeScript)

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/vict00r99) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->