trip-init

# TRIP Initialization Mode You are now in **initialization mode** for setting up the TRIP workflow. ## What is TRIP? TRIP is a structured development workflow with four phases: - **P**lan - Design features before implementation - **I**mplement - Build with proper documentation - **R**eview - Systematic code review - **T**est - Comprehensive testing Why call it TRIP instead of PIRT? Because why not --- ## Your Task Initialize the TRIP workflow for the project: **$ARGUMENTS** If no project name provided, ask the user for the project name before proceeding. --- ## Phase 1: Create Documentation Folder Structure Create the following folder structure if it doesn't exist: ``` docs/ ├── 1-plans/ # Feature planning documents ├── 2-changelog/ # Version changelog files ├── 3-code-review/ # Code review documentation ├── 4-unit-tests/ # Unit testing documentation └── 6-memo/ # Miscellaneous notes and memos ``` Note: `5-tuto/` folder is created conditionally in Phase 6 only if the user wants tutorial generation. Files (`ARCHI.md`, `ARCHI-rules.md`, `changelog_table.md`, `TESTING.md`) will be created in later phases after codebase analysis. --- ## Phase 2: Codebase Exploration Perform a **thorough exploration** of the codebase to gather information: ### 2.1 Project Indicators to Identify Look for these signals to understand the project: **Build/Package Files:** - `package.json` → Node.js/JavaScript/TypeScript - `Cargo.toml` → Rust - `CMakeLists.txt`, `Makefile` → C/C++ - `pom.xml`, `build.gradle` → Java - `pyproject.toml`, `setup.py`, `requirements.txt` → Python - `go.mod` → Go - `*.csproj`, `*.sln` → C#/.NET - `platformio.ini`, `*.ino` → Embedded/Arduino **Framework Indicators:** - `next.config.*`, `nuxt.config.*` → Web frontend frameworks - `electron.*`, `tauri.conf.*` → Desktop apps - `Dockerfile`, `docker-compose.*` → Containerized services - `serverless.yml`, `firebase.json` → Cloud functions - `startup.s`, `linker.ld`, `*.hal` → Embedded/firmware **Source Structure:** - `src/components/` → Component-based UI - `src/routes/`, `src/pages/` → Web routing - `src/hal/`, `src/drivers/` → Hardware abstraction - `src/cmd/`, `cmd/` → CLI tools - `lib/`, `crates/` → Libraries ### 2.2 Information to Gather - **Current version** - Check `package.json`, `Cargo.toml`, `version.h`, `__version__`, git tags, or any versioning mechanism. Note the format (SemVer, CalVer, custom). If no version exists, start at `0.1.0`. - **Languages used** and their versions - **Build system** and toolchain - **Dependencies** and their purposes - **Directory structure** and organization patterns - **Entry points** (main files, boot sequences) - **Configuration** approach (env vars, config files, compile-time) - **Testing** framework and conventions --- ## Phase 3: Project Type Classification Based on Phase 2 findings, classify the project into one of these categories: ### Project Type Profiles | Type | Indicators | Key Concerns | | --------------------- | -------------------------------------------------- | ----------------------------------------------------- | | **Web Frontend** | React/Vue/Angular/Svelte, components, routing, CSS | Components, State, Styling, Routing, API calls | | **Web Backend** | Express/FastAPI/Gin/Spring, routes, middleware | Endpoints, Database, Auth, Middleware, Error handling | | **Full-Stack Web** | Both frontend and backend in monorepo | All of above, plus API contracts | | **Desktop App** | Electron/Tauri/Qt/GTK/WinForms | Windows, Native APIs, IPC, Cross-platform | | **Mobile App** | React Native/Flutter/Swift/Kotlin | Screens, Navigation, Platform APIs, Offline | | **CLI Tool** | Main entry, arg parsing, no GUI | Commands, Config, I/O, Exit codes | | **Library/SDK** | Public API, no main entry, exports | API surface, Versioning, Docs, Compatibility | | **Embedded/Firmware** | HAL, interrupts, memory-mapped I/O | Hardware, Memory, Real-time, Peripherals, Boot | | **Game** | Game loop, rendering, entities | Loop, Rendering, Physics, Input, Assets | | **Data/ML Pipeline** | Notebooks, data processing, models | Data flow, Training, Inference, Pipelines | ### Classification Output After classification, note: 1. **Primary type** (the main category) 2. **Secondary aspects** (e.g., a CLI tool that's also a library) 3. **Domain-specific concerns** (e.g., real-time constraints, security requirements) --- ## Phase 4: Generate ARCHI.md Based on the project type, generate `docs/ARCHI.md` using the appropriate sections. ### Universal Sections (ALL projects) ```markdown # [Project Name] Architecture Documentation ## 1. How to Read This Document [Document structure and intended audience] ## 2. Overview [Project purpose, main functionality, high-level architecture] ## 3. Technology Stack [Languages, frameworks, tools with versions] ## 4. Project Structure [Directory tree with explanations] ## 5. Core Architecture Principles [Design principles guiding the codebase] ## 6. Build System & Toolchain [How to build, compile flags, build targets] ## 7. Configuration [Environment variables, config files, compile-time options] ``` ### Type-Specific Sections Select sections based on project type classification. **Important**: The sections below are starting points, not exhaustive lists. If during codebase exploration you identify architectural aspects that deserve their own section but aren't listed here, **add them**. Examples of custom sections you might add: - **Caching Layer** - for projects with complex caching strategies - **Plugin/Extension System** - for extensible architectures - **Multi-tenancy** - for SaaS applications - **Offline Support** - for apps with offline-first patterns - **WebSocket/Real-time** - for real-time communication - **File Processing Pipeline** - for media/document processing - **Logging & Observability** - for complex monitoring setups - **Feature Flags** - for projects with feature flag systems - **Migration System** - for projects with data migration patterns - _...or any other architectural aspect significant to the project_ --- #### For Web Frontend ```markdown ## Components & UI Architecture [Component organization, patterns (atomic, feature-based), reusability] ## State Management [Local state, global state, server state caching] ## Routing [Route structure, navigation patterns, guards] ## Styling Architecture [CSS approach, theming, responsive design] ## API Integration [Service layer, data fetching, error handling] ## Internationalization (i18n) [If applicable - translation system, locale handling] ``` --- #### For Web Backend / API ```markdown ## API Design [Endpoints, REST/GraphQL conventions, versioning] ## Request Lifecycle [Middleware chain, validation, response formatting] ## Database Layer [ORM/query patterns, migrations, connections] ## Authentication & Authorization [Auth flow, session/token management, RBAC] ## Error Handling [Error types, logging, client responses] ## Background Jobs [If applicable - queues, scheduled tasks, workers] ``` --- #### For Desktop Application ```markdown ## Window Management [Main window, dialogs, multi-window architecture] ## Native Platform Integration [System APIs, file system, notifications, tray] ## IPC Architecture [If applicable - main/renderer communication, message protocols] ## Cross-Platform Considerations [Platform-specific code, abstractions, conditional compilation] ## Packaging & Distribution [Installers, updates, code signing] ``` --- #### For CLI Tool ```markdown ## Command Structure [Commands, subcommands, argument parsing] ## Input/Output Handling [stdin/stdout/stderr, interactive mode, piping] ## Configuration Management [Config files, environment variables, precedence] ## Error Handling & Exit Codes [Error types, user-friendly messages, exit code conventions] ``` --- #### For Library/SDK ```markdown ## Public API Surface [Exported modules, main entry points, API stability] ## Internal Architecture [Private modules, helper utilities] ## Versioning Strategy [SemVer policy, breaking changes, deprecation] ## Integration Patterns [How consumers use the library, common patterns] ## Documentation [API docs generation, examples, guides] ``` --- #### For Embedded/Firmware ```markdown ## Hardware Abstraction Layer (HAL) [Peripheral abstractions, board support packages] ## Memory Architecture [Memory map, stack/heap, static allocation, DMA] ## Interrupt Handling [ISR design, priorities, critical sections] ## Peripheral Drivers [UART, SPI, I2C, GPIO, ADC, timers, etc.] ## Boot Process [Startup sequence, initialization order, watchdog] ## Power Management [Sleep modes, wake sources, power budgeting] ## Real-Time Constraints [Timing requirements, latency budgets, determinism] ## Communication Protocols [Protocol stacks, message formats, error recovery] ``` --- #### For Game Development ```markdown ## Game Loop Architecture [Update/render cycle, fixed timestep, frame timing] ## Entity/Component System [Entity management, component patterns, systems] ## Rendering Pipeline [Graphics API, shaders, scene graph, culling] ## Input Handling [Input abstraction, rebinding, multiple devices] ## Asset Pipeline [Asset loading, formats, streaming, caching] ## Audio System [Sound engine, music, spatial audio] ## Physics & Collision [Physics engine, collision detection, response] ``` --- ### Closing Universal Sections (ALL projects) ```markdown ## Data Flow Diagrams [Mermaid diagrams showing key interactions] ## Error Handling Strategy [How errors are handled, logged, and reported] ## Testing Strategy [Test types, frameworks, coverage expectations] ## Performance Considerations [Optimization strategies, profiling, benchmarks] ## Security Considerations [If applicable - threat model, mitigations] ## Deployment [How the project is deployed/distributed/flashed] ## Conclusion [Summary and key architectural decisions] ``` --- ## Phase 5: User Review & Validation After generating ARCHI.md, **stop and request user review**. ### Present to User Summarize what was generated: 1. **Project classification** - What type was detected and why 2. **Sections included** - List the sections added to ARCHI.md 3. **Custom sections** - Highlight any sections added beyond the standard templates 4. **Key architectural decisions** documented ### Ask for Feedback **Use the `AskUserQuestion` tool** to present the user with a structured choice: - **Question**: "Please review the generated ARCHI.md. How would you like to proceed?" - **Options**: 1. **"Approved"** — ARCHI.md looks good, proceed to Phase 6 2. **"Request changes"** — I have corrections or modifications 3. **"Add sections"** — I'd like additional sections added ### Handle Feedback - **If "Approved"**: Proceed to Phase 6 - **If "Request changes"**: Make the requested modifications, then re-present for validation using `AskUserQuestion` again - **If "Add sections"**: Add them, then re-present for validation using `AskUserQuestion` again - **If "Other" (custom input)**: Handle accordingly **Do NOT proceed to Phase 6 until the user explicitly approves the ARCHI.md.** --- ## Phase 6: Update TRIP Skills After user validation, update the other TRIP skill files based on the **actual codebase architecture** documented in ARCHI.md. > **IMPORTANT**: The examples below are **recommendations and starting points**, not templates to copy blindly. Always tailor the content based on: > > - What was actually discovered during codebase exploration (Phase 2) > - The patterns and conventions documented in the validated ARCHI.md (Phase 5) > - The specific tools, frameworks, and practices used in **this** project ### Skills to Update: 1. **`TRIP-1-plan`** - Technical considerations, guidance sections, documentation impact candidates 2. **`TRIP-2-implement`** - Testing gate commands 3. **`TRIP-3-release`** - Version file, week offset, tutorials