One issue in. One reviewed merge request out.
Here is everything in between: how you set it up, what each step of a run does, where it runs and what it is allowed to see.
Four steps to your first run.
Your beta invite opens a setup wizard that walks you through each one and tests it before you move on.
- 1
Connect your GitLab
Create an OAuth application on gitlab.com or your own instance, with the values the wizard gives you. From then on your team signs in with GitLab.
- 2
Set up the bot
On a self-managed instance Nightsquire creates the bot user, with an admin token you paste once. On gitlab.com Premium or Ultimate it can use a group access token; on gitlab.com Free you create a bot account and paste its token. Either way, its token rotates itself.
- 3
Pick an executor
Choose a managed size and it is ready, or run the one-line installer on a Linux VM of your own; it installs Docker for you. Either way it serves only your organisation and connects out over HTTPS.
- 4
Pick the AI, enable projects
Nightsquire AI needs no setup. Or add a Claude API key, or any OpenAI-compatible endpoint. Enable a project and the webhook and bot membership are set up for you.
Every step that touches code runs in its own container, with only what it needs.
A run is a chain of steps. The steps that run agent-written code never hold the GitLab token, and the steps that hold it never run your project's code.
- 01
Triage
before round 1
Reads the issue and picks implement or plan. A request for research, a plan or a choice gets a plan; everything else gets implemented. A nightsquire::implement or nightsquire::plan label decides it for you.
agent - 02
Prepare
round 1
Checks the trigger again through the GitLab API, so a forged webhook starts nothing. Writes the issue context and packs the repository into a bundle for the next step.
publish - 03
Implement
round 1
The agent works on the bundle: reads the code and your CLAUDE.md, makes the change, writes tests and runs your test gate until it passes. Its commits leave the container as a bundle, not as a push.
agent - 04
Publish
round 1
Checks the agent's commits before anything leaves, pushes them to the run's own branch and opens a draft merge request that links the issue.
publish - 05
Pipeline
round 1
Waits for your own CI pipeline on the pushed branch. If it fails, a CI fix round reads the failed jobs, fixes the cause and pushes again.
your CI - 06
Scan
round 1
GitLab's own Semgrep (SAST) and Gitleaks (Secret Detection) analyzers run on the pushed tree. No network, no secrets.
no secrets - 07
Security review
round 1
A separate, read-only pass reviews the diff together with the scanner findings, against the severity threshold you set. If something blocks, it gets one attempt to fix it, tested before it is pushed.
agent, read-only - 08
Security fix
round 2, only when needed
The fix is pushed after the same checks, then the pipeline, the scanners and a final review run again on the new head. Rounds that are not needed are not planned.
all three - 09
Hand-off
wrap-up
Opens a thread for each security note, marks the merge request ready (or keeps it a draft when something is blocking), adds the project's owners as reviewers and writes the summary. Whoever started the run gets an email.
publish
It says what is left, and leaves the work where you can see it.
Not every issue fits in one run. When one doesn't, nothing disappears into a log you have to dig for.
It hits its time limit
If it made progress, it continues once on the same branch. If it still isn't done, the work so far is committed and the merge request stays a draft, with a comment that says where the work is and how to continue.
It needs a project it can't read
The run comment names the project with a Grant access link. An Owner or Admin adds the bot as Reporter in one click, never more. Even then, a run reads another project only if the person who started it can read that project in GitLab themselves.
A security finding stays open
The merge request stays a draft, the finding is a thread (on the line, when the line is in the diff), and the run is marked blocked in the dashboard.
Everything happens in GitLab.
Only members of your organisation can start a run, identified by their GitLab account, not their username. The bot ignores its own events. It pushes only to the run's own branch, or to its claude-md branch for a CLAUDE.md, and creates issues only when one of you asks it to.
| You do this | Where | Nightsquire does this |
|---|---|---|
| Assign the issue to the bot | Issue | Triage, then implement or plan |
| nightsquire::implement | Issue label | Skips triage and implements |
| nightsquire::plan | Issue label | Posts a plan in the issue, no branch |
| Comment on its merge request | Merge request | Makes the change, runs every check again, answers the thread |
| @nightsquire-bot create the issues | Merge request | Creates the follow-up issues it proposed |
| @nightsquire-bot suggest a CLAUDE.md | Issue | Opens a draft merge request with project instructions for the agent |
| @nightsquire-bot add the CLAUDE.md | Merge request | Commits the CLAUDE.md it suggested |
Sensible defaults. Every one of them yours to change.
Set it once for the organisation and override it per project. Every change is versioned and audited.
- Model, effort, turn and time limits
- Which scanners run, and the severity that blocks
- CI and security fix rounds
- Network: open, or an allowlist built from what runs used
- Docker inside steps, for projects whose tests need it
- Notes about your GitLab that every agent reads
limits: timeout_minutes: 120 auto_continue: 1review: severity_threshold: medium sast: true secret_detection: trueci: enabled: truenetwork: mode: open
Try it on a real issue.
The beta is invite-only for now. Leave your email and we'll tell you when it opens.