AI Internal Admin Dashboard Builder

Most engineering teams have a tier of internal tools that exists only as raw SQL queries pasted into Slack messages. Customer support needs to see a user's recent invoices: somebody on the team writes the query, runs it, copies the result, pastes it. Operations needs to refund an order: somebody writes the SQL, gets the engineer to run it, hopes nothing was typed wrong. Engineering needs to mark a feature flag enabled for a single account: more SQL, more risk, more time spent on tasks the team should be able to do without involving a database administrator. The cost is paid in the engineer hours that go into running these queries by hand and in the bugs that come from typos in production SQL run by people who would rather be doing other work.

An internal dashboard fixes the problem by giving the team a UI to do these tasks safely. The dashboard is not a marketing site; it does not need a hero gradient or a typography system. It needs dense data tables, fast filtering, working pagination, detail views, CRUD forms with validation, and search. It needs to be reliable for the team's daily work and easy to extend when the next data type arrives. Building one well used to take a frontend engineer a week. The /prism-dashboard skill produces the same artifact in hours, calibrated to the team's existing data and component patterns, so the SQL-in-Slack tier can be replaced with a tool people actually want to use.

Why generalist AI builds bad internal tools

Ask Cursor or ChatGPT for an admin panel. You get something that looks like a marketing site: cards with hero images, padding everywhere, a navigation bar that takes 80px of vertical space. Internal tools have different visual priorities. Density matters because the user is scanning many rows. Latency matters because the user is doing many small actions and waiting for each one is painful. Keyboard navigation matters because power users are not going to mouse over every button. The marketing-shaped output looks polished and is operationally bad.

The other failure mode is the missing functionality. A generalist tool builds a list view; it does not build the filter that scopes the list to the user's actual question. It builds a detail view; it does not build the edit form that lets the user fix the bad data they just found. It builds a CRUD form; it does not build the validation that prevents the bad data from being saved in the first place. Each of these is small to add individually and tedious in aggregate. The dashboard that ships from a generalist tool is the dashboard the team uses for a week and abandons because the missing features turned out to be the ones that mattered.

What a useful internal dashboard requires

Internal tools have five core needs. Data tables that support sorting on every column, filtering by the obvious dimensions (date range, status, search), and pagination that does not break when the table is large. Detail views that show all the relevant fields and links to related records. CRUD forms with validation that catches the bad data before it hits the database. Search that finds records by any meaningful field. Bulk actions for the cases where the user needs to update many rows at once. The discipline is to build all of these together, calibrated to the actual data shape, rather than build them piecemeal as feature requests arrive.

The visual layer is also different from marketing UI. Tables are dense (12-row default rather than 6). Padding is tight. Forms are inline rather than modal where possible. Keyboard shortcuts for common actions (Cmd+K for search, J/K for navigation). The styling does not need to be ugly; it needs to prioritize information density and operational speed over visual flourish. /prism-dashboard is calibrated to that priority set.

How /prism-dashboard works

Step one: read the data model

When invoked, /prism-dashboard reads the project's data model (database schema, ORM models, or API spec) to identify the entities and their relationships. The entity list becomes the navigation. The fields per entity become the columns and form inputs. The relationships become the links between detail views (clicking a customer_id on an invoice opens that customer's detail page). Reading the model is what makes the dashboard match the actual data rather than imagined data.

Step two: build the table primitive

The data table is the dashboard's most-used component. The skill builds it with sorting (clickable column headers), filtering (a filter bar with type-aware inputs: date range for timestamps, multi-select for enums, search for free-text), and pagination (cursor-based by default to handle large tables without performance degradation). Bulk selection is supported with row checkboxes and a bulk action menu when rows are selected. Keyboard navigation moves selection up/down with J/K and opens the detail view with Enter.

Step three: detail views and CRUD forms

Each entity gets a detail view (drawer or full page based on the data density) showing all fields with links to related entities. The form for creating or editing an entity has validation that matches the database constraints: required fields are required, enums are constrained, format validation runs on email/URL/etc. The form posts to the existing API rather than directly to the database, so existing business logic and audit logging is preserved.

Step four: search, shortcuts, and access control

Global search finds records across entities by any meaningful field. Keyboard shortcuts cover the common actions. Access control is integrated with the project's existing auth so the dashboard respects the team's role boundaries (a support agent sees the customer view but not the billing edit). The skill scaffolds the access checks at the route level rather than only in the UI, so a sufficiently determined user cannot bypass the role check by hitting the API directly.

Tonone's /prism-dashboard skill builds internal admin tools with dense data tables, detail drawers, CRUD forms, search, and keyboard shortcuts calibrated to operational use rather than marketing aesthetics.

When to use /prism-dashboard, and when not to

/prism-dashboard is the right call when engineers or operations teams need a UI for data they currently access only via SQL or the API, when building an admin panel or back-office interface, or when an existing internal tool is incomplete (list view exists, but no edit form, or pagination breaks at scale).

Skip the skill for customer-facing UI (use /prism-ui for full-screen production-grade implementation). For component-level work, /prism-component produces reusable primitives. For chart and dashboard data visualization, /lens-dashboard is calibrated to analytics use cases rather than CRUD operations.

A worked example: support dashboard

Suppose the brief is: build a support dashboard so customer service can look up users, view their invoices, and adjust subscriptions. Run /prism-dashboard against the existing data model.

// app/admin/users/page.tsx (excerpt)
'use client';

import { DataTable } from '@/components/admin/DataTable';
import { useUsers } from '@/hooks/admin/users';

export default function UsersPage() {
  return (
    <DataTable
      title="Users"
      query={useUsers}
      columns={[
        { key: 'email', label: 'Email', sortable: true, search: true },
        { key: 'name', label: 'Name', sortable: true, search: true },
        { key: 'plan', label: 'Plan', filter: 'enum', options: PLANS },
        { key: 'created_at', label: 'Joined', sortable: true, filter: 'dateRange' },
        { key: 'last_active_at', label: 'Last active', sortable: true, filter: 'dateRange' },
      ]}
      rowAction={(user) => `/admin/users/${user.id}`}
      bulkActions={[
        { label: 'Send password reset', handler: bulkPasswordReset },
        { label: 'Export to CSV', handler: bulkExport },
      ]}
      shortcuts={{ search: 'cmd+k', new: 'n' }}
    />
  );
}

// Detail view (drawer) opens on row click:
// - Profile fields
// - Recent invoices (linked table)
// - Active subscription with adjust action
// - Audit log (last 50 entries)
//
// Edit form: validates email format, plan enum,
// dispatches PUT /api/admin/users/:id with the existing
// admin route guard and audit logging.

The team's customer service uses the dashboard for the daily lookups instead of asking engineering to run SQL. The data model determines the table shape, the validation matches the database constraints, the access control respects the existing role boundaries. The SQL-in-Slack tier disappears, and engineering reclaims the hours that used to go into being a manual database client.

Related skills

/prism-dashboard builds admin tools. For customer-facing screens, /prism-ui is the right call. For reusable component primitives, /prism-component covers individual components. For analytics-style dashboards (charts, KPIs), /lens-dashboard is calibrated to that use case.

Install

/prism-dashboard ships with the Prism agent in the Tonone for Claude Code package. Install Tonone, invoke /prism-dashboard from any Claude Code session, and the skill produces an internal dashboard calibrated to the project's data model and access control.

Internal tools that the team actually wants to use are the ones built for operational density rather than marketing polish. The skill is built for that priority.