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".
In this repository43 other files it gives its agents.
- skills/vercel-react-best-practices/AGENTS.mdAGENTS.md
- agent-notepadSkill
- architecture-reviewerSkill
- channel-listenerSkill
- code-reviewerSkill
- coder-file-transferSkill
- cold-start-generatorSkill
- creating-skillsSkill
- critical-thinkingSkill
- dark-factory-buildSkill
- dependency-risk-auditorSkill
- df-adversary-gateSkill
- df-app-walkthroughSkill
- df-context-storeSkill
- df-data-transform-lensSkill
- df-dispatch-subagentsSkill
- df-infrastructureSkill
- df-observabilitySkill
- df-product-ownerSkill
- df-qaSkill
- df-solution-architectSkill
- df-tdd-developerSkill
- df-ui-verifySkill
- df-video-intakeSkill
- dx-maintainability-reviewerSkill
- frontend-auditorSkill
- handoffSkill
- microservices-architectSkill
- production-readiness-reviewerSkill
- repo-docsSkill
- requirements-discoverySkill
- sc-auditSkill
- sc-devSkill
- scope-initSkill
- scope-retireSkill
- security-threat-modelerSkill
- service-mapperSkill
- test-quality-gatekeeperSkill
- vercel-react-best-practicesSkill
- vinculum-loopSkill
- vinculum-mapSkill
- web-design-guidelinesSkill
- work-autonomouslySkill
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
- Distinctive: line 55
Create a mental model of the service:
≈ “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.
Files
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 packagesStep 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:
| Component | Details |
| Endpoints | REST routes, GraphQL resolvers, gRPC services |
| Async | Message queues, cron jobs, webhooks |
| Data Stores | Databases, caches, file storage |
| External APIs | Third-party integrations, internal services |
| Secrets | API 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:
| Severity | Icon | Meaning |
| 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
| Category | Critical | High | Medium | Low |
| Security | 0 | 1 | 2 | 1 |
| Reliability | 0 | 0 | 1 | 2 |
| Performance | 0 | 0 | 0 | 1 |
| Observability | 0 | 0 | 1 | 0 |
E) Recommendations
Prioritized action items:
- [Most critical fix]
- [Second priority]
- ...
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
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
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.

