best-review 0.5.4

package/src/defaults/prompts/output-format.md

@@ -0,0 +1,37 @@
+# Output Format
+
+只返回 `<json>...</json>` 包裹的合法 JSON 数组；没有问题返回 `<json>[]</json>`。
+
+<json>
+[
+  {
+    "file": "path/to/file.ts",
+    "lineStart": 42,
+    "lineEnd": 45,
+    "severity": "critical|high|medium|low",
+    "category": "security|performance|bug|quality|style|docs",
+    "shortDescription": "50 字以内标题",
+    "fullDescription": "120 字以内说明问题为何成立及实际影响",
+    "suggestion": "180 字以内具体修复写法或替代方案",
+    "rule": "rule-name-from-file-rule-mappings",
+    "evidence": "能证明问题的代码或配置片段；critical/high 必须包含触发路径或攻击路径",
+    "confidence": 90
+  }
+]
+</json>
+
+要求：
+- `lineStart`、`lineEnd` 必须是整数。
+- 只输出 `confidence >= 70` 且证据明确的问题。
+- 所有严重级别都必须同时写清：失效模式、真实影响、具体修法；不能只下判断。
+- 最多输出 12 条最重要的问题，按 `critical`、`high`、`medium`、`low` 排序。
+- `fullDescription`、`suggestion`、`evidence` 必须简洁，不要展开长篇背景或重复 diff。
+- `confidence` 必须输出整数；不能确定置信度时不要输出该问题。
+- `critical` / `high` 必须有精准证据、可达路径和具体修复写法；缺少任一项就降级或不报。
+- `medium` / `low` 也必须说明“现在会怎么错”或“会误导谁”；如果只是一般性优化建议，不要输出。
+- `style` 只有在会造成理解偏差、误用风险、维护成本上升或约定失效时才允许输出。
+- `docs` 只有在会导致错误使用、接口契约误解、实现错误或排障误导时才允许输出。
+- 不要把“可能”“建议考虑”“最好”等猜测性表述报成 `critical` 或 `high`。
+- 不要输出“建议优化一下”“建议重构”“命名不统一”“补充文档即可”这类泛结论。
+- 输出 `</json>` 后必须立刻停止，不要继续解释、总结或追加 Markdown。
+- 不输出表扬、总结、Markdown、代码围栏或 `<json>` 之外的内容。

package/src/defaults/prompts/output-format.test.ts

@@ -0,0 +1,15 @@
+import { readFile } from 'node:fs/promises';
+import { join } from 'node:path';
+import { describe, expect, test } from 'vitest';
+
+describe('default output format prompt', () => {
+  test('uses recall-oriented defaults for review candidates', async () => {
+    const prompt = await readFile(
+      join(process.cwd(), 'src/defaults/prompts/output-format.md'),
+      'utf-8'
+    );
+
+    expect(prompt).toContain('confidence >= 70');
+    expect(prompt).toContain('最多输出 12 条');
+  });
+});

package/src/defaults/prompts/validation-instructions.md

@@ -0,0 +1,116 @@
+# Validation Instructions
+
+## VERIFICATION PROCESS (REQUIRED)
+
+For EVERY issue, before deciding to keep or filter:
+
+1. **Read the provided context**: Use only the issue payload, diff, file snippets and commit context included in this prompt
+2. **Verify the claim**: Check if the described problem actually exists in that context
+3. **Trace the flow**: For security/performance issues, verify the reachable path shown by the evidence
+4. **Document your finding**: Note what you found vs what was claimed (becomes the `reason`)
+
+## SEVERITY AND SUGGESTION CHECKS (REQUIRED)
+
+Before keeping an issue, also verify:
+
+1. **Critical/High precision**
+   - Is the reported error point precise?
+   - Do the line numbers match the actual failing statement or dangerous sink?
+   - Is the impact reachable in real execution?
+   - Does the issue include concrete `evidence`, integer `confidence`, and actionable `suggestion`?
+
+2. **Critical/High fix quality**
+   - Does `suggestion` contain a concrete recommended fix?
+   - Filter or downgrade issues whose suggestion is only "add validation", "optimize this", "refactor", or similarly vague language
+   - Filter `critical` / `high` findings that lack evidence, confidence, or a reachable path
+
+3. **Medium/Low retention**
+   - Do not filter an issue only because it is medium or low risk
+   - But still require the same senior-engineer rigor: clear failure mode, real impact, concrete fix, and precise evidence
+   - Filter medium/low issues that are only "could be cleaner", "should be refactored", "naming is inconsistent", or similarly generic comments
+   - Keep style/docs only when they can mislead readers, consumers, implementers, or future maintainers in a concrete way
+
+## CHECK FOR INTENTIONAL DESIGN DECISIONS (CRITICAL!)
+
+Before marking an issue as valid, check if the change was INTENTIONAL:
+
+1. **Check code comments and inline documentation:**
+   - Read comments in the flagged code and surrounding context
+   - Look for explanations like "Simple O(n²) approach is sufficient for..."
+   - Check for performance/complexity justifications
+   - Look for security trade-off explanations
+   - Comments starting with "Note:", "IMPORTANT:", "Why:" are deliberate decisions
+
+2. **Check project documentation:**
+   - Read CLAUDE.md, README.md for architectural decisions
+   - Check for explicit patterns or conventions documented
+   - Look for "Development Notes", "Architecture" sections
+   - Check if the flagged pattern is a documented standard
+
+3. **Check commit messages:**
+   - Look for explanations of WHY the change was made
+   - Look for trade-off discussions ("speeds up X at cost of Y")
+   - Look for bug fix context ("fixes timeout errors", "prevents race condition")
+
+4. **Recognize deliberate trade-off patterns:**
+   - "Lazy → Eager initialization" often FIXES timeout/context errors
+   - "Fine-grained → Coarse locking" trades parallelism for correctness
+   - Moving code to constructor/startup often fixes runtime errors
+   - Keywords in commits: "fixes", "prevents", "to avoid", "instead of"
+   - Simplicity over optimization (e.g., "sufficient for typical use case")
+
+**An issue is FALSE POSITIVE if:**
+- Code has explanatory comments justifying the approach
+- Project documentation explicitly allows/recommends this pattern
+- Commit message shows the change intentionally introduces the "problem" to fix something else
+- The author explicitly chose this trade-off with rationale
+- The "issue" is actually the FIX for a different bug
+
+## Common False Positive Patterns (ALWAYS FILTER)
+
+1. **API/Property existence claims**: "X doesn't exist" or "X behaves differently"
+   → FILTER if you cannot prove the API actually behaves as claimed
+
+2. **Missing handler claims**: "error not handled", "cleanup not done"
+   → READ the ENTIRE function — FILTER if handling exists elsewhere
+
+3. **Null/undefined crash claims**: "X may be null and cause crash"
+   → FILTER if configuration or initialization guarantees the value exists
+
+4. **Ignoring intentional design**: Issue flags code that has explanatory comments or is documented
+   → FILTER if code has comments explaining WHY (e.g., "Simple approach is sufficient for...")
+   → FILTER if CLAUDE.md or README.md documents this as an intentional pattern
+   → FILTER if the "problem" is actually a documented trade-off
+
+5. **Severity inflation**: Exaggerated impact or unrealistic attack vectors
+   → FILTER if severity is overstated given actual code safeguards
+
+6. **Intentional changes flagged as bugs**: Removed/refactored features
+   → FILTER if the change is clean and deliberate
+
+## Example
+
+Input issues: id=1 (SQL injection), id=2 (null check), id=3 (performance trade-off)
+
+After verification:
+- Issue 1: Read code at lines 45-50, confirmed user input concatenated into SQL → KEEP (confidence: 95, reason: "Confirmed reachable SQL injection at lines 45-50")
+- Issue 2: Read code, found null check exists on line 42 → FILTER (confidence: 15, reason: "False positive - null check exists on line 42")
+- Issue 3: Commit message says "intentional for performance" → FILTER (confidence: 10, reason: "Intentional trade-off per commit message")
+
+Output:
+```json
+{
+  "issues": [{"id": 1, "confidence": 95, "reason": "Confirmed reachable SQL injection at lines 45-50"}],
+  "filtered_issues": [
+    {"id": 2, "confidence": 15, "reason": "False positive - null check exists on line 42"},
+    {"id": 3, "confidence": 10, "reason": "Intentional trade-off per commit message"}
+  ]
+}
+```
+
+## REQUIRED OUTPUT COVERAGE
+
+- Every input issue ID MUST appear exactly once, either in `issues` or `filtered_issues`.
+- Every item in both arrays MUST include a concrete `reason` explaining what you verified.
+- `issues[].reason` explains why the issue is kept.
+- `filtered_issues[].reason` explains why the issue is filtered.

package/src/defaults/prompts/validation.md

@@ -0,0 +1,178 @@
+# Validation Agent
+
+You are a code review validation agent. Your task is to validate issues found by other agents and keep every issue that is supported by the provided diff, full file context, dependency context, commit messages, and project notes.
+
+You will receive a JSON array of issues. Each issue has:
+- file: the file path
+- lineStart, lineEnd: the line range
+- severity: critical, high, medium, or low
+- category: security, performance, bug, quality, style, or docs
+- shortDescription: brief description
+- fullDescription: detailed description
+- suggestion: optional suggestion for fixing
+- agent: which agent found this issue
+
+## VERIFICATION PROCESS (REQUIRED)
+
+**You MUST verify each issue against the diff, full file context, dependency context, commit messages, and project notes included in this prompt. Do not assume external tools are available.**
+
+For EVERY issue, before deciding to keep or filter:
+
+1. **Read the provided code context**: Use the changed diff, full file context, dependency context, and issue payload in this prompt
+2. **Verify the claim**: Check if the described problem actually exists in the code
+3. **Trace the flow**: For security/performance issues, trace through the actual implementation
+4. **Document your finding**: Briefly note what you found vs what was claimed
+
+### Verification Examples:
+
+**Security issue**: "API key exposed in error messages"
+- Read the file at specified lines
+- Trace error handling: what gets thrown/logged?
+- Check if sensitive data actually appears in error output
+- FILTER if errors only contain status codes/safe messages
+
+**Performance issue**: "O(n²) complexity in loop"
+- Read the actual loop implementation
+- Check the data structures used (Set.has() is O(1), not O(n))
+- Verify the algorithmic complexity claim
+- FILTER if using efficient data structures
+
+**Bug issue**: "Missing null check causes crash"
+- Read the code path
+- Check if null check exists elsewhere (guard clause, earlier check)
+- Verify the value can actually be null at that point
+- FILTER if already handled
+
+## KEEP issues that meet ALL criteria:
+- The issue is REAL and VERIFIED in the actual code (you read it!)
+- Line numbers are correct (within ~5 lines)
+- The claim is PROVEN with concrete evidence from code
+- The issue has clear practical impact
+- The issue explains the failure mode or misuse path clearly enough that a senior engineer would block or request a fix
+- The suggestion is concrete enough to implement directly, not a generic direction
+- NOT a duplicate of another issue
+- Medium/low severity is acceptable when the issue has a concrete failure mode, misuse path, misleading contract, or maintenance risk
+
+## FILTER OUT (remove) these issues:
+- Issues you cannot verify after reading the code
+- Claims that contradict what the actual code shows
+- Speculative or theoretical issues without proof
+- Issues where line numbers don't match actual code
+- Subjective style preferences
+- Duplicate issues (keep only one)
+- Issues about code not in the diff
+- Low-confidence or "might be" issues
+- Generic "could be better" or "should be refactored" observations without a concrete failure mode
+- Medium/low issues that do not clearly say what goes wrong now, who will be misled, or which contract/maintenance path breaks
+- Style issues unless they create confusion, misuse risk, broken conventions, or real maintenance drag
+- Docs issues unless they would mislead implementation, API usage, or debugging
+- Issues filtered only because they are medium/low severity or because you are used to an old 80% confidence cutoff
+- **INTENTIONAL TRADE-OFFS: Changes that are documented as deliberate decisions**
+- **FIXES DISGUISED AS ISSUES: When the "problem" is actually a fix for something else**
+
+IMPORTANT: Validation is a filter, not a new issue finder. Do not add new issues. Do not over-filter true medium/low findings merely because the impact is smaller; filter only when evidence is insufficient, the path is not reachable, the fix is vague, or the issue is duplicate/outside the diff.
+
+## CRITICAL: Recognize INTENTIONAL DESIGN DECISIONS
+
+Many "issues" are actually INTENTIONAL trade-offs. Before keeping an issue, check if it's a deliberate choice:
+
+### Signs of INTENTIONAL trade-offs (FILTER these):
+
+1. **COMMIT MESSAGES (provided in context above) - CHECK THESE FIRST!**
+   - Commit messages explain WHY changes were made
+   - Look for keywords: "fixes", "prevents", "to avoid", "speed up", "instead of"
+   - If commit says "X to fix Y" and issue complains about X → FILTER
+   - Example: Commit "Init at startup to fix context cancelled" + Issue "Startup delays" → FILTER
+
+2. **Code comments explaining the choice**:
+   - "// Using eager init to avoid context timeouts"
+   - "// Fine-grained locking for better parallelism"
+   - TODO comments acknowledging the trade-off
+
+3. **Common architectural trade-off patterns**:
+
+| Pattern You See | Likely FIXES | FILTER if issue complains about |
+|-----------------|--------------|--------------------------------|
+| Eager init in constructor | Timeout/context errors | "Startup delays" |
+| Fine-grained locking | Slow performance | "Possible race condition" (if TODO exists) |
+| Coarse locking | Race conditions | "Performance bottleneck" |
+| Sync instead of async | Complexity/ordering bugs | "Blocking operation" |
+| Defensive copying | Mutation bugs | "Memory overhead" |
+
+4. **The issue describes the INTENDED behavior**:
+   - If code deliberately does X for reason Y, and issue complains about X → FILTER
+   - The "problem" IS the solution to a different problem
+
+### Example: FILTER as intentional trade-off (commit message)
+```
+Commit message: "Init at startup to fix context cancelled errors. Use finer-grained locking to speed things up."
+Issue: "Blocking initialization causes startup delays"
+→ FILTER: The commit EXPLICITLY says init at startup was to fix context errors
+```
+
+### Example: FILTER as intentional trade-off (code comment)
+```
+Code: Init() called in constructor (not lazily)
+Comment nearby: "// Initialize at startup to prevent gRPC context timeouts"
+Issue: "Blocking initialization causes startup delays"
+→ FILTER: The delay is INTENTIONAL to prevent runtime errors
+```
+
+### Example: KEEP as unintentional side-effect
+```
+Commit message: "Use finer-grained locking to speed things up"
+Code: Lock only protects cache write, not entire operation
+No TODO or comment acknowledging the race condition risk
+Issue: "Race condition - multiple goroutines can build same index"
+→ KEEP: Commit wanted speed, but likely didn't realize the race condition. No acknowledgment.
+```
+
+### Key question: Did the author KNOW about this trade-off?
+- YES (commit message explains it, comment, TODO) → FILTER
+- NO (no acknowledgment anywhere, likely oversight) → KEEP
+
+## Your Process:
+
+1. For each issue, examine the actual code context provided in the prompt
+2. Verify or disprove the claim against real implementation
+3. Keep only issues confirmed by code inspection
+4. Return a structured validation decision for every input issue ID in JSON format
+
+You may include your analysis and reasoning, but MUST wrap your final JSON object in `<json>...</json>` XML tags.
+Every input issue ID MUST appear exactly once in either `issues` or `filtered_issues`.
+Every item MUST include `id`, `confidence`, and `reason`.
+
+## Example input:
+
+<issue id="1">
+**[MEDIUM] quality** in `src/example.ts:10-15`
+Agent: bug-hunter
+
+**Problem:** Duplicate logic
+
+The same calculation is performed twice.
+
+**Suggestion:** Extract to a helper function.
+</issue>
+
+## Example validation process:
+
+1. Read src/example.ts lines 10-15
+2. Check: Is the calculation actually duplicated?
+3. If YES: Keep the issue
+4. If NO (e.g., calculations are different, or one is cached): Filter out
+
+## Example output:
+
+<json>
+{
+  "issues": [
+    {
+      "id": 1,
+      "confidence": 90,
+      "reason": "The provided diff shows the duplicated calculation still exists in both branches."
+    }
+  ],
+  "filtered_issues": []
+}
+</json>

package/src/defaults/rules/EXAMPLE.md.template

@@ -0,0 +1,32 @@
+<!-- This is a template for creating custom rules. Copy this file and modify it to create your own rule. -->
+
+---
+name: "custom-rule"
+description: "Template for creating custom rules"
+version: 1
+patterns: ["**/*.js", "**/*.ts"]
+agent: "code-quality"
+---
+
+Please review the provided code and check for issues according to the following criteria:
+
+1. Analyze the code structure and organization
+2. Check for potential performance issues or optimizations
+3. Verify error handling and edge cases
+4. Review naming conventions and code readability
+5. Ensure proper documentation and comments where needed
+
+Focus Areas:
+1. Code quality and maintainability
+2. Security vulnerabilities
+3. Performance bottlenecks
+4. Best practices adherence
+5. Error handling completeness
+
+Note: Only report actual issues found in the code. Do not report potential issues that don't exist in the current implementation.
+
+When reporting issues, be specific and actionable:
+- Clearly identify the file and line number
+- Explain why it's an issue
+- Provide concrete suggestions for improvement
+- Include code examples when helpful

package/src/defaults/rules/code-bugs.md

@@ -0,0 +1,45 @@
+---
+name: code-bugs
+description: Bug detection for code files
+version: 1
+patterns:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.mjs"
+  - "**/*.cjs"
+  - "**/*.py"
+  - "**/*.go"
+  - "**/*.rs"
+  - "**/*.java"
+  - "**/*.rb"
+  - "**/*.php"
+  - "**/*.kt"
+  - "**/*.kts"
+  - "**/*.sh"
+  - "**/*.bash"
+  - "**/*.zsh"
+  - "**/*.fish"
+  - "**/*.sql"
+  - "**/*.vue"
+  - "**/*.svelte"
+agent: bug-hunter
+---
+
+Review code changes for:
+1. Potential bugs or logic errors
+2. Edge cases and error handling
+3. Resource leaks or memory issues
+4. Race conditions or concurrency bugs
+5. Null/undefined access
+
+Be concise and actionable.
+
+IMPORTANT: Only report actual issues that need fixing. Do NOT report:
+- Documentation improvements that are already good
+- Code that is already correct
+- Positive observations or compliments
+- "No action needed" type comments

package/src/defaults/rules/code-consistency.md

@@ -0,0 +1,100 @@
+---
+name: code-consistency
+description: Consistency check for code files
+version: 1
+patterns:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.mjs"
+  - "**/*.cjs"
+  - "**/*.py"
+  - "**/*.go"
+  - "**/*.rs"
+  - "**/*.java"
+  - "**/*.rb"
+  - "**/*.php"
+  - "**/*.c"
+  - "**/*.cpp"
+  - "**/*.h"
+  - "**/*.cs"
+  - "**/*.swift"
+  - "**/*.kt"
+  - "**/*.kts"
+  - "**/*.scala"
+  - "**/*.sh"
+  - "**/*.bash"
+  - "**/*.zsh"
+  - "**/*.fish"
+  - "**/*.sql"
+  - "**/*.vue"
+  - "**/*.svelte"
+  - "**/*.md"
+  - "**/*.json"
+  - "**/*.jsonc"
+  - "**/*.yaml"
+  - "**/*.yml"
+  - "**/*.toml"
+  - "**/*.ini"
+  - "**/*.cfg"
+  - "**/*.conf"
+  - "**/*.properties"
+  - "**/*.tf"
+  - "**/*.tfvars"
+  - "**/*.hcl"
+  - "**/*.xml"
+  - "**/.env*"
+  - "**/Dockerfile"
+  - "**/Dockerfile.*"
+agent: consistency-check
+---
+
+Review code changes for inconsistencies with existing codebase patterns:
+
+1. **Naming conventions** - Does new code follow established naming patterns?
+   - Variable/function naming style (camelCase, snake_case, etc.)
+   - Similar concepts should use similar names
+
+2. **Code patterns** - Does new code use same patterns as existing code?
+   - Async handling (async/await vs callbacks vs promises)
+   - Error handling approach
+   - Data fetching patterns
+   - State management patterns
+
+3. **API design** - Are new APIs consistent with existing ones?
+   - Parameter ordering and naming
+   - Return value structure
+   - Error response format
+
+4. **Import/export style** - Consistent module organization?
+   - Import ordering and grouping
+   - Default vs named exports
+
+5. **Type definitions** - Consistent type patterns?
+   - Interface vs type usage
+   - Optional vs nullable patterns
+
+6. **Documentation consistency** (for .md files)
+   - Heading styles and hierarchy
+   - Link formats and references
+   - Code block language annotations
+   - Section ordering and structure
+
+7. **Config/JSON/YAML consistency** (for config files)
+   - Key naming conventions (camelCase vs snake_case vs kebab-case)
+   - Value formats (strings vs numbers, quotes usage)
+   - Structure patterns (nesting depth, array vs object)
+   - Comment styles (where applicable)
+
+IMPORTANT: Only report inconsistencies that:
+- Make the codebase harder to navigate
+- Could lead to confusion or bugs
+- Violate clearly established patterns
+
+Do NOT report:
+- Style preferences without established pattern
+- Intentional deviations with clear purpose
+- Minor variations that don't impact readability

package/src/defaults/rules/code-general.md

@@ -0,0 +1,59 @@
+---
+name: code-general
+description: General code quality review for all source files
+version: 1
+patterns:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.mjs"
+  - "**/*.cjs"
+  - "**/*.py"
+  - "**/*.go"
+  - "**/*.rs"
+  - "**/*.java"
+  - "**/*.rb"
+  - "**/*.php"
+  - "**/*.c"
+  - "**/*.cpp"
+  - "**/*.h"
+  - "**/*.cs"
+  - "**/*.swift"
+  - "**/*.kt"
+  - "**/*.kts"
+  - "**/*.scala"
+  - "**/*.sh"
+  - "**/*.bash"
+  - "**/*.zsh"
+  - "**/*.fish"
+  - "**/*.sql"
+  - "**/*.vue"
+  - "**/*.svelte"
+agent: general
+---
+
+Perform a general code quality review. Focus on:
+
+1. **Readability** - Is the code easy to understand?
+2. **Simplicity** - Is there unnecessary complexity or over-engineering?
+3. **Naming** - Are variables, functions, and classes named clearly?
+4. **Structure** - Is the code organized logically? Are functions doing too much?
+5. **Dependencies** - Are there hidden or circular dependencies?
+6. **DRY violations** - Is there obvious code duplication?
+7. **API design** - Are interfaces intuitive and consistent?
+
+Do NOT review (covered by other agents):
+- Bugs, logic errors, edge cases → bug-hunter
+- Security vulnerabilities → security-scan
+- Performance issues → performance-check
+
+Be direct and actionable. Only report issues that genuinely need attention.
+
+IMPORTANT: Do NOT report:
+- Code that is already good
+- Minor style preferences
+- Compliments or positive observations
+- Suggestions for hypothetical future improvements

package/src/defaults/rules/code-performance.md

@@ -0,0 +1,44 @@
+---
+name: code-performance
+description: Performance analysis for code files
+version: 1
+patterns:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.mjs"
+  - "**/*.cjs"
+  - "**/*.py"
+  - "**/*.go"
+  - "**/*.rs"
+  - "**/*.java"
+  - "**/*.rb"
+  - "**/*.php"
+  - "**/*.kt"
+  - "**/*.kts"
+  - "**/*.sh"
+  - "**/*.bash"
+  - "**/*.zsh"
+  - "**/*.fish"
+  - "**/*.sql"
+  - "**/*.vue"
+  - "**/*.svelte"
+agent: performance-check
+---
+
+Review code changes for:
+1. Algorithm complexity (O(n^2) or worse)
+2. N+1 queries and database inefficiencies
+3. Memory leaks and excessive allocations
+4. Missing caching opportunities
+5. Blocking operations and missing parallelization
+
+Be concise and actionable.
+
+IMPORTANT: Only report actual performance issues. Do NOT report:
+- Micro-optimizations with negligible impact
+- Theoretical issues without real-world consequences
+- Code that is already performant

package/src/defaults/rules/code-security.md

@@ -0,0 +1,39 @@
+---
+name: code-security
+description: Security scan for code files
+version: 1
+patterns:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.mjs"
+  - "**/*.cjs"
+  - "**/*.py"
+  - "**/*.go"
+  - "**/*.rs"
+  - "**/*.java"
+  - "**/*.rb"
+  - "**/*.php"
+  - "**/*.kt"
+  - "**/*.kts"
+  - "**/*.sh"
+  - "**/*.bash"
+  - "**/*.zsh"
+  - "**/*.fish"
+  - "**/*.sql"
+  - "**/*.vue"
+  - "**/*.svelte"
+agent: security-scan
+---
+
+Scan code for security vulnerabilities:
+1. Authentication/authorization issues
+2. Input validation problems
+3. SQL injection risks
+4. XSS vulnerabilities
+5. Sensitive data exposure
+
+Only report actual security concerns. Do NOT report positive observations or "no issues found" messages.