feat: add deepschema for .deepreview files, remove redundant review rule

Create a standard deepschema for .deepreview config files with semantic
quality requirements (description accuracy, strategy intent, actionable
instructions, placement, consolidation, precomputed commands, auto-fix
marking). Remove the now-redundant deepreview_config_quality rule from
the root .deepreview since the deepschema covers the same ground.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: nhorton

.deepreview

@@ -369,90 +369,6 @@ shell_code_review:
         section markers) still accurate after the changes? Flag any comments
         that describe behavior that no longer matches the code.
 
-deepreview_config_quality:
-  description: "Review .deepreview configs for rule consolidation, overly broad rules, description accuracy, and correct directory placement."
-  match:
-    include:
-      - "**/.deepreview"
-  review:
-    strategy: matches_together
-    additional_context:
-      unchanged_matching_files: true
-    instructions: |
-      Review the .deepreview config files for structural quality. Check all
-      four of the following, across ALL .deepreview files (changed and unchanged):
-
-      ## 1. Rule Consolidation
-
-      Rules that match the same (or nearly the same) set of files SHOULD be
-      combined into a single rule — unless merging their instructions would
-      make the reviewer's context too large or unfocused. Specifically:
-
-      - Flag rules in the same .deepreview file (or across files at the same
-        directory level) whose `match.include` patterns overlap substantially.
-      - "Too large" means the combined instructions would exceed ~2000 words
-        or cover unrelated concerns that would confuse a single reviewer.
-      - If two rules match identical files but one uses a specialized `agent`
-        persona, that is a valid reason to keep them separate.
-
-      ## 2. Description Accuracy
-
-      Each rule's `description` field must accurately reflect what the rule
-      actually checks. Compare the description to the `instructions` (inline
-      or referenced file) and flag any mismatches. For example:
-
-      - A description saying "Review Python files for security" when the
-        instructions only check formatting — flag it.
-      - A description that is vague or generic when the instructions are
-        specific — flag it and suggest a more accurate description.
-
-      ## 3. Overly Broad Rules (Needless Combining)
-
-      The inverse of consolidation: a single rule that matches a broad set of
-      files but whose instructions are actually file-specific or path-specific.
-      This is a sign the rule should be split into multiple narrower rules.
-
-      Indicators to flag:
-      - A rule with a wide `match.include` pattern (e.g., `**/*.py`, `src/**`)
-        but instructions that say things like "For files in src/foo/, check X;
-        for files in src/bar/, check Y" — these should be separate rules with
-        narrower match patterns.
-      - Instructions that enumerate specific filenames or paths and assign
-        different checks to each — the match pattern should be doing this
-        filtering, not the instructions.
-      - A rule whose instructions are mostly conditional on which file is being
-        reviewed, rather than applying uniformly to all matched files.
-
-      Exceptions (do NOT flag these):
-      - Rules where ~70%+ of the instructions apply to all matched files, with
-        only minor per-file notes (e.g., "For test files, also check fixtures").
-      - Rules using `matches_together` strategy where cross-file analysis is
-        the point (e.g., doc-sync rules that compare source and documentation).
-
-      ## 4. Directory Placement
-
-      .deepreview files should live as close as possible to the files they
-      govern. If ALL of a rule's `match.include` patterns target files within
-      a single subdirectory (e.g., `learning_agents/**`), then the rule
-      should likely live in that subdirectory's `.deepreview` file instead
-      of the project root. Flag rules that could be moved closer to their
-      target files.
-
-      Exceptions (do NOT flag these):
-      - Rules that intentionally match files across multiple top-level
-        directories (e.g., `src/**` AND `tests/**`).
-      - Rules using `all_changed_files` strategy, which are project-wide
-        by nature.
-      - Rules that reference `additional_context.unchanged_matching_files`
-        with patterns spanning multiple directories.
-
-      ## Output Format
-
-      - PASS: No issues found.
-      - FAIL: Issues found. List each with the .deepreview file path,
-        rule name, which check failed (consolidation / description / overly-broad / placement),
-        and a specific recommendation.
-
 job_schema_instruction_compatibility:
   description: "Verify all standard and library job.yml definitions and templates are compatible with the job schema."
   match:

src/deepwork/standard_schemas/deepreview/deepreview_schema.json

@@ -0,0 +1 @@
+../../schemas/deepreview_schema.json

src/deepwork/standard_schemas/deepreview/deepschema.yml

@@ -0,0 +1,84 @@
+summary: "Schema for .deepreview config files that define automated code review rules."
+
+instructions: |
+  .deepreview files define review rules that match changed files by glob pattern and
+  run AI-powered reviews against them. Each rule has a description, match patterns,
+  a review strategy, and instructions for the reviewer. The JSON schema enforces
+  structure; these requirements enforce quality that structural validation cannot catch.
+
+  Key concepts:
+  - Rules are scoped by directory — a .deepreview file governs files relative to its location
+  - Strategies control batching: individual (one task per file), matches_together (one task
+    for all matched files), all_changed_files (one task with every changed file in the PR)
+  - Instructions can be inline or referenced from a markdown file
+  - precomputed_info_for_reviewer_bash_command runs before the reviewer and injects output
+    as context, avoiding the need for the reviewer to run tools itself
+  - additional_context.unchanged_matching_files pulls in unchanged files that match the
+    pattern, useful for cross-file consistency checks
+
+json_schema_path: "deepreview_schema.json"
+
+matchers:
+  - "**/.deepreview"
+
+requirements:
+  description-matches-instructions: >
+    Each rule's `description` MUST accurately reflect what the rule's instructions
+    actually check. A description saying "Review for security" when instructions only
+    check formatting is misleading. Descriptions are used for rule discovery and
+    triage — inaccurate descriptions waste reviewer time.
+
+  strategy-matches-intent: >
+    The `strategy` MUST match the rule's review intent. Use `individual` when each
+    file can be reviewed independently. Use `matches_together` when the reviewer needs
+    to see all matched files together (e.g., cross-file consistency, DRY checks). Use
+    `all_changed_files` when the reviewer needs full PR context regardless of match
+    patterns (e.g., requirements traceability). A rule using `matches_together` or
+    `all_changed_files` whose instructions only examine each file in isolation SHOULD
+    use `individual` instead.
+
+  instructions-actionable: >
+    Rule instructions MUST be specific enough for a reviewer to produce a consistent
+    PASS/FAIL verdict. "Check if it looks good" is not actionable. Instructions SHOULD
+    enumerate concrete checks and specify the output format (PASS with no issues, or
+    FAIL with file, line, and description for each issue).
+
+  instructions-not-overly-broad: >
+    A single rule MUST NOT contain per-file or per-path conditional logic in its
+    instructions (e.g., "For files in src/foo/, check X; for files in src/bar/,
+    check Y"). If instructions vary by file path, the rule SHOULD be split into
+    multiple narrower rules with appropriate match patterns.
+
+  placement-near-target: >
+    Rules SHOULD live in the .deepreview file closest to the files they govern. If
+    all of a rule's match patterns target files within a single subdirectory, the
+    rule SHOULD be in that subdirectory's .deepreview file, not the project root.
+    Exception: rules that intentionally span multiple top-level directories or use
+    `all_changed_files` strategy are project-wide by nature.
+
+  no-overlapping-rules: >
+    Rules in the same .deepreview file (or at the same directory level) whose match
+    patterns overlap substantially SHOULD be combined into a single rule — unless
+    merging would make instructions unfocused (over ~2000 words), or the rules use
+    different `agent` personas. Duplicate coverage wastes reviewer time and can
+    produce contradictory findings.
+
+  precompute-runnable-commands: >
+    If a rule's instructions tell the reviewer to run a shell command (e.g.,
+    `uv run ruff`, `make lint`, `pytest`), that command SHOULD be moved to
+    `precomputed_info_for_reviewer_bash_command` instead. The reviewer receives
+    precomputed output as context automatically, which is faster and more reliable
+    than having the reviewer invoke tools. Instructions SHOULD then reference the
+    precomputed output rather than telling the reviewer to run commands.
+
+  file-reference-for-long-instructions: >
+    Rules with inline instructions exceeding ~80 lines SHOULD use a file reference
+    (`instructions: { file: path/to/instructions.md }`) instead. Long inline YAML
+    blocks are hard to read, edit, and diff. The referenced file can use full markdown
+    formatting.
+
+  auto-fix-rules-clearly-marked: >
+    Rules that instruct the reviewer to edit files (auto-fix rules) MUST clearly
+    state "This is an auto-fix rule — you SHOULD edit files to resolve issues" at
+    the top of their instructions. This distinguishes them from read-only review
+    rules and sets correct expectations for the reviewer agent.