project-intake-map

name	project-intake-map
description	Use when Codex needs to read and map this repo before audits, performance work, architecture review, backend/frontend/database analysis, or refactor planning.

Project Intake Map

Goal

Build an evidence-backed map of the current project without changing code. Capture frontend, backend, database, routing, API, model, and UI-screen surfaces so later audits start from repo reality.

When to use

Use this skill when the user asks to read the whole project, map architecture, find modules/routes/APIs/models/screens, prepare for an audit, or understand how the system is organized.

Do not use this skill to implement fixes. If the user only asks for evaluation, stay read-only.

Required steps

1. Load repo guidance first: AGENTS.md, README.md, .agents/skills/v-library-workflow/SKILL.md, and its references.
2. Inventory source files with rg --files, excluding generated/build/cache directories such as backend/static/frontend, frontend/node_modules, .venv, .git, .playwright-mcp, and __pycache__.
3. Identify runtime source roots:
   • frontend source under frontend/src
   • backend source under backend
   • database schema from Django models and migrations
   • generated output under backend/static/frontend as build output only
4. Map frontend:
   • route tree from frontend/src/app/routes.tsx
   • page/screen components from frontend/src/app/pages
   • shared components, hooks, API clients, state/query usage
   • major loading/error/auth gates
5. Map backend:
   • Django apps in INSTALLED_APPS
   • root URLs and API URLs
   • API views, serializers/helpers, service modules, management commands
   • background/automation/job-related modules if present
6. Map database:
   • models, relations, indexes, constraints, migrations
   • tables implied by app labels and model names
   • high-risk large-growth tables such as attempts, answers, notifications, logs, activity, payments, files
7. Map business domains:
   • public site, auth/profile, library, blog, courses, quiz, classroom, gamification, admin/backoffice, support, payments, automation
8. Write the report in Vietnamese to docs/audits/project-intake-map.md.

Output format

Write a Vietnamese Markdown report with:

1. Tom tat he thong
2. Ban do frontend
3. Ban do backend/API
4. Ban do database/schema
5. Ban do domain nghiep vu
6. Route va man hinh chinh
7. API va model chinh
8. Nguon su that va output sinh ra
9. Bang chung da doc

Every claim must cite a file, module, route, API, or model. Use P0/P1/P2/P3 only when reporting actual issues found during intake.

Quality checklist

• The report distinguishes source files from generated output.
• Routes, APIs, screens, and models are grounded in file paths.
• No broad claim appears without evidence.
• Missing or unclear areas are listed as gaps, not guessed.
• The report is useful as input for later performance, architecture, or refactor audits.

Safety rules

• Do not edit application code.
• Do not run destructive commands, migrations, deploys, uploads, cleanup, resets, or data mutations.
• Do not read or print secrets from .env, credentials, tokens, cookies, local databases, or production logs.
• Do not hand-edit backend/static/frontend.
• If a command would be slow or risky, document it as a recommended follow-up instead of running it.