The prompt
Score 10 of 10, Excellent
Use it when Your product needs user roles, and you want a clear matrix of who can see, create, change and delete what, with the open decisions flagged.
- {{product_objects}}
- {{roles}}
- {{customers}}
- {{access_requests}}
- {{rules}}
- {{reviewers}}
Full prompt and why it works
System prompt
You help product teams define user roles and permissions for software. You are precise about each action, you favor the least access a role needs, and you never invent features or objects the product does not have.
User message
<product> {{product_objects}} </product> <roles> {{roles}} </roles> <context> Who our customers are and how their teams are organized: {{customers}} Requests or complaints about access so far: {{access_requests}} Rules we must follow (security reviews, regulations, contracts): {{rules}} </context> Design a roles and permissions matrix for the product above, for {{reviewers}} to review before engineering builds it, so that each role can do its job and nothing more. Produce: 1. The matrix: a table with one row per object and action (view, create, edit, delete, export, share, manage settings, as they apply) and one column per role, with each cell marked Yes, No, or Own (only items the user created). 2. Role descriptions: one sentence per role on who it is for and what it lets them do. 3. Sensitive actions: actions to limit to the fewest roles or to log, such as deleting or exporting data, changing billing or changing other users' roles, each with the reason. 4. Edge cases: what happens when a user's role changes, when the last admin leaves, when an item's owner is removed, and when a user belongs to more than one team. 5. Decisions needed: cells you could not fill from the material, each written as a question. <example> The form of one row: "Invoices: export | Admin: Yes | Manager: Yes | Member: Own | Viewer: No" </example> A good matrix is one an engineer could build from and a customer's admin could explain to their team. Start from no access and add what each role needs, because access is easy to grant later and hard to take back. Use only the objects, actions and roles in the material; if a role seems to be missing, such as a read-only role for auditors, suggest it under Decisions needed rather than adding it to the matrix. If you cannot tell whether a role should have an action, mark the cell "?" and add it to Decisions needed instead of guessing.
Variables
- {{product_objects}}
- The things users work with in your product and what they can do to each, for example "projects, tasks, invoices, reports, team settings, billing".
- {{roles}}
- The roles you have or plan, with a line on each, for example "Admin: runs the account; Member: does the daily work".
- {{customers}}
- Who your customers are and how their teams are set up, for example "agencies with 5 to 40 staff, split by client".
- {{access_requests}}
- What customers have asked for or complained about regarding access. Write "none" if nothing yet.
- {{rules}}
- Security, regulatory or contract rules on access, for example "audit log of all exports", or "none known".
- {{reviewers}}
- Who reviews the matrix, for example "the PM, the tech lead and the security lead".
Why it works
- What good looks like. Access starts from none and is added role by role, the least-access rule that keeps the matrix safe to build from.
- An example. A sample row shows the Yes, No and Own values, so the whole matrix comes back in one consistent form.
- If unsure. Cells the material cannot settle are marked "?" and turned into questions instead of filled with a plausible guess.