# Specialist Registry

This file is generated by Shrey Junior.
Profile: `{{profileName}}`
Detected project type: `{{projectType}}`

Use this registry to choose the smallest specialist that matches the work. It is the portable definition layer. Repo-specific `.agent/roles/*.md` and `.github/agents/*.md` are only installed when relevant.

## How To Use It

- Read first: explicit repo authority, `.agent/state/active-role-hints.json`, `.agent/state/current-phase.json`, `.agent/memory/current-focus.json`, latest checkpoint, then this file.
- Allowed write targets: stay inside repo-owned files plus the specific task packet or handoff scope.
- Handoff rule: finish with evidence, checks run, unresolved risks, next file, and next command.
- Stop rule: stop when the task crosses policy, ownership, or validation boundaries you cannot prove safely.

## Curated Specialists

### `python-specialist`

- Purpose: Python implementation work in app, service, script, or infra-supporting repos.
- Allowed MCP categories: core-pack, research-pack, aws-pack when repo authority justifies it.
- Required checks: the narrowest Python test, lint, or typecheck available.
- Best next handoff: `qa-specialist` or `security-specialist`.

### `backend-specialist`

- Purpose: server-side API, service, persistence, and contract-safe backend delivery.
- Allowed MCP categories: core-pack, research-pack, aws-pack for AWS repos, and web-qa-pack when browser evidence matters.
- Required checks: the narrowest backend validation plus explicit contract side-effect review.
- Best next handoff: `review-specialist`, `qa-specialist`, or `security-specialist`.

### `frontend-specialist`

- Purpose: UI implementation and review with clear browser evidence and repo-aware design boundaries.
- Allowed MCP categories: core-pack, web-qa-pack, research-pack.
- Required checks: the narrowest frontend build/test loop plus browser evidence when behavior changed.
- Best next handoff: `qa-specialist` or `review-specialist`.

### `fullstack-specialist`

- Purpose: TypeScript or Node implementation work, especially app and web repos.
- Allowed MCP categories: core-pack, web-qa-pack, research-pack.
- Required checks: the narrowest build, typecheck, or test loop available.
- Best next handoff: `qa-specialist` or `review-specialist`.

### `data-platform-specialist`

- Purpose: schema, migration, query, transform, and data-boundary work.
- Allowed MCP categories: core-pack, research-pack, aws-pack only when repo authority explicitly calls for it.
- Required checks: migration or query proof, plus the narrowest data validation available.
- Best next handoff: `qa-specialist`.

### `android-specialist`

- Purpose: Android or Kotlin mobile implementation and review.
- Allowed MCP categories: core-pack, android-pack, research-pack.
- Required checks: repo-local Android build/test commands only; do not imply Android MCP parity.
- Best next handoff: `qa-specialist`.

### `ios-specialist`

- Purpose: iOS, Swift, SwiftUI, or Xcode-bound work.
- Allowed MCP categories: core-pack, ios-pack, research-pack.
- Required checks: repo-local Xcode or Swift validation; use Xcode bridges only when actually available.
- Best next handoff: `qa-specialist` or `review-specialist`.

### `qa-specialist`

- Purpose: validation, acceptance gaps, regression spotting, and test evidence.
- Allowed MCP categories: core-pack, web-qa-pack, research-pack.
- Required checks: verify what ran, what passed, and what remains unproven.
- Best next handoff: `review-specialist` or `release-specialist`.

### `review-specialist`

- Purpose: general code review, reconcile, and correctness/risk synthesis across specialist outputs.
- Allowed MCP categories: core-pack, research-pack.
- Required checks: findings first, missing evidence called out explicitly, and contradictions resolved before checkpointing.
- Best next handoff: `release-specialist` or the next implementation specialist.

### `security-specialist`

- Purpose: auth, permission, exposure, secret-handling, and unsafe-boundary review.
- Allowed MCP categories: core-pack, research-pack, aws-pack for AWS repos only.
- Required checks: explicit security-sensitive diff review and missing-proof callouts.
- Best next handoff: `review-specialist` or `release-specialist`.

### `refactor-specialist`

- Purpose: refactor, performance, scaling, and runtime-risk review.
- Allowed MCP categories: core-pack, web-qa-pack, research-pack.
- Required checks: smallest meaningful perf/build/test proof available.
- Best next handoff: `review-specialist`.

### `docs-specialist`

- Purpose: architecture docs, onboarding, task summaries, memory cleanup, and contract clarity.
- Allowed MCP categories: core-pack, research-pack.
- Required checks: align docs with repo-local truth, not memory or chat assumptions.
- Best next handoff: `architecture-specialist` or the actual next worker.

### `architecture-specialist`

- Purpose: decide who should work next, what they should read, and what proof they owe.
- Allowed MCP categories: core-pack, research-pack.
- Required checks: packet or handoff completeness, not implementation checks.
- Best next handoff: whichever specialist is named next.

### `push-specialist`

- Purpose: conservative push-readiness review before anyone recommends staging, committing, or pushing.
- Allowed MCP categories: core-pack, research-pack.
- Required checks: validate reconcile state, validations, and git cleanliness without mutating git state.
- Best next handoff: `release-specialist` or the user.

### `release-specialist`

- Purpose: synthesize multi-role outputs into a coherent next action.
- Allowed MCP categories: core-pack, research-pack.
- Required checks: compare evidence, risks, and unresolved contradictions before recommending next steps.
- Best next handoff: `docs-specialist`, `push-specialist`, or the user.

### `mcp-specialist`

- Purpose: choose and explain MCP packs or capability usage without inventing runtime guarantees.
- Allowed MCP categories: core-pack, research-pack, web-qa-pack, aws-pack, ios-pack, android-pack.
- Required checks: match pack guidance to repo type, runtime reality, and approval policy.
- Best next handoff: whichever specialist now has a credible tool plan.

## Compatibility Aliases

- `python-implementer` -> `python-specialist`
- `typescript-implementer` -> `fullstack-specialist`
- `sql-specialist` -> `data-platform-specialist`
- `security-reviewer` -> `security-specialist`
- `performance-reviewer` -> `refactor-specialist`
- `handoff-editor` -> `docs-specialist`
- `dispatcher` -> `architecture-specialist`
- `reconciler` -> `review-specialist`
- `release-readiness` -> `release-specialist`
