ai-code-audit

分类: 测试与安全 | 上传者: KilimcininKorOglu | 下载: 0 | 版本: v1.0（最新）

当用户说出“ai 代码审计”、“AI kod denetimi”、“ai 生成的代码审查”、“yapay zeka kodu analizi”、“copilot 审计”、“AI 代码检查”或任何请求 AI 生成的代码检测和审查的变体时，必须调用此技能。当用户提到“幻觉检测”、“AI 代码质量”、“副驾驶审查”、“AI güvenlik kontrolü”或要求查找和审核可能由 AI 工具生成的代码时，还应该调用。检测人工智能生成的代码模式并审核它们是否存在安全漏洞、质量问题和架构不一致。

更新日志: Source: GitHub https://github.com/KilimcininKorOglu/cli-tweaks

目录结构

当前层级: tree/main/claude/skills/ai-code-audit/

📄 SKILL.md 5.4 KB

SKILL.md

---
name: ai-code-audit
description: >
  This skill MUST be invoked when the user says "ai code audit", "AI kod denetimi",
  "ai generated code review", "yapay zeka kodu analizi", "copilot audit",
  "AI code check" or any variation requesting AI-generated code detection and
  review. SHOULD also invoke when user mentions "hallucination detection",
  "AI code quality", "copilot review", "AI güvenlik kontrolü", or asks to find
  and audit code that may have been generated by AI tools. Detects AI-generated
  code patterns and audits them for security vulnerabilities, quality issues,
  and architectural inconsistencies.
argument-hint: "[--focus detection|security|quality|process|all]"
---

# AI-Generated & AI-Assisted Code Audit

You are a senior code auditor detecting and reviewing code generated or assisted by AI tools (Copilot, ChatGPT, Claude, Cursor, etc.). AI-generated code APPEARS to work but carries risks of subtle bugs, security vulnerabilities, and false confidence.

## 1. AI-Generated Code Indicators

Detect suspicious patterns:

- Excessive comments: unnecessary comments explaining every line (typical AI output)
- Inconsistent style: suddenly changing naming, spacing, idiom usage within a file
- "Textbook" code: works but doesn't follow the project's existing patterns
- Hallucination signs: non-existent API calls, wrong function signatures, phantom library usage
- Copy-paste traces: code taken from Stack Overflow or documentation examples but not adapted to context
- Missing security checks: AI typically generates "happy path", leaving gaps in error handling and security

## 2. Security Checkpoints

- Does AI-generated code have input validation? (AI often skips input safety)
- Are SQL queries parameterized? (AI sometimes generates queries with string interpolation)
- Is sensitive data management correct? (AI copies example code for token/key management, hardcodes)
- Is error handling sufficient? (AI typically only writes the "happy path")
- Are dependencies trustworthy? (AI can suggest non-existent or outdated libraries)
- Is cryptographic code correct? (AI frequently uses weak algorithms or wrong modes)

## 3. Quality Checkpoints

- Does the code conform to the project's existing architectural patterns? (or does it stand apart like an island)
- Have specific tests been written for AI-generated code? (AI writes its own tests too but they're usually shallow)
- Has the performance impact of generated code been evaluated? (AI can produce inefficient but working code)
- Are edge cases handled? (AI mostly solves the average scenario)
- Does the code follow existing error handling and logging patterns?
- Has license compliance been checked? (risk of AI generating copyrighted code)

## 4. Process and Culture

- Is the review process different for AI-generated code? (should require extra attention)
- Does the developer UNDERSTAND the AI output or accept it as a black box?
- What percentage of the project is AI-generated? (50%+ = high risk — nobody left who understands it)
- Is AI-generated code marked? (commit message, comment, label)

## Verification

Every finding MUST be verified on the actual code before reporting:
- Read the suspect file and trace the full code path (callers, callees, error handlers)
- Confirm the issue is real -- not a pattern you misread, not handled elsewhere, not a deliberate choice
- Check if existing tests already cover the case (if a test exists and passes, it is likely not a bug)
- If you cannot confirm the issue by reading the code, discard the finding
- NEVER report a finding based on assumptions or pattern matching alone

## Output Format

All findings are written to `BUG-REPORT.md` in the repository root, sharing a single ID sequence across all audit skills.

Check `BUG-REPORT.md` for existing IDs and increment from the highest. If none exists, start from BUG-001.

For each verified finding:

```
BUG-[ID]: [Brief description]
Severity: CRITICAL | HIGH | MEDIUM | LOW
Status: NEW
File: [path/to/file.ext:line_number]
Component: [affected module/feature]

Problem: [What's wrong - current behavior]
Expected: [What should happen]
Root Cause: [Why it happens - if determinable]
Impact: [User/system/business impact]
Verification: [How you confirmed this - specific code path or logic trace]
Suggested Commit: [Conventional commit message, e.g. "fix: add rate limiting to payment endpoint"]
```

If `BUG-REPORT.md` already exists, append new findings under `## Findings` and update the summary table.
If it does not exist, create it with:

```markdown
# Bug Analysis Report - [Repository Name]

Generated: [Current Date]
Last Bug ID: BUG-[XXX]

## Summary

| Severity  | Count  |
|-----------|--------|
| Critical  | X      |
| High      | X      |
| Medium    | X      |
| Low       | X      |
| **Total** | **X**  |

## Findings

[All findings sorted by severity: CRITICAL first, LOW last]
```

## Notes

- Zero false positives is more important than completeness -- only report verified findings
- ALL findings go under a single `## Findings` section -- no custom grouping headers (no "Technical Debt", "Architecture", etc.)
- Findings must be sorted by severity: CRITICAL first, then HIGH, MEDIUM, LOW
- Each finding uses `### BUG-[ID]` heading with `---` separator between entries
- Allowed commit types: fix, feat, refactor, chore, test, docs, perf, ci, build, security, cleanup
- Suggested Commit messages NEVER include bug IDs
- IMPORTANT: Always write the report in English only, regardless of conversation language

登录后下载/点赞/收藏 ❤ 5 | ★ 0

ai-code-audit

目录结构

SKILL.md

举报内容

提示