القائمة
Use when capturing OAS design intent — room requirements, area targets, adjacency rules, circulation rules, or global constraints — before any geometry has been resolved.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when authoring or editing OAS-Core JSON — rooms, walls, openings (doors/windows), curtain walls, roofs, floor slabs, furniture, railings, or annotations in a 2D floor plan.
Use when adding or editing OAS extension blocks — machinery, materials, site, MEP, or Autodesk metadata — that augment a Core or Layout document.
Use when writing or debugging OAS geometry — points, polygons, line segments, arcs, circles, spirals, fillets, units, or coordinate conventions. Load before any geometry-heavy edit.
Use when producing or editing fully resolved OAS-Layout JSON — multi-level plans with levels, rooms, walls, openings, slabs, roofs, furniture, railings, and inter-level connections.
Use when mapping OAS plans to a visual output — SVG, Canvas, or WebGL — including scale, axis orientation, and z-order layering.
| name | oas-program |
| description | Use when capturing OAS design intent — room requirements, area targets, adjacency rules, circulation rules, or global constraints — before any geometry has been resolved. |
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.
oas_program, plan_id, title, description — metadata; plan_id links 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 has id, 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-form rules[]rationale — optional reasoning string per roomboundary_polygon, walls, or coordinates. Resolved geometry lives in OAS-Layout.desired_area_m2 accepts { "min": X, "max": Y } or an exact number. Both are valid per the spec — don't reject a scalar.must_have/must_touch are hard; should_have/should_touch are soft; avoid_touch is a hard negative. There's no separate hard: true field.id, not Layout ids. Layout ids don't exist yet — adjacency targets are program-level ids like "corridor" or "living_kitchen".rules[] are natural-language strings. Solvers parse them heuristically; keep them concise and declarative.See docs/program.md for the complete reference, including constraint composition and adjacency weighting.
oas-layout — the resolved geometry derived from a programoas-core — for the vocabulary of usage values shared with Layout