agentleFS
OneDro1dOneDro1d/dark-factory/skills/backend-service-auditor/SKILL.md

backend-service-auditor

Skill4 starsChanged 2 months agoApache-2.0View on GitHub

Audit backend services for security, reliability, performance, and operability issues. Use when reviewing APIs, microservices, workers, or backend code changes. Triggers on "audit backend", "security review", "service audit", "API audit", "check vulnerabilities", "review microservice", "backend security", "audit API", "review service".

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a mental model of the service:

    line 55

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Backend Service Auditor

Comprehensive auditor for backend services (APIs, workers, microservices) focusing on security, reliability, correctness, performance, data integrity, and operability. All findings are grounded in actual code and configuration.

When to Use

  • Reviewing backend code changes before merge
  • Security auditing APIs or microservices
  • Pre-deployment checks for critical services
  • Investigating reliability or performance concerns
  • Auditing authentication/authorization flows
  • Reviewing data handling and integrity patterns

Audit Workflow

On EVERY invocation, execute these steps in order:

Step 1: Detect Stack & Service Boundaries

Identify the technology stack and architectural boundaries:

- Language/framework (Node/Express/Nest, Go, Python/FastAPI, Java/Spring, Rust, etc.)
- Entrypoints (main files, server bootstrap, lambda handlers)
- Module/package boundaries
- Infrastructure config (Docker, K8s, Terraform, serverless.yml)
- Shared libraries and internal packages

Step 2: Scan Recent Changes

Review what has changed recently:

# Check working directory changes
git status
git diff --stat

# Review recent commits affecting backend
git log --oneline -20 --all -- "src/" "api/" "services/" "internal/"

Summarize:

  • What behavioral changes were introduced?
  • What new attack surface was added?
  • What critical paths were modified?

Step 3: Build Service Map

Create a mental model of the service:

ComponentDetails
EndpointsREST routes, GraphQL resolvers, gRPC services
AsyncMessage queues, cron jobs, webhooks
Data StoresDatabases, caches, file storage
External APIsThird-party integrations, internal services
SecretsAPI keys, credentials, tokens

Step 4: Execute Audit Checklist

Audit touched services plus all critical paths (auth, payments, trading, user data).

See CHECKLIST.md for the complete audit checklist covering:

  • Security (AuthN/AuthZ, injection, secrets, dependencies)
  • Reliability & Correctness (idempotency, retries, concurrency, data integrity)
  • Performance & Scalability (queries, caching, memory)
  • Observability & Ops (logging, metrics, deployment)

Output Format

Structure your audit report as follows:

A) Scope Scanned

Services: [list services/modules audited]
Files reviewed: [count]
Commits analyzed: [range]
Stack: [detected technology stack]

B) Service Map

Endpoints: [count] routes across [modules]
Data stores: [list DBs, caches]
External deps: [list integrations]
Critical paths: [auth, payments, etc.]

C) Findings

Use severity levels:

SeverityIconMeaning
CRITICAL:red_circle:Exploitable now, data breach risk
HIGH:orange_circle:Serious issue, needs immediate fix
MEDIUM:yellow_circle:Should fix soon, moderate risk
LOW:white_circle:Minor issue, fix when convenient
INFO:blue_circle:Observation, no action required

For each finding:

### [SEVERITY] Title

**Location:** `path/to/file.ts:123`
**Category:** Security > Input Validation

**Issue:** [Describe the problem]

**Evidence:**
[Code snippet or proof]

**Risk:** [What could go wrong]

**Recommendation:** [How to fix]

D) Summary Table

CategoryCriticalHighMediumLow
Security0121
Reliability0012
Performance0001
Observability0010

E) Recommendations

Prioritized action items:

  1. [Most critical fix]
  2. [Second priority]
  3. ...

Quick Commands

# Check for vulnerable dependencies (Node)
npm audit

# Check for vulnerable dependencies (Python)
pip-audit

# Find hardcoded secrets
grep -rn "password\|secret\|api_key\|token" --include="*.ts" --include="*.js" --include="*.py"

# Find TODO/FIXME security notes
grep -rn "TODO.*security\|FIXME.*auth\|XXX" src/

Resources

  • CHECKLIST.md - Complete audit checklist
  • PATTERNS.md - Common vulnerability patterns by framework

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.