# Check if skill directory exists
ls components/skills/convert-$1-$2/

# Search for existing PRs
gh pr list --search "convert-$1-$2" --state all

# Check if reverse skill exists
ls components/skills/convert-$2-$1/

# Search for reverse skill PRs
gh pr list --search "convert-$2-$1" --state all

## Reverse Skill Found

| Field         | Value                                      |
| ------------- | ------------------------------------------ |
| Reverse Skill | `convert-$2-$1`                            |
| Location      | `components/skills/convert-$2-$1/SKILL.md` |
| Key Insights  | [List patterns that apply bidirectionally] |

**Action**: Reference in "See Also" section, share pitfalls documentation

## Reverse Skill Status

No `convert-$2-$1` skill exists. Consider:

- [ ] Create issue for reverse skill if commonly needed
- [ ] Document one-way patterns in this skill's pitfalls section

Please provide source and target languages:
/create-lang-conversion-skill <source-lang> <target-lang>

Example: /create-lang-conversion-skill typescript rust

# Check for section headers (example for bash, but do this by reading the file)
for pillar in "Module" "Error" "Concurrency" "Metaprogramming" "Zero\|Default" "Serialization" "Build" "Testing"; do
  grep -c "## .*$pillar" components/skills/lang-$1-dev/SKILL.md
done

## 8 Pillars Validation

| Skill       | Mod | Err | Conc | Meta | Zero | Ser | Build | Test | Score |
| ----------- | --- | --- | ---- | ---- | ---- | --- | ----- | ---- | ----- |
| lang-$1-dev | ✓   | ✓   | ✓    | ~    | ✓    | ✓   | ✓     | ✓    | 7.5/8 |
| lang-$2-dev | ✓   | ✓   | ✓    | ✓    | ✓    | ✓   | ✓     | ✓    | 8/8   |

**Combined Score:** 15.5/16 (Excellent)
**Gaps:** lang-$1-dev metaprogramming is partial
**Mitigation:** Reference `patterns-metaprogramming-dev`
**Decision:** Proceed ✓

## Difficulty Assessment

| Factor      | Score | Rationale                                                |
| ----------- | ----- | -------------------------------------------------------- |
| Type System | +X    | [e.g., "Dynamic → Static requires type annotation"]      |
| Paradigm    | +X    | [e.g., "OOP → FP requires mental model shift"]           |
| Memory      | +X    | [e.g., "GC → Ownership requires lifetime understanding"] |
| Concurrency | +X    | [e.g., "Promises → Actors"]                              |
| Platform    | +X    | [e.g., "Node → BEAM"]                                    |
| **Total**   | **X** | **[Easy/Medium/Hard/Expert]**                            |

**Implications:**

- Expected skill size: X lines
- Key focus areas: [List 2-3 main challenges]
- Recommended examples: [Number based on difficulty]

# Find skills involving source language
ls components/skills/convert-$1-*/
ls components/skills/convert-*-$1/

# Find skills involving target language
ls components/skills/convert-$2-*/
ls components/skills/convert-*-$2/

mkdir -p components/skills/convert-$1-$2

---
name: convert-<source>-<target>
description: Convert <Source> code to idiomatic <Target>. Use when migrating <Source> projects to <Target>, translating <Source> patterns to idiomatic <Target>, or refactoring <Source> codebases. Extends meta-convert-dev with <Source>-to-<Target> specific patterns.
---

# Convert <Source> to <Target>

Convert <Source> code to idiomatic <Target>. This skill extends `meta-convert-dev` with <Source>-to-<Target> specific type mappings, idiom translations, and tooling.

## This Skill Extends

- `meta-convert-dev` - Skill creation patterns (structure, template)
- `meta-convert-guide` - Conversion methodology (APTV workflow, testing strategies)

For general concepts like the Analyze → Plan → Transform → Validate workflow, testing strategies, and common pitfalls, see `meta-convert-guide` first.

## This Skill Adds

- **Type mappings**: <Source> types → <Target> types
- **Idiom translations**: <Source> patterns → idiomatic <Target>
- **Error handling**: <Source> error model → <Target> error model
- **Async patterns**: <Source> concurrency → <Target> concurrency
- **[If applicable] Memory/Ownership**: <Source> memory model → <Target>

## This Skill Does NOT Cover

- General conversion methodology - see `meta-convert-dev`
- <Source> language fundamentals - see `lang-<source>-dev`
- <Target> language fundamentals - see `lang-<target>-dev`
- Reverse conversion (<Target> → <Source>) - see `convert-<target>-<source>`

---

## Quick Reference

| <Source> | <Target> | Notes |
| -------- | -------- | ----- |
| ...      | ...      | ...   |

## When Converting Code

1. **Analyze source thoroughly** before writing target
2. **Map types first** - create type equivalence table
3. **Preserve semantics** over syntax similarity
4. **Adopt target idioms** - don't write "<Source> code in <Target> syntax"
5. **Handle edge cases** - null/nil/None, error paths, resource cleanup
6. **Test equivalence** - same inputs → same outputs

---

## Type System Mapping

### Primitive Types

| <Source> | <Target> | Notes |
| -------- | -------- | ----- |
| ...      | ...      | ...   |

### Collection Types

| <Source> | <Target> | Notes |
| -------- | -------- | ----- |
| ...      | ...      | ...   |

### Composite Types

| <Source> | <Target> | Notes |
| -------- | -------- | ----- |
| ...      | ...      | ...   |

---

## Idiom Translation

### Pattern: <Common Pattern Name>

**<Source>:**

```<source-lang>
// Source code example
```

// Target code example - idiomatic, not transliterated

// Simple, focused example demonstrating one concept

// Idiomatic translation of the single concept

// Example combining 2-3 concepts (e.g., types + error handling)

// Shows how concepts interact in target language

// Complete, realistic source code (~50-100 lines)
// Demonstrates a real-world use case

// Complete, idiomatic target code
// Shows full translation including edge cases

### Step 6: Populate Content

Fill in the template with specific content for this language pair:

#### Content Requirements

| Section | Minimum | Quality Bar |
|---------|---------|-------------|
| Quick Reference | 10 entries | Most common type mappings (see example below) |
| Primitive Types | All primitives | Include edge cases (infinity, NaN) |
| Collection Types | 5+ types | Array, Map, Set, Tuple equivalents |
| Composite Types | 3+ types | Struct, Class, Interface mappings |
| Idiom Translations | See priority list below | Common patterns with "why" explanations |
| Error Handling | Complete section | Full error model translation |
| Concurrency | Complete section | Async/threading translation |
| Memory/Ownership | If applicable | Include if languages differ (GC vs ownership) |
| Examples | 3+ (simple, medium, complex) | Progressive complexity |
| Pitfalls | 5+ pitfalls | Language-pair specific mistakes |

**Quick Reference Example (TypeScript → Rust):**

| TypeScript | Rust | Notes |
|------------|------|-------|
| `string` | `String` / `&str` | `String` for owned, `&str` for borrowed |
| `number` | `i32` / `f64` | Choose based on usage (integer vs float) |
| `boolean` | `bool` | Direct mapping |
| `null \| undefined` | `Option<T>` | Use `None` for absence |
| `T[]` | `Vec<T>` | Dynamic array equivalent |
| `Map<K,V>` | `HashMap<K,V>` | Import from `std::collections` |
| `interface` | `trait` / `struct` | Trait for behavior, struct for data |
| `class` | `struct` + `impl` | Separate data from methods |
| `Promise<T>` | `Future<Output=T>` | Requires async runtime |
| `try/catch` | `Result<T,E>` + `?` | Compile-time error handling |

This example shows 10 high-value mappings that cover the most common translation needs.

#### Organizing Large Type Mapping Tables

When type mappings exceed 20 entries, organize for scanability:

1. **Group by category**: Primitives → Collections → Composites → Special types
2. **Alphabetize within groups**: Easier to find specific types
3. **Use subsections**: Split into `### Primitive Types`, `### Collection Types`, etc.
4. **Highlight gotchas**: Bold or add ⚠️ for non-obvious translations

**Anti-pattern**: One giant table with 50+ rows sorted arbitrarily.

#### Idiom Translation Priority

**Required patterns (must include):**
1. Null/optional handling (null → Option, Maybe → nil, etc.)
2. Collection operations (map, filter, reduce equivalents)
3. Error propagation (try/catch → Result, throws → Either)
4. Async/await patterns (if either language has async)

**Language-specific patterns (include 2-6 based on relevance):**
- Type alias/newtype definitions
- Pattern matching
- Generics/type parameters
- Interface/trait implementations
- Resource cleanup (using/defer/Drop)
- Builder patterns
- Iteration patterns

#### Handling Features With No Equivalent

When source language has a feature with no direct target equivalent:

| Strategy | When to Use | Example |
|----------|-------------|---------|
| **Explain the gap** | Feature is truly missing | Python decorators → Go (no equivalent; use code generation or manual wrapping) |
| **Suggest workaround** | Alternative achieves similar outcome | TypeScript `enum` → Go (use `const` + `iota` pattern) |
| **Recommend library** | Third-party fills the gap | Python list comprehensions → Java (use Streams or Guava) |
| **Document limitation** | No good solution exists | Ruby blocks → C (callbacks require explicit function pointers) |

**Template for no-equivalent patterns:**

```markdown
### Pattern: <Source Feature> (No Direct Equivalent)

**<Source>:**
\`\`\`<source-lang>
// Source code using the feature
\`\`\`

**<Target> - Closest Approximation:**
\`\`\`<target-lang>
// Best available approach
\`\`\`

**Why no direct equivalent:**
- [Explanation of language design differences]

**Workaround limitations:**
- [What the workaround doesn't provide]
```

#### Choosing Between Multiple Idiomatic Approaches

When the target language has multiple valid translations:

1. **Document all viable options** with trade-offs
2. **Recommend a default** for most cases
3. **Explain when to choose alternatives**

**Example (TypeScript `interface` → Rust):**

| Approach | When to Use |
|----------|-------------|
| `trait` | Defining shared behavior across types |
| `struct` | Defining data shape only |
| `struct` + `impl` | Data shape with associated methods |

**Template for multiple approaches:**

```markdown
### Pattern: <Source Pattern>

**Option A: <First Approach>** (Recommended for most cases)
\`\`\`<target-lang>
// Implementation
\`\`\`
When to use: [Criteria]

**Option B: <Alternative Approach>**
\`\`\`<target-lang>
// Implementation
\`\`\`
When to use: [Criteria]

**Decision guide:**
- Use A when: [condition]
- Use B when: [condition]
```

#### Common Pattern Template Snippets

Reusable templates for frequently needed patterns:

**Constructor/Factory Functions:**
```markdown
### Pattern: Constructor Function

**<Source>:**
\`\`\`<source-lang>
class User {
  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }
}
\`\`\`

**<Target>:**
\`\`\`<target-lang>
// Target equivalent (struct + new function, builder, etc.)
\`\`\`

**Why this translation:**
- [Reason for the pattern choice]
```

**Resource Cleanup:**
```markdown
### Pattern: Resource Management

**<Source>:** `try-finally` / `using` / `with`
**<Target>:** `Drop` trait / `defer` / context manager equivalent

[Include ownership/lifetime considerations if applicable]
```

**Singleton/Module Pattern:**
```markdown
### Pattern: Module-Level State

**<Source>:** Static class / module singleton
**<Target>:** `lazy_static!` / `once_cell` / module-level `const`

[Note thread-safety implications]
```

#### When to Use Code Comments vs Separate Explanation

| Situation | Use Comments | Use "Why" Section |
|-----------|--------------|-------------------|
| Non-obvious syntax | Yes - inline | No |
| Conceptual difference | Light comment | Yes - detailed |
| Performance implication | Brief note | Yes - with rationale |
| Gotcha/pitfall | Warning comment | Yes - with example |
| Standard idiom | No (self-evident) | Brief note if notable |

**Good comment pattern:**
```rust
// Note: Rust requires explicit Option unwrap; TS would allow direct access
let name = user.name.unwrap_or_default();
```

**When to move explanation out of code:**
- Explanation exceeds 2 lines
- Requires comparison to source language
- Documents a design decision, not just syntax

#### Quality Guidance: Good vs Great

| Aspect | Good | Great |
|--------|------|-------|
| Type mapping | `String → &str` | `String → &str for borrowed, String for owned; use Cow<str> when ownership varies` |
| Why explanation | "Use Result in Rust" | "Use Result because Rust has no exceptions; the ? operator propagates errors like try/catch but at compile time" |
| Example code | Syntactically correct | Syntactically correct + follows target language conventions (naming, formatting, idioms) |
| Pitfall | "Don't forget to handle errors" | "TypeScript's `undefined` vs Rust's `Option`: TS allows property access on undefined (runtime error), Rust requires explicit unwrap (compile error)" |

#### Example Complexity Guide

| Level | Lines | Concepts | Purpose |
|-------|-------|----------|---------|
| Simple | 5-15 | 1 | Demonstrate single type/idiom translation |
| Medium | 20-40 | 2-3 | Show concept interactions |
| Complex | 50-100 | 4+ | Real-world use case, production-ready |

#### Example Quality Checklist

Before finalizing examples, verify each one meets these criteria:

- [ ] **Syntactically valid** - Source code compiles/runs without errors
- [ ] **Target is idiomatic** - Not transliterated (avoid "Source code in Target syntax")
- [ ] **Demonstrates pattern clearly** - Single focus per example (Simple), combined focus (Medium/Complex)
- [ ] **Complexity matches level** - Don't overcomplicate Simple examples
- [ ] **Comments explain "why"** - Not just "what" the code does
- [ ] **Edge cases shown** - Null handling, error paths, empty collections where relevant

#### Example Organization (For Large Skills)

When skills grow beyond 800 lines or have 5+ examples:

**File Structure Options:**

```
convert-source-target/
├── SKILL.md              # Core content, inline simple/medium examples
├── examples/
│   ├── 01-simple.md      # Or inline if < 20 lines each
│   ├── 02-medium.md
│   └── 03-complex-api-client.md  # Named by use case
└── gotchas/
    └── common-mistakes.md  # Extract if > 10 pitfalls
```

**When to extract examples to separate files:**
- Example exceeds 50 lines (complex examples often do)
- Multiple variations of the same pattern
- Examples need their own context/setup code

**Naming conventions:**
- Number prefix for ordering: `01-`, `02-`, `03-`
- Descriptive suffix: `-api-client`, `-error-handling`, `-async-patterns`

**Keep inline when:**
- Simple/medium examples under 30 lines
- Pattern is central to understanding the skill
- Extraction would hurt discoverability

#### Balancing Comprehensiveness vs Maintainability

Skills should be complete enough to be useful but not so large they become unmaintainable.

**Size guidelines by difficulty:**

| Difficulty | Target Lines | Max Lines | When to Split |
|------------|--------------|-----------|---------------|
| Easy | 200-400 | 500 | Rarely needed |
| Medium | 400-800 | 1000 | Extract complex examples |
| Hard | 800-1200 | 1500 | Use progressive disclosure |
| Expert | 1200+ | 2000 | Split into focused sub-skills |

**Signs a skill is too comprehensive:**
- More than 80% of content is rarely used
- Examples cover edge cases that aren't practically common
- Type mappings include every possible type (not just common ones)

**Signs a skill is too sparse:**
- Users frequently need to search elsewhere for answers
- Common patterns are missing
- "See also" links are doing the heavy lifting

**Maintainability checklist:**
- [ ] Each section can be updated independently
- [ ] Examples can be validated without reading entire skill
- [ ] New patterns can be added without restructuring
- [ ] Outdated content can be identified and removed

#### Testing/Validation Guidance

To verify conversion examples are correct:

1. **Use language playgrounds** for quick validation:
   - TypeScript: [TS Playground](https://www.typescriptlang.org/play)
   - Python: [Python Tutor](https://pythontutor.com/) or REPL
   - Rust: [Rust Playground](https://play.rust-lang.org/)
   - Go: [Go Playground](https://go.dev/play/)
   - Elixir: [Elixir Playground](https://playground.elixir-lang.org/)

2. **For complex examples**, consider:
   - Create minimal test files to verify both source and target compile
   - Run equivalent inputs through both to verify same outputs
   - Check error cases behave equivalently

3. **Document behavioral differences**:
   - If source and target have different semantics (e.g., overflow behavior), note this
   - Include comments like `// Note: Python int is arbitrary precision, Rust i64 overflows`

### Step 7: Validate Skill

Run through this checklist before completing:

#### Structure Validation
- [ ] SKILL.md has valid YAML frontmatter
- [ ] `name` matches directory name (`convert-$1-$2`)
- [ ] `description` includes trigger phrases (convert, migrate, translate)
- [ ] All sections from template are present
- [ ] No placeholder text remains (`...`, `<Description>`, etc.)

#### Content Validation
- [ ] Type mapping tables are comprehensive
- [ ] Idiom translations include "why" explanations
- [ ] Error handling section covers full error model
- [ ] Concurrency section addresses async patterns
- [ ] Memory/Ownership included if languages differ
- [ ] Paradigm Translation included if paradigms differ (OOP→FP, etc.)

#### Type Mapping Validation Checklist
- [ ] **Primitives**: All basic types covered (int, float, string, bool, char)
- [ ] **Numerics**: Precision differences noted (i32 vs i64, overflow behavior)
- [ ] **Nullability**: null/nil/None → Option/Maybe mappings clear
- [ ] **Collections**: Array, List, Map, Set, Tuple equivalents
- [ ] **Composites**: Struct, Class, Interface, Enum, Union mappings
- [ ] **Generics**: Type parameter syntax and constraints
- [ ] **Special types**: Never/Bottom, Unit/Void, Any/Dynamic

#### Example Validation
- [ ] Examples progress in complexity (simple → complex)
- [ ] Source code examples are syntactically correct
- [ ] Target code examples are idiomatic (not transliterated)
- [ ] Examples cover different aspects (types, errors, async)
- [ ] Complex example is realistic and complete

#### Cross-Reference Validation
- [ ] References `meta-convert-dev` as foundation
- [ ] Links to `lang-$1-dev` if it exists
- [ ] Links to `lang-$2-dev` if it exists
- [ ] Mentions reverse skill `convert-$2-$1` in "Does NOT Cover"
- [ ] Lists related `convert-X-Y` skills in "See Also"

#### Bidirectional Consistency Validation

If a reverse skill (`convert-$2-$1`) exists, verify bidirectional consistency:

| Check | Status | Notes |
|-------|--------|-------|
| Type mappings are inverse | ☐ | e.g., `String→&str` ↔ `&str→String` |
| Shared pitfalls documented in both | ☐ | Common gotchas apply both ways |
| Platform considerations consistent | ☐ | Same platform diff noted in both |
| One-way patterns marked clearly | ☐ | Some patterns only work in one direction |
| Cross-references link to each other | ☐ | Both skills link to each other |

**One-Way Pattern Examples:**

| Pattern | Direction | Why One-Way |
|---------|-----------|-------------|
| GC→Ownership | Any→Rust | Must add lifetime annotations, no reverse automatic |
| Dynamic→Static | Python→TypeScript | Type inference possible but not automatic reverse |
| Macro→Function | Rust→Go | Macros have no Go equivalent |
| Actor→Thread | Erlang→Java | Actor patterns don't map back cleanly |

When documenting one-way patterns:
```markdown
<!-- In Pitfalls section -->
> **One-Way Pattern**: This translation from [source] to [target]
> does not have a clean reverse. See `convert-$2-$1` for the
> reverse approach, which uses [different strategy].
```

### Step 8: Suggest Cross-References

After creating the skill, suggest related skills that should reference it:

```markdown
## Cross-Reference Updates Suggested

Consider adding references to this skill in:

1. **`meta-convert-dev`** - Add to "Existing Conversion Skills" section
2. **`lang-$1-dev`** - Add to "Related Skills" section
3. **`lang-$2-dev`** - Add to "Related Skills" section
4. **`convert-$2-$1`** - Reference as reverse skill (if it exists)

## Skill Created

| Field | Value |
|-------|-------|
| Skill Name | `convert-<source>-<target>` |
| Location | `components/skills/convert-<source>-<target>/SKILL.md` |
| Extends | `meta-convert-dev` |

**Validation Results:**
- [ ] Structure valid
- [ ] Content complete
- [ ] Examples validated
- [ ] Cross-references added

**Key Features:**
- [List main type mappings covered]
- [List main idiom translations covered]
- [Error handling approach]
- [Concurrency model translation]

**Next Steps:**
1. Review type mapping completeness
2. Test with real conversion scenarios
3. Update cross-referenced skills

## Skills & Commands Used

| Resource                        | Type    | How Used                              |
| ------------------------------- | ------- | ------------------------------------- |
| `meta-convert-dev`              | skill   | Foundation for structure and patterns |
| `lang-$1-dev`                   | skill   | Source language patterns (if used)    |
| `lang-$2-dev`                   | skill   | Target language patterns (if used)    |
| `convert-X-Y`                   | skill   | Reference for examples (if used)      |
| `/create-lang-conversion-skill` | command | This workflow                         |

## Feedback: <skill-or-command-name>

### Context

- **Task**: Creating `convert-$1-$2` skill
- **Used for**: [e.g., "Understanding APTV workflow", "Type mapping patterns"]

### What Worked Well

- [Specific positive feedback with examples]

### Suggested Improvements

- [ ] [Actionable improvement 1]
- [ ] [Actionable improvement 2]

### Additional Notes

[Any other observations or suggestions]

---

Feedback from: `/create-lang-conversion-skill $1 $2`

# If parent issue #205 exists for meta-convert-dev
gh issue create --repo aRustyDev/ai \
  --title "feedback(meta-convert-dev): from convert-$1-$2 creation" \
  --body "$(cat <<'EOF'
## Feedback: meta-convert-dev

### Context
- **Task**: Creating `convert-typescript-rust` skill
- **Used for**: Foundation patterns, type mapping strategies

### What Worked Well
- APTV workflow provided clear structure
- Type mapping tables were excellent templates

### Suggested Improvements
- [ ] Add more examples for async cancellation patterns
- [ ] Include guidance on translating decorators/attributes

Relates to #205

---
Feedback from: `/create-lang-conversion-skill typescript rust`
EOF
)"

## Feedback Submitted

| Resource                        | Issue | Summary         |
| ------------------------------- | ----- | --------------- |
| `meta-convert-dev`              | #XXX  | [Brief summary] |
| `/create-lang-conversion-skill` | #YYY  | [Brief summary] |

/create-lang-conversion-skill typescript rust
/create-lang-conversion-skill python golang
/create-lang-conversion-skill typescript python