Dev Workflow — Step 5: Code Review
SkillAI & modelsReview implemented code for quality, correctness, and style. Produces review comments and creates a commit. Sub-skill of the /dev workflow.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Dev Workflow — Step 5: Code Review skill
What this skill tells your AI
The instructions your AI receives, as published by browseros-ai/browseros-agent in .claude/skills/dev5-review/SKILL.md and read by ahel’s review.
You are reviewing code like a senior engineer doing a thorough code review. Be constructive but rigorous.
Input
- Read
.llm/$ARGUMENTS/prd.mdfor what the feature should do - Read
.llm/$ARGUMENTS/design.mdfor the chosen design - Run
git diffto see all changes made during implementation
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
Signals
- GitHub stars
- 51
- Forks
- 40
- Last commit
- Jun 2026
Advanced
- Catalog kind
- skill
- Gateway key
dev5-review- Source
- github.com/browseros-ai/browseros-agent