Docs Specialists
Specialists
Use this page to pick the right specialist in under 60 seconds. Expand any row below to see when to invoke that specialist, what it produces, when NOT to use it, and an example command. AC (acceptance criteria — the checklist that defines “done”) and CWE (a public catalog of common vulnerability types) show up in a few rows below.
PM /asdt-pm Locks scope and turns vague requests into structured user stories.
- Invoke when…
- The request is vague or user-facing, scope isn't locked, or user stories don't exist yet
- Produces
- pm/handoff — the change in one sentence, stories in delivery order, in/out scope, acceptance criteria, risks
- Do NOT use when…
- You already have a clear backlog entry — re-running PM regenerates stories from scratch
- Example command
-
/asdt-pm "Add dark mode toggle to user settings"
Architect /asdt-architect Decides how the pieces fit together before anyone writes code.
- Invoke when…
- The solution touches service boundaries, data models, or API contracts, or has two viable technical approaches worth documenting
- Produces
- architectural-decision (ADR) + system-design-final — data model, API surface, service boundaries
- Do NOT use when…
- You need implementation code, test plans, or UX specs — Architect produces decisions, not code
- Example command
-
/asdt-architect "Document the decision to use PostgreSQL row-level security for multi-tenancy"
Developer /asdt-developer Turns a settled design into an ordered implementation plan or real code.
- Invoke when…
- The shape of the solution is settled and you need an ordered implementation plan or production code written to the repo
- Produces
- developer/dev-implementation — ordered file manifest and code plan
- Do NOT use when…
- You haven't locked scope or architecture yet — Developer will implement against ambiguous requirements
- Example command
-
/asdt-developer "Implement the multi-tenancy RLS policy from the Architect's ADR"
QA /asdt-qa Turns acceptance criteria into a systematic test plan with a go/no-go verdict.
- Invoke when…
- Code is ready for review, AC exists but hasn't been validated, or you need systematic edge case and boundary coverage
- Produces
- test-plan — AC coverage %, uncovered gaps, full Given/When/Then test case list, quality verdict
- Do NOT use when…
- You want executable test code written — QA produces test specifications, not runnable code
- Example command
-
/asdt-qa "Review the checkout flow for edge cases"
Security /asdt-security Hunts for auth, data, and integration risks before they ship.
- Invoke when…
- The feature touches auth, sessions, PII, external integrations, webhooks, or new public API endpoints
- Produces
- security-findings (severity-rated, CWE-referenced) + hardening-checklist — must-fix vs can-defer
- Do NOT use when…
- You want implementation code or architectural decisions — Security produces findings and checklists only
- Example command
-
/asdt-security "Review the session management in the auth module"
UX/UI /asdt-ux-ui Maps flows and components before implementation starts.
- Invoke when…
- A new screen or feature-level UI needs design before implementation begins, or user flows need mapping
- Produces
- ux-brief (flows, IA, success criteria) + component-spec — inventory of reused/extended/new components
- Do NOT use when…
- The screen has already been built — a UX spec delivered after implementation is too late to shape it
- Example command
-
/asdt-ux-ui "Design a data table component with sorting, filtering, and pagination"
Researcher /asdt-researcher Explores a fuzzy problem before anyone commits to a direction.
- Invoke when…
- The problem is fuzzy or open-ended — you need discovery and framing before requirements can be written
- Produces
- researcher/handoff — problem framing, one recommended direction, every rejected one with its reason, feasibility evidence
- Do NOT use when…
- You already have a defined problem statement — Researcher explores; it does not produce user stories or ADRs
- Example command
-
/asdt-researcher "Explore ways to reduce onboarding drop-off"
When the work spans multiple perspectives, skip the rows above and run /asdt <feature description> — the orchestrator classifies the change and routes it through the right specialists in the right order.
Switching specialists
There is no “wrong” specialist to recover from — specialists work independently, so switching costs nothing. You can run any specialist directly at any point; each one reads prior artifacts from the shared knowledge base automatically. If a request doesn’t fit the specialist you picked, /asdt will recommend a more suitable one.
Example: if you ran /asdt-developer before creating an ADR, run /asdt-architect to produce the decision record, then re-invoke /asdt-developer. The Developer will read the ADR automatically on its next run.
See Troubleshooting for step-by-step recovery procedures.