Layers And Ownership

Clarify L0, L1, and L2 layer ownership and override resolution for frontend assets.

5|Updated May 6, 2026
One-click install
npx skills add https://github.com/binary16labs/prime-silo --skill layers-and-ownership-binary16labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Layers And Ownership
Source: https://github.com/binary16labs/prime-silo/tree/main/app/L0/_all/mod/_core/skillset/ext/skills/development/layers-ownership
Command: npx skills add https://github.com/binary16labs/prime-silo --skill layers-and-ownership-binary16labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents broken permissions and confusing overrides by clarifying how layer placement, group/user structure, and authorization rules determine what you can read or write.

Core Features & Use Cases

  • Explains L0/L1/L2 placement semantics: distinguishes firmware-owned repo code (L0) from group customware (L1) and user customware (L2).
  • Maps group and user storage layout: documents the canonical locations for user metadata, auth state, module roots, and group membership configuration.
  • Defines permission and resolution order: details who can read/write each layer and how higher-ranked modules override lower-ranked ones, including compositional behavior across filenames.

Quick Start

Use this skill to decide whether a change belongs in app/L0/_all/mod/_core, app/L1/_all or app/L1/<group>, or app/L2/<username>, and to predict how overrides will resolve across groups and users.

Frequently Asked Questions about Layers And Ownership

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do frontend asset overrides resolve across L0, L1, and L2 layers?

Frontend asset overrides resolve through a ranked order where higher-ranked L2 user customware overrides L1 group customware, which overrides L0 firmware-owned repo code, combining matches by path and extension.

What is the difference between L0, L1, and L2 filesystem layout for custom code?

The filesystem layout distinguishes L0 as firmware-owned repo code, L1 as group customware stored in app/L1/_all or app/L1/<group>, and L2 as user customware stored in app/L2/<username>.

How do I choose the correct layer and path for storing new frontend files?

Choose the correct layer by checking read/write authority rules: place baseline code in app/L0/_all/mod/_core, group shared assets in app/L1/<group>, and individual operator assets in app/L2/<username>.

Can managing-group and admin access controls restrict read and write permissions per layer?

Yes, managing-group and admin access controls enforce read and write authority rules for each layer, preventing broken permissions by restricting who can modify L0, L1, and L2 filesystem locations.

Where are user metadata, auth state, and group membership configuration stored in this layout?

User metadata, auth state, module roots, and group membership configuration are stored in canonical locations mapped across the L0, L1, and L2 group and user filesystem structure.

Why are my frontend asset permission overrides not working as expected?

Overrides fail when layer placement violates managing-group read/write authority rules, or when compositional override resolution by path and extension conflicts with the ranked L0, L1, and L2 resolution order.