scenic-code

name	scenic-code
description	Use when the user asks to write, edit, debug, explain, or review Scenic code, Scenic scenarios, Scenic simulator integrations, or Scenic syntax errors. Especially useful for Scenic object specifiers, requirements, behaviors, modular scenarios, temporal logic, Python integration, and loop/iteration constraints.

Scenic Code

Overview

Use this skill for Scenic language work. It is designed to be self-contained enough that another Codex instance can write Scenic from local skill context without needing to search the web.

Default to generic Scenic unless the target repo clearly defines a project-specific world model, simulator bridge, or custom Scenic vocabulary.

Workflow

1. Determine whether the task is generic Scenic or repo-specific Scenic.
2. Inspect the target repo for:
   • model ... imports
   • custom Scenic classes and properties
   • simulator wrappers or Simulator / Simulation subclasses
   • existing .scenic examples and test files
3. Read the relevant local references from this skill before writing code.
4. Write Scenic using generic constructs unless the repo clearly requires project-specific classes or properties.
5. Check the result for Scenic-specific failure modes before finishing.

Task Routing

• For new Scenic files from scratch, start with references/core-language.md.
• For dynamic scenarios, behaviors, monitors, temporal logic, or composition, also read references/dynamics-and-statements.md.
• For Python-side scenario loading, simulator wrappers, replay, or backend debugging, read references/apis-and-integrations.md.
• For built-in driving-domain or simulator-oriented work, read references/domains-and-simulators.md.

Reference Map

Read these files as needed:

• references/scenic-reference.md
  • Start here for routing and quick reminders.
• references/core-language.md
  • Read for syntax, types, classes, object creation, specifiers, distributions, operators, regions, requirements, loops, and gotchas.
• references/dynamics-and-statements.md
  • Read for behaviors, monitors, modular scenarios, composition, temporal requirements, record, mutate, wait until, interrupts, and overrides.
• references/apis-and-integrations.md
  • Read for Python APIs, simulator integration patterns, serialization, replay, helper functions such as localPath and resample, and backend verification rules.
• references/domains-and-simulators.md
  • Read for driving-domain patterns, simulator options, example idioms, and implementation-oriented notes.

Generic-First Rules

• Do not assume downstream repo-specific model names, object classes, asset metadata properties, or simulator-only helper fields unless the target repo explicitly defines them.
• Prefer built-in Point, OrientedPoint, and Object, or classes imported from the repo's own Scenic world model.
• Treat coordinates, quaternion formats, simulator APIs, camera semantics, and dynamic property semantics as backend-specific details to verify from local code.

Authoring Checklist

• Use new for object creation.
• Scenic classes can define methods and attributes, but most scenario code should still rely on property defaults, specifiers, and helper functions.
• Add model ... only when the target domain or repo actually requires it.
• Use param ... for externally supplied configuration rather than hard-coding everything in module-level constants.
• Prefer contained in region when the whole bounding box must fit.
• Keep hard requirements coherent to avoid pathological rejection sampling.
• Use loops to avoid repetitive Scenic when creating many objects or pairwise constraints.
• In behaviors and monitors, every loop must yield with take, wait, or do.

Review Checklist

• Verify every custom property referenced in Scenic is actually defined by the target world model.
• Verify simulator-facing code matches the real backend API and data conventions.
• Check for top-level random control flow and nondeterministic top-level loop bounds.
• Check whether in should be contained in.
• Check whether visibility, collision, and workspace requirements are stronger than intended.
• Check that imported actions, behaviors, and classes actually exist in the selected world model.