john/claude-engineering-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(document-review): widen autofix classification beyond trivial fixes (#524)

Browse Source
This commit is contained in:
Trevin Chow
2026-04-06 22:05:27 -07:00
committed by GitHub
parent a6183ed000
commit 9a82222aba
3 changed files with 36 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
plugins/compound-engineering/skills/document-review/references/subagent-template.md
View File

@@ -26,9 +26,17 @@ Rules:
- Set `finding_type` for every finding:
- `error`: Something the document says that is wrong -- contradictions, incorrect statements, design tensions, incoherent tradeoffs.
- `omission`: Something the document forgot to say -- missing mechanical steps, absent list entries, undefined thresholds, forgotten cross-references.
- Set `autofix_class` based on whether there is one clear correct fix, not on severity:
- `auto`: One clear correct fix, applied silently. Three categories: (1) internal reconciliation -- one document part authoritative over another (summary/detail mismatches, wrong counts, stale cross-references, terminology drift); (2) implied additions -- correct content mechanically obvious from the document (missing steps, unstated thresholds, completeness gaps); (3) codebase-pattern-resolved -- an established codebase pattern resolves ambiguity (cite the specific file/function in `why_it_matters`). Always include `suggested_fix`. NOT auto if more than one reasonable fix exists or if scope/priority judgment is involved.
- `present`: Requires user judgment -- strategic questions, tradeoffs, design tensions.
- Set `autofix_class` based on whether there is one clear correct fix, not on severity or importance:
- `auto`: One clear correct fix, applied silently. This includes trivial fixes AND substantive ones:
- Internal reconciliation -- one document part authoritative over another (summary/detail mismatches, wrong counts, stale cross-references, terminology drift)
- Implied additions -- correct content mechanically obvious from the document (missing steps, unstated thresholds, completeness gaps)
- Codebase-pattern-resolved -- an established codebase pattern resolves ambiguity (cite the specific file/function in `why_it_matters`)
- Incorrect behavior -- the document describes behavior that is factually wrong, and the correct behavior is obvious from context or the codebase
- Missing standard security measures -- HTTPS enforcement, checksum verification, input sanitization, private IP rejection, or other controls with known implementations where omission is clearly a bug
- Incomplete technical descriptions -- the accurate/complete version is directly derivable from the codebase
- Missing requirements that follow mechanically from the document's own explicit, concrete decisions (not high-level goals -- a goal can be satisfied by multiple valid requirements)
The test is not "is this fix important?" but "is there more than one reasonable way to fix this?" If a competent implementer would arrive at the same fix independently, it is auto -- even if the fix is substantive. Always include `suggested_fix`. NOT auto if more than one reasonable fix exists or if scope/priority judgment is involved.
- `present`: Requires user judgment -- genuinely multiple valid approaches where the right choice depends on priorities, tradeoffs, or context the reviewer does not have. Examples: architectural choices with real tradeoffs, scope decisions, feature prioritization, UX design choices.
- `suggested_fix` is required for `auto` findings. For `present` findings, include only when the fix is obvious.
- If you find no issues, return an empty findings array. Still populate residual_risks and deferred_questions if applicable.
- Use your suppress conditions. Do not flag issues that belong to other personas.