Skill

configure_reviews

Sets up DeepWork Reviews by creating or updating .deepreview YAML files for automated code review rules. Guides optimal placement, rule combination to minimize overhead, testing, and summaries.

code-quality

developer-tools

npx claudepluginhub unsupervisedcom/deepwork --plugin deepwork

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Help the user set up automated code review rules for their project.

SKILL.md

Similar Skills

deepreviews

Documents DeepWork Reviews for configuring automated code reviews with .deepreview YAML files that match git branch changes and dispatch focused reviewer agents.

deepwork

reviewing

Reviews code against project rules and reference files, flagging violations in correctness, security, reliability, architecture, dead code, complexity, and conventions.

1 file

orchestrate

review

Conducts tiered code reviews for security (OWASP top 10), performance, and quality on staged git changes, PRs, or files before commits or releases.

6 tools

code-quality

Stats

Parent Repo Stars39

Parent Repo Forks3

Last CommitFeb 23, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Configure DeepWork Reviews

Help the user set up automated code review rules for their project.

How to Use

Read the README_REVIEWS.md file in this plugin directory for the complete reference on DeepWork Reviews

Look at existing .deepreview files in the project that might have something related to what the user wants to do. Reuse existing rules / instructions if possible, including refactoring inline instructions that need to be reused into their own files in the .deepwork/review directory

Ask any clarifications needed using AskUserQuestion. Skip if you are clear on the need.

Create or update .deepreview YAML config files in the appropriate locations in their project

Test your change. Make a small change that should trigger the affected rule, then call mcp__deepwork__get_review_instructions and verify that the output includes text referencing your new rule. Be sure to revert the change.

Summarize your changes.

Ask the user if they'd like you to run a review now using the /review skill to try out the new configuration.

Important

Always read README_REVIEWS.md first (if you have not in this conversation already) — it contains the full configuration reference, examples, and glob pattern guide

Help users think about WHERE to place .deepreview files (project root for broad rules, subdirectories for scoped rules)

Write practical review instructions that will produce actionable feedback

Minimize reviewer count. Each review rule spawns a separate sub-agent with material overhead (context setup, API round-trips, teardown). Combine rules into a single rule whenever the joint instructions would not overload the reviewer's context. For example, running ruff and mypy on Python files should be one python_lint rule — not two separate rules — because the combined instructions are short and the file set is identical. Only split into separate rules when the instructions are long enough or distinct enough that merging them would degrade review quality.

Configure DeepWork Reviews

Help the user set up automated code review rules for their project.

How to Use

Read the README_REVIEWS.md file in this plugin directory for the complete reference on DeepWork Reviews
Look at existing .deepreview files in the project that might have something related to what the user wants to do. Reuse existing rules / instructions if possible, including refactoring inline instructions that need to be reused into their own files in the .deepwork/review directory
Ask any clarifications needed using AskUserQuestion. Skip if you are clear on the need.
Create or update .deepreview YAML config files in the appropriate locations in their project
Test your change. Make a small change that should trigger the affected rule, then call mcp__deepwork__get_review_instructions and verify that the output includes text referencing your new rule. Be sure to revert the change.
Summarize your changes.
Ask the user if they'd like you to run a review now using the /review skill to try out the new configuration.

Important

Always read README_REVIEWS.md first (if you have not in this conversation already) — it contains the full configuration reference, examples, and glob pattern guide
Help users think about WHERE to place .deepreview files (project root for broad rules, subdirectories for scoped rules)
Write practical review instructions that will produce actionable feedback
Minimize reviewer count. Each review rule spawns a separate sub-agent with material overhead (context setup, API round-trips, teardown). Combine rules into a single rule whenever the joint instructions would not overload the reviewer's context. For example, running ruff and mypy on Python files should be one python_lint rule — not two separate rules — because the combined instructions are short and the file set is identical. Only split into separate rules when the instructions are long enough or distinct enough that merging them would degrade review quality.