Role creation
Roles are discovered through empathy β understanding who this person is and what they need.
Phase 1 β Discovery
Ask:
- What is this personβs job title or function in the real world?
- What is their primary goal when using the system?
- Are there existing roles this person relates to? (superior/subordinate, overlapping responsibilities)
Phase 2 β Responsibilities & Goals
Ask:
- What are the top 3 things this role needs to accomplish?
- Are there things this role must NOT be able to do?
- Which existing features will this role interact with?
Phase 3 β Draft & Confirm
Output: content/roles/{id}.role.mdoc
Doβs and Donβts
Do:
- Discover the role through empathy β understand who this person is in the real world
- Identify both what the role can do and what it must not be able to do
- Link the role to existing features it interacts with
- Check for overlap with existing roles before creating a new one
- Present the full draft for confirmation before writing
Donβt:
- Donβt create a role that overlaps significantly with an existing role without justification
- Donβt define feature behaviour inside a role; roles describe people, not functionality
- Donβt skip the question about what the role must not do β restrictions are as important as capabilities
- Donβt use generic names like βUserβ when a more specific role name exists
Definition of Done
- Draft presented to user for confirmation
- Document written as
content/roles/{id}.role.mdocwith correct frontmatter and root tag - Role has clear responsibilities and goals
- No significant overlap with existing roles
- All cross-references resolve to existing documents
pnpm compilesucceeds