What this prompt does
This prompt takes your product name, type, required admin features, and target team sizes, then generates a complete admin/settings architecture — not just wireframe labels but actual structured output covering eight distinct areas from the settings sidebar down to API key management. The template enforces a strict two-level maximum for settings nesting, mandates auto-save with visible status indicators, and explicitly bans hiding destructive actions — all encoded directly into the Industry Design Rules block so the model cannot drift into generic SaaS conventions.
What makes it work is the specificity of the framework variable at the end. Instead of producing conceptual prose, the prompt forces implementation-level output for team management and role permissions in your actual stack. The permission matrix section — features x roles, with custom role creation defined separately — is described in enough structural detail that the model generates something you can map directly to a database schema or authorization layer, not a diagram description.
When to use it
- You are building a multi-tenant SaaS and need to define the settings information architecture before writing a single component.
- Your team is debating how to structure role permissions — owner vs admin vs member vs viewer — and you want a concrete matrix to react to.
- You are integrating a billing system (Stripe, Paddle) and need the plan/proration/invoice UI spec before touching the API.
- You need to scope an audit log feature and want to see a realistic filterable/exportable design before estimating the work.
- A designer is starting on the admin panel and needs a structured reference to inform component decisions.
- You are evaluating whether to build custom SSO/2FA enforcement or use an identity provider, and need the settings surface mapped out first.
Example output
For product_name = Trackflow, product_type = project management, admin_features = SSO + custom roles + usage billing, team_sizes = 5–500, framework = Laravel + Filament:
Settings Navigation
├── General (workspace name, timezone, logo)
├── Team (members, invites, roles)
│ └── Roles & Permissions (matrix: Projects / Reports / Billing / API x Owner / Admin / Member / Viewer)
├── Billing (Pro plan · 47/500 seats · next invoice $423 · proration preview on upgrade)
├── Security (SAML SSO config, 2FA: required for admins, session timeout)
├── Audit Log (actor · action · resource · timestamp · filter by user/date · CSV export)
└── API (keys list · last used · rate limit: 1,000 req/hr · revoke with confirmation)
Filament Resource: TeamMemberResource
- Table: name, email, role (badge), joined, actions [Edit Role | Remove]
- Role select: owner (1 max), admin, member, viewer
- Remove: confirmation modal → transfers ownership check if owner
Pro tips
- The model adjusts permission granularity based on team scale — so set
team_sizesto the realistic upper bound, not aspirational. A 5-person startup does not need a custom role builder; a 500-person enterprise does. The variable is doing architectural work, not just labeling. - If your billing setup uses usage-based pricing (seats, API calls, storage), say so explicitly in
admin_features. The generic billing section the model produces otherwise assumes flat subscription tiers, which will produce the wrong UI surface entirely. - Run the prompt twice: once with your real
framework, once with "framework-agnostic pseudocode." The agnostic pass often reveals cleaner architecture before you commit to implementation details. - The audit log section is the most underspecified part of most admin panels. After running the prompt, follow up immediately: "Expand the audit log: what events are captured, what is the retention policy UI, and how does export handle large date ranges?" The base prompt plants the structure; the follow-up fills it.
- Pair this with your actual authorization package docs (e.g., Spatie Laravel Permission, Casbin) in a second message. Paste the permission matrix output back and ask the model to map it to real gate/policy names — the matrix is abstract until it touches your actual codebase.
