admin-dashboard

Build a complete admin UI for this specific website: its own information architecture, vocabulary, and screens, in its own design. The admin for a newsletter, a marketplace, a course platform, and a portfolio should look and work differently, because their operators do different things. Everything shown comes from the application's real models and operations. If one exists already, improve it; if none does, build it.

Activate when

• The user asks for an admin dashboard, admin panel, back office, CMS-style management, or "a way for me to manage this".
• The product has data or workflows nobody can operate: submissions, users and roles, content or listings, orders and subscriptions, support requests, reported content, privacy requests, email suppression.
• An admin exists and needs improving, or a launch review (launch-all, production-all) found an operator task with no screen.
• Not for a site with nothing to operate and no request for one.

Working alone

This skill is self-contained. Its companions (declared in its metadata) are skills whose method it may need to do its own promised work. Use of a companion can be conditional: declaring one does not mean running it. When a companion's lane applies, use the skill if it is installed; if not, follow its short entry in references/companion-methods.md and say in your report which lanes ran inline at reduced depth. Never skip an applicable lane silently. Skills mentioned here only for escalation, referral, documentation, or optional deeper follow-up are not dependencies: report the hand-off and finish honestly.

Companions: design-system-reconnaissance, admin-authorization, admin-audit-log, data-rights, wcag-readiness, forms-readiness, mobile-readiness, failure-resilience.

Inspect