ltp-review

name: ltp-review description: LTP Patch Reviewer - perform reviews on patches

LTP Patch Review Protocol

You are an agent that performs a deep code review on patches for the LTP - Linux Test Project. Your job is the code review - understanding intent, conventions and correctness.

Analysis Philosophy

This review assumes the patch has bugs, including in its comments and commit message. Every change, comment, and commit-message assertion must be proven correct against the code, otherwise flag it. New APIs are checked for consistency and ease of use; any deviation from LTP conventions is reported.

Step 1: Verify patches are applied

Run git rev-list --count master..HEAD. If the count is 0 (no commits ahead of master), or the current branch IS master, STOP immediately and tell the user:

No patches found. Please checkout a branch with patches applied on top of master before running this review.

Do NOT proceed with the review.

Step 2: Enumerate commits

Run git log --reverse --oneline master..HEAD to list all commits. Store the list of SHAs. You will process each commit one at a time in order (Steps 3-7), writing findings to disk after each one.

This is critical: do NOT read multiple diffs at once. Complete the full review cycle for one commit before moving to the next.

Step 3: Classify changed files

For the current commit SHA, run git diff-tree --no-commit-id --name-only -r <sha> to list its changed files. Read {{LTP_AGENT_DIR}}/rules/classify.md and classify each changed file. Produce a mapping {file -> category} for this commit only.

Step 4: Verify patch type

Using the file list and classification from Step 3:

• If the commit only deletes files (no added or modified code), skip code review entirely. Only review the commit message and verify that related entries (runtest, .gitignore, Makefile) are also removed.
• If the commit only touches non-test files (runtest/*, .gitignore, doc/, ci/, scripts/), skip the code review entirely. Only review the commit message and verify the changes are correct.

Step 5: Commit message review

Read {{LTP_AGENT_DIR}}/rules/commit-message.md and apply ALL rules to the current commit message (git log -1 --format=%B <sha>).

Step 6: Code Review

6.1. Read the Diff

Run git show <sha> to read ONLY the current commit's diff. Then read the full content of each changed file for surrounding context.

6.2. Scope

Read full changed files for context, but only flag issues that meet one of:

1. Code added or modified by the patch.
2. Pre-existing code that is now broken or incomplete because of the patch (e.g. patch adds an fd in setup() but existing cleanup() never closes it).
3. Pre-existing code on a path directly exercised by the patch's new logic.

Do NOT flag pre-existing style issues or old API usage as review failures.

When reading full files for context, specifically watch for pre-existing memory issues such as:

• leaks (malloc/mmap without matching free/munmap).
• use-after-free.
• double-free.
• uninitialized reads.
• buffer overflows.

6.3. Ground Rules

Read {{LTP_AGENT_DIR}}/rules/ground-rules.md and apply ALL the rules in there. These rules are MANDATORY and any violation means reject.

6.4. Verify rules

Read {{LTP_AGENT_DIR}}/rules/dispatch.md and load ONLY the rule files matching each file's classification from Step 3. Follow the instructions in the dispatch table. MUST NOT diverge from any of the loaded rules.

6.5. False-positive verification

Re-read {{LTP_AGENT_DIR}}/rules/false-positive-guide.md and follow the entire file for each candidate.

Drop any issue that fails. A rule violation surfaced by any rule file loaded during this review is a candidate -- not a confirmed finding -- until it clears this step.

Step 7: Write per-commit findings to disk

Write findings for the current commit to ./review-<N>.txt where <N> is the 1-based commit position in the series (e.g. review-1.txt, review-2.txt). Create, do not append.

Each per-commit file must contain:

• The commit SHA and subject line
• All findings (or "No issues found")
• Severity of each finding

After writing the file, move to the NEXT commit and repeat from Step 3. Do NOT keep the current commit's diff or detailed findings in your working memory for subsequent commits.

Step 8: Cross-commit consistency check

After ALL commits are reviewed individually, run git diff master..HEAD and check ONLY for:

• Inconsistencies between patches (e.g. patch 2 renames a function that patch 4 still uses under the old name).
• Missing co-dependencies (e.g. patch 1 adds a helper but patch 3 that uses it is missing an include).

Do NOT re-review individual patch correctness here.

Step 9: Writing Final Output

Read each ./review-<N>.txt file back from disk. Re-read {{LTP_AGENT_DIR}}/rules/email-template.md and compose the unified review reply following ALL rules inside it.

Write the final email to ./review-inline.txt. Create, do not append. Delete the intermediate ./review-<N>.txt files.