diff --git a/.opencode/skills/pr-build/SKILL.md b/.opencode/skills/pr-build/SKILL.md new file mode 100644 index 0000000..d0d051b --- /dev/null +++ b/.opencode/skills/pr-build/SKILL.md @@ -0,0 +1,107 @@ +--- +name: pr-build +description: Builds and tests a pull request branch, fixing compilation errors and test failures. Use when the user says "build PR", "fix PR build", "run PR build", or wants to compile and test a PR branch. +--- + +# PR Build Skill + +Builds, tests, and fixes a pull request branch. This skill CAN edit files, commit, and push. + +## Workflow + +### Step 1: Identify the PR branch + +If the user specifies a PR number, check it out: +```bash +tea pr checkout +``` + +If already on a PR branch, verify with: +```bash +git branch --show-current +git log main..HEAD --oneline +``` + +### Step 2: Clean build + +```bash +rm -rf build +cmake -B build -S . 2>&1 +cmake --build build -j$(nproc) 2>&1 +``` + +Capture both stdout and stderr. + +### Step 3: Handle build failures + +If the build fails, read the error output carefully. Common issues: + +**Missing include / undefined reference:** +- Check if the new `.c` file is in the right `file(GLOB ...)` directory +- Check if the new `.h` file is included properly +- Check if CMakeLists.txt needs updating (new target, new source file, new dependency) + +**Type errors / implicit declarations:** +- Check function signatures match between `.h` and `.c` +- Check struct field names and types + +**Linker errors:** +- Check if all required libraries are linked in CMakeLists.txt +- Check if all source files are included in the target + +Use the cmake-expert agent to diagnose and fix CMake issues. + +### Step 4: Run unit tests + +If build succeeds: +```bash +./build/tests +``` + +### Step 5: Handle test failures + +If tests fail: +- Read the test output carefully +- Check which test function failed and the assertion line +- Read the test source file and the module being tested +- Use the test-writer agent to investigate and fix + +### Step 6: Run integration tests (optional) + +```bash +python3 test.py +``` + +This runs the integration + benchmark suite. It takes longer — only run if the user asks or if unit tests pass. + +### Step 7: Fix and commit + +If fixes were needed: +```bash +git add -A +git commit -m "Fix build: " +git push +``` + +### Step 8: Report results + +Print a summary: + +``` +=== PR BUILD SUMMARY === +Branch: +Build: [PASS/FAIL] +Unit tests: [PASS/FAIL] (/) +Integration tests: [PASS/FAIL/SKIPPED] + +Fixes applied: + +``` + +## Rules +- DO edit source files and CMakeLists.txt to fix issues +- DO commit and push fixes +- Always build from clean state (rm -rf build) +- Read error messages carefully before fixing +- Don't change functionality — only fix build/test issues +- Preserve existing code style when making fixes diff --git a/.opencode/skills/pr-review/SKILL.md b/.opencode/skills/pr-review/SKILL.md new file mode 100644 index 0000000..8a4f830 --- /dev/null +++ b/.opencode/skills/pr-review/SKILL.md @@ -0,0 +1,119 @@ +--- +name: pr-review +description: Reviews a pull request for bugs, memory safety, thread safety, and style issues. Use when the user says "review PR", "review this PR", "review pull request", or wants a code review of changes. +--- + +# PR Review Skill + +Read-only code review of a pull request branch. Produces a report — does NOT edit files. + +## Workflow + +### Step 1: Identify the PR branch + +If the user specifies a PR number, check it out: +```bash +tea pr checkout +``` + +If already on a PR branch, verify with: +```bash +git branch --show-current +git log main..HEAD --oneline +``` + +### Step 2: Get changed files + +```bash +git diff main --name-only -- '*.c' '*.h' +``` + +This gives the list of C source and header files changed in the PR. + +### Step 3: Read all changed files + +Use the Read tool to read every changed `.c` and `.h` file. Read full files — don't skip any. + +### Step 4: Review each file + +For each changed file, review for: + +**Memory Safety** +- Every `malloc`/`calloc` has a matching `free` on all code paths (including error paths) +- No use-after-free (pointers used after `*_destroy()` is called) +- No double-free +- Null checks after allocation before use +- Correct buffer sizes (strlen + 1 for null terminators) +- `Data` objects created/destroyed properly + +**Thread Safety** +- Shared state accessed under mutex +- No race conditions on queue operations +- Condition variable signals under lock +- No deadlock potential (consistent lock ordering) +- `done` flags checked properly in consumer loops + +**Protocol Safety** +- `send_n_data` / `receive_n_data` return values checked +- Status codes validated before use +- Config serialization handles partial reads + +**Logic Errors** +- Off-by-one in loops/buffers +- Incorrect size calculations +- Wrong enum values or comparisons +- Missing break statements in switch + +**Error Handling** +- Resources freed on error paths (no leaks) +- Functions return appropriate error values +- Error messages are useful + +### Step 5: Categorize findings + +For each issue: +1. **File:line** — exact location +2. **Severity** — critical / warning / style +3. **Category** — memory / thread / protocol / logic / error +4. **Description** — what's wrong and how to fix it + +### Step 6: Output report + +Print a formatted summary: + +``` +=== PR REVIEW SUMMARY === +Branch: +Files reviewed: +Issues found: + +CRITICAL: +WARNING: +STYLE: + +=== ISSUES === +[1] src/shared/compression.c:42 — CRITICAL (memory) + Potential leak: data returned from data_compress() not freed on error path + Fix: Add data_destroy(compressed) before return false + +... + +=== VERDICT === +[PASS] No critical issues found + — or — +[FAIL] critical issues must be fixed before merge +``` + +### Step 7: Optional PR comment + +If the user wants to post the review as a PR comment: +```bash +tea pr comment --comment "" +``` + +## Rules +- Do NOT edit any source files +- Do NOT run builds or tests +- Do NOT commit or push +- Report ALL issues — don't filter or minimize +- Be specific about line numbers and fix suggestions