Date: 2026-09-11 Date: 2026-09-10

​
Explore, plan, code, verify, commit

Use an evidence-based workflow to understand the change, make the smallest coherent edit, and prove the result.

​
A disciplined workflow

Nova is most reliable when repository work follows five explicit stages:
  1. Explore the current implementation.
  2. Plan when uncertainty or risk justifies it.
  3. Code the smallest coherent change.
  4. Verify with evidence appropriate to the change.
  5. Commit only when explicitly requested.
These stages need not become five separate conversations. A clear, low-risk fix can move through them in one turn. The point is that inspection and verification must not be skipped.

​
1. Explore

Begin by locating the behaviour, its dependencies, and its tests. Nova should prefer focused filename and code searches, then read targeted sections rather than scanning the whole repository. Example:
A useful exploration result distinguishes:
  • Observed facts from code and configuration.
  • Inferences that still need confirmation.
  • The root cause from downstream symptoms.
  • Existing conventions that a fix should follow.
  • Missing tests or runtime evidence.

​
2. Decide whether to plan

Planning is appropriate for architecture changes, migrations, breaking changes, high-risk systems, or work spanning coupled modules where the wrong sequence would cause rework. Nova distinguishes direct execution from an approval-gated plan workflow. It normally classifies the request from its complexity and risk; you can also ask explicitly for a plan:
A formal plan is recorded and tracked by the runtime. Once approved, Nova executes tasks sequentially and records completion. If scope materially changes, the plan should be updated rather than silently abandoned. Use /resume plan [planId] to list or reactivate unfinished implementation plans in an interactive session. For simple fixes, direct execution is better. Creating a plan for a one-line typo adds ceremony without reducing risk.

​
3. Code

Implementation should follow the project’s established patterns. Before editing, Nova should inspect:
  • The complete function or component being changed.
  • Imports, types, and public interfaces.
  • Nearby implementations solving similar problems.
  • Existing tests and fixtures.
  • Dependency manifests before introducing a library.
A strong implementation prompt is specific about invariants:
Nova should avoid unrelated formatting, opportunistic refactors, speculative abstractions, and comments that merely restate the code.

​
4. Verify

Verification should target the observable success criteria. Depending on the project, that may include:
  • Focused unit or integration tests.
  • Linting and type checking.
  • A production build.
  • Browser verification for a real UI path and its loading, error, empty, and success states.
  • Diff inspection for documentation-only work.
  • Git status to confirm the exact change surface.
A passing command is evidence only for what it actually checks. Nova should not claim UI correctness from type checking alone or runtime correctness from a clean diff. When a check fails, determine whether the failure was introduced by the change, already existed, or depends on an unavailable external service. Do not hide or relabel failures as success.

​
5. Review and commit

Before committing, inspect the working tree and staged diff. Check for unrelated files, generated artefacts, credentials, oversized binaries, and accidental configuration changes. Nova never needs a commit to consider an implementation complete. Commit only when the user asks. When the interactive agent handles that request, its workflow is to:
  1. Inspect Git status.
  2. Stage the relevant changes.
  3. Review the staged diff.
  4. Generate a conventional commit message.
  5. Run the commit without bypassing hooks.
  6. Push only if the user requested a push.
The built-in /commit and nova commit commands are narrower: they require changes to be staged already, generate a conventional message from git diff --staged, and create the commit. They do not stage files or push. Existing user changes must not be reset or overwritten as a shortcut.

​
Recovering from mistakes

Nova supports /rollback last for removing the last conversational turn from active context. That does not undo side effects. Checkpoint restoration is separate, opt-in, file-scoped, and approval-gated:
Git remains the authoritative way to inspect repository history, but destructive resets or checkouts that discard work require explicit care and approval.

​
What you learned

  • Explore the current implementation and its tests before choosing a change.
  • Use a formal plan when risk, uncertainty, or coupling makes sequencing important.
  • Verify the observable success criteria and commit only when you explicitly intend to do so.

​
Safe practice exercise

Ask Nova to trace a small feature and identify its tests without editing files. Then decide whether the proposed change needs a plan before you ask it to implement anything.

Previous: Your first Nova session

Return to lesson 4.

Next: Context and session management

Continue to lesson 6.