Date: 2026-10-24

​
Best practices

A good Nova request defines the result, the boundary, and the evidence needed to accept the work.

​
Start with an outcome and constraints

Say what should change and what must not change.
Name relevant files, compatibility requirements, performance limits, or release constraints when you know them. Nova can then inspect the local implementation rather than inventing a pattern.

​
Separate investigation from implementation

For unclear failures, first ask for a diagnosis without edits. Approve the proposed fix only after you have reviewed the cause and scope. This avoids changing code to mask a symptom.

​
Ask for evidence

State how completion will be checked: a focused test, a type check, a build, a lint command, or a manual scenario. A passing command validates only the state it checked; review the output and the diff together.

​
Keep scope small

Ask Nova to make the minimum change that satisfies the task. Split unrelated changes into separate requests, especially when they touch different services, public interfaces, or deployment paths.

​
Treat credentials and external systems carefully

Do not paste secrets, private keys, access tokens, or production data into prompts. Use the configured authentication and integration paths instead. Be explicit before asking Nova to send messages, create cloud resources, publish changes, or alter production-facing systems.

​
Review before irreversible actions

Inspect Git status and the staged diff before a commit. Treat commits, pushes, deployments, dependency removals, and destructive commands as deliberate checkpoints. Nova’s approval flow is a guardrail, not a substitute for your review.

​
Keep project guidance current

Nova can read repository instructions and configuration. Keep those instructions specific: record supported commands, coding conventions, validation requirements, and ownership boundaries close to the project.