dev-booster 1.13.0 → 1.15.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-booster",
-  "version": "1.13.0",
+  "version": "1.15.0",
   "description": "Reusable AI development kit with manual boosters, governance, and project bootstrap",
   "type": "module",
   "scripts": {

package/template/.devbooster/boosters/diff-review.md

@@ -41,17 +41,26 @@ Report the current state clearly to the user:
 - Current branch
 
 ### PHASE 2 — SCOPE SELECTION
-Present the user with three review options based on the current Git state:
+Present the user with three review options based on the current Git state using a vertical list format that renders clearly in narrow chat UIs:
 
-```
+```md
 O que você quer revisar?
-  [1] Unstaged changes        (git diff)
-  [2] Staged changes          (git diff --cached)
-  [3] Working tree + commits  (git diff HEAD~N)
+
+1. Unstaged changes
+   `git diff`
+
+2. Staged changes
+   `git diff --cached`
+
+3. Working tree + commits
+   `git diff HEAD~N`
+
+Se escolher `3`, eu vou te perguntar quantos commits atrás incluir.
 ```
 
-- If the user picks `[1]` or `[2]`, proceed directly to Phase 3 with the respective `git diff`.
-- If the user picks `[3]`, ask: *"Quantos commits atrás incluir? (padrão: 1)"*. Accept a numeric answer (e.g., `1`, `2`, `3`). Use `1` as default if the user does not specify. Then run `git diff HEAD~<N>` which includes both the working tree changes and the last N commits.
+- Accept `1`, `2`, or `3` as the user's answer.
+- If the user picks `1` or `2`, proceed directly to Phase 3 with the respective `git diff`.
+- If the user picks `3`, ask: *"Quantos commits atrás incluir? (padrão: 1)"*. Accept a numeric answer (e.g., `1`, `2`, `3`). Use `1` as default if the user does not specify. Then run `git diff HEAD~<N>` which includes both the working tree changes and the last N commits.
 
 ### PHASE 3 — DIFF REVIEW EXECUTION
 After the user selects the scope:
@@ -145,57 +154,40 @@ Analyze the diff across these dimensions:
 
 ## 4. OUTPUT STRUCTURE (MANDATORY)
 
-Your response MUST use this exact format:
-
-```md
-## 🔍 Diff Review: [HEAD~N..HEAD]
+Your response MUST be concise, decision-oriented, and written like a senior developer approving or blocking a PR. Prefer brevity over exhaustiveness.
 
-### 📋 Files Analyzed
-- `file/path.ts` (X additions, Y deletions)
-- ...
+Use this exact format:
 
-### ✅ What Looks Good
-- [Positive observations about naming, consistency, reuse, or project alignment]
-
-### ⚠️ Review Comments
-#### Naming
-- `[file:line]` — [comment and suggested direction]
-
-#### Duplication
-- `[file:line]` — [comment and suggested direction]
+```md
+## 🔍 Diff Review
 
-#### Project Patterns
-- `[file:line]` — [comment and suggested direction]
+Escopo revisado: [unstaged changes | staged changes | working tree + N commits | N arquivos alterados]
 
-#### Responsibility Boundaries
-- `[file:line]` — [comment and suggested direction]
+### ✅ O que está bom
+- [1 to 3 short positive observations only if they are genuinely useful]
 
-#### Readability
-- `[file:line]` — [comment and suggested direction]
+### ⚠️ Pontos de atenção
+- `[file:line]` — [short, direct comment and suggested direction]
+- `[file:line]` — [short, direct comment and suggested direction]
 
 ### 🏁 Verdict
 **APPROVED** | **MINOR SUGGESTIONS** | **NEEDS CHANGES**
 
-[Short justification for the verdict]
-
-📝 Review saved at `@booster-generated/diff-review/<slug>.md`
+[One short justification line]
 ```
 
 ### Output rules:
-- Group comments by dimension.
+- Do NOT list every analyzed file.
+- If useful, summarize scope only as a short count or diff mode.
+- Keep the review compact and scan-friendly.
+- Limit comments to the most important issues only, ideally 3 to 5 maximum.
+- Prefer direct comments over long explanations.
+- Group all issues under `Pontos de atenção` instead of expanding into many sections.
+- If there is nothing meaningful to praise, omit `O que está bom`.
+- If there is nothing meaningful to flag, omit `Pontos de atenção`.
 - Always include file path and line when referencing code.
-- Be constructive and direct, like a senior developer reviewing a PR.
-- Explain why the change would improve readability, consistency, reuse, or project alignment.
-- If there is nothing to comment in a dimension, omit that dimension.
 - Do not invent issues that are not visible in the diff or verifiable from local patterns.
 - The verdict must be clear and justified.
+- Do NOT generate files, artifacts, logs, or review documents for this booster.
 
-## ARTIFACT GENERATION
-During your execution, create a state file at `@booster-generated/diff-review/<slug>.md` with the full review report.
-
-- **Uniqueness rule:** If the slug already exists in `@booster-generated/diff-review/`, generate a new variation of the name instead of overwriting
-- **Notification rule:** After writing, notify the user with: 📝 Review saved at `@booster-generated/diff-review/<slug>.md`
-
-Do NOT update this file silently in the background.
-
-**Reply:** On activation only, use the armed-mode banner above, check the Git state, report it clearly, and present the three review options. After the user selects the scope, load the required local rules and review intelligence, analyze the appropriate `git diff` as a senior code writing review, generate the report, notify the artifact path, and answer in the global language configured for the active LLM/environment.
+**Reply:** On activation only, use the armed-mode banner above, check the Git state, report it clearly, and present the three review options. After the user selects the scope, load the required local rules and review intelligence, analyze the appropriate `git diff` as a senior code writing review, and answer concisely in the global language configured for the active LLM/environment.