diff --git a/plugins/compound-engineering/skills/document-review/references/subagent-template.md b/plugins/compound-engineering/skills/document-review/references/subagent-template.md index 8cbf1ea..7baf1b9 100644 --- a/plugins/compound-engineering/skills/document-review/references/subagent-template.md +++ b/plugins/compound-engineering/skills/document-review/references/subagent-template.md @@ -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. diff --git a/plugins/compound-engineering/skills/document-review/references/synthesis-and-presentation.md b/plugins/compound-engineering/skills/document-review/references/synthesis-and-presentation.md index 466ffbc..083a404 100644 --- a/plugins/compound-engineering/skills/document-review/references/synthesis-and-presentation.md +++ b/plugins/compound-engineering/skills/document-review/references/synthesis-and-presentation.md @@ -53,6 +53,11 @@ Scan `present` findings for codebase-pattern-resolved auto-eligibility. Promote The principle: when a reviewer mentions multiple theoretical approaches but the codebase already has an established pattern that makes one approach clearly correct, the codebase context settles the question. Alternatives mentioned in passing do not create a real tradeoff if the evidence shows the codebase has already chosen. +Additional auto-promotion patterns (promote `present` -> `auto` when): +- The finding identifies factually incorrect behavior in the document and the suggested fix describes the correct behavior (not a design choice between alternatives) +- The finding identifies a missing industry-standard security control where the document's own context makes the omission clearly wrong (not a legitimate design choice for the system described), and the suggested fix follows established practice +- The finding identifies an incomplete technical description and the complete version is directly derivable from the codebase (the reviewer cited specific code showing what the description should say) + Do not promote if the finding involves scope or priority changes where the document author may have weighed tradeoffs invisible to the reviewer. ### 3.7 Route by Autofix Class @@ -66,7 +71,7 @@ Do not promote if the finding involves scope or priority changes where the docum Demote any `auto` finding that lacks a `suggested_fix` to `present`. -**Auto-eligible patterns:** summary/detail mismatch (body is authoritative over overview), wrong counts, missing list entries derivable from elsewhere in the document, stale internal cross-references, terminology drift, prose/diagram contradictions where prose is more detailed, missing steps mechanically implied by other content, unstated thresholds implied by surrounding context, completeness gaps where the correct addition is obvious, codebase-pattern-resolved fixes where the reviewer cites a specific existing pattern and the suggested_fix follows it. If the fix requires judgment about *what* to do (not just *what to write*) and the codebase context does not resolve the ambiguity, it belongs in `present`. +**Auto-eligible patterns:** summary/detail mismatch (body is authoritative over overview), wrong counts, missing list entries derivable from elsewhere in the document, stale internal cross-references, terminology drift, prose/diagram contradictions where prose is more detailed, missing steps mechanically implied by other content, unstated thresholds implied by surrounding context, completeness gaps where the correct addition is obvious, codebase-pattern-resolved fixes where the reviewer cites a specific existing pattern and the suggested_fix follows it, factually incorrect behavior where the correct behavior is obvious from context or the codebase, missing standard security controls with known implementations, incomplete technical descriptions where the complete version is derivable from the codebase. If the fix requires judgment about *what* to do (not just *what to write*) and the codebase context does not resolve the ambiguity, it belongs in `present`. ### 3.8 Sort diff --git a/plugins/compound-engineering/skills/git-commit-push-pr/SKILL.md b/plugins/compound-engineering/skills/git-commit-push-pr/SKILL.md index e709852..fd0e838 100644 --- a/plugins/compound-engineering/skills/git-commit-push-pr/SKILL.md +++ b/plugins/compound-engineering/skills/git-commit-push-pr/SKILL.md @@ -317,18 +317,25 @@ Append a badge footer to the PR description, separated by a `---` rule. Do not a --- [![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin) -🤖 Generated with [MODEL] ([CONTEXT] context, [THINKING]) via [HARNESS](HARNESS_URL) +![HARNESS](https://img.shields.io/badge/HARNESS_SLUG-MODEL_SLUG-COLOR?logo=LOGO&logoColor=white) ``` -Fill in at PR creation time: +Fill in at PR creation time using the harness and model lookup tables below. -| Placeholder | Value | Example | -|-------------|-------|---------| -| `[MODEL]` | Model name | Claude Opus 4.6, GPT-5.4 | -| `[CONTEXT]` | Context window (if known) | 200K, 1M | -| `[THINKING]` | Thinking level (if known) | extended thinking | -| `[HARNESS]` | Tool running you | Claude Code, Codex, Gemini CLI | -| `[HARNESS_URL]` | Link to that tool | `https://claude.com/claude-code` | +**Harness lookup:** + +| Harness | `HARNESS_SLUG` | `LOGO` | `COLOR` | +|---------|---------------|--------|---------| +| Claude Code | `Claude_Code` | `claude` | `D97757` | +| Codex | `Codex` | (omit logo param) | `000000` | +| Gemini CLI | `Gemini_CLI` | `googlegemini` | `4285F4` | + +**Model slug:** Replace spaces with underscores in the model name. Append context window and thinking level in parentheses if known, separated by commas. Examples: + +- `Opus_4.6_(1M,_Extended_Thinking)` +- `GPT_5.4_(High)` +- `Sonnet_4.6_(200K)` +- `Opus_4.6` (if context and thinking level are unknown) ### Step 7: Create or update the PR @@ -340,13 +347,13 @@ PR description here --- -[BADGE LINE FROM BADGE SECTION ABOVE] -🤖 Generated with [MODEL] ([CONTEXT] context, [THINKING]) via [HARNESS](HARNESS_URL) +[![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin) +![Claude Code](https://img.shields.io/badge/Claude_Code-Opus_4.6_(1M,_Extended_Thinking)-D97757?logo=claude&logoColor=white) EOF )" ``` -Use the badge from the Compound Engineering badge section above. +Use the badge from the Compound Engineering badge section above. Replace the harness and model badge with values from the lookup tables. Keep the PR title under 72 characters. The title follows the same convention as commit messages (Step 2).