002f9879b2
Replaces cherry-picked upstream_ref with complete source trees. xllm/ — Iluvatar official C++ inference engine (15MB, 1470 files) Complete: kernels → layers → models → runtime → scheduler → api Excluded: .git, binary images, third_party submodule checkouts ds_vllm/ — Iluvatar official vllm fork (8MB, 703 files) Included: csrc/ (ALL CUDA kernels), fused_moe/, qwen3_5 model, _custom_ops Excluded: tests, benchmarks, docs, examples (not needed for reference) Critical call chains now fully traceable: MoE: moe_topk_softmax_kernels.cuh → ixformer.h → fused_moe.cpp → layer GDN: qwen3_gated_delta_net_base.cpp → qwen3_5_gated_delta_net.cpp Attention: ixformer.h → xllm_paged_attention → attention.cpp
3.4 KiB
3.4 KiB
name, description
| name | description |
|---|---|
| code-review | Review code changes for quality, security, performance, and correctness following project-specific standards. Use when reviewing pull requests, examining git diffs, or when the user asks for a code review. This skill should be used proactively — when the user asks for a review without specifying commits, automatically detect the current branch and diff against the main branch. |
Code Review
Workflow
Step 1: Determine the diff
If the user provides explicit SHAs or a PR link, use those. Otherwise, auto-detect:
# Fetch latest remote state
git fetch origin main --quiet
# Detect current branch
CURRENT_BRANCH=$(git branch --show-current)
# Find the merge base with origin/main
MERGE_BASE=$(git merge-base origin/main HEAD)
# Show what changed
git diff --stat $MERGE_BASE..HEAD
git diff $MERGE_BASE..HEAD
If CURRENT_BRANCH is main, warn the user and ask which commits to review.
Step 2: Read project standards
Read custom-code-style.md for project-specific coding style.
Step 3: Review against the checklist
Correctness:
- Logic handles edge cases and boundary conditions
- Error handling is comprehensive (no silent failures)
- Type safety maintained (no unsafe casts, proper use of
std::optional) - Resource lifecycle correct (RAII, no leaks, proper cleanup order)
Architecture:
- Clean separation of concerns, no layer violations
- Dependencies flow in the correct direction
- Changes align with existing patterns in the codebase
- No unnecessary coupling introduced
Performance & Concurrency:
- No performance regressions on hot paths
- Thread safety: proper locking, no data races
- CUDA/NPU kernels: memory coalescing, occupancy, sync correctness
- No unnecessary copies of large objects (tensors, vectors)
Testing:
- Tests verify actual logic, not just mock wiring
- Edge cases and error paths covered
- Integration tests for cross-component changes
Production Readiness:
- Backward compatibility maintained (or breaking changes documented)
- Migration strategy for schema/config changes
- No hardcoded values that should be configurable
Step 4: Output findings
Use the format below.
Output Format
Strengths
[Specific things done well, with file:line references]
Issues
Critical (Must Fix)
[Bugs, security holes, data loss risks, broken functionality]
Important (Should Fix)
[Architecture problems, missing error handling, test gaps, performance issues]
Minor (Nice to Have)
[Style, optimization opportunities, documentation improvements]
Each issue must include:
- File:line reference
- What is wrong
- Why it matters
- How to fix (if not obvious)
Recommendations
[Broader improvements for code quality, architecture, or process]
Assessment
Ready to merge? [Yes / No / With fixes]
Reasoning: [1-2 sentence technical assessment]
Rules
DO:
- Apply project-specific style from custom-code-style.md
- Follow DDD (Domain Driven Design) principles, and keep the codebase clean and maintainable
- Categorize by actual severity (not everything is Critical)
- Be specific with file:line references
- Explain WHY issues matter
- Acknowledge strengths
- Give a clear verdict
DON'T:
- Approve without thorough review
- Mark nitpicks as Critical
- Give feedback on code not in the diff
- Be vague (e.g., "improve error handling" without specifics)