When to use
Use this skill when the user is describing what they want rather than what exists: target areas, must-be-near rules, circulation preferences, count of rooms, hard limits. Program is the brief; Layout is the answer. If a polygon or wall coordinate is being emitted, you're in oas-layout territory, not here.
Key fields (the document is a flat JSON object, not typed classes)
oas_program,plan_id,title,description— metadata;plan_idlinks program → layoutdesign_goal— natural-language intent sentence (helps LLM context)global_constraints—target_area_m2,max_area_m2,orientation_preference,climate,accessibility_level, etc.rooms[]— each entry hasid,usage,desired_area_m2,must_have,should_have,adjacency,avoidadjacency— uses prefixed keys:must_touch,should_touch,avoid_touch,must_connect_viacirculation—primary_entry+ free-formrules[]rationale— optional reasoning string per room
Critical rules
- Intent only — no resolved geometry. Program documents must not contain
boundary_polygon, walls, or coordinates. Resolved geometry lives in OAS-Layout. desired_area_m2accepts{ "min": X, "max": Y }or an exact number. Both are valid per the spec — don't reject a scalar.- Constraint strength is encoded by the field prefix, not a flag.
must_have/must_touchare hard;should_have/should_touchare soft;avoid_touchis a hard negative. There's no separatehard: truefield. - Refer to rooms by program
id, not Layout ids. Layout ids don't exist yet — adjacency targets are program-level ids like"corridor"or"living_kitchen". - Circulation
rules[]are natural-language strings. Solvers parse them heuristically; keep them concise and declarative.
Full schema
See docs/program.md for the complete reference, including constraint composition and adjacency weighting.
Related skills
oas-layout— the resolved geometry derived from a programoas-core— for the vocabulary ofusagevalues shared with Layout