New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Language Idioms Refiner

by techygarg in techygarg/lattice

Facilitate a structured conversation to define language-specific idioms and patterns for a repository.

MITAuto-check passedDevelopment

Install Language Idioms Refiner

skills CLI
$ npx skills add techygarg/lattice --skill language-idioms-refiner -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install techygarg/lattice language-idioms-refiner --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/techygarg/lattice.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/language-idioms-refiner .claude/skills/language-idioms-refiner && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
language-idioms-refiner
GitHub stars
199
Token cost
~4.1k tokens
SKILL.md length
1,847 words
Files
2 (incl. assets)
Skills in repo
33
Repo updated
First seen
Licence
MIT

At a glance

Facilitate a structured conversation to define language-specific idioms and patterns for a repository.

  • Works in 4 steps: Confirm language and version → Walk through sections with proposals → Additional sections → …
  • Setting up a new project
  • SKILL.md covers What This Produces, Scope Clarification, Before You Begin and Interview Flow, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Language Idioms Refiner is an agent skill from techygarg/lattice. Facilitate a structured conversation to define language-specific idioms and patterns for a repository. Produces a language-idioms.md document consumed by multiple atoms to adapt pseudocode defaults to the project's language. Use when setting up a new project, switching languages, or when the user says 'setup language', 'define language idioms', 'configure language', 'language patterns', or 'adapt for Go/Rust/Python'.

Its SKILL.md is about 4.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including assets (for example `assets/template.md`).

It sits in Development. It works with Python and Rust. The repository describes itself as: Install engineering discipline into any AI coding assistant. Composable skills for design, implementation, review, and team standards. Better process, not just better prompts. The licence is MIT.

When your agent uses it

  • Setting up a new project
  • Switching languages
  • The user says setup language
  • Define language idioms

Example prompts

  • “setup language”
  • “define language idioms”
  • “configure language”
  • “/language-idioms-refiner”

Requirements

  • Python 3

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Confirm language and version
  2. Walk through sections with proposals
  3. Additional sections
  4. Produce document

What it can do on your machine

Read from SKILL.md and the folder at commit ed226a0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Language Idioms Refiner loads about 4.1k tokens when it runs. Until then it costs about 111 tokens; SKILL.md has 1,847 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~111
When it runs · the whole SKILL.md, loaded when a task matches
~4.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from techygarg/lattice at commit ed226a0, republished under its MIT licence (© techygarg). 1,847 words, ~4,115 tokens.

Download SKILL.mdSave it as .claude/skills/language-idioms-refiner/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
language-idioms-refiner
description
Facilitate a structured conversation to define language-specific idioms and patterns for a repository. Produces a language-idioms.md document consumed by multiple atoms to adapt pseudocode defaults to the project's language. Use when setting up a new project, switching languages, or when the user says 'setup language', 'define language idioms', 'configure language', 'language patterns', or 'adapt for Go/Rust/Python'.

Language Idioms Refiner

What This Produces

  • Output: .lattice/standards/language-idioms.md (or custom path from .lattice/config.yaml -> paths.language_idioms)
  • Mode: Always standalone -- no embedded language defaults exist in atoms to overlay on. For revisions, load existing document and update sections in place.
  • Config keys:
    • language (top-level) -- language identifier (e.g., go, rust, python, java, typescript)
    • paths.language_idioms -- path to the produced document
  • Template: Read ./assets/template.md for the full document structure, pre-populated examples, and interview guidance comments
  • Consumed by: Multiple atoms reference specific sections by heading name:
SectionConsumed by
Error Handlingclean-code atom (§8), secure-coding atom (§2 validation error messages)
Type System & Object Modelclean-code atom (§1 SRP/cohesion), domain-driven-design atom (entities, VOs, aggregates)
Naming Conventionsclean-code atom (§4)
Testing Patternstest-quality atom (§5 naming, §4 isolation, §6 builders)
Parameter & Function Designclean-code atom (§2 function size, §5 parameters)
Dependency Managementclean-code atom (§9 testability/DI), architecture atom (dependency direction)

These six section headings are the stable contract. Atoms reference them by name. Additional sections can be added by consumers but these six must be present.

Scope Clarification

This document captures how the project's language expresses engineering patterns -- the language-level idioms that atoms need to adapt their pseudocode defaults. Clear boundaries:

ConcernWhere It BelongsNot Here
Project identity, tech stack, directory layoutknowledge-priming atomNo project structure or framework docs
Code craftsmanship rules (thresholds, heuristics)clean-code atom / overlayNo function size limits or DRY rules
Architecture layers, dependency directionarchitecture atom / overlayNo layer definitions
Domain modeling guardrailsdomain-driven-design atom / overlayNo aggregate rules
Team-specific preferences within languageAtom-specific overlaysNo team decisions (see below)

Key distinction from atom overlays: This document describes how the language works. Atom overlays describe how the team works within the language.

  • Language idioms doc: "Go uses explicit error returns (if err != nil), not exceptions"
  • Clean-code overlay: "We use fmt.Errorf('context: %w', err) for wrapping, custom error types for domain errors"

Language idioms are facts about the language. Atom overlays are team choices.

Before You Begin

Check for existing documents
  1. Read .lattice/config.yaml -- does paths.language_idioms point to a file?
  2. If yes, read that file. Ask the user:
    • "You already have a language idioms document for [language]. Would you like to revise it (update specific sections), start fresh (new interview), or switch language?"
    • Revise: Load the existing document, walk through only the sections the user wants to change.
    • Start fresh: Proceed with the full interview flow below.
    • Switch language: Proceed with full interview for the new language; existing document will be replaced.
  3. If no config or no existing document, proceed with the full interview flow.
Detect the language

Determine the project language before starting the interview:

  1. From config: Check .lattice/config.yaml for language key.
  2. From project files (if no config key):
    • package.json → TypeScript / JavaScript
    • tsconfig.json → TypeScript (confirm over JavaScript)
    • go.mod → Go
    • pom.xml or build.gradle or build.gradle.kts → Java or Kotlin
    • Cargo.toml → Rust
    • requirements.txt or pyproject.toml or setup.py → Python
    • Gemfile → Ruby
    • *.csproj or *.sln → C# / .NET
    • Package.swift → Swift
  3. Multiple languages detected: Ask the user which is the primary language. One language-idioms document per project (covers the primary language).
  4. No detection: Ask the user directly.
<!-- synced with lattice-init "Language/framework detection" -- edit both -->

Present the detected language: "I detected this is a Go project (found go.mod). I'll propose Go-idiomatic patterns for each section. You can confirm or adjust."

Interview Flow

This refiner works differently from other refiners. Instead of showing defaults and asking "change or keep?", it proposes language-specific content and asks "does this match your team's usage?"

Step 1: Confirm language and version

"I detected [Language] [version]. Is this correct?"

Record language and version. These go in the document frontmatter.

Step 2: Walk through sections with proposals

For each of the 6 sections:

  1. Propose pre-populated content based on the detected language (see Language-Specific Proposals below).
  2. Present the proposal: "Here's what I'd recommend for [Language]. Does this match how your team uses [Language]?"
  3. User confirms → record as-is.
  4. User adjusts → discuss specifics, record their version.
Step 3: Additional sections

After the 6 core sections, ask: "Any language-specific patterns I should add? For example: concurrency patterns, memory management, async/await idioms, or framework-specific conventions."

Record any additional sections the user wants.

Step 4: Produce document

Assemble and write the document.

Section-by-Section Interview Guide

Read ./assets/template.md and follow the <!-- INTERVIEW GUIDANCE: --> comments for each section.

The 6 core sections
#SectionWhat It Captures
1Error HandlingLanguage error philosophy (exceptions, error returns, Result types), error propagation patterns, error creation idioms
2Type System & Object ModelClasses vs structs, interfaces (nominal vs structural), inheritance vs composition, generics, type safety idioms
3Naming ConventionsCase conventions, visibility modifiers, acronym style, package/module naming, idiomatic patterns
4Testing PatternsTest framework idioms, test organization, assertion patterns, mocking approach, test naming style
5Parameter & Function DesignArgument passing idioms, options/config patterns, multiple returns, named parameters, function signatures
6Dependency ManagementDI approach (container vs manual), interface placement, wiring patterns, import/module conventions
Cross-section awareness
Decision inAffectsHow
§1 Error Handling§4 TestingError patterns determine how error paths are tested
§2 Type System§5 Parameters, §6 DependenciesObject model shapes function signatures and DI approach
§3 Naming§4 TestingNaming conventions apply to test names too

Language-Specific Proposals

For well-known languages, pre-populate each section with idiomatic defaults. The interview confirms or adjusts these. For unrecognized languages, ask open-ended questions.

Go
SectionProposal summary
Error HandlingExplicit error returns (value, err := ...), if err != nil, error wrapping with fmt.Errorf("context: %w", err), sentinel errors for expected cases, no exceptions
Type SystemStructs with methods (receiver functions), implicit interfaces (structural typing), composition via embedding, no inheritance, no classes
NamingExported = capitalized, unexported = lowercase, short names in small scopes, acronyms fully uppercase (HTTP, ID), package name is part of identifier (http.Client not http.HTTPClient)
TestingTable-driven tests, t.Run for subtests, testing.T parameter, test files _test.go co-located, no assertion library required (stdlib comparisons)
ParametersAccept interfaces return structs, functional options pattern for config (WithTimeout(5*time.Second)), multiple return values, no method overloading
DependenciesPass interface parameters (not constructor DI), define interfaces at consumer not provider, no DI container, explicit wiring in main() or cmd/
Rust
SectionProposal summary
Error HandlingResult<T, E> for recoverable, panic! for unrecoverable, ? operator for propagation, thiserror for library errors, anyhow for application errors
Type SystemStructs + impl blocks, traits (explicit implementation), enums with data (algebraic types), ownership/borrowing, no inheritance, no null (Option<T> instead)
Namingsnake_case functions/variables, PascalCase types/traits, SCREAMING_SNAKE constants, lifetime names short ('a, 'b)
Testing#[test] attribute, #[cfg(test)] mod tests in same file, integration tests in tests/ directory, assert_eq!/assert! macros
ParametersOwnership: borrow (&T) vs move, generic bounds (impl Trait), builder pattern for complex config, no default parameters
DependenciesTrait objects (dyn Trait) or generics (impl Trait) for abstraction, no DI container, explicit construction
Show full SKILL.md (748 more words)Show less
Python
SectionProposal summary
Error HandlingEAFP over LBYL (try/except, not if-checks), context managers (with) for cleanup, custom exceptions inheriting from base classes, raise/except
Type SystemClasses, dataclasses (@dataclass), protocols for structural typing (PEP 544), duck typing, type hints encouraged but optional at runtime
Namingsnake_case functions/variables, PascalCase classes, SCREAMING_SNAKE constants, _private convention (single underscore), __dunder__ for magic methods
Testingpytest preferred, fixtures for setup/teardown, @pytest.mark.parametrize for data-driven tests, plain assert (pytest rewrites), test files test_*.py
Parameters**kwargs for options, named/keyword arguments, default values, dataclass or TypedDict for config objects
DependenciesConstructor injection with protocols/ABCs, or function parameters, no heavyweight DI container (or dependency-injector if needed)
Java / Kotlin
SectionProposal summary
Error HandlingJava: unchecked exceptions preferred over checked (modern style), custom exceptions extend RuntimeException. Kotlin: sealed class Result pattern, runCatching, no checked exceptions
Type SystemJava: classes, interfaces, records (16+), sealed classes (17+). Kotlin: data classes, sealed hierarchies, null safety (?), extension functions
NamingcamelCase variables/methods, PascalCase classes/interfaces, SCREAMING_SNAKE constants, packages lowercase.dotted
TestingJUnit 5, @Test, @ParameterizedTest, @Nested for grouping, Mockito (Java) / MockK (Kotlin), AssertJ for fluent assertions
ParametersJava: builder pattern for >3 params, method overloading. Kotlin: named arguments, default values, data class config
DependenciesConstructor injection (Spring, Guice, or manual), DI containers are idiomatic, program to interfaces
TypeScript
SectionProposal summary
Error Handlingtry/catch with custom Error subclasses, typed error handling optional (Result pattern via libraries), no checked exceptions
Type SystemInterfaces, type aliases, union/intersection types, generics, unknown over any, discriminated unions for state
NamingcamelCase variables/functions, PascalCase types/classes/enums, SCREAMING_SNAKE constants, no I prefix for interfaces
TestingJest or Vitest, describe/it blocks, mock functions (jest.fn()), expect().toBe() assertions, .test.ts or .spec.ts co-located
ParametersOptions objects with destructuring, default values, rest parameters, overloaded signatures for type narrowing
DependenciesConstructor injection, DI optional (tsyringe, inversify), or module-level factory functions
C# / .NET
SectionProposal summary
Error HandlingExceptions for exceptional cases, custom exceptions from Exception base, try/catch/finally, no error codes for business logic, Result pattern growing in popularity
Type SystemClasses, interfaces (explicit), records (C# 9+), structs (value types), nullable reference types (C# 8+), generics
NamingPascalCase methods/properties/classes, camelCase local variables/parameters, _camelCase private fields, I prefix for interfaces (IService)
TestingxUnit or NUnit, [Fact]/[Theory] (xUnit), [Test]/[TestCase] (NUnit), FluentAssertions, Moq for mocking
ParametersNamed parameters, optional parameters with defaults, builder pattern or options pattern (IOptions<T>) for config
DependenciesConstructor injection via built-in DI (IServiceCollection), DI containers idiomatic, interface-first
Other Languages

For languages not listed above, use open-ended questions for each section:

  1. "How does [Language] handle errors? Exceptions, error returns, algebraic types, or something else?"
  2. "What's the object model? Classes, structs, traits, protocols? Inheritance or composition?"
  3. "What are the naming conventions? Case style, visibility markers, module naming?"
  4. "What's the testing ecosystem? Framework, organization, assertion style?"
  5. "How do you pass configuration and options to functions? Named params, objects, builders?"
  6. "How is dependency injection handled? Containers, manual wiring, interface parameters?"

Output Assembly

  1. YAML frontmatter: language and version
  2. Title line: # Language Idioms: {Language}
  3. All 6 core sections with confirmed/adjusted content
  4. Any additional sections the user added
  5. Strip all <!-- INTERVIEW GUIDANCE: --> comments

Target size: 40-60 lines of focused content. Each section should be 4-8 lines: a brief philosophy statement plus the key idiomatic patterns as a concise list. No code examples -- atoms have their own examples in pseudocode that they adapt using this document's guidance.

Determine output path:

  1. If .lattice/config.yaml exists and has paths.language_idioms, use that path.
  2. Otherwise, default to .lattice/standards/language-idioms.md.

Update config:

  1. Set language: {language} at top level (create or update).
  2. Set paths.language_idioms pointing to the output file.
  3. If .lattice/config.yaml does not exist, create it. Preserve all existing content.

Confirm to user: "Your language idioms document has been written to [PATH] for [Language] [version]. The following atoms will now adapt their patterns: clean-code, test-quality, secure-coding, domain-driven-design, and architecture."

Document Quality Checks

Before writing the final document, verify:

  • All 6 core section headings are present and match exactly: Error Handling, Type System & Object Model, Naming Conventions, Testing Patterns, Parameter & Function Design, Dependency Management
  • Content is specific to the language, not generic advice ("use error returns" not "handle errors properly")
  • No code craftsmanship rules (thresholds, complexity limits) -- those belong in atom overlays
  • No project identity information (tech stack, directory layout) -- that belongs in knowledge-priming
  • Content is concise -- each section 4-8 lines, total document under 60 lines
  • Frontmatter has correct language and version values
  • Config file is correctly updated with both language key and paths.language_idioms
  • No <!-- INTERVIEW GUIDANCE: --> comments remain in output

© techygarg, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (assets) in skills/language-idioms-refiner of techygarg/lattice.

  • SKILL.md
  • assets/template.md

Open the folder on GitHubat commit ed226a0

Compare with similar skills

Language Idioms Refiner next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Language Idioms Refiner compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Language Idioms Refiner this skilltechygarg/lattice199—~4.1kAutomated safety check: PassMIT
Release Skillsnexmoe/eve4213 repos~3.3kAutomated safety check: PassNone
RustPython C-API ExpansionRustPython/RustPython22k—~831Automated safety check: PassMIT
jscpd Code Migration Trackerkucherenko/jscpd6.4k—~5kAutomated safety check: PassMIT
RustPython Stdlib UpgradeRustPython/RustPython22k—~876Automated safety check: PassMIT
Rust Ffiariebovenberg/whenever2.4k—~2.5kAutomated safety check: PassMIT

Similar skills

  • Release Skills

    nexmoe/eve

    Universal release workflow. An agent skill from nexmoe/eve.

    421 GitHub starsUsed in 3 repos~3.3k tokens
    DevelopmentAuto-check passed

  • RustPython C-API Expansion

    RustPython/RustPython

    Implements missing CPython C-API functions in RustPython's crates/capi, mapping each header to its module with the pyo3-ffi header split.

    22k GitHub stars~831 tokensUpdated today
    DevelopmentAuto-check passed

  • jscpd Code Migration Tracker

    kucherenko/jscpd

    Measures a code port between languages or frameworks with jscpd's function-level comparison, porting tests before code and tracking what is left unmatched.

    6.4k GitHub stars~5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • RustPython Stdlib Upgrade

    RustPython/RustPython

    Upgrades a Python standard library module from CPython into RustPython with update_lib, then triages and marks the tests that still fail.

    22k GitHub stars~876 tokensUpdated today
    DevelopmentAuto-check passed

  • Rust Ffi

    ariebovenberg/whenever

    Instructions for using whenever's internal Rust FFI abstractions

    2.4k GitHub stars~2.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Samply

    vortex-data/vortex

    Analyze Samply Firefox-profiler output, record focused profiles, summarize hot threads/stacks, inspect symbolication, and compare profile evidence before and after a performance change.

    3.3k GitHub stars~2.7k tokensUpdated today
    DevelopmentAuto-check passed

More from techygarg/lattice

All 33 skills in this repo

  • Architecture Compass

    techygarg/lattice

    Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a…

    199 GitHub stars~4.6k tokensUpdated yesterday
    Auto-check passed

  • Lattice Init

    techygarg/lattice

    Guided setup and upgrade-check experience for Lattice projects -- scans the repository, detects existing configuration and outdated conventions, suggests refiners and available upgrades in priority…

    199 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check passed

  • Skill Align

    techygarg/lattice

    Audit and fix all Lattice documentation, README, docs/, PROJECT.md, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory.

    199 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Skill Validate

    techygarg/lattice

    Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners.

    199 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Architecture Refiner

    techygarg/lattice

    Facilitate a structured conversation to define architecture principles for a repository.

    199 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed

  • Clean Code Refiner

    techygarg/lattice

    Facilitate a structured conversation to define clean code principles for a repository.

    199 GitHub stars~3k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Language Idioms Refiner

What does Language Idioms Refiner do?

Facilitate a structured conversation to define language-specific idioms and patterns for a repository. Language Idioms Refiner is an agent skill from techygarg/lattice. Facilitate a structured conversation to define language-specific idioms and patterns for a repository.

When should I use Language Idioms Refiner?

Language Idioms Refiner fits situations like: setting up a new project; switching languages; the user says setup language; define language idioms.

How do I install Language Idioms Refiner in Claude Code?

Run `npx skills add techygarg/lattice --skill language-idioms-refiner -a claude-code`. Or copy the skill folder (skills/language-idioms-refiner in techygarg/lattice) into .claude/skills/language-idioms-refiner in your project. Claude Code loads it when a task matches its description.

How do I install Language Idioms Refiner in Codex?

Run `npx skills add techygarg/lattice --skill language-idioms-refiner -a codex`. Or copy the skill folder (skills/language-idioms-refiner in techygarg/lattice) into .agents/skills/language-idioms-refiner in your project. Codex loads it when a task matches its description.

Can I use Language Idioms Refiner in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add techygarg/lattice --skill language-idioms-refiner -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/language-idioms-refiner, .gemini/skills/language-idioms-refiner, .github/skills/language-idioms-refiner and .opencode/skills/language-idioms-refiner in your project.

What does Language Idioms Refiner need to run?

SKILL.md names no scripts, command-line tools or credentials: Language Idioms Refiner is instructions for the agent only. Our summary lists: Python 3.

Does Language Idioms Refiner access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Language Idioms Refiner safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Language Idioms Refiner use?

Language Idioms Refiner is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Language Idioms Refiner use?

About 4.1k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Language Idioms Refiner?

Skills that share tags, products or a category with Language Idioms Refiner: Release Skills (nexmoe/eve, 421 stars), RustPython C-API Expansion (RustPython/RustPython, 22k stars), jscpd Code Migration Tracker (kucherenko/jscpd, 6.4k stars) and RustPython Stdlib Upgrade (RustPython/RustPython, 22k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Language Idioms Refiner?

techygarg (a GitHub user) maintains it in techygarg/lattice, which has 199 GitHub stars. The repository holds 33 skills in this directory. The repository was last updated on October 10, 2026.

Source: techygarg/lattice on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.