Skip to main content

code-review

Review pull requests to code-graph-rag, a multi-language code graph parser. Focuses on graph-edge correctness in language parsers, cross-language consistency, and test fixtures that actually exercise the fix.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
vitali87/code-graph-rag
آخر نشاط في المصدر
٢٠ سبتمبر ٢٠٢٦ في ٢٣:٤٤
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٥٬١٦٤
التفرعات
٦٨٢

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
code-review
description
Review pull requests to code-graph-rag, a multi-language code graph parser. Focuses on graph-edge correctness in language parsers, cross-language consistency, and test fixtures that actually exercise the fix.
# Reviewing code-graph-rag This repository parses source in many languages with tree-sitter and ingests the result into a code graph: nodes for modules, classes and functions, edges such as `CALLS`, `INSTANTIATES`, `DEFINES` and `IMPORTS`. Most defects that reach `main` are wrong or missing *edges* for a specific language construct, not crashes. Weight the review accordingly. ## Highest-value checks ### Graph-edge correctness - Does a new or changed construct produce every edge it should, and no edge it should not? A constructor call is the recurring example: it should record `INSTANTIATES` on the class *and* `CALLS` on the constructor. - Check the qualified name the edge is attached to. Name-mangling bugs recur here: duplicate-suffixed classes, verbatim identifiers (`@class` in C#), named constructors, generics (`Box<int>()`) and marker-stripping passes have each produced an edge pointing at a name that no node has. - Resolution must respect scope. A local variable shadowing a type means the receiver is not a construction; flag resolution that matches on bare name without checking what is actually in scope. ### Language coverage and consistency - A fix in one language's parser usually applies to its siblings. If the change touches `dart/`, ask whether `csharp/`, `cpp/`, and the rest share the shape and need the same fix — or say explicitly why they do not. - Grammars are optional at install time. Code and tests must not assume a grammar is present; tests for one language should skip cleanly without it. ### Tests - Every behavioral fix needs a fixture reproducing the exact construct, and the fixture must be *valid source in that language* — an invalid fixture can pass for the wrong reason. Verify the assertion would fail without the fix. - Prefer asserting on specific edges between specific qualified names over asserting on counts, which pass accidentally. ## Repository conventions - Python 3.12, `ruff` (line length 88), and `uv` for dependencies. Any dependency change must update `uv.lock`; CI fails on drift via `uv lock --check`. - Comments explain *why*, not what. Match the density of surrounding code. ## Calibration Report correctness problems: a wrong edge, a missed construct, a fixture that does not test the fix, a resolution that ignores scope. Do not report style that `ruff` already enforces, and do not restate what the diff does. If the change is correct, say so briefly rather than inventing findings.
عرض على GitHub