安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install forensic-audit
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 forensic-audit。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Forensic Audit is a structured three-phase codebase assessment designed for developers, security teams, and technical auditors who need actionable findings without modifying project files. The workflow examines authentication, authorization, cryptography, GDPR controls, database concurrency, Prisma performance, infrastructure, architecture, Electron security, cron behavior, and test isolation.
As an Openclaw Skills workflow, it creates a fresh timestamped report directory for every run, captures repository and Git context, performs targeted signal scans, and writes independently verified Markdown reports. Strict read-only controls, cross-phase deduplication, severity classification, targeted diffs, and executive summaries make the results suitable for remediation planning and audit evidence.

应用场景

Run
/forensic-audit
before releasing a backend, desktop application, or full-stack product.
Investigate suspected authentication flaws, privilege escalation, IDOR, exposed secrets, replay attacks, or missing rate limits.
Review Prisma queries, transaction boundaries, isolation levels, indexes, N+1 patterns, and unbounded database reads.
Assess Fastify plugins, Stripe and Twilio integrations, SSE connections, environment validation, and connection pooling.
Inspect cron jobs, timezone handling, Electron IPC boundaries, error handling, and test-runner isolation.
Produce a non-destructive security check when repository integrity and untouched source files are mandatory.
Preserve separate historical audit runs for compliance reviews, remediation tracking, and regression comparisons.

工作原理

Detect the /forensic-audit request or an equivalent forensic audit, vulnerability scan, or security check instruction.
Resolve a new timestamped output directory under the user Desktop _Reports folder and verify that it can be created.
Capture repository context, including the current path, Git commit, branch, working-tree status, and a source-directory snapshot.
Run quick signal scans for unbounded Prisma queries, hardcoded secrets, missing awaits, sensitive console logging, and TODO or FIXME markers.
Execute Phase 1 as a cybersecurity, cryptography, and data privacy review covering authentication, authorization, rate limiting, secret hygiene, Stripe webhooks, and GDPR workflows.
Write and verify audit_1_security.md; the file must exist and exceed 500 bytes before the next phase starts.
Execute Phase 2 as a database integrity and performance review, independently re-reading the code and referencing Phase 1 findings instead of duplicating them.
Write and verify audit_2_database.md, including concurrency, transaction, query, indexing, SSE, and connection-pooling findings.
Execute Phase 3 as an architecture, resilience, and lifecycle review covering timezones, SOLID boundaries, configuration, Electron IPC, error handling, and test isolation.
Write audit_3_architecture.md, then provide completion details, a three-sentence phase summary, and a combined severity table.

配置指南

The skill requires access to the repository, source inspection tools such as view_file and grep_search, command execution for Git and ripgrep, and permission to write only to the Desktop _Reports directory. It is intended for environments that can inspect TypeScript, JavaScript, Prisma schema, Fastify, Electron, and related project files.
Place the skill in the agent's configured skills directory and ensure it is enabled for the coding workspace.
Open the target repository and confirm the agent can read source files and execute repository metadata commands.
Confirm that the Desktop report location is writable. If direct writing is unavailable, request permission for the target directory or use PowerShell through the command runner.
Invoke the workflow with /forensic-audit or request a forensic audit explicitly.

Verify repository context

pwd
git rev-parse --short HEAD
git branch --show-current
git status --short

Confirm source files and common audit signals

rg --files apps/api/src | sort
rg -i "password\s*=\s*['"][^'"]{4,}|api_key\s*=\s*['"]|secret\s*=\s*['"]" --type ts -l
On Windows, the expected report location is %USERPROFILE%/Desktop/_Reports//. Each execution receives a new yyyy-MM-dd_HHmm folder and never overwrites earlier reports. The workflow must remain read-only inside the project repository; only the report directory may receive files.

数据架构

Output directory
Reports are stored using this structure:
Path Purpose
%USERPROFILE%/Desktop/_Reports// Unique output folder for one audit run
audit_1_security.md Security, cryptography, authentication, privacy, and webhook findings
audit_2_database.md Database integrity, concurrency, Prisma, indexing, and performance findings
audit_3_architecture.md Architecture, resilience, lifecycle, Electron, and testing findings
Required report metadata
Every report begins with a Markdown header containing:
Phase title
Audit date and time
Repository root path
Short Git HEAD hash
Current branch
Dirty or clean working-tree state
Auditor role for the phase
Finding taxonomy
Findings use a file-and-line reference followed by severity and a concise problem statement. Phase 1 supports CRITICAL, HIGH, and MEDIUM; Phases 2 and 3 support HIGH, MEDIUM, and LOW. Findings include targeted before-and-after diffs with no more than 30 lines of context, while repeated issues are linked to the original phase through cross-phase references.
Completion metadata
The final response reports the output path, confirms all three files, provides one highest-severity finding per phase, and includes combined counts for CRITICAL, HIGH, MEDIUM, and LOW findings.

高级特性

Strict read-only enforcement prevents edits, refactors, file creation, or branch creation inside the project repository.
Sequential phase gates require every report to exist and exceed 500 bytes before the next audit phase begins.
Timestamped output preserves historical audits and prevents accidental report overwrites.
Cross-phase deduplication links recurring findings instead of repeating full diffs.
Repository-aware headers capture Git commit, branch, dirty state, and audit role for traceability.
Targeted ripgrep signal scans quickly identify hardcoded credentials, sensitive logging, unbounded queries, missing awaits, and technical-debt markers.
Security analysis includes OWASP-oriented authentication, authorization, IDOR, brute-force, cryptographic, webhook, and GDPR checks.
Database analysis evaluates transaction isolation, race conditions, Prisma query efficiency, indexes, relation loading, SSE cleanup, and connection limits.
Architecture analysis examines SOLID boundaries, Fastify lifecycle hooks, startup validation, safe configuration fallbacks, Electron isolation, and test-runner network access.
Fault-tolerant recommendations avoid destructive fixes and prohibit broad file rewrites or deletion of validation and
.refine()
logic.
Permission-aware writing supports explicit authorization requests or PowerShell-based report generation when direct Desktop access is restricted.
Designed for repeatable Openclaw Skills workflows that turn complex codebase reviews into auditable, actionable Markdown deliverables.

name: forensic-audit description: Three-phase read-only forensic audit of a codebase. Use when the user invokes /forensic-audit, asks to run a "forensic audit", "forensic audit pipeline", "multi-pass audit", "security audit", "vulnerability scan", "security check", or "code vulnerability scan".

Skill: forensic-audit

Trigger

Use this skill when the user invokes /forensic-audit, asks to run a "forensic audit", "forensic audit pipeline", "multi-pass audit", "security audit", "vulnerability scan", "security check", or "code vulnerability scan".

Description

Three-phase read-only forensic audit of a codebase. Each phase is written to a timestamped report file before the next phase begins. Reports are saved to %USERPROFILE%\Desktop_Reports\.

STRICT READ-ONLY: Never modify, refactor, or create any files inside the project repository. Only write to the _Reports output folder.

Execution Protocol

Pre-flight (before any phase)
Resolve output path: $outDir = "$env:USERPROFILE\Desktop_Reports$(Get-Date -Format 'yyyy-MM-dd_HHmm')" — new timestamped subfolder every run to preserve previous audits.
Create output dir: mkdir -p "$outDir" (or equivalent PowerShell command) — confirm creation, abort if it fails.
Capture repo context (embed in every report header):
Current directory (repo root)

git rev-parse --short HEAD — git hash
git branch --show-current — branch name
git status --short — dirty/clean state

Quick signal scan (run before Phase 1 to orient findings): Use the grep_search tool (or run_command to run rg):

# Unbounded queries

rg ".findMany()" --type ts -l

# Potential hardcoded secrets

rg -i "password\s*=\s*['"][^'"]{4,}|api_key\s*=\s*['"]|secret\s*=\s*['"]" --type ts -l

# Missing await / fire-and-forget risks

rg "^\s*[^/].*\bprisma." --type ts -l | head -20

# console.log with sensitive-looking data

rg "console.(log|error)(.*?(token|password|secret|hash)" --type ts -l

# TODO / FIXME / HACK markers

rg "TODO|FIXME|HACK|XXX" --type ts

Directory snapshot: rg --files apps/api/src | sort — full source tree before Phase 1.
Report Header Template (prepend to every phase file)

# [Phase Title]

Date: YYYY-MM-DD HH:MM Repo: [repo root path] Git HEAD: [short hash] ([branch]) Dirty files: [output of git status --short, or "clean"] Auditor role: [role for this phase]

Phase 1 — Security, Cryptography & Data Privacy

Role: Senior Cybersecurity Expert (OWASP), Cryptographer, EU DPO.

Audit scope — read the relevant source files using view_file or search via grep_search, then write findings:

PASS 1: Authentication & Privilege Escalation
POST /register: guard preventing unauthenticated users from passing role: "ADMIN" or role: "OPERATOR" in the payload?
JWT plugin: secrets verified against empty/default fallbacks? Expiration enforced? Refresh token rotation (RTR) atomic and replay-safe?
TOTP /totp/verify: lastUsedTotpCode stored to prevent 30-second replay attacks?
PASS 2: Authorization & IDOR
Every business route: explicit auth hook (preHandler: [app.authenticate])? Unprotected endpoints?
CLIENT-scoped endpoints (GET /api/queue/:id, POST /api/appointments, POST /api/sessions/:id/feedback): strict ownership validation, or IDOR via ID swap?
PASS 3: Rate Limiting & Brute Force
/login, /register, /forgot-password, /reset-password, /totp/verify: is rateLimit config present? What are the limits? Are they adequate?
Missing rate limit on any auth-adjacent endpoint = HIGH finding.
PASS 4: Cryptographic Practices & Secret Hygiene
AES-256-GCM helper (crypto.ts): key length verified at startup? authTag and iv correctly stored/decrypted?
Desktop credential storage: plaintext JSON in %APPDATA% or Electron safeStorage?
GET /clients and similar: sensitive fields (encrypted passwords, raw tokens, hashes) explicitly excluded from Prisma select?
Hardcoded secrets scan: any API keys, tokens, or passwords committed directly in source (.ts, .js, .env.* tracked by git)?
console.log / app.log calls that print tokens, hashes, or raw PII?
PASS 5: Stripe Webhook Security
/webhooks/stripe: webhook signature verified via stripe.webhooks.constructEvent? What happens if STRIPE_WEBHOOK_SECRET is missing?
Is the raw body preserved (not parsed as JSON) before signature check?
Does the handler log Stripe event payloads in a way that could expose customer PII?
PASS 6: GDPR / DSGVO Compliance
Account deletion (POST /api/dsgvo/delete-account): cascade deletes/anonymizes orphaned Client PII (names, addresses, RustDesk access data)?
Session consent handler: logs immutable metadata (IP, timestamp, clientId) confirming explicit consent before remote control?
Data export (GET /api/dsgvo/export): does it include all personal data per Art. 20? Is the download URL scoped to the requesting user?

Output format:

1. Executive Summary (Security Focus)

2. Top Critical Security Vulnerabilities

3. Detailed Severity Breakdown

CRITICAL findings

[file:line] CRITICAL — [problem]
```diff

• before

• after
  ```

HIGH findings

...

MEDIUM findings

...

4. Severity Count

CRITICAL: N | HIGH: N | MEDIUM: N

Every finding: [file:line] Severity — problem + targeted before/after diff (≤30 lines context). No full-file rewrites. No deletion of validation/.refine() blocks.

Write result to: $outDir\audit_1_security.md

Verify write: check file exists and size > 500 bytes. If empty or missing — do not proceed, report error.

Phase 2 — Database Integrity, Transactions & Performance

Role: Principal DBA, Prisma ORM Expert, Performance Engineer.

Fresh file-system pass — re-read source files independently, do not rely on Phase 1 memory.

Cross-phase dedup rule: if a finding was already reported in audit_1_security.md, write → see Phase 1: [brief label] instead of repeating the full diff.

PASS 1: Concurrency, Race Conditions & Isolation Levels
Queue accept (POST /api/queue/:id/accept): atomic Prisma transaction preventing two operators from accepting the same client simultaneously?
Voucher / appointment booking: SERIALIZABLE isolation with retry loop, or READ COMMITTED phantom-read risk?
Any findUnique + conditional update pair outside a transaction (TOCTOU race)?
PASS 2: Prisma Optimization & N+1 Queries
Admin metrics / dashboard (GET /api/admin/metrics, GET /api/stats): sequential loops or unbatched Promise.all? Consolidate to raw SQL or optimal include/select?
Unbounded findMany() calls without take/skip/cursor — list every occurrence with file:line.
include loading full relations when only a count or single field is needed?
PASS 3: Database Integrity & Indexes
Compare queries in route files against schema.prisma: fields used in where/orderBy/joins — do they have @@index or @unique, or will they trigger full table scans?
onDelete actions: RESTRICT blocking standard deletes, or accidental CASCADE wiping analytics logs?
Missing unique constraints that should logically be unique (e.g., one active subscription per user)?
PASS 4: I/O, SSE & Connection Pooling
SSE infrastructure (queue-sse.ts): close event removes listeners? Memory/socket leaks under reconnection storms?
Prisma connection limit (connection_limit in DATABASE_URL) vs Fastify concurrent load?
Long-running un-awaited promises that hold Prisma connections open?

Output format:

1. Database & Performance Summary

2. Concurrency & Race Condition Pitfalls

3. Query & Index Optimization Breakdown (with Diffs)

4. Severity Count

HIGH: N | MEDIUM: N | LOW: N

Write result to: $outDir\audit_2_database.md

Verify write: check file exists and size > 500 bytes. If empty or missing — do not proceed, report error.

Phase 3 — Architecture, SOLID, Resilience & Lifecycle

Role: Senior Software Architect, SRE, QA Automation Lead.

Fresh file-system pass. Cross-phase dedup: if already in Phase 1 or 2 — reference it, don't repeat.

PASS 1: Logic, Timezones & Cron Lifecycles
Background cron jobs (proactive-outreach.ts, index.ts): DST-safe? Europe/Berlin autumn/spring shifts handled without double-fire or skip?
Schedule validation (schedule.ts): raw string comparisons ("09:00" < "17:00")? Midnight crossovers? Night shifts (e.g., 22:00–06:00)?
Batch cron loops: local try/catch per item, or one error aborts the entire batch for all remaining clients?
PASS 2: Architecture Purity & SOLID
Route/controller files: direct DB + Stripe + Twilio calls without a service layer? List files where transport and business logic are mixed.
Fastify plugins (Prisma, Stripe): wrapped in fastify-plugin (fp)? onClose lifecycle hooks registered?
Single Responsibility: any one file doing >3 distinct concerns?
PASS 3: Infrastructure, Error Handling & Configuration
Env-var wrappers (mailer.ts, twilio.ts): silent dry-run fallback in prod when var is missing, or safe startup crash?
Error handlers: structured JSON logs, or raw stack traces / SQL query fragments exposed to client response?
Missing startup validation: does the server fail fast with a clear message if JWT_SECRET, DATABASE_URL, or STRIPE_SECRET_KEY are absent?
PASS 4: Electron Lifecycle & Test Runner Isolation
Desktop IPC bridges: arbitrary node module invocation possible via IPC? before-quit blocking synchronous network calls?
contextIsolation and nodeIntegration settings in BrowserWindow config?
Test suite: app.inject() in-process testing, or real localhost HTTP calls against a running server?
Test mocks: any test that reaches a real DB, network, or filesystem without explicit opt-in?

Output format:

1. Architectural & Resilience Overview

2. Critical Lifecycle & Logic Issues

3. Structural Refactoring & Testability Breakdown (with Diffs)

4. Severity Count

HIGH: N | MEDIUM: N | LOW: N

Write result to: $outDir\audit_3_architecture.md

Completion

After all three files are written and verified, output to chat:

Forensic audit completed. Saved to: [outDir]

Created files:

• audit_1_security.md
• audit_2_database.md
• audit_3_architecture.md

Then provide a 3-sentence executive summary — one sentence per phase, each naming the single highest-severity finding and its file:line.

Finally, output a combined severity table:

Constraints (apply to all phases)
READ-ONLY on project source. Zero writes, edits, or new git branches inside the repository.
Timestamped output — never overwrite previous audit runs.
Report header required — every file must start with date, git hash, branch, dirty state.
File write verification — confirm each phase file is > 500 bytes before proceeding to the next phase.
No full-file rewrites in reports. Diffs must be targeted (≤30 lines context).
No destructive fixes: never suggest deleting validation or .refine() blocks. Fixes must extend business logic algorithmically.
Fault tolerance: no top-level throw Error fixes that crash Electron / desktop clients. Always propose architectural fallbacks.
Cross-phase dedup: Phase 2 and 3 must reference Phase 1 findings rather than duplicate them.
Sequential phases: Phase N+1 starts only after Phase N file is confirmed written and non-empty.
Permission Handling: If you do not have permission to write directly to %USERPROFILE%\Desktop_Reports, request it using ask_permission for write_file with target C:\Users\relig\Desktop or execute the file write operations via the run_command tool in PowerShell.
DSGVO 审计
产品 UX 审计