Admin Groups

Manage group membership and admin permissions in L1 group.yaml files.

5|Updated May 6, 2026
One-click install
npx skills add https://github.com/binary16labs/prime-silo --skill admin-groups-binary16labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Admin Groups
Source: https://github.com/binary16labs/prime-silo/tree/main/app/L0/_admin/mod/_core/overlay_agent/ext/skills/admin-user-management/groups
Command: npx skills add https://github.com/binary16labs/prime-silo --skill admin-groups-binary16labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps administrators clearly create and maintain group membership, manager inheritance, and special-group behavior without accidentally breaking the canonical group contract stored in group.yaml.

Core Features & Use Cases

  • Explain the canonical group model: maps how membership vs manager permissions work and where runtime-managed data must live (L1/<group>/group.yaml).
  • Guide group creation and updates: shows the correct way to write included_users, included_groups, managing_users, and managing_groups to group.yaml.
  • Manage admin escalation: documents the safe, canonical way to grant or remove admin access via L1/_admin/group.yaml.

Quick Start

Use the Admin Groups skill to update L1/team-red/group.yaml by adding alice to included_users while keeping manager inheritance rules separate and intact.

Frequently Asked Questions about Admin Groups

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

FAQPage Schema
How do I manage group membership and admin access in a group.yaml file?

To manage group membership in a group.yaml file, you update the included_users and included_groups fields for standard membership, while using managing_users and managing_groups to define manager permissions, ensuring you follow the canonical read-parse-normalize-write workflow.

What is the canonical way to grant workspace admin access via group.yaml?

Granting workspace admin access requires updating the L1/_admin/group.yaml file by adding the target user to the included_users array, which safely applies admin permissions without violating the canonical group contract.

How does manager inheritance and special-group semantics work in an institutional skill registry?

Manager inheritance is controlled by separating managing_users and managing_groups from standard membership fields, while special-group semantics dictate that _admin membership handles escalation and _all defines universal membership behavior.

How do I safely update group.yaml fields without breaking the canonical group contract?

Safely updating group.yaml fields requires a read-parse-normalize-write process that strictly maintains the separation between membership rules and manager permissions, avoiding incorrect placement of rules in L1 directories.

Can I edit group.yaml directly to add a user to included_users without breaking manager permissions?

Yes, you can add a user to the included_users array in group.yaml directly, provided you keep the manager inheritance rules defined in managing_users and managing_groups separate and intact during the update.