How to use the Code Review Assistant.
A code review should connect findings to specific behavior or risk. Avoid treating style preferences as defects without a project convention.
Make the workflow fit your task.
Review the code against its expected behavior and project conventions, tying findings to specific lines or cases. Distinguish defects, meaningful risks and optional style suggestions, with a reproducible example where possible.
- What you provide
- Code diff and project conventions.
- What you get
- Potential defects and maintainability findings with references.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Python code review: def average(total, count): return total / count. No zero-count contract supplied.
Completed example
Finding: count=0 raises ZeroDivisionError. Reproduction: average(10, 0). Contract question: should an empty set return a designated value or raise a deliberate domain error? Proposed action: define that behavior and add a zero-count test before changing the implementation. Ordinary nonzero division is not itself identified as a defect.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should style preferences be reported as bugs?
Label them according to the project's conventions. A preference is different from behavior that fails a requirement.
Why does a review flag a problem that callers already prevent?
Inspect the function's contract and call sites. State the assumption rather than evaluating the fragment as though it had no context.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑