[Feature] /review (nanocoder review <pr|branch>) Command

[akramcodez]

Description

Add a dedicated slash command and CLI command to review a Pull Request or a specific Git branch.

Use Case

Code review is a massive use case for AI. A user should be able to type /review or nanocoder review main to get an automated, architect-level review of the diff, highlighting bugs, security issues, and style violations.

Proposed Solution

• Add a new slash command in source/commands/.
• Reuse existing tools in source/tools/git/ to fetch the diff against the base branch.
• Feed the diff to a specific review prompt (e.g., source/app/prompts/sections/review.ts).
• Output the review report to the terminal or write it to a markdown file.

Alternatives Considered

• Having the user manually prompt "review the git diff" (inconsistent results without a strong system prompt).

Additional Context

• I have searched existing issues to ensure this is not a duplicate
• This feature aligns with the project's goals (local-first AI assistance)

[puri-adityakumar]

I thoroughly reviewed PR #1099 by @soumojit-D48. The /review it implements is a single one-shot, non-agentic LLM call: one client.chat() invocation with no tools registered, no file reads, and no tool loop. A stateless diff-in → review-out pass.

Evidence, source/commands/review.ts L173-178 (PR head):

const messages: Message[] = [
    {role: 'system', content: reviewPrompt},
    {role: 'user', content: parts.join('\n')},
];

const response = await client.chat(messages, {}, {});

The second argument is the tool registry; per the signature in source/ai-sdk-client/ai-sdk-client.ts L150-156, {} means an empty tool registry. The review model therefore structurally cannot open files, run git, or verify anything beyond the truncated diff, yet the system prompt asks it to "avoid hallucinated issues." Issue #1002 itself is silent on call architecture (its only LLM-adjacent wording is "feed the diff to a specific review prompt"), so a richer design does not conflict with it.

TL;DR

Evolve /review into two modes: the current one-shot becomes /review quick, the default /review becomes a token-efficient find→verify flow (one agent, read-only tools, self-verification), and /review deep adds parallel finder subagents with an independent per-finding verification pass. Grounding uses tools nanocoder already ships: git_diff, git_log, read_file, search_file_contents, lsp_get_diagnostics.

The two modes

/review default, lite (token-efficient: ~1-2x the diff)

 pre-flight (pure code, 0 tokens)
   resolve target · verify ref · diff non-empty
   LSP diagnostics on changed files (free, local)
        │
        ▼
 ONE finder agent (tool loop, read-only tool profile)
   git_diff · git_log · read_file ·
   search_file_contents · lsp_get_diagnostics
   budget: ≤10 tool calls · diff pre-truncated
        │
        ▼
 self-verify (same agent, zero extra calls)
   re-read every cited file:line · score 0-100
   · drop anything below 80
        │
        ▼
 report: P0/P1/nit · severity · mandatory
         file:line citation per finding

/review deep (evidence-based fan-out: ~6-10x the diff, opt-in)

 same pre-flight + repo-map context pack
        │
        ├─▶ subagent ①  bug hunt     (diff + surrounding code)
        ├─▶ subagent ②  standards    (AGENTS.md / repo conventions)
        └─▶ subagent ③  spec/intent  (issue refs · spec lookup chain)
        │        isolated contexts · read-only · citations mandatory
        ▼
 VERIFY FAN-OUT (one independent agent per finding)
   0-100 confidence rubric · keep only ≥ 80
        │
        ▼
 dedupe + rank → report (Standards / Spec kept
 separate) · --output-format json for CI / VS Code

I'd like to work on this, and I think it would be best as a collective effort with @soumojit-D48's PR . @akramcodez @will-lamerton, keen to hear your thoughts on the two-tier direction before I start.