Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.neo.projectdiscovery.io/llms.txt

Use this file to discover all available pages before exploring further.

Once your install is connected and auto-review is on, Neo runs on every push to a pull request. You can also direct the agent inline with @pdneo commands.

Where Neo Works

Neo operates inside the pull request itself:
  • summary comment — one top-level comment per review with the overall result
  • inline comments — anchored to the specific lines where each finding lives
  • check run — surfaces review status in the PR checks panel; optional gating can block merges
  • PR comment commands — direct Neo conversationally with @pdneo …
Neo doesn’t post in issues, discussions, or commit comments. Everything happens on the PR.

Automatic Reviews

When auto-review is enabled on a repo (the default for newly added repos), Neo runs on every push to a PR:
  • a new PR is opened → full review
  • a new commit is pushed to an open PR → incremental review that only analyzes the new changes and references prior findings
The review pipeline runs in several phases, each refining the result before anything reaches the PR:
  1. Scanner pipeline runs in parallel: TruffleHog (verified secrets only), Semgrep (auto-configured rules), ast-grep (structural patterns for dangerous sinks). Results are filtered to lines actually changed in the diff.
  2. Agent reasoning over the diff: traces data flow from input sources to sinks, evaluates guards and framework protections, marks each finding with an explicit exploitability assessment. For PRs touching security-sensitive areas (auth, routing, input validation, infrastructure, dependency updates), the agent automatically pulls in a small set of related files outside the diff to understand the broader context.
  3. Verification pass. Before anything is posted, Neo runs a dedicated verification step that re-examines each candidate finding — checking it against the surrounding code, re-tracing reachability, and discarding patterns the model is unsure about. This loop can iterate when new evidence changes the picture, so the comment that lands on the PR is the one Neo would defend.
  4. Optional runtime validation. When a preview / staging URL is available, Neo can exercise the implicated endpoints against the live target to confirm whether a code-level finding is actually exploitable in deployment.
  5. Output. Verified findings become inline review comments and, when the finding is confirmed strongly enough, a separate GitHub issue with the evidence — so the work survives outside the PR’s lifecycle. The summary comment ties it all together.
This multi-pass design is why Neo’s reviews tend to be short and high-signal: most low-confidence guesses are dropped during verification rather than posted as noise.

What Neo Posts

Summary Comment

One per review. Lists the findings, severity counts, a brief overview of what changed, and an “Open in Neo” link to the full task with all evidence and artifacts.

Inline Comments

Anchored to the lines where findings live. Each inline comment includes:
  • severity (info / low / medium / high / critical)
  • short rationale explaining the issue
  • structured evidence: source of attacker-controlled input, reachability, guards checked, framework protections, false-positive assessment
  • suggested fix when the agent can produce one (toggled by the suggested_changes config)
Example of an inline comment Neo posts on a line:
**🔴 Critical · SQL injection via user-controlled input**

`username` reaches the query string unsanitized. The parameter is read
directly from `req.body` and concatenated into the SQL — no parameterization,
no allow-list. Reachable from the public `/login` route with no auth in
front of it.

**Suggested change**

```suggestion
db.query('SELECT * FROM users WHERE email = $1', [req.body.username]);
```

Open in Neo → https://neo.projectdiscovery.io/task/abc-123
The suggestion block is committable directly from GitHub’s “Commit suggestion” button on the review thread.

Check Run

A check run appears on the PR with the review status. If gating is configured, the check fails when findings exceed the configured severity threshold, blocking the PR from merging.

Incremental Review And Auto-Resolve

When a new commit lands on an already-reviewed PR, Neo runs incrementally:
  • it analyzes only the new changes, not the whole diff
  • it references prior findings to avoid repeating itself
  • it auto-resolves previously-flagged comment threads whose issues were fixed in the new commit
  • only new findings introduced by the new commit are posted
This keeps the PR review conversation focused. You don’t accumulate stale comments and you don’t get pinged again about issues you already fixed.

Comment Commands

Mention @pdneo followed by a command in any PR comment. Each block below is copy-pastable.

Review

@pdneo review
Scans your changes for security issues and posts inline comments with findings. On a PR that’s already been reviewed, this runs incrementally — only the new commits get checked.
@pdneo full review
Re-reviews the entire PR from scratch, ignoring prior findings. Use this when you want a clean re-evaluation (e.g., after large refactors).

Ask About The PR

@pdneo investigate how does the auth middleware handle this route?
Codebase Q&A scoped to the PR. Neo searches the repo and answers with code references.
@pdneo summary
Posts a high-level human summary of what the PR changes.

Respond Or Resolve

@pdneo reply
Responds to the specific review thread you posted this comment in.
@pdneo resolve
Resolves all open Neo review threads on the PR.

Issues

@pdneo create issue
Files a GitHub issue from PR context. Matches repo issue templates when present.
@pdneo create an issue for the race condition in token refresh
Natural-language form — same behavior, you describe what you want in plain English.

Live Validation

@pdneo validate https://preview-pr-42.example.com
Exercises flagged endpoints against a real deployment to confirm whether code-level findings translate to runtime-exploitable behavior.

Control Auto-Review

@pdneo pause
Stops auto-reviews on this specific PR. New pushes won’t trigger Neo until you resume.
@pdneo resume
Re-enables auto-review on this PR.

Per-Repo Configuration

@pdneo config set severity high
@pdneo config set gating block_on_high
@pdneo config set auto_review false
Updates a per-repo setting from the PR comment. Full key/value reference in Admin & Permissions.
@pdneo config get auto_review
Reads back the current value of a setting.

Help

@pdneo help
Prints a usage summary as a reply comment.

Live Validation

@pdneo validate <preview-url> exercises the flagged endpoints against a real deployment to confirm whether code-level findings translate to runtime-exploitable behavior. The validation agent:
  • enumerates the URLs implicated by each open finding
  • attempts the relevant exploit primitives against the live target
  • annotates each finding with a confirmed / not-reproducible verdict
  • attaches the evidence (HTTP traces, payloads) to the review
Use this when you have a preview or staging environment for the PR and want runtime confirmation before merge.

Pausing Reviews On A Specific PR

@pdneo pause stops auto-reviews on the current PR. New pushes will not trigger Neo on this PR until you @pdneo resume. This is useful for in-progress PRs where you don’t want noise on every commit. Other PRs in the repo are unaffected.

Org Or User Mentions In Other Contexts

Neo only acts inside PR-attached threads. Mentioning @pdneo in:
  • issue comments — ignored
  • commit comments — ignored
  • discussions — ignored
  • PR review threads on lines outside the current diff — ignored (a follow-up commit that includes the line re-enables it)
This keeps the agent’s surface explicit and predictable.

Continuing In Neo

Every review and command run is also a task in Neo with full execution detail, all agent traces, file artifacts, and prior findings. The PR’s summary comment includes an “Open in Neo” link to that task — useful when you want to:
  • see the full reasoning trail
  • inspect every tool call and evidence step
  • download artifacts (PoC scripts, validation outputs)
  • queue follow-up work that isn’t naturally part of a PR

Next