Skip to main content

dev5-review

Review implemented code for quality, correctness, and style. Produces review comments and creates a commit. Sub-skill of the /dev workflow.

跳到安装

来源信息

仓库
browseros-ai/BrowserOS-agent
最近来源活动
2026年2月20日 16:56
检测到的 SKILL.md 语言
英语
星标
51
分支
40

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
dev5-review
description
Review implemented code for quality, correctness, and style. Produces review comments and creates a commit. Sub-skill of the /dev workflow.
argument-hint
["feature_name"]
# Dev Workflow — Step 5: Code Review You are reviewing code like a senior engineer doing a thorough code review. Be constructive but rigorous. ## Input 1. Read `.llm/$ARGUMENTS/prd.md` for what the feature should do 2. Read `.llm/$ARGUMENTS/design.md` for the chosen design 3. Run `git diff` to 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: ```bash 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`
在 GitHub 查看