Build locally with AI

Choose the editor and agent directory

After connecting a project and running the first App in the Quickstart, open my-project/my-app as the editor or coding agent's working directory. Substitute your own folder names. App development needs no Core, SDK or sandbox-manager source checkout.

The project directory groups Apps and binds them to a Developers project. Each App directory is its own development and Git unit. Have the agent read the generated AGENTS.md, nexia.json and docs/ first; preserve existing instructions.

Location	Work
`my-project/`	Connect with `nexia connect <project-id>` and run the project's `nexia dev`
`my-project/my-app/`	Edit source, generate resources and pages, install dependencies, run `nexia check`
Sandbox workspace	Check screens, permissions and persisted results

Keep the project's nexia dev terminal running. Use a second terminal inside the App for development commands. An agent shell may not inherit your terminal environment. For an alternate platform, supply the endpoint, CLI configuration directory and any required environment activation procedure, then enter the App and check connectivity in that same shell. Do not share tokens or authentication file contents.

Code example

Shell

# Run inside the App directory
nexia status12

Confirm connected and the intended project and sandbox. Source validation success does not establish connectivity. Do not start a duplicate watcher or silently switch the connection target.

Extend resources, fields and forms

The first CRUD screen is a starting point. Complete a business task across the following layers. All paths below are relative to the App root.

Task	Implementation and completion criteria
Add a resource	`nexia make resource` generates model, API, policy and screen scaffolding; business rules still need implementation
Add fields	Add a new migration in `database/migrations/tenant/`, update `src/Models/`, Controller validation and responses, and frontend types
Edit forms, details and lists	Wire draft, submission and saved baselines in `resources/js/resources/`, read displays and list columns; add labels in `resources/lang/`
Filters, sorting and permissions	Keep `src/Contribution/Resources/` declarations, actual queries and `src/Policies/` consistent
Relate resources	Implement same-App relationships with authorization; use public SDK references for other Apps rather than querying their tables
Build a separate workflow page	`nexia make page` scaffolds the page; implement its API, queries, persistence and permissions. Unimplemented controllers return 501

For example, retain Note and add customers and tasks by running these commands inside the App. This example uses tenant-wide records. Use --record-owner legal_entity and the matching permission scope for legal-entity-owned records.

Code example

Shell

nexia make resource Customer --record-owner tenant --label-ko 고객
nexia make resource Task --record-owner tenant --label-ko 업무12

Do not regenerate resources that already exist. Implement email, due date, task status and customer selection afterwards. A resource may have several creation, editing or business-action forms; each form does not require its own resource.

Follow Data model and migrations to connect a field across the stack and Build an App frontend surface for record and independent pages. Add new migrations instead of changing or deleting applied ones. Decide how existing records receive defaults or satisfy new required fields.

Give the agent a business outcome

With the App directory open, a request can be:

Read AGENTS.md, nexia.json and docs, and work only in this App.
Preserve Note and its data while adding Customer and Task resources.
Customers need email and category; tasks need a due date, status and customer selection.
Implement customer creation → task creation for that customer → task completion.
Connect migrations, validation, permissions, APIs, forms, lists and details.
Add new migrations; do not modify applied migrations.
The project's nexia dev is already running. Do not start another watcher.
Tell me which menus, permissions and steps to use for sandbox UI verification,
and distinguish anything you have not verified.
Do not clone Core, read credentials or invent unsupported APIs.12345678910

Verify the implemented workflow

nexia dev watches changes, builds the frontend and prepares server execution. New files or a successful local build do not prove the server has adopted them. Resolve failed or review-required preparation before retrying.

With Core 0.8.163 and Manager 0.1.0-alpha.89, a source update that is confirmed to have rolled back is marked as failed, allowing a later save to proceed without resetting development data. An uncertain outcome remains blocked for review. Check the preparation status before retrying; do not assume that restarting the watcher resolves it.

Wait for the CLI to confirm the new runtime preparation completed.
Open the App in the workspace. If access is missing, add its permissions to a role in Settings → Credentials and access → Roles, then assign that role and its applicable scope to your user in Access. Creating a role alone does not grant access.
Follow the workspace's refresh prompt and open the new resource from the App menu. Project Apps still contains the same App entry. If the resource is absent even from the role permission catalog, check declaration preparation first.
Verify creation, editing, persistence after refresh, relationship selection, invalid input, permission denial, search, filtering and sorting. Check existing records after adding columns too.
Check unsaved input during a code change, cancellation and reopening, and reconnection without losing intended work or data.

Run nexia check inside the App and choose relevant business checks from Test an App. Report source checks, builds and actual UI results separately. Continue to Release an App when the workflow is ready. AI assistance and App registration do not publish an App automatically.

See the public CLI documentation for command and option details.