Skip to main content
Getting started

From one workflow to a proven rollout.

Start with a representative ticket, a real engineering environment and clear approval rules. Judge Nova from the pull request, evidence and reviewer effort.

The path

Six steps from setup to a credible result.

  1. 01

    Choose the first workflow

    small, useful and measurable

    Pick a kind of engineering work with a clear definition of done, such as a bug fix, dependency update or browser regression.

  2. 02

    Connect Jira and GitHub

    limited to what Nova needs

    Choose the Jira projects and repositories Nova may use. Keep access narrow for the first evaluation and expand only when the results justify it.

  3. 03

    Prepare the work environment

    yours or managed by NovaCore

    Make the repository, toolchain, test suite and application services available in an isolated environment where Nova can do and verify the work.

  4. 04

    Add project guidance

    the standards your team follows

    Provide the build commands, test expectations, coding conventions and review requirements that define a credible contribution to the project.

  5. 05

    Set rules and approvals

    authority before autonomy

    Decide which actions may proceed, which need a named approver and which Nova must never take. Set usage limits for the team or project.

  6. 06

    Run and review the pilot

    evidence, then scale

    Assign real tickets and judge the pull requests, verification, reviewer effort and handling of ambiguity before widening the rollout.

The important gate

Define authority before asking for autonomy.

Your team defines which actions Nova can take, which require a named approver and which are always blocked. Those rules remain in force throughout the work.

Instructions inside a ticket or repository cannot widen that authority, and approving one request does not create standing permission for later work.

Begin in assisted mode, keep high-impact writes behind people, and widen only where the observed result and evidence earn it.

What you confirm
Projects
and their repositories
Environment
tenant-owned or managed
How to build
and how to run the tests
Where work starts
NovaCore or Jira
Who approves actions
by action and scope
Usage limits
per team and project
Then what

What the first month usually looks like.

Start with a review boundary

Let Nova implement and verify changes, then stop at pull-request creation. You are measuring the output before granting broader authority.

Widen one action at a time

Allow a narrow class of routine actions while keeping higher-impact work behind approval. Autonomy is not one global switch.

The second team is easy

Adding another repository or team costs a fraction of the first one because the environment, connections and rules are already understood.

See Nova run on your own code.

A working session rather than a slide deck. Bring a repository and a ticket you would otherwise assign to someone, and watch it go from the ticket to a pull request you approve.

Book a demo Talk to us