Published February 2026 · Quantum Studio

The AI-Powered System Audit: Do this before your Vibe Project Breaks

A single prompt that turns an AI agent into a staff-level engineer performing a complete technical inventory of any codebase

View the Complete System Audit Prompt ↓

Every engineering leader has lived through it. You inherit a system. Maybe it's an acquisition. Maybe the previous team left. Maybe you're the new CTO and nobody who built the original platform is still around. You open the repo and find a README that was last updated eighteen months ago, an architecture doc that describes a system that no longer exists, and a Confluence page titled "How Deployment Works" that contains three bullet points and a broken diagram.

You're now responsible for a production system serving real users, and you don't know how it works.

The traditional response is to spend weeks—sometimes months—having your new team reverse-engineer the codebase. Senior engineers trace request flows through unfamiliar frameworks. Someone discovers an undocumented cron job that turns out to be critical. The database has tables nobody can explain. There are environment variables referenced in code that aren't in any .env.example file. Half the API endpoints aren't documented anywhere. The deployment process lives in one person's head, and that person left six months ago.

It's archaeology, and it's brutally expensive. Not just in engineering hours, but in risk. Every day your new team operates a system they don't fully understand is a day something can break in a way nobody knows how to fix.

We Built a Better Way

At Quantum Studio, we manage and build systems across multiple sectors—property, travel, events, music, spatial computing. Systems come and go. Teams rotate. Due diligence on acquisitions happens fast. We needed a repeatable process that could produce a comprehensive technical handoff package for any system in hours, not months.

So we built a prompt. Not a chatbot conversation. Not a template. A single, detailed instruction set—roughly 3,000 words of precise directives—that turns an AI coding agent into a staff-level engineer performing a complete technical audit of any codebase and its running infrastructure.

You point the agent at a repository, give it access to the running environment, and let it work. What comes back is a structured engineering handoff package that would take a senior engineer weeks to produce manually. We've now used it on dozens of systems. It works. And we're sharing it publicly.

What the Audit Covers

The prompt instructs the AI agent to inspect the actual running system—not guess from documentation, not summarise a README, not give you a shallow overview. It traces real code paths, examines real configuration, and documents what actually exists. The scope is exhaustive:

Honest About What It Doesn't Know

This is the part that matters most. The prompt explicitly instructs the agent: do not invent missing details. If something cannot be confirmed from the actual code and configuration, it must be marked as one of three things:

UNVERIFIED — found a reference but couldn't confirm it's active or correct

INFERRED — deduced from context but not explicitly documented or tested

NOT FOUND — expected this to exist but couldn't locate it

This is critical. A handoff document that sounds confident about everything is more dangerous than having no document at all—it creates false trust. Our audit is explicit about uncertainty, which means the receiving team knows exactly where to focus their own verification effort. When they see INFERRED next to a claim about the caching layer, they know to test it themselves before relying on it.

The prompt also enforces a strict rule: if there are contradictions between documentation and implementation, the agent must prioritise what the code actually does and explicitly call out the mismatch. Stale docs are worse than no docs. The audit surfaces them instead of perpetuating them.

Concrete Deliverables

The audit doesn't produce a single massive document. It generates a structured handoff package of individual markdown files, each serving a specific purpose:

Where possible, it also generates Mermaid diagrams—architecture overviews, entity-relationship diagrams, service dependency maps, and route maps. Real artefacts a team can use immediately.

The Phased Approach

We learned early that throwing the entire audit at an AI agent in one pass leads to truncation and laziness in the later sections. The prompt is designed to run in five explicit phases:

  1. Discovery — inventory the entire system: repo structure, services, frameworks, databases, deployment targets, third-party integrations, unknowns
  2. Documentation — deep-dive into frontend, backend, data model, APIs, auth, and infrastructure
  3. Handoff docs — generate the structured markdown files in a /docs or /handoff directory
  4. Risk audit — security, performance, reliability, maintainability, scalability, and operational risk assessment
  5. Onboarding — create concise onboarding documentation for the new team

At the end of each phase, the agent summarises findings, lists open questions, flags unverified assumptions, and catalogues every file it inspected. This creates an auditable trail of the audit itself—you can see exactly what the agent looked at and what it might have missed.

The phased approach also prevents a common failure mode with AI agents: context exhaustion. A single massive prompt often results in thorough early sections and increasingly shallow later ones. By breaking the work into discrete phases, each section gets the agent's full attention.

The prompt also instructs the agent to inspect the live deployed environment where accessible—running services, open ports, environment configuration, process managers, logs, reverse proxy configuration, database connections, webhook endpoints, and DNS routing. This is where the audit goes beyond what any static analysis tool can do. It's not just reading code—it's understanding the running system. It documents secret names and usage without ever exposing actual values.

Why This Matters

This isn't just a developer convenience tool. It solves real business problems:

The quality bar we set is explicit in the prompt: this should read like documentation prepared by a strong staff engineer doing a serious transition package. Precise, exhaustive, implementation-grounded, and honest about uncertainty. At the end, the agent delivers the top 20 files a new developer should read first, the top 10 architectural risks, the top 10 highest-value improvements, and a one-page explanation of how the entire system works. Everything a new team lead needs to hit the ground running.

Use It

We're sharing the complete prompt publicly because we believe better handoffs make the entire industry stronger. Fewer abandoned systems, fewer failed transitions, fewer engineers burning out trying to understand code nobody documented. Use it with any AI coding agent that has access to your codebase—Claude with computer access, Cursor, an agent in your IDE, or any tool that can read files and run commands.

→ View the full prompt on Google Docs

Or expand the section below to read and copy the entire prompt directly:

View the Complete System Audit Prompt 
TECHNICAL AUDIT PROMPT


I need you to perform a complete technical inventory and handoff audit of this entire project so a new engineering team could fully understand, operate, maintain, debug, secure, extend, and rebuild it if necessary.

Your task is to inspect the actual running project, codebase, configuration, deployment setup, connected services, data model, APIs, auth, infrastructure, build chain, and operational tooling.

Do not give me a shallow summary.

I want a true engineering handoff package based on what actually exists in the system right now.

OBJECTIVE

Produce a complete, accurate, implementation-grounded documentation set for this project, including:

1. Executive architecture overview
2. Detailed technical architecture
3. Full file and component inventory
4. Data model and schema documentation
5. API inventory and endpoint documentation
6. Auth, roles, permissions, and security model
7. Infrastructure, deployment, hosting, domains, env vars, secrets references, and runtime services
8. Frontend architecture
9. Backend architecture
10. Third party services, SDKs, packages, libraries, tools, and dependencies
11. Background jobs, queues, cron jobs, webhooks, and async processes
12. Observability, logging, analytics, and monitoring
13. Failure points, risks, tech debt, and known weak spots
14. Local development and deployment instructions
15. Maintenance and troubleshooting guide
16. Upgrade and extension guidance
17. Recommended refactor priorities
18. A clear "how this whole system works" explanation for a new dev team

APPROACH

You must inspect the code and environment directly.

Do not invent missing details.

If something cannot be confirmed, clearly mark it as:
- UNVERIFIED
- INFERRED
- NOT FOUND

For every major claim, point to the exact file(s), config(s), code section(s), table(s), endpoint(s), or service(s) that support it.

If there are contradictions between docs and implementation, prioritize implementation and call out the mismatch.

OUTPUT FORMAT

Create the output as a structured handoff package with these sections:

A. SYSTEM SUMMARY
- What the product does
- Main user flows
- Core business logic
- High level system diagram in text form

B. ARCHITECTURE OVERVIEW
- Frontend stack
- Backend stack
- Database(s)
- Auth
- Hosting / infra
- External integrations
- Realtime systems if any
- Storage systems
- Messaging / queues if any

C. REPOSITORY + FILE INVENTORY
- Top level folder tree
- What each major directory does
- Important files and why they matter
- Dead code, duplicate code, legacy code, experimental code
- Entry points for app, API, workers, scripts, admin tools

D. FRONTEND DOCUMENTATION
- App structure
- Routing
- Pages and views
- Shared components
- State management
- Data fetching strategy
- Forms
- Styling system
- Asset pipeline
- Error handling
- Auth flow on frontend
- Performance considerations

E. BACKEND DOCUMENTATION
- Service architecture
- Controllers / routes / handlers
- Business logic modules
- Services layer
- Database access layer
- Caching layer
- Background processing
- Validation and error handling
- Internal utilities
- Configuration flow

F. DATA MODEL / SCHEMA
- All databases and schemas
- Tables / collections
- Fields, types, constraints, indexes
- Relationships
- Derived fields
- Migration history
- Seed data
- Data lifecycle
- Risky schema areas
- Missing constraints or integrity issues

G. API INVENTORY
For every API endpoint or callable service:
- Method
- Path
- Purpose
- Request params
- Body schema
- Response schema
- Auth requirements
- Roles/permissions
- Side effects
- Source file location
- Consumer(s) of endpoint
- Known issues / risks

Also include:
- Internal APIs
- External APIs used
- Webhooks in and out
- Realtime channels
- SDK interfaces if any

H. AUTH + SECURITY
- Authentication system
- Session / token flow
- User roles
- Permission enforcement points
- Sensitive data handling
- Secrets usage
- Input validation
- File upload security
- CORS / CSP / headers
- Rate limiting
- Abuse risks
- PII exposure risks
- Trust boundaries
- Security weaknesses and recommended fixes

I. INFRASTRUCTURE + DEPLOYMENT
- Hosting providers
- Runtime environments
- Build pipeline
- CI/CD
- DNS / domains / subdomains
- Environment variables by purpose
- Secret references without exposing secret values
- Storage buckets
- CDN / cache
- Process manager
- Containers / services
- Database hosting
- Scheduled jobs
- Deployment steps
- Rollback process
- Disaster recovery concerns

J. DEPENDENCIES + TOOLS
- Core frameworks
- Libraries
- SDKs
- Dev tools
- Build tools
- Testing tools
- Analytics tools
- Monitoring tools
- AI or model providers
- Payment or auth providers
- Why each is used
- What breaks if removed

K. OPERATIONS RUNBOOK
- How to start locally
- Required env vars
- Install steps
- Migrate database
- Seed database
- Start frontend
- Start backend
- Start workers
- Run tests
- Build for production
- Deploy
- Read logs
- Debug common failures
- Restart services
- Safe maintenance checklist

L. TROUBLESHOOTING + FAILURE MODES
- Most likely breakpoints
- Common error sources
- Debug paths
- External dependency failure impact
- Data corruption risk areas
- Race conditions
- Realtime failure risks
- Performance bottlenecks
- Scaling limitations

M. TECH DEBT + IMPROVEMENT PLAN
- Immediate fixes
- Short term cleanup
- Medium term refactors
- High value upgrades
- Security improvements
- Reliability improvements
- Developer experience improvements
- Documentation gaps

N. HANDOFF FOR NEW DEV TEAM
- What they should read first
- What they should never change casually
- Where to safely extend features
- How to test changes safely
- How to service production
- Suggested onboarding order for a new engineer

O. APPENDICES
- Folder tree
- Route map
- Environment variable catalog
- DB schema summary
- Endpoint summary table
- Dependency summary table
- Service/component map
- Glossary of project-specific terms

DELIVERABLE REQUIREMENTS

1. Write this to markdown files in a /docs or /handoff folder.
2. Also create:
   - ARCHITECTURE_OVERVIEW.md
   - SYSTEM_INVENTORY.md
   - API_REFERENCE.md
   - DATABASE_SCHEMA.md
   - OPERATIONS_RUNBOOK.md
   - SECURITY_REVIEW.md
   - TECH_DEBT_AND_RECOMMENDATIONS.md
   - NEW_TEAM_ONBOARDING.md

3. Also create one concise file:
   - DEV_TEAM_HANDOFF_SUMMARY.md
   This should be the fast-read version for executives and incoming tech leads.

4. If possible, generate:
   - a diagram in Mermaid
   - a route map
   - an ERD in Mermaid
   - a service dependency map

5. Include concrete references to source files throughout.

6. Do not stop at package.json or high-level guesses.
   Trace actual usage through the codebase.

7. If this is a monorepo or multi-service system, document each app/service separately and then explain how they connect.

8. If parts of the system are missing, stale, broken, or unclear, explicitly identify them.

AUDIT INSTRUCTIONS

Please inspect all of the following where present:
- repository structure
- package manifests
- lockfiles
- tsconfig / jsconfig
- env examples
- docker files
- compose files
- nginx / proxy config
- server config
- cloud config
- migrations
- ORM schema
- SQL files
- seed scripts
- frontend routes
- API routes
- middleware
- auth logic
- queue / worker logic
- cron jobs
- webhook handlers
- analytics
- tests
- scripts folder
- admin tools
- deployment scripts
- README files
- comments that reveal intent
- dead or legacy code paths

QUALITY BAR

I want this to read like documentation prepared by a strong staff engineer doing a serious transition package.

Be precise.
Be exhaustive.
Be implementation-grounded.
Be honest about uncertainty.

At the end, give me:
1. The top 20 files a new dev should read first
2. The top 10 architectural risks
3. The top 10 highest-value improvements
4. A one-page explanation of how the whole system works

---

PHASED EXECUTION (recommended)

A better approach is to run this in phases so the agent does not get lazy or truncate.

Phase 1:
Discover and inventory the entire system.
Output:
- repo tree
- major services
- frameworks
- databases
- deployment targets
- third party integrations
- unknowns and missing pieces

Phase 2:
Document frontend, backend, data model, APIs, auth, and infrastructure in detail.

Phase 3:
Create handoff docs in /docs or /handoff.

Phase 4:
Perform a risk audit:
- security
- performance
- reliability
- maintainability
- scalability
- operational risk

Phase 5:
Create concise onboarding docs for a new dev team.

At the end of each phase:
- summarize findings
- list open questions
- list unverified assumptions
- list exact files inspected

---

LIVE SYSTEM INSPECTION

Also inspect the deployed environment and operational setup where accessible:
- running services
- open ports
- environment configuration
- build and runtime commands
- scheduled jobs
- process manager
- logs
- reverse proxy
- database connections
- storage references
- webhook endpoints
- DNS/domain routing

Do not expose secret values.
Only document secret names, usage, and where they are required.

---

Do not optimize for brevity.
Optimize for completeness, accuracy, and usefulness to a replacement engineering team.

The next time you need to hand off a system, onboard a new team, perform due diligence on a potential acquisition, or just understand what you're actually running in production—don't spend a month on it. Point an AI agent at the codebase, give it this prompt, and let it do the archaeology for you.

The documentation it produces won't be perfect. No automated audit replaces deep institutional knowledge. But it will be comprehensive, structured, honest about its limitations, and ready in hours instead of weeks. That's not just a time saving—it's the difference between a new team that's productive on day one and a new team that's still confused on month three.

That's the starting point your new team actually needs. And now it takes an afternoon instead of a quarter.