원클릭으로
deepreviews
Reference documentation for DeepWork Reviews — automated code review rules using .deepreview configs and DeepSchema-generated rules
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Reference documentation for DeepWork Reviews — automated code review rules using .deepreview configs and DeepSchema-generated rules
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Set up DeepWork Reviews — automated code review rules using .deepreview config files
Start structured planning — explores, designs, and produces an executable plan
Create and manage DeepSchemas — rich file-level schemas with automatic validation and review generation
Start or continue DeepWork workflows using MCP tools
Agent profile/skill maintenance — quickly edit ks-config/agents and commit + push successful changes
Personal assistant — may start personal_assistant/reservation, personal_assistant/birthday, personal_assistant/calendar_prioritize, or personal_assistant/memory_search
| name | deepreviews |
| description | Reference documentation for DeepWork Reviews — automated code review rules using .deepreview configs and DeepSchema-generated rules |
This is a reference skill. Read it to understand the DeepWork Reviews system before running or configuring reviews.
DeepWork Reviews lets you define automated code review policies using .deepreview config files placed anywhere in your project. When a review runs, it detects which files changed on your branch, matches them against rules, and dispatches parallel review agents — each with focused instructions and only the files it needs.
Reviews are triggered in two ways:
/review skill — runs all matching rules against your branch's changesfinished_step automatically runs reviews on step outputsA .deepreview file is YAML containing one or more named rules. Each rule has a match section (what files to trigger on) and a review section (how to review them).
.deepreview files work like .gitignore — glob patterns match relative to the file's directory. Place them close to the code they govern:
project/
├── .deepreview # Project-wide rules
├── src/
│ ├── .deepreview # Rules scoped to src/
│ └── auth/
│ └── .deepreview # Rules scoped to src/auth/
rule_name:
description: "Short description" # Required, under 256 chars
match:
include:
- "glob/pattern/**/*.ext" # Required, at least one
exclude:
- "pattern/to/skip/**" # Optional
review:
strategy: individual # Required: individual | matches_together | all_changed_files
instructions: | # Required: inline text or file reference
Review this file for ...
agent: # Optional: platform-specific agent persona
claude: "security-expert"
precomputed_info_for_reviewer_bash_command: .deepwork/review/gather_context.sh # Optional
additional_context: # Optional
all_changed_filenames: true # Include all changed files list
unchanged_matching_files: true # Include unchanged files matching the pattern
| Strategy | Behavior | Best for |
|---|---|---|
individual | One review per matched file | Per-file linting, style checks |
matches_together | All matched files in one review | Cross-file consistency, migration safety |
all_changed_files | If any file matches, reviewer sees ALL changed files | Security audits, broad impact analysis |
Instructions tell the reviewer what to check. They can be inline or reference an external file:
# Inline
instructions: "Check for proper error handling."
# File reference (resolved relative to .deepreview location)
instructions:
file: .deepwork/review/python_review.md
Reusable instruction files should live in .deepwork/review/.
.deepreview files in the project.deepwork/tmp/review_instructions/Deleted files are excluded — there's nothing to review.
DeepSchemas automatically generate synthetic review rules. When a file matches a DeepSchema with requirements, the review pipeline creates a rule that checks those requirements during /review and workflow quality gates. No .deepreview file is needed — the DeepSchema's requirements field drives the review.
This means requirements defined in a DeepSchema are enforced in two places:
/reviewDuring DeepWork workflows, finished_step triggers reviews on step outputs. These come from three sources:
review blocks defined on step outputs in job.ymlreview blocks on step_arguments in job.yml.deepreview rules and DeepSchema rules — any rules whose patterns match the output filesAll three run automatically. If any review fails, finished_step returns needs_work with feedback.
all_changed_filenames: true — gives the reviewer a list of every changed file, even those outside this rule's scope. Useful for spotting related changes.unchanged_matching_files: true — includes files matching the pattern that weren't changed. Useful for sync checks (e.g., "are all version files still in sync?").The precomputed_info_for_reviewer_bash_command field runs a shell command before the review and injects its stdout into the instruction file as a "Precomputed Context" section. This eliminates the need for the reviewer agent to run many tool calls to gather context.
review:
strategy: all_changed_files
precomputed_info_for_reviewer_bash_command: .deepwork/requirements_traceability_info.sh
instructions: |
Review changed files for requirements traceability...
Behavior:
.deepreview file's directoryThe optional agent field assigns a specialized persona to the reviewer:
agent:
claude: "security-expert"
If omitted, the default agent handles the review.
All detection is local (no remote fetches). Included: committed branch changes, staged changes, unstaged modifications, untracked files. Excluded: deleted files. You can override detection by passing explicit files.
/review — Run reviews on the current branch/configure-reviews — Create or modify .deepreview rules/deepschema — Create DeepSchemas that auto-generate review rules