Agent skill

Coordinate Frames

by LunCoSim in LunCoSim/lunco-sim

A skill your agent uses when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view…

Apache-2.0Auto-check passed

Install Coordinate Frames

skills CLI
$ npx skills add LunCoSim/lunco-sim --skill coordinate-frames -a claude-code

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

GitHub CLI
$ gh skill install LunCoSim/lunco-sim coordinate-frames --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/LunCoSim/lunco-sim.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/coordinate-frames .claude/skills/coordinate-frames && 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
coordinate-frames
GitHub stars
105
Token cost
~4k tokens
SKILL.md length
2,104 words
Files
1
Skills in repo
38
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view…

  • Works in 5 steps: Read the authoritative f64 pose from… → Convert source → target semantic frame… → Resolve the target Grid from… → …
  • Moves in the wrong direction
  • SKILL.md covers Find the semantic owner first, Use the existing conversion path, Do not patch symptoms and Required tests
  • Calls cargo

What it does

Coordinate Frames is an agent skill from LunCoSim/lunco-sim. Use when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view switch, or when adding a new orbital/body-fixed reference frame. Also use for BigSpace, CellCoord, FloatingOrigin, ActivePhysicsFrame, or frame-conversion work.

Its SKILL.md is about 4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Collaborative Multiphysics Cosimulator For Space Missions 🌎🚀🌚. The licence is Apache-2.0.

When your agent uses it

  • Moves in the wrong direction
  • Changes altitude while stationary
  • Loses its orientation after a view switch
  • Adding a new orbital/body-fixed reference frame

Example prompts

  • “/coordinate-frames”

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Read the authoritative f64 pose from USD, ephemeris, Modelica, or Avian.
  2. Convert source → target semantic frame with the existing f64 frame helpers.
  3. Resolve the target Grid from ReferenceFrameIndex.
  4. Split once with Grid::translation_to_grid.
  5. Attach/migrate atomically with lunco_core::attach::migrate_to_grid.

What it can do on your machine

Read from SKILL.md and the folder at commit d1c6f00. 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

    Shell commands in SKILL.md call:

    • cargo

    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

Coordinate Frames loads about 4k tokens when it runs. Until then it costs about 89 tokens; SKILL.md has 2,104 words of instructions outside code blocks.

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

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 LunCoSim/lunco-sim at commit d1c6f00, republished under its Apache-2.0 licence (© LunCoSim). 2,104 words, ~4,011 tokens.

Download SKILL.mdSave it as .claude/skills/coordinate-frames/SKILL.md (or your agent's skills folder).
name
coordinate-frames
description
Use when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view switch, or when adding a new orbital/body-fixed reference frame. Also use for BigSpace, CellCoord, FloatingOrigin, ActivePhysicsFrame, or frame-conversion work.

Coordinate frames and BigSpace

Use this runbook for coordinate changes. The concise design contract is docs/architecture/45-big-space-correct-usage.md.

Find the semantic owner first

Every astronomical or surface pose has a semantic ReferenceFrame:

  • World for the persistent scene frame;
  • EclipticJ2000 { center } for non-rotating body-centred work;
  • BodyFixed { body } for a rotating surface frame.

Resolve it through ReferenceFrameIndex. Never select the first Grid, walk an arbitrary parent, or add a second frame marker to a precision sub-grid. Missing and duplicate declarations must remain errors (None).

Use the existing conversion path

  1. Read the authoritative f64 pose from USD, ephemeris, Modelica, or Avian.
  2. Convert source → target semantic frame with the existing f64 frame helpers.
  3. Resolve the target Grid from ReferenceFrameIndex.
  4. Split once with Grid::translation_to_grid.
  5. Attach/migrate atomically with lunco_core::attach::migrate_to_grid.

CellCoord, Transform, and GlobalTransform are private projection state. They never cross a user/API/network/model boundary and never become the authoritative source of an astronomical or physics value.

For immutable high-precision presentation entities, use BigSpace's existing Stationary marker. Streamed globe/terrain visual tiles may use it because their placement is fixed until the entity is replaced; never use it on a camera, avatar, physics tile, or any entity that can mutate CellCoord, Transform, or ChildOf. Remove Stationary before relocating an entity, as required by BigSpace.

Application schedule gates may skip BigSpace work only from authoritative spatial invalidations. LocalFloatingOrigin::is_local_origin_unchanged reports the result of its most recent computation; after an origin changes, admit one follow-up local-origin computation to settle that flag. Do not treat a retained false as a permanent high-precision invalidation. Verify an origin shift, its settle pass, then stable frames with propagation closed. Track the pending settle between admitted passes rather than scanning every grid in an idle gate.

For a camera, compose the selected camera's authoritative f64 pose into the persistent WorldGrid and update the grid-direct OriginAnchor's (CellCoord, Transform) split. OriginAnchor is the sole owner of FloatingOrigin; cameras never receive or transfer that marker. For a site-anchored scene, celestial placement mounts only the authored site root. The root becomes the nested site Grid and ActivePhysicsFrame as soon as its SiteAnchor is projected, then is atomically migrated beneath the matching body-fixed surface Grid when that hierarchy is ready without changing the active frame. Terrain and rover/lander roots are sibling top-level children of that scene Grid; a rover is never parented to terrain. Each such top-level prim carries its own CellCoord, while visual and collision descendants remain ordinary children rooted in LowPrecisionRoot. Celestial placement does not query or migrate an avatar/camera. If the site Grid is reparented, the physics bridge reseeds bodies from the new site-local hierarchy and rotates only their velocity vectors; a frame switch without reparenting transports the existing physics pose. The avatar subsystem captures a loader-relative local-camera pose after USD projection has committed and applies it at the explicit scene-handoff boundary. All explicit camera frame changes stay with the camera subsystem through the same atomic migration helper. For a physical entity, keep it under ActivePhysicsFrame and let BigSpacePhysicsBridgePlugin own the Avian f64 pose exchange. The shared lunco-physics::avian_backend contract owns numeric backend admission; the bridge owns lifecycle admission and raises the runtime fault when changed poses or collider AABBs are invalid. It gates the nested physics phases before Avian grows AABBs or runs a query; GridSpatialQuery reuses the same point check after conversion. Keep the evidence layers separate: malformed composed USD transforms fail during projection, mutable runtime pose/AABB failures raise RuntimeFaults plus PhysicsHolds::SAFETY_FAILURE, and invalid public query origins return no hit without becoming a simulation fault. Use the existing bridge and scene-teardown tests for the first two, and a production Rhai scene test for the public query contract; do not add a second per-producer filter. For a line joining two frames, convert both endpoints into one semantic frame before generating cell-local geometry. For authored motion directly beneath a BigSpace Grid, use standard USD double3 xformOp:translate samples and split the f64 position with Grid::translation_to_grid before writing the local Transform. Unbound samples use SimulationPresentationTime, which stays between completed physical ticks and holds while transport is paused. Do not introduce a mission-specific trajectory component or independent clock for motion already represented by USD animation.

Celestial body ephemerides are not ordinary USD animation: body frames, rotation, the semantic SunState, shadows, and the sky readout share one lunco_time::CelestialTime sample. It is a child of WorldTime and can be rate-scaled up to 100,000× without changing Avian's fixed physics cadence. Modelica reads celestial-derived environment inputs at its ordinary communication points. From a lunar surface, Earth stays near one sky position because the Moon is tidally locked; expect libration, while Earth's single body-fixed grid continues to rotate for the day/night cycle. At 100,000×, a lunar month takes about 24 seconds. Test both the parent-relative CellCoord/Transform and the BigSpace-propagated GlobalTransform; local transform checks alone do not prove a rendered pose reached its consumer. The celestial cadence commits the CelestialTime sample it gated, and advances body position and spin together.

For the local kinematic avatar, use the existing Avian MoveAndSlide query in ActivePhysicsFrame: convert the source Grid pose, displacement, and up vector with grid_transform_between_grids, perform one shape move, and convert the solved pose back before Grid::translation_to_grid. The avatar is a camera embodiment, so do not invent a USD body schema or read GlobalTransform as its collision authority. This path preserves the fixed solver/substep contract.

For orbital camera views, keep presentation state on the avatar in OrbitViewHistory, keyed by the stable celestial ephemeris id. Capture a user-controlled OrbitCamera pose before switching targets or leaving orbit, and restore it only for that same body, including a later surface-to-orbit scroll entry. When no saved pose exists, derive the arrival direction from the camera's current radial region after resolving the target's inertial BigSpace grid. Do not use a fixed world-axis/Sun-facing arrival, a scene-wide pose cache, or a second transform writer. Clear this transient history with active-Twin teardown and avatar demotion.

When an orbital view must frame a mission site, publish the scene's valid SiteAnchor position transformed into the body's inertial grid as a typed f64 vector. This location belongs to the scene frame and does not depend on a possessed vehicle. Show the mission-site action as its own HUI card, apart from the mode selector. Rhai computes the orbit angles, reads the persisted CameraInputSettings.orbit_direction_animation_duration_s property, and sends the generic AnimateOrbitCameraDirection command. The camera transition moves along the current orbit without changing its radius or vertical offset; the orbit writer commits each BigSpace pose and refreshes the orbital pin. Direct user look input cancels the transition. Surface/orbit transitions use the persisted CameraInputSettings.surface_mode_engage_altitude_m property as the shared engage altitude and orbital zoom floor (1,000 m by default). Clearance uses sampled local DEM terrain where the active terrain covers the camera and the body's reference radius outside that coverage. Its companion surface_mode_disengage_altitude_m property provides hysteresis and defaults to 2,000 m under the same rule.

For transform gizmos, use transform-gizmo-bevy only as a render-space frontend on an unparented proxy. Capture through SimulationPoseQuery, keep the proposed pose in the explicit ActivePhysicsFrame, convert the complete pose back with the canonical render/grid and parent-local helpers, and commit through one TransformEntity scene command. Never apply render deltas to a parent-local Transform, read GlobalTransform as physics authority, or write Avian Position/Rotation from editor code. Reproject from the active-frame transaction pose after BigSpace origin/cell changes. Because the frontend writes its final proxy pose in Last after the normal interaction transfer in PostUpdate, snapshot that final pose in Last before release cleanup. USD preview scale is authored through UsdOp::SetScale; live scale remains outside the physics contract.

For USD geometry, xformOpOrder is the authoritative ordered transform stack. Read the complete composed local transform through the shared USD transform decoder, including scale; do not inspect individual xformOp:* attributes in a second path.

Show full SKILL.md (825 more words)Show less

For a new top-level scene or runtime spawn, convert the semantic f64 pose into the scene root's parent-local representation with pose_in_grid_to_parent_storage. The direct Grid child receives the returned CellCoord and local Transform; do not attach the rover under a terrain mesh or write a large parent-local f32 value with a zero cell.

For Rhai scene tools, use the shared pointer coordinate contract. Rust converts the picking backend's RenderPos exactly once through the admitted ActivePhysicsFrame; the context exposes world_position as a tagged point3 in active_physics and render_position as a tagged render point. Use the prelude helpers point3, world_point, point_values, point_frame, point_delta, point_distance, point_offset, and pointer_point. Never author from the render point, subtract raw arrays from points in another frame, or silently use the persistent world grid when the active nested site frame is unavailable. pointer_point is the user-facing failure boundary: it returns an explicit error for a missing hit or frame rather than an identity/floating-origin fallback. This keeps all screen tools—terrain, route, gizmo, and future tools—on one conversion owner. Scene-tool behavior must consume the generic context.pointer_intents/pointer_intent(context, name) surface from the shared input settings; do not encode Alt, Shift, Ctrl, or mouse-button meaning inside a route or terrain tool. This keeps remapping a settings change while the coordinate conversion remains owned by the Rust frame adapter.

For waypoint labels, author lunco:billboard* on the waypoint and let the generic billboard renderer consume its propagated GlobalTransform. The renderer uses the shared BigSpace world-pose machinery for the camera/subject range check; route projection does not add another distance or coordinate conversion owner. The terrain-grid/BigSpace hierarchy and the existing billboard path already own that conversion. The shared overlay wraps labels to a bounded width, clamps their backdrop inside the active viewport, and gives nearer labels first choice of non-overlapping camera-facing slots. A label with no safe slot is omitted for that frame rather than covering another marker. Editor-created waypoints use the canonical USD billboard authoring helper; runtime-only waypoints attach the same UsdBillboard data plus the generic BillboardIndex fact to the shared marker root. Keep both paths on this one renderer; do not overwrite Name or add a waypoint-specific overlay.

For physics and co-simulation, resolve a demanded direction target from its composed position into each EnvironmentProbe frame through the shared BigSpace f64 helpers. Normalize the displacement once into UnitDirection3; frame rotations preserve that unit vector. The USD wire selects the source id, while the consumer model uses a generic target-direction input. SunState contains solar irradiance only. A static DistantLight contributes a framed ray through the same resolver only after composed-root celestial-source classification confirms that no finite celestial target owns sun. Celestial roots use their finite body target exclusively, and a prior static ray is withdrawn before probe resolution. Do not add per-body conversion systems, another coordinate cache, or a local solar clock. Invalid input bindings may withhold the optional observer camera, but cannot block creation of celestial targets used by the direction resolver.

Publish SunRenderState from the finalized scene-sun GlobalTransform after BigSpaceSystems::PropagateLowPrecision. Any conversion of that render direction through a terrain GlobalTransform belongs after that phase in PostUpdate: static material wiring, horizon-cache validity/bake decisions, and streamed-tile shadow intent binding all consume that finalized frame. Put streamed-tile binding in the public TerrainSurfaceSet::RenderShadowBinding phase so it cannot observe a previous-frame terrain transform. Do not repair a stale projection with an offset or another per-frame transform writer. The projection is change-gated by the selected source revision and changed BigSpace ancestor chains, so stable frames do not rebuild f64 poses.

The render backend samples the resulting cascades with Bevy's hardware 2x2 comparison filter in standard and high profiles. Keep that choice separate from the semantic sun angle and the authored cascade/range/bias policy; do not introduce a Gaussian/PCSS blur or tune physical light state to hide a filtering artifact.

Do not patch symptoms

Do not add a per-frame position correction, a fallback frame, a guessed parent, an epoch-specific offset, a raw f32 absolute position, or a second transform writer. Those hide the ownership error and will reappear at a grid boundary or view transition.

Required tests

Add the smallest real regression at the owning boundary:

  • frame index rejects missing and duplicate semantic grids;
  • f64 pose conversion round-trips position and rotation;
  • atomic migration preserves the pose across a cell boundary;
  • the Avian bridge is invariant to BigSpace re-splitting and celestial-parent rotation;
  • surface ↔ inertial camera transfer preserves target pose and up direction;
  • per-avatar orbital history restores independent body poses and clears with active-Twin teardown;
  • the selected camera projects through the persistent WorldGrid into the sole OriginAnchor, while duplicate or missing world-shell entities fail closed.
  • a standard render camera receives the hardware 2x2 shadow filter exactly once; fast mode remains unlit and does not attach it.

Run focused checks first:

sh
scripts/run_rust_tests.sh -p lunco-core --lib -j 4
scripts/run_rust_tests.sh -p lunco-celestial -j 4
scripts/run_rust_tests.sh -p lunco-usd-avian -j 4
RUSTC_WRAPPER= cargo build -p lunco-luncosim --bin luncosim -j 4

For visual acceptance, launch the built production binary head-full with an explicit free API port, inspect surface and inertial views, then send the API Exit command and verify the process and port are gone. Use --no-ui only for headless deterministic checks.

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

Files

Just SKILL.md in skills/coordinate-frames of LunCoSim/lunco-sim.

Open the folder on GitHubat commit d1c6f00

Compare with similar skills

Coordinate Frames 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.

Coordinate Frames compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Coordinate Frames this skillLunCoSim/lunco-sim105—~4kAutomated safety check: PassApache-2.0
Agent Consensus Coordinatorruvnet/ruflo74k3 repos~3.2kAutomated safety check: PassMIT
Agent Mesh Coordinatorruvnet/ruflo74k3 repos~3.2kAutomated safety check: PassMIT
Agent Queen Coordinatorruvnet/ruflo74k3 repos~1.3kAutomated safety check: PassMIT
Agent Adaptive Coordinatorruvnet/ruflo74k2 repos~4kAutomated safety check: PassMIT
Agent Hierarchical Coordinatorruvnet/ruflo74k2 repos~2.8kAutomated safety check: PassMIT

Similar skills

  • Agent skill for consensus-coordinator - invoke with $agent-consensus-coordinator

    74k GitHub starsUsed in 3 repos~3.2k tokens
    Agent WorkflowsAuto-check passed
  • Agent skill for mesh-coordinator - invoke with $agent-mesh-coordinator

    74k GitHub starsUsed in 3 repos~3.2k tokens
    Agent WorkflowsAuto-check passed
  • Agent skill for queen-coordinator - invoke with $agent-queen-coordinator

    74k GitHub starsUsed in 3 repos~1.3k tokens
    Auto-check passed
  • Agent skill for adaptive-coordinator - invoke with $agent-adaptive-coordinator

    74k GitHub starsUsed in 2 repos~4k tokens
    Data & AnalyticsAuto-check passed
  • Agent skill for hierarchical-coordinator - invoke with $agent-hierarchical-coordinator

    74k GitHub starsUsed in 2 repos~2.8k tokens
    Agent WorkflowsAuto-check passed
  • Agent skill for memory-coordinator - invoke with $agent-memory-coordinator

    74k GitHub starsUsed in 2 repos~1.2k tokens
    Agent WorkflowsAuto-check passed

More from LunCoSim/lunco-sim

All 38 skills in this repo
  • Nightly Changelog

    LunCoSim/lunco-sim

    Generate concise LunCoSim nightly GitHub release notes with platform downloads, installation guidance, an AI-agent mission prompt, and a changelog link.

    105 GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Build or repair a reusable scene component through a live LunCoSim Editor session.

    105 GitHub stars~4.4k tokensUpdated today
    Auto-check passed
  • Assembly Quality

    LunCoSim/lunco-sim

    Build or review a componentized LunCoSim USD assembly with a realistic, dimensionally checkable presentation.

    105 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Author Rhai Tests

    LunCoSim/lunco-sim

    Author and review LunCoSim behavioral, asset-backed, component, mission, visual, and requirements-verification tests.

    105 GitHub stars~3.5k tokensUpdated today
    Auto-check passed
  • Author Rhai Tool

    LunCoSim/lunco-sim

    Create, extend, register, or debug a reusable LunCoSim Rhai tool library for live USD authoring, component linting, inspection, or test support.

    105 GitHub stars~5.2k tokensUpdated today
    Auto-check passed
  • Author Tutorial

    LunCoSim/lunco-sim

    Author an interactive tutorial, guided lesson, onboarding flow, coach-mark tour, or objectives checklist in LunCoSim.

    105 GitHub stars~1.4k tokensUpdated today
    Auto-check passed

Questions about Coordinate Frames

What does Coordinate Frames do?

A skill your agent uses when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view…. Coordinate Frames is an agent skill from LunCoSim/lunco-sim. Use when a rover, camera, terrain tile, trajectory, planet, or link jitters, moves in the wrong direction, changes altitude while stationary, loses its orientation after a view switch, or when adding a new orbital/body-fixed reference frame.

When should I use Coordinate Frames?

Coordinate Frames fits situations like: moves in the wrong direction; changes altitude while stationary; loses its orientation after a view switch; adding a new orbital/body-fixed reference frame.

How do I install Coordinate Frames in Claude Code?

Run `npx skills add LunCoSim/lunco-sim --skill coordinate-frames -a claude-code`. Or copy the skill folder (skills/coordinate-frames in LunCoSim/lunco-sim) into .claude/skills/coordinate-frames in your project. Claude Code loads it when a task matches its description.

How do I install Coordinate Frames in Codex?

Run `npx skills add LunCoSim/lunco-sim --skill coordinate-frames -a codex`. Or copy the skill folder (skills/coordinate-frames in LunCoSim/lunco-sim) into .agents/skills/coordinate-frames in your project. Codex loads it when a task matches its description.

Can I use Coordinate Frames 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 LunCoSim/lunco-sim --skill coordinate-frames -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/coordinate-frames, .gemini/skills/coordinate-frames, .github/skills/coordinate-frames and .opencode/skills/coordinate-frames in your project.

What does Coordinate Frames need to run?

Going by SKILL.md and its folder, Coordinate Frames needs the command-line tools its instructions call (cargo).

Does Coordinate Frames 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 Coordinate Frames 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 Coordinate Frames use?

Coordinate Frames is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Coordinate Frames use?

About 4k 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 Coordinate Frames?

Skills that share tags, products or a category with Coordinate Frames: Agent Consensus Coordinator (ruvnet/ruflo, 74k stars), Agent Mesh Coordinator (ruvnet/ruflo, 74k stars), Agent Queen Coordinator (ruvnet/ruflo, 74k stars) and Agent Adaptive Coordinator (ruvnet/ruflo, 74k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Coordinate Frames?

LunCoSim (a GitHub organization) maintains it in LunCoSim/lunco-sim, which has 105 GitHub stars. The repository holds 38 skills in this directory. The repository was last updated on October 7, 2026.

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