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.

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: , , , , , , , .

1. Is there an admin already? Search for , , , role checks, admin API routes ( lists them). If yes, read it, list what it covers and misses, and improve it in place. If the project already uses an admin framework (react-admin, Refine, AdminJS, Payload, Strapi), extend it instead of building a parallel one.

2. Inventory the application. Run the helper (path relative to this skill's folder):

node scripts/inventory-data-model.mjs --root .

It lists entities and columns from Prisma, SQL migrations, Drizzle, and Mongoose, flags personal-data, secret-like, soft-delete, role, and owner columns, and reports the stack (auth, database, payments, email), the UI kit and table library, and existing admin routes. It shows what is defined, not what is populated, and names stores it cannot read (Firestore, TypeORM, Sequelize): read those from code. Then read the app itself: auth and how roles work, the routes and features, forms and submissions, payments and subscriptions, user content and reports, email, and privacy flows ().

3. Write the admin brief. Follow section 0 of references/admin-blueprint.md. Decide, from this product: who the operators are and their five most frequent tasks; the product's own vocabulary; the navigation order and grouping; the landing view; the navigation idiom, density, and personality copied from the existing site; where to invest real workflow depth and where a simple list is enough; the right view for each entity (table, calendar, board, media grid). Ask the owner only about facts the code cannot tell you.

4. Inspect the design system before writing UI. Run : tokens, components, layout shell, table/form/dialog patterns, navigation, motion, voice. Build every screen from them. Never introduce a new UI kit or a ReadyVibe look.

5. Review what the admin will touch: sensitive fields to minimize or mask, destructive actions and the audit trail they need (), and how deletion really works ().

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.

Build or improve the admin using the project's stack and existing design system, shaped by the brief:

"Admin dashboard complete", "secure", or "operators can manage everything". Describe exactly which tasks it supports and what remains out of scope. Never present placeholder or invented figures as live.

The user did not ask for an admin and existing tools (provider dashboards, the database console) already cover every operator task. Then report the runbook step for each task instead of building screens nobody needs.