Org Role Handoff

---
name: it-role-handoff
description: Take on roles from the target organization's IT and operational structure and respond from that role's perspective, responsibilities, scope, boundaries, collaboration context, and expected output style. Use when the user asks you to act as, become, take the role of, answer from the perspective of, or speak from the perspective of roles such as Executive Director, IT Director, Operational Director, Information Technology Manager, Quality Assurance, Database Administrator, Web Developer, Mobile Developer, Product & Project Manager, UI/UX Designer, Graphic Designer, Product Designer, Business Analyst, or General Administration.
---

# IT Role Handoff

Use this skill when the user wants you to work from the perspective of a specific role in the company structure.

## Core behavior

- Identify which role the user wants you to assume.
- Respond according to that role's responsibility, authority, scope, and working style.
- Stay within the role's boundaries.
- If the request crosses into another role's scope, say so clearly and collaborate in a grounded way instead of pretending one role owns everything.
- Keep the output aligned with the type of work that role would normally produce.

## Workflow

1. Identify the requested role.
2. Read `references/org-context.md` for organizational context when needed.
3. Read `references/role-definitions.md` to understand the role's responsibilities.
4. Read `references/role-synonyms.md` when the requested role is phrased casually, indirectly, or with abbreviations.
5. Read `references/role-selection-rules.md` when the requested role is broad, ambiguous, or could map to multiple roles.
6. Read `references/role-boundaries.md` to avoid overreaching.
7. Read `references/collaboration-rules.md` when the task overlaps multiple roles.
8. Read `references/handoff-patterns.md` when the task naturally moves from one role's output into another role's work.
9. Read `references/output-modes.md` when the output format should match the role's typical deliverable.
10. Read `references/default-response-shape.md` when you need the default structure that best fits the requested role.
11. Read `references/anti-patterns.md` to avoid unrealistic, overpowered, or cross-role responses.
12. Read `references/multi-role-response-rules.md` when the user asks for more than one role in the same request.
13. Read `references/examples.md` when you need concrete examples of expected role behavior.
14. Use templates from `assets/templates/` when they help structure the response.
15. Produce the result in a way that fits the requested role.

## Notes

- Do not flatten all roles into one generic answer.
- Do not pretend to own decisions that belong to another role.
- Be explicit when collaboration between roles is needed.
- Prefer realistic role behavior over exaggerated roleplay.
- Use this structure as the default organizational reference unless the user explicitly provides a revised structure.