---
name: identity-and-scope-routing
description: Use when the user asks who they are in Remix, what scope a bound repo maps to, which organization, project, or app is relevant, or when cwd-derived scope must be interpreted safely.
---

# Identity And Scope Routing

Use this skill when identity, cwd context, or directory routing is the main question.

This skill is about scope interpretation, not collaboration mutation.

Recommended sequence:

1. When cwd matters, start with `remix_identity_whoami`.
2. If the question is about the bound repo, ground on the bound app first with:
   - `remix_identity_whoami`
   - `remix_directory_get_app`
   - `remix_context_get_app_overview` when operational context helps
3. Use project or organization reads only when:
   - the user explicitly asked for those scopes,
   - an explicit id was provided,
   - or app-grounded context shows those broader scopes are readable and relevant.
4. When the user asks about a scope outside the current repo context, prefer explicit ids over cwd inference.
5. When listing apps, prefer scoped or ownership-aware discovery before broad readable discovery:
   - prefer `organizationId` or `projectId` when the relevant tenant scope is known,
   - otherwise use `ownership` and `accessScope="explicit_member"` when the user means “apps I can actually work on.”

Important rules:

- In a bound repo, treat the app as the default anchor for scope reasoning.
- Do not assume the bound app's project or organization is readable just because the app is readable.
- Treat warnings on cwd-derived results as meaningful partial context, not as failure.
- If cwd inference cannot safely resolve a broader scope, prefer the app-level answer and explain the boundary.
- Use explicit ids when switching from "what is this repo?" to "tell me about that other org/project/app".
- Do not default to broad unscoped app listing when the task is work-oriented; reserve `accessScope="all_readable"` for explicit public or broad readable discovery.
