Glm5 cp benchmark data readme

.agents/skills/code-review/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: code-review
+description: 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**:
+
+```bash
+# 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](references/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](references/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)