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

feat(ce-brainstorm): group requirements by logical concern, tighten autofix classification (#412)

Browse Source 
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Trevin Chow
2026-03-27 13:06:50 -07:00
committed by GitHub
parent 69fc5032b2
commit 90684c4e82
3 changed files with 12 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
plugins/compound-engineering/skills/ce-brainstorm/SKILL.md
View File

@@ -186,8 +186,13 @@ topic: <kebab-case-topic>
[Who is affected, what is changing, and why it matters]
## Requirements
- R1. [Concrete user-facing behavior or requirement]
- R2. [Concrete user-facing behavior or requirement]
**[Group Header]**
- R1. [Concrete requirement in this group]
- R2. [Concrete requirement in this group]
**[Group Header]**
- R3. [Concrete requirement in this group]
## Success Criteria
- [How we will know this solved the right problem]
@@ -221,6 +226,8 @@ For **Lightweight** brainstorms, keep the document compact. Skip document creati
For very small requirements docs with only 1-3 simple requirements, plain bullet requirements are acceptable. For **Standard** and **Deep** requirements docs, use stable IDs like `R1`, `R2`, `R3` so planning and later review can refer to them unambiguously.
When requirements span multiple distinct concerns, group them under bold topic headers within the Requirements section. The trigger for grouping is distinct logical areas, not item count — even four requirements benefit from headers if they cover three different topics. Group by logical theme (e.g., "Packaging", "Migration and Compatibility", "Contributor Workflow"), not by the order they were discussed. Requirements keep their original stable IDs — numbering does not restart per group. A requirement belongs to whichever group it fits best; do not duplicate it across groups. Skip grouping only when all requirements are about the same thing.
When the work is simple, combine sections rather than padding them. A short requirements document is better than a bloated one.
Before finalizing, check:

2
plugins/compound-engineering/skills/document-review/references/findings-schema.json
View File

@@ -98,7 +98,7 @@
},
"autofix_classes": {
"auto": "Local, deterministic document fix: terminology consistency, formatting, cross-reference correction, completeness corrections (wrong counts, missing list entries, undefined values where the correct value is verifiable from elsewhere in the document). Must be unambiguous.",
"batch_confirm": "Obvious fix with a clear correct answer, but touches document meaning enough to warrant user awareness. Grouped with other batch_confirm findings for a single approval rather than individual review. Examples: adding a missing implementation step that is mechanically implied, updating a section summary to reflect its own contents.",
"batch_confirm": "Obvious fix with a clear correct answer, but requires authoring new content where exact wording needs verification. Grouped with other batch_confirm findings for a single approval rather than individual review. Examples: adding a missing implementation step that is mechanically implied, rewording a section to resolve an ambiguity. Note: fixes that are deterministically derivable from existing document content (updating a summary to match its own list, correcting a count, adding group headers to requirements) belong in auto, not here.",
"present": "Requires individual user judgment -- strategic questions, design tradeoffs, meaning-changing fixes, or findings where reasonable people could disagree on the right action."
},
"finding_types": {