GitHub Copilot prompt to build an admin panel
Admin panels are where accidental data loss happens, so the guardrails matter more than the CRUD. This prompt points GitHub Copilot at your existing models and auth, then builds role-hidden routes, an allowlist-driven edit form, and an audit trail, with typed confirmation standing between an admin and a delete.
Last updated
Build an internal admin panel for managing {{resource}} records on top of the existing API. Use @workspace to find the current model fields and auth middleware, then generate routes under /admin guarded by a role check that returns 404, not 403, so the panel's existence is not advertised. Screens: a paginated table with server-side sorting on created date and a text filter, a detail view showing every field read-only, and an edit form covering only fields marked editable in a single config object at the top of the module. Every write goes through the existing service layer, no direct database calls from admin handlers, and each change appends who, when, before, after to an audit_log table. Destructive actions need a typed confirmation, the record's own identifier, not a yes button. Acceptance: a non-admin session hitting /admin sees a 404, and editing one field produces exactly one audit row.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build an internal admin panel for managing users records on top of the existing API. Use @workspace to find the current model fields and auth middleware, then generate routes under /admin guarded by a role check that returns 404, not 403, so the panel's existence is not advertised. Screens: a paginated table with server-side sorting on created date and a text filter, a detail view showing every field read-only, and an edit form covering only fields marked editable in a single config object at the top of the module. Every write goes through the existing service layer, no direct database calls from admin handlers, and each change appends who, when, before, after to an audit_log table. Destructive actions need a typed confirmation, the record's own identifier, not a yes button. Acceptance: a non-admin session hitting /admin sees a 404, and editing one field produces exactly one audit row.
Same task in other tools
Questions about this prompt
Why return 404 instead of 403 for non-admins on /admin?
A 403 confirms the route exists to whoever is probing. A 404 gives nothing away, and legitimate admins never see it, so the only cost is one deliberate choice in the guard middleware.
How do I make more fields editable later?
Add them to the editable config object at the top of the module. That keeps writability changes to a one-line diff a reviewer can see, instead of a form field buried in markup.
Audit rows show identical before and after values. What broke?
The handler snapshotted the record after the service call instead of before it. Re-prompt with the ordering spelled out: read, mutate through the service, then write both snapshots to audit_log.