Code Review

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/code-reviewThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Review changed code for quality, security, and architecture compliance. Use only when the user explicitly requests local review or a PR finding requires it.

---
name: code-review
description: Review changed code for quality, security, and architecture compliance. Use only when the user explicitly requests local review or a PR finding requires it.
---

# Code Review

## Planner Entry

Run this local review only when the user explicitly asks or an actionable PR/CI
finding requires it. Do not use it automatically before opening a PR: the two
configured PR AI reviewers are the semantic-review gate.

Review the current changes in the codebase (Go backend + Vite/React SPA monorepo). Every finding needs a `file_path:line_number` reference, an explanation of *why* it matters, and a concrete fix.

Start from intent and evidence: read the spec/task first when available, then changed tests before production code. Tests reveal the expected behavior and whether the change is actually verified.

### Architecture discussion gate

For a large architectural change, verify the authenticated actor's repository
permission before the PR opens. Maintainers and collaborators with `push`,
`maintain`, or `admin` permission may proceed without a linked issue. For an
actor without write access, require a linked issue with maintainer discussion;
if the issue or discussion is missing, report a blocker. Prefer one logical
change and a small diff because this limits risk and maintainer burden.

## Available skills

- **`/tdd`** — Recommend when flagging untested logic. The author can use this to add tests.
- **`/mobile-parity`** — Required when a review touches frontend or user-facing UI, including scrolling, visibility, or activation behavior, even when the change is not described as responsive.

## Steps

### 1. Identify changed files and check scope

Determine the right diff scope:
- **Local changes**: `git diff --name-only` (unstaged) and `git diff --cached --name-only` (staged)
- **Untracked changes**: `git ls-files --others --exclude-standard`; read any in-scope source or tests before drawing conclusions
- **PR review**: `git diff origin/<base_branch>...HEAD --name-only` to diff against the base branch

Reconcile the inventory with `git status --short` without staging user changes. If
the review includes uncommitted files, describe it as a working-tree snapshot
over `HEAD`; do not imply that `HEAD` contains the implementation.

For an existing PR, first confirm the exact head under review. Do not assume the
local checkout is current: inspect the PR's base branch and head SHA, fetch the
head if needed, and use that immutable SHA in the diff. If the current PR head
cannot be fetched, say so rather than reporting a stale checkout as a review of
the current PR.

A Kandev task worktree may hold none of the work: a clean checkout can be an old
base while the reviewable code lives on the PR's branch, and prior-session claims
that local changes exist may be stale. Before reporting “no changes”, confirm
that `git log "$(git merge-base <base-remote>/<base-ref> HEAD)"..HEAD` is
non-empty. If it is empty, resolve the PR branch with
`gh pr view <N> --json headRefName,headRefOid`, fetch that ref, and review its
immutable head, stating why it is not the local branch.

Record the base and head SHA for each review round. A new contributor push starts
a new round: reassess prior findings and the verdict against the new head, and
verify checks or workflow results for that head rather than relying on a PR
number or author summary. From `scripts/pr-state --summary`, also record
`pr.base_ref_name`, `pr.base_head_oid`, `pr.merge_base_oid`, and
`pr.base_advanced_since_head` when available.

For a follow-up round, inspect `<previous-reviewed-head>..<current-head>` first,
then re-evaluate `<base>...<current-head>` for complete PR coverage. Record both
immutable heads. The first range does not isolate the author's response when the
branch merged or rebased onto an advanced base: it also carries every upstream
commit that arrived with it. Use `git log --oneline --first-parent
<previous-reviewed-head>..<current-head>` to list the branch's own commits, then
`git show --stat <sha>` per commit to size the response. When history shape
decides review scope, preserve the complete Git output, including merge commits
and subjects.

When `pr.base_advanced_since_head` is `true`, validate the actual merge result
before declaring the PR ready. Record the latest base and immutable head SHAs,
create a temporary worktree from that base, merge the head with `git merge
--no-commit --no-ff <head-sha>`, and run focused verification in the merged tree
before removing the worktree. GitHub's `mergeable: MERGEABLE` status proves
conflict compatibility, not that the merged result was tested. If an older
`pr-state` helper lacks the base fields, resolve the current base
head only as a fallback with `gh api
repos/{owner}/{repo}/git/ref/heads/{base}` and derive/record the merge base
before making the same decision; do not try the unsupported
`gh pr view --json baseRefOid` field.

For an existing GitHub PR, inspect both `scripts/pr-state --summary <PR>` and
`scripts/pr-resolve list <PR>` before treating review feedback as clean. Read
the body of any exact-current-head review as well as inline threads: bots can
place actionable findings outside the diff. A review's `commit_id` is the
current-head signal; timestamps are only collection order. If `pr-state`
reports hidden unresolved threads, use `pr-resolve list` to inspect them rather
than assuming the filtered list is complete.

Compare the PR description, checklist, and claimed manual validation with that
exact head, especially after a major refactor. Treat unchecked static template
boxes preserved by `/pr` as intentional; flag only prose or checklist claims
factually contradicted by the exact-head diff or evidence. Report stale claims
separately; they are not verification evidence for the current diff.

Read each changed file in full — understand surrounding code, not just the diff. Navigate callers, interfaces, and tests to understand changes end-to-end.

To read files a

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Code Review

• github.com/kdlbs/kandev/tree/main/.agents/skills/code-review — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology