permission-system
Permission System
Own the whole chain from "who should be able to do what" to code that enforces it: model selection, role and permission analysis, the permission matrix, schema, runtime enforcement, caching, and the tests that prove a normal user cannot reach an admin endpoint.
This skill is language- and framework-agnostic. It describes the model, the algebra, the tables, and the enforcement points; translate them into whatever stack the project already uses.
Authorization only. Authentication — login, passwords, OAuth/SSO, token issuance and refresh — is a separate problem. Assume the request already carries a trusted, verified user identity.
The One Idea Everything Follows From
Permission design is the art of reducing the number of mappings you maintain. Binding permissions directly to users (ACL) means N users × M permissions of hand-maintained edges; every new hire is a config session and every policy change is a sweep. So you insert an intermediary — role, department, position, permission group — and one unmaintainable many-to-many collapses into two small ones.
Every intermediary you add cuts maintenance cost and adds one more place a permission can come from. Add enough of them and nobody — including you, at 2am, with an angry customer on the phone — can answer "why does this user have this button?"
Keeping that question answerable by one query is the constraint that settles most of the design arguments you are about to have. When in doubt, choose the design whose answer is shorter.