Code review overview

Two-layer architecture

📦 All 12 skills open-sourced

L2 code-review + ten L1 analyzers + data pipeline bug-import (official path to your own bug history) live on:

github.com/Nox-Lumen-tech/combo-skills

Install from chat:

/skill-install Nox-Lumen-tech/combo-skills/code-review
/skill-install Nox-Lumen-tech/combo-skills/bug-import
/skill-install Nox-Lumen-tech/combo-skills/ruff
/skill-install Nox-Lumen-tech/combo-skills/checkstyle
…

LTM sinks: bug-pattern pool + feedback pool

Code review gets sharper over time because two paths write LTM:

Path	Writer	memory_type	tags anchor	When
① Bug patterns (real-time)	`code-review` Step 6 (post-review auto call)	`fact`	`bug_pattern` + `source:agent_realtime`	New pattern found this review
② Bug patterns (historical rollup)	`bug-import` Phase 3	`fact`	`bug_pattern` + `source:bug_import_aggregator`	Periodic aggregation after imports
③ False-positive / missed feedback	`code-review` Step 6 when user reacts	`error_pattern`	`false_positive` / `missed_issue`	User labels a finding

Paths ①② share tags—single fetch in L2 Step 2:

unified_search(sources=["fact"], tags_include=["bug_pattern"], min_confidence=0.7)
unified_search(memory_type="error_pattern", query="<change keywords>")  # Path ③

Hits surface as bug_pattern_match (severity severe).

Why bug patterns aren’t error_pattern facts

Legal memory_type values number five: fact / preference / program / error_pattern / chunk_node. error_pattern covers both review feedback and platform/tool/runtime faults—partitioned softly via tags.
Code bug patterns intentionally use fact + tags=["bug_pattern"] to avoid mixing with “tool keeps failing” noise. bug-import always did this; code-review real-time learning now matches—two writers, one clean pool.

“bug_pattern is a tag, not a memory_type” — convention between skills, not a hard-coded platform field. Agents may invent tag vocabulary (module:CarSyncShare, pattern:heartbeat_disconnect, …). See code-review · LTM sink.

combo agent decouples layers:

Rendering diagram…

Layer	Does	Doesn’t
L1 static	Deterministic linting (syntax, policy, vuln patterns)	Contextual judgement
L2 semantic	Req vs code, architecture alignment, bug-pattern hits	Static checks (that’s L1)

Division of labor

L1 — nine static skills

Language	Tooling page
Python	bandit / ruff / mypy / semgrep
Java	checkstyle / pmd / spotbugs
C / C++	clang-tidy / cppcheck
Kotlin	detekt

All emit unified CodeEvidence JSON consumed by L2.

L2 — code-review

LLM-driven review against requirements, design, coding standards, bug history. Does not perform static scans (L1), repo operations (integrations), or config synthesis (standards-converter).

Eight L2 finding categories

Category	Severity
`requirement_not_implemented`	fatal
`requirement_deviation`	severe
`design_inconsistency`	severe
`standard_violation`	general
`security_risk`	severe
`performance_issue`	general
`bug_pattern_match`	severe
`design_compliance_violation`	general

Typical scenarios

Scenario	Layers	Trigger	Notes
A. Single PR / MR / change	L1 + L2	Gerrit/GitLab/GitHub/Gitee integrations	Diff scope, seconds–minutes
B. Batch scan	L1	Scheduled	Rules only
C. Full-branch / repo	L1 full + L2 deep	Manual / pre-release gate	Requires light/heavy indexing; Gerrit adapter unsupported—use GitHub/GitLab/generic git
Security audits	L1 (bandit/semgrep) + L2	Scheduled / compliance	Recommend heavy index when taint matters
MISRA / ISO 26262	L2 + standards-converter configs	Automotive programs	Heavy index for cross-TU reasoning

Choose A or C?

Daily flow → A (diff). Reserve C (whole repo) for major releases, repo onboarding, or monthly security/compliance sweeps—it drives deeper retrieval (see three-tier code index).

Code review overview

On this page