القائمة
Assign correct frame levels in YAML when nesting > 0. Use when creating or modifying a frame YAML that contains containers (items with children). Ensures siblings share the same visual class.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Sync broader design-language specs into the diagram system. Use when importing typography, spacing, or grid rules from the upstream design language into tokens.ts, shared renderer constants, draw.io style sync, or layout helpers.
Redraw rough sketches or inconsistent diagrams into on-brand SVG and draw.io outputs. Use when adding a new diagram slug, translating a rough source into generator code, picking local icons, wiring compare pages, or producing editable outputs.
Build and validate diagram-generator outputs. Use when changing renderers, shared primitives, deliverable SVGs, draw.io exports, compare pages, or any diagram slug that needs rebuild, sanitization, and focused output checks.
Safely modify manually edited draw.io files. Use when preparing a review copy, checkpointing an original draw.io file, promoting reviewed changes back, or documenting a revert path for protected manual edits.
| name | level-assignment |
| description | Assign correct frame levels in YAML when nesting > 0. Use when creating or modifying a frame YAML that contains containers (items with children). Ensures siblings share the same visual class. |
| argument-hint | Path to the frame YAML file, or describe the nesting structure |
children:).level: values need to be set or corrected.Level assignment is an authoring-time rule. It follows from the
deepest nesting among siblings, not from each item's own children.
By default, the engine requires explicit level: fields in YAML - it
does not guess levels from structure. This procedure tells you how to
choose the right value. Diagrams may opt into a typed meta.frame_roles
profile; those profiles synthesize explicit levels during compile before
style resolution and must be generic, not fixture-keyed.
Let D be the maximum structural child-nesting depth across a sibling
group.
D = 0 → child / leaf (level: 1). Items without children:
and without level: are leaves by default.
D = 1 → parent / panel (level: 2). When any item at a given
depth has structural children, promote all siblings at that depth
to level: 2 - including those without children. A childless panel
is a grey card; that's fine.
D >= 2 → section (level: 3). When any item at a given depth
contains a panel that itself contains structural children, promote
all siblings at that depth to level: 3 - including those that
only wrap leaves directly or have no children at all.
Siblings never mix classes. If one item needs to be a section, all its siblings are sections. If one item needs to be a panel, all its siblings are panels.
Map the nesting. For each depth in the tree, find the maximum nesting depth among siblings.
Assign levels bottom-up.
level: needed in YAML; it's the default.level: 2.level: 3.Set level: explicitly on every headed container in the YAML. Leaves don't need an explicit level.
If a diagram declares meta.frame_roles.strategy, verify that the profile is
the intended generic rule before omitting levels.
Verify sibling consistency. Scan each group of siblings. Every sibling at the same depth must have the same level.
Check hierarchy rules.
level: 0) are layout-only and do not count as a tier.variant: annotation) are exempt from level rules.variant: highlight) keep their structural level; they
only change fill/text contrast.role: separator) are outside the box-tier system.heading: field)
get level 0 automatically and don't count as a tier.resolveStyles() in
packages/layout-engine/src/resolve-styles.ts auto-downgrades at
render time: a panel inside a panel becomes a leaf, a section
inside a section becomes a panel. This is a safety net, not a
feature - set levels correctly in YAML.Levels determine visual treatment automatically through resolveStyles()
(TS: packages/layout-engine/src/resolve-styles.ts). See docs/frame-classes.md for the
complete class table and rendering rules. Do not use inline styling
in YAML.
meta.frame_roles.strategy: root-edge-source-section-target-parent is available
for layered provider/consumer topologies. Root compounds that contain sources of
cross-root arrows become sections (level: 3); root compounds that contain
targets of cross-root arrows become parents (level: 2). Explicit authored
level: values still win.
weight: in label lines. Use heading: for bold text on a frame.fill: in label lines. Use style: muted for grey annotation text.size: in label lines. Font sizes are determined by the class system.Use heading: on the frame for bold heading text:
# Container with heading (gets synthetic __heading child)
- id: my_panel
level: 2
heading: "Panel title"
children:
- id: child1
label: [Content]
# Non-container with heading (heading prepended as bold first line)
- id: my_leaf
heading: "Leaf title"
label:
- Body text below the heading
Planning, Implementation, and Delivery are siblings. Implementation wraps "Dev team" (a panel wrapping leaves) – that's 2-level nesting. Therefore all three are sections (level: 3), even though Planning and Delivery only contain leaves directly.
children:
- id: planning
level: 3 # section – sibling has 2-level nesting
heading: Planning
children:
- id: p_task1
label: [Define scope]
- id: p_task2
label: [Set timeline]
- id: implementation
level: 3 # section – has 2-level nesting
heading: Implementation
children:
- id: devteam
level: 2 # panel – has children
heading: Dev team
children:
- id: dev1
label: [Frontend]
- id: dev2
label: [Backend]
- id: delivery
level: 3 # section – sibling has 2-level nesting
heading: Delivery
children:
- id: d_task1
label: [Deploy]
After assigning levels:
npm --prefix packages/layout-engine test.node scripts/check_no_new_python.mjs from the repo root.