initialize

Initialize the onboarding structure and perform initial project mapping. This command must be run first before any other onboarding steps. All other steps will check for these files and return an error if initialization hasn't been completed. DO NOT MODIFY ANY EXISTING CODE.

CRITICAL - Parallel Execution & File Writes:

• All file writes MUST be written directly to disk using file write tools (not staged/suggested edits).
• When updating .cursor/onboarding-docs/CURSOR-ONBOARDING.md, ALWAYS re-read the file first to get the latest state from any parallel sessions.
• If changes are staged and not applied, other parallel sessions will not see them and may overwrite work.
• Each step marks itself as [P] (in progress) at the start to prevent duplicate execution.

EXECUTION PLAN:

1. Mark Command as In Progress [P]:

   • Check if .cursor/onboarding-docs/CURSOR-ONBOARDING.md exists.
   • If it exists:
     • Read it to get the current Step Completion Status.
     • Update the Step Completion Status section to mark "Initialize Onboarding" as [P] (in progress).
     • Write the updated content back to .cursor/onboarding-docs/CURSOR-ONBOARDING.md.
   • If it doesn't exist: This will be created in step 6 with [P] status.

2. Initialize Directory Structure:

   • Check if .cursor/onboarding-docs directory exists. If not, create it.
   • This directory will hold all onboarding documentation.

3. Map File Tree:

   • If .cursor/onboarding-docs/PROJECT_MAP.txt already exists and is not empty: Read it first to check if mapping is already complete. If it appears complete, you may skip this step or update it.
   • Use list_dir tool recursively to explore the project structure.
   • Start from the workspace root and explore up to 5 levels deep.
   • Use glob_file_search to find files while excluding common directories:
     • Ignore: .git/, node_modules/, .venv/, venv/, dist/, build/, .cursor/onboarding-docs/, .next/, __pycache__/, bin/, obj/
   • Build a structured file tree representation and save it to .cursor/onboarding-docs/PROJECT_MAP.txt.
   • Format: Use indentation or tree structure (e.g., ├── or ) to show hierarchy.
   • Note: This can be run multiple times safely - it will update the mapping.

4. Initial Analysis (Stack Discovery):

   • Read the PROJECT_MAP.txt to understand the project structure.
   • Identify and read dependency management files using glob_file_search or read_file:
     • .csproj, .sln (C#/.NET)
     • package.json, yarn.lock, pnpm-lock.yaml (Node.js)
     • pom.xml, build.gradle (Java)
     • go.mod, go.sum (Go)
     • pyproject.toml, requirements.txt, setup.py, Pipfile (Python)
     • Cargo.toml, Cargo.lock (Rust)
     • composer.json (PHP)
     • Gemfile, Gemfile.lock (Ruby)
     • build.sbt (Scala)
   • If no dependency files are found: Use codebase_search with query: "What programming language and framework is this project using?" to infer stack from source files.
   • Do not read other source code files at this stage unless dependency files are missing.
   • Determine the tech stack based on files found (e.g., "C# .NET Core 8.0 Web API with Entity Framework Core").
   • Extract key metadata for AI reference:
     • Primary language and version
     • Main framework(s) and versions
     • Key libraries/dependencies (top 5-10 most important)
     • Build system (MSBuild, npm, Maven, etc.)
     • Runtime requirements (.NET version, Node version, Python version, etc.)

3a. Detect Event-Driven Architecture Usage: * Determine whether the project leverages an event-driven/pub-sub model before later steps run: - Use codebase_search queries such as: - "Where are events published or emitted?" - "What message brokers or queues are used?" - "How are topics, queues, or streams defined?" - Use grep to scan for messaging keywords: - Publish|Subscribe|EventBus|EventEmitter|emit\(|on\(|topic|queue|Kafka|RabbitMQ|SQS|SNS|PubSub|NATS|EventBridge|Azure Service Bus - Review configuration files (docker-compose, infrastructure IaC, etc.) for broker references. * If clear signals exist: - Set detected to true. - Capture supporting evidence (file paths, services, broker names). * If no signals were found: set detected to false. * Write .cursor/onboarding-docs/EVENT_DRIVEN_STATUS.json: json { "detected": true|false, "evidence": ["path or identifier", "..."], "notes": "Short summary (e.g., 'Kafka producer in infra/kafka.ts')" } - Replace placeholders with actual findings (use empty list/string when unknown). * Update .cursor/onboarding-docs/CURSOR-ONBOARDING.md ## Event-Driven Architecture section (created below) with: - Detected: Yes/No - Signals: brief comma-separated hints - Next Step: instruct to run /onboarding/analyze-event-driven-architecture if detected.