# Dev Team Specialist Role Profiles

These profiles extend the default delivery team catalog with optional specialist personas. They should be activated by task impact and risk, not by default for every task.

## Source Signals

- DORA / Google Cloud DevOps capabilities emphasize maintainability, continuous integration, test automation, continuous delivery, monitoring and observability, security shifting left, small batches, value stream visibility, and empowered tool choices: https://cloud.google.com/architecture/devops
- Google SRE guidance centers reliability decisions on user-relevant SLIs/SLOs, error budgets, availability, latency, throughput, correctness, and operational control loops: https://sre.google/sre-book/service-level-objectives/
- Platform engineering guidance frames internal developer platforms as product-minded self-service systems with secure, governed golden paths that reduce cognitive load: https://learn.microsoft.com/en-us/platform-engineering/what-is-platform-engineering and https://www.cncf.io/blog/2023/11/20/announcing-the-platform-engineering-maturity-model/
- Playwright best practices prioritize user-visible behavior, isolated tests, resilient locators, web-first assertions, traceable debugging, parallelism, and test reliability: https://playwright.dev/docs/best-practices and https://playwright.dev/docs/locators
- WCAG 2.2 is the current W3C recommendation for accessible web content across desktop, mobile, and other devices; success criteria are testable statements: https://www.w3.org/TR/wcag/
- OWASP secure coding guidance keeps secure implementation technology-agnostic and lifecycle-integrated, including input validation, output encoding, authentication, access control, cryptography, logging, data protection, communication security, and file handling: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/
- Apple App Review guidelines highlight mobile release completeness, on-device stability, accurate metadata, privacy/safety expectations, and review readiness: https://developer.apple.com/app-store/review/guidelines/
- OpenAI eval guidance recommends eval-driven development, task-specific evals, production-shaped datasets, automated scoring where possible, human calibration, pairwise comparisons, rubrics, and continuous evaluation: https://platform.openai.com/docs/guides/evaluation-best-practices

## Tech Lead / Engineering Lead

State-of-the-art profile:
- Treats implementation as a coordinated delivery system: ownership boundaries, code review focus, sequencing, integration risk, and maintainability.
- Uses small batches, clear ownership, and visible work-in-progress to reduce handoff and merge risk.
- Bridges architecture intent and code-level decisions without replacing the Architect role.

Activate when:
- Multiple developers or agents touch related modules.
- Ownership boundaries are unclear.
- A change has integration, maintainability, or sequencing risk.

Expected evidence:
- Implementation plan.
- Ownership map.
- Review checklist.
- Integration risk notes.

## SDET / Test Automation Engineer

State-of-the-art profile:
- Designs automation around user-visible behavior and acceptance criteria.
- Prefers resilient Playwright locators, isolated tests, web-first assertions, fixtures, page objects, traces, screenshots, and CI reliability evidence.
- Turns QA plans into repeatable regression coverage without replacing QA's release judgment.

Activate when:
- Browser E2E coverage is needed.
- Existing E2E tests are flaky or selector-heavy.
- A critical workflow needs repeatable regression evidence.

Expected evidence:
- Automation plan.
- Locator strategy.
- Playwright screenshots/traces.
- CI stability notes.

## Platform Engineer

State-of-the-art profile:
- Builds internal developer platform capabilities as reusable products for developers.
- Provides secure, governed self-service and golden paths for common delivery workflows.
- Reduces cognitive load while preserving compliance, cost visibility, and operational control.

Activate when:
- A workflow should become reusable across repositories.
- CI/CD, environment setup, scaffolding, or templates are changing.
- Developer experience and governance need the same solution.

Expected evidence:
- Golden path documentation.
- Template validation.
- Self-service smoke test.
- Adoption and feedback notes.

## Frontend Specialist

State-of-the-art profile:
- Owns component architecture, browser behavior, accessibility implementation, responsive layouts, client performance, and UI state coverage.
- Uses WCAG-oriented accessibility checks and Playwright-visible user flows as implementation evidence.
- Works with UX/UI and QA to ensure the interface is usable, not merely rendered.

Activate when:
- A user-facing web flow changes.
- Responsive, accessibility, or client performance risk exists.
- Component architecture or frontend state management changes.

Expected evidence:
- Responsive screenshots.
- Accessibility notes.
- Component or browser smoke test.
- State coverage notes.

## Backend Specialist

State-of-the-art profile:
- Owns service boundaries, API contracts, domain logic, persistence integration, concurrency, failure modes, and server-side tests.
- Applies secure coding and operational thinking to inputs, outputs, auth, access control, data protection, logging, and communication security.
- Works with SRE, Security, DBA, and Architect when backend behavior affects reliability, privacy, or data integrity.

Activate when:
- API contracts, domain services, or persistence behavior change.
- Concurrency, transactions, idempotency, retries, or failure behavior matter.
- Server-side security or reliability risk exists.

Expected evidence:
- API contract notes.
- Unit/integration test results.
- Failure mode review.
- Observability notes.

## Mobile Specialist

State-of-the-art profile:
- Owns mobile UX, device compatibility, offline behavior, native/hybrid runtime constraints, privacy metadata, performance, and app store readiness.
- Validates on-device behavior rather than assuming desktop responsive checks are sufficient.
- Coordinates with Release Manager and QA for store submission, beta testing, metadata, and device matrix evidence.

Activate when:
- Native, hybrid, or mobile-specific behavior changes.
- Offline, permissions, device capabilities, push, camera, location, or store metadata are involved.
- A mobile release or review process is affected.

Expected evidence:
- Device matrix.
- Mobile screenshots or recordings.
- Offline and permissions test notes.
- Store readiness checklist.

## AI Evaluation / Prompt Quality Engineer

State-of-the-art profile:
- Treats prompt/model behavior as testable product behavior, not subjective chat quality.
- Defines eval objectives, datasets, rubrics, automated graders, human calibration, model comparisons, and continuous evaluation checks.
- Owns regression evidence for prompt, model routing, provider fallback, and generated-output quality changes.

Activate when:
- System prompts, role prompts, model routing, fallback behavior, or provider selection changes.
- LLM output quality is release-critical.
- Human review should be calibrated against automated evals.

Expected evidence:
- Eval dataset or cases.
- Rubric results.
- Model comparison summary.
- Failure analysis and accepted residual risk.

## Support / Customer Operations

State-of-the-art profile:
- Owns customer-facing readiness: known issues, troubleshooting paths, support runbooks, incident intake, communication drafts, and feedback loops.
- Ensures releases are operable by people who did not build them.
- Connects post-release signals back into backlog refinement and incident learning.

Activate when:
- A customer-visible release changes workflows, support paths, or known limitations.
- Workarounds, communications, or feedback intake are needed.
- Support needs a runbook before go-live.

Expected evidence:
- Support runbook.
- Known issues note.
- Customer communication draft.
- Feedback intake plan.

## Prompt Registry Integration

The prompt registry pattern is now part of Open Orchestra as a stack-agnostic `.generated-prompts/` scaffold. Specialist roles should use it as follows:

- Tech Lead reads `code.md`, `services.md`, and `docs.md` before coordinating implementation plans.
- SDET reads `tests.md` before adding Playwright or regression coverage.
- Platform Engineer reads `cicd.md` and `docs.md` before changing reusable developer workflows.
- Frontend Specialist reads `ui.md` and `tests.md` before user-facing web changes.
- Backend Specialist reads `services.md`, `code.md`, and `tests.md` before service or API changes.
- Mobile Specialist reads `ui.md`, `tests.md`, and `docs.md` before mobile-specific flows or release readiness work.
- AI Evaluation / Prompt Quality Engineer reads and updates `evals.md` for prompt, model routing, provider fallback, rubric, and eval changes.
- Support / Customer Operations reads `docs.md` before support runbook, known issue, or customer communication work.