BrowserOS dev5-review
Review implemented code for quality, correctness, and style. Produces review comments and creates a commit. Sub-skill of the /dev workflow.
install
source · Clone the upstream repo
git clone https://github.com/browseros-ai/BrowserOS
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/browseros-ai/BrowserOS "$T" && mkdir -p ~/.claude/skills && cp -r "$T/packages/browseros-agent/.claude/skills/dev5-review" ~/.claude/skills/browseros-ai-browseros-dev5-review && rm -rf "$T"
manifest:
packages/browseros-agent/.claude/skills/dev5-review/SKILL.mdsource content
Dev Workflow — Step 5: Code Review
You are reviewing code like a senior engineer doing a thorough code review. Be constructive but rigorous.
Input
- Read
for what the feature should do.llm/$ARGUMENTS/prd.md - Read
for the chosen design.llm/$ARGUMENTS/design.md - Run
to see all changes made during implementationgit diff
Step 1: Style guide review
If the project uses TypeScript, invoke
/ts-style-review to check all changed files against the Google TypeScript Style Guide and team conventions. Incorporate its findings into your review comments.
Step 2: Review the code
Review every changed file. Check for:
Correctness
- Does the implementation match the PRD requirements?
- Are there edge cases not handled?
- Are there logical errors?
Code Quality
- Functions under 20-30 lines?
- Logic grouped without unnecessary blank lines?
- No excessive console.log statements?
- Comments only where logic is non-obvious (explaining why, not what)?
- Self-contained functions that do one thing?
Architecture
- Does it follow existing codebase patterns?
- Are there unnecessary abstractions or over-engineering?
- Is the code simple and direct?
Safety
- Any security issues (injection, XSS, etc.)?
- Proper error handling at system boundaries?
- No leaked secrets or credentials?
Step 3: Write review comments
Write review comments to
.llm/$ARGUMENTS/tmp_review.md in this format:
## Review Comments ### [file_path:line_number] — severity (critical/suggestion/nit) Description of the issue and suggested fix. ### [file_path:line_number] — severity ...
Step 4: Present review to user
Show the user a summary:
- Total files reviewed
- Number of critical / suggestion / nit comments
- Top 3 most important issues (if any)
Step 5: Commit
Stage all changes and create a commit with a clear, descriptive commit message that summarizes the feature:
git add -A && git commit -m "feat: <concise description of what was built>"
Step 6: Hand off
Tell the user the review summary, then:
- If there are critical or suggestion comments: immediately invoke
/dev6-review-fix $ARGUMENTS - If there are zero actionable comments (only nits or clean code): skip dev6 and immediately invoke
/dev7-pr $ARGUMENTS