Act as a senior product engineer building management software. Help me design and implement this system: Management domain and users: [DOMAIN AND USERS] Core workflows and rules: [WORKFLOWS] Existing stack and repository context: [TECH STACK] Data entities and available integrations: [DATA AND INTEGRATIONS] Scope for this response: [REQUESTED DELIVERABLE] Start by translating the workflows into explicit roles, permissions, entities, relationships, states, transitions, and audit events. Distinguish a draft from an approved, active, archived, cancelled, or deleted record where relevant. Identify who can create, edit, assign, approve, export, and view sensitive fields. Do not treat a status field as enough if the workflow needs an approval trail or immutable history. Then produce [REQUESTED DELIVERABLE]. If code is requested, give working code organized by file, with installation or migration commands, types, validation, authorization checks, error handling, and tests for the key business rules. Use the stated stack; if it is missing, propose one minimal stack and label it an assumption before coding. If a full build is too large, implement one vertical slice that creates, lists, updates, and enforces permissions for the central entity. Cover failure cases concretely: concurrent edits, invalid state transitions, duplicate submissions, deleted users, timezone handling for dates, pagination, empty states, and integration retries or webhooks when applicable. Never invent API keys, package behavior, customer data, or compliance certification. Before answering, self-check that every workflow rule has a corresponding data rule, UI behavior, or test. Then check that each mutation enforces authorization server-side, not only in the interface. Ask up to three clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [DOMAIN AND USERS] | Describe the management area and the people who will use the software. | Account management tool for customer success managers, team leads, and finance viewers. |
| [WORKFLOWS] | List the actions, approvals, assignments, and business rules the system must support. | CSMs create account plans, log risks, assign follow-ups, and request renewal discounts; leads approve discounts over 10%; finance can view approved discounts but cannot edit plans. |
| [TECH STACK] | Enter the existing languages, frameworks, database, and repository constraints. | Next.js 15, TypeScript, PostgreSQL, Prisma, Clerk authentication, existing monorepo. |
| [DATA AND INTEGRATIONS] | Describe the records to manage and any systems that exchange data with the app. | Accounts, contacts, plans, risks, tasks, discount requests; import account owner from Salesforce nightly. |
| [REQUESTED DELIVERABLE] | Specify what you want now, such as a schema, architecture, API route, or working feature. | Prisma schema, role-aware API routes for discount requests, and Vitest tests for approval rules. |
How to use
- Paste the prompt with the actual roles, workflow rules, stack, and the smallest feature you need first.
- Read the state transitions and permissions before accepting code; they reveal assumptions that are expensive to change later.
- Run the supplied tests and add one example for a user who should be denied access.
- Follow up with: “Add an acceptance-test matrix for each role and every discount-request state transition.”
Variations
Requirements brief
Use this before coding a new management product.
Create a product requirements brief for [MANAGEMENT DOMAIN]. Users and roles: [USERS]. Current process and pain points: [CURRENT PROCESS]. Required workflows: [WORKFLOWS]. Constraints: [CONSTRAINTS]. Output: goals, non-goals, role-permission matrix, entities, state transitions, acceptance criteria, and open questions. Separate verified requirements from assumptions. Include audit history, retention, exports, and notification needs only where the workflow requires them. Check that every acceptance criterion maps to a stated workflow; ask up to three questions only for missing required inputs.
Database design
Use this to model records and approval history before building APIs.
Design a relational database for [SYSTEM]. Entities and workflow: [ENTITIES AND RULES]. Database and ORM: [DATABASE STACK]. Return an ERD in Mermaid, tables with fields and constraints, indexes, and migration notes. Model ownership, assignments, soft deletion where justified, timestamps, and immutable approval or status history. Explain uniqueness and foreign-key choices in one sentence each. Do not create fields for unstated features. Check that the schema prevents invalid duplicates and preserves who changed a record and when.
Bug triage
Use this to diagnose a broken workflow in an existing tool.
Diagnose this management-software defect. Expected workflow: [EXPECTED BEHAVIOR]. Actual behavior: [ACTUAL BEHAVIOR]. Relevant code and logs: [EVIDENCE]. Stack: [STACK]. Return a ranked list of likely causes, the smallest safe fix, and tests that would have caught it. Trace the path through validation, authorization, persistence, and asynchronous jobs as applicable. Do not claim a root cause without evidence; mark assumptions. Check that the fix preserves valid workflow transitions and cannot expose records across tenants.
Tips
- Model approval history as records or events when an approval can be reversed, delegated, or audited; a single boolean loses the reason and actor.
- Make permission tests cover direct API calls, because hiding an interface button does not protect a server endpoint.
- Define idempotency for actions that may be retried, such as imports, webhooks, and approval submissions.
- Store timestamps in UTC and define the display timezone separately for deadlines, service windows, and reports.
FAQ
Can AI build an entire management app from one prompt?
It can accelerate a well-scoped vertical slice, but permissions, integrations, and operational rules need review against real workflows before production use.
What requirements matter most at the start?
Roles, approval rules, state changes, data ownership, and what must be auditable. These decisions shape the database and API more than screen layout does.
Should every record support deletion?
Not necessarily. Management systems often need archive or soft-delete behavior to preserve reporting and audit history.