Skills DirectorySearch all skills ↗AI agent skill · by @PiLastDigit
TRIP Init
Initialize TRIP workflow in a new project (creates docs structure and generates ARCHI.md)
Archived 2026-10-23 · Source updated 2026-09-24. Check the original repository for the latest version.
SKILL.md instructions
# 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 4. **`TRIP-review`** - `checklist.md` and `cr-template.md` adapted to actual architecture 5. **`TRIP-test`** - Test commands, structure, priorities --- ### 6.1 Universal Updates (ALL skills) **Project Name**: Replace the `[PROJECT_NAME]` placeholder with the actual project name in all skill files. --- ### 6.2 Update `TRIP-1-plan` **A. Technical Considerations Section** Replace the `[ADAPT_TO_PROJECT]` markers in the Technical Considerations section with concerns **relevant to this specific codebase**. The examples below are starting points - adapt based on what ARCHI.md documents: - If the project uses specific patterns (e.g., a custom state management approach), include them - If certain concerns don't apply (e.g., no i18n in this project), omit them - If the project has unique concerns (e.g., regulatory compliance, specific hardware constraints), add them **For Web Frontend:** ```markdown ## Technical Considerations - **Pattern Usage**: Which existing patterns to follow (from ARCHI.md) - **Performance**: useMemo, useCallback, lazy loading, code splitting - **Accessibility**: Keyboard navigation, ARIA labels, focus management - **Responsive Design**: Mobile/tablet/desktop breakpoints - **Edge Cases**: Empty states, loading states, error states - **Theming**: Light/dark mode support ``` **For Web Backend:** ```markdown ## Technical Considerations - **Pattern Usage**: Which existing patterns to follow (from ARCHI.md) - **Database Impact**: Schema changes, migrations, query performance - **API Design**: REST conventions, versioning, backwards compatibility - **Security**: Input validation, authentication, authorization - **Error Handling**: Error codes, logging, client responses - **Edge Cases**: Rate limiting, timeouts, partial failures ``` **For CLI Tool:** ```markdown ## Technical Considerations - **Pattern Usage**: Which existing patterns to follow (from ARCHI.md) - **User Experience**: Help text, progress indicators, error messages - **Configuration**: Precedence (flags > env > config file > defaults) - **Exit Codes**: Success/failure codes, scripting compatibility - **Edge Cases**: Invalid input, missing files, permission errors - **Cross-Platform**: Path handling, line endings, shell compatibility ``` **For Embedded/Firmware:** ```markdown ## Technical Considerations - **Pattern Usage**: Which existing patterns to follow (from ARCHI.md) - **Memory Impact**: Stack usage, heap allocation, static vs dynamic - **Timing**: Interrupt latency, real-time constraints, blocking calls - **Power**: Sleep mode impact, wake sources, power budget - **Hardware Dependencies**: Pin assignments, peripheral conflicts - **Edge Cases**: Startup race conditions, watchdog, error recovery ``` **For Library/SDK:** ```markdown ## Technical Considerations - **Pattern Usage**: Which existing patterns to follow (from ARCHI.md) - **API Design**: Public surface, naming conventions, consistency - **Backwards Compatibility**: Breaking changes, deprecation strategy - **Documentation**: API docs, examples, migration guides - **Edge Cases**: Null handling, error propagation, thread safety ``` _Adapt based on actual project architecture. Only include considerations that are relevant to this codebase._ **B. Guidance Sections** Replace the `[ADAPT_TO_PROJECT: Guidance Sections]` comment block with guidance that matches **the actual architectural patterns in ARCHI.md**. Look at the major component types documented and create guidance for each. Examples: **For Web Frontend** (keep existing React sections) **For Embedded/Firmware:** ```markdown ## For New Peripheral Drivers Required analysis: - Hardware interface (registers, pins, timing) - Interrupt requirements (priority, latency) - DMA usage if applicable - Power management impact - Error handling strategy ## For New Communication Protocols Required analysis: - Message format and framing - Error detection/correction - Timeout and retry strategy - Buffer management - Thread/interrupt safety ``` **For CLI Tool:** ```markdown ## For New Commands Required analysis: - Command name and aliases - Required and optional arguments - Input sources (args, stdin, files) - Output format (human, JSON, etc.) - Error messages and exit codes ## For Configuration Changes Required analysis: - Config key naming - Default value - Validation rules - Documentation updates ``` _These are examples. Create guidance sections based on what's actually in ARCHI.md - the major patterns, layers, and component types specific to this project._ **C. Documentation Impact Candidates** Replace the `[ADAPT_TO_PROJECT]` marker inside the plan template's **Documentation Impact** section with the project's actual living documentation — every non-TRIP document that code changes can leave stale, one bullet per doc with when it's affected. Draw from what Phase 2 discovered: - `README.md` — quick start, repo structure tree, command reference - Module/subdirectory READMEs - Operations or user manuals - Reference `.md` specs living next to the code - Contributor guides (`CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`) This list is what makes the TRIP-3 Documentation Sync step effective — a doc missing here tends to drift silently. Also resolve the `[ADAPT_TO_PROJECT]` marker in the **Prerequisites** list at the top of `TRIP-1-plan`: if the project has living docs a plan must respect beyond ARCHI.md (e.g. an operations manual), list them with the condition under which they must be read; otherwise delete that line. **D. Custom Plan Sections** **Use the `AskUserQuestion` tool** to ask: - **Question**: "Are there any project-specific sections you want included in every plan?" - **Options**: 1. **"No custom sections"** — Standard plan sections are sufficient 2. **"Yes, add custom sections"** — I want to specify additional sections (provide details via "Other") If the user selects "Yes" or provides custom input, add the specified sections to the plan template. --- ### 6.3 Update `TRIP-2-implement` and `TRIP-3-release` The testing gate in `TRIP-2-implement` and the standalone-verification block in `TRIP-3-release` share the same command placeholders. The release ceremony customizations (version, week, tutorials) live in `TRIP-3-release`: **A. Version File Location** Update Step 2 to reference the actual version file: - `package.json` for Node.js - `Cargo.toml` for Rust - `setup.py` / `pyproject.toml` for Python - `CMakeLists.txt` or `version.h` for C/C++ - Or other location identified in Phase 2 **B. Week Anchor** The week Init is run becomes **Week 1** of the project. Capture the anchor date (Monday of the current week) and update the week formula in `TRIP-3-release`. Run this to get the anchor date: ```bash python3 -c "from datetime import date, timedelta; t = date.today(); print(t - timedelta(days=t.weekday()))" ``` Then replace the `[WEEK_ANCHOR_DATE]` placeholder in `TRIP-3-release` Step 1 with the actual date (ISO format, `YYYY-MM-DD` — the formula parses it with `date.fromisoformat`). The formula counts elapsed weeks from that fixed date, so it works across year boundaries indefinitely, and both this command and the formula use Python instead of `date -d`, so they run identically on GNU/Linux and macOS (BSD `date`). If `python3` is not on PATH — e.g. Git Bash on Windows — use `python` instead. **C. Main Branch** Replace the `[MAIN_BRANCH]` placeholder in `TRIP-3-release` (the Documentation Sync diff command and the fast-forward merge step) with the repo's default branch name. Detect it with: ```bash basename "$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null || git branch --show-current)" ``` (The fallback covers repos without a remote — there, the branch Init runs on is the main branch.) **D. Tutorial Generation** **Use the `AskUserQuestion` tool** to ask: - **Question**: "Do you want the Implement command to generate tutorials after each implementation (learn by doing)?" - **Options**: 1. **"Yes"** — Generate tutorials after each implementation 2. **"No"** — Skip tutorial generation **If "No"**: - Remove the `[TUTORIAL_STEP]` block entirely from `TRIP-3-release` - Do NOT create the `docs/5-tuto/` folder - No renumbering needed — the existing step numbers are already correct for this case **If "Yes"**: - Create the `docs/5-tuto/` folder - **Use the `AskUserQuestion` tool** with multiple questions to customize tutorial generation: **Question 1** (header: "Level"): "What is your current programming level?" - **Options**: "Beginner" (learning fundamentals), "Intermediate" (comfortable with basics, learning advanced), "Advanced" (experienced, deep dives and edge cases) **Question 2** (header: "Focus", multiSelect: true): "What do you want to learn from these tutorials?" - **Options**: "Language fundamentals" (syntax, idioms, patterns), "Framework specifics" (React, Rust, etc.), "Architecture & patterns" (design patterns, system design), "Performance & optimization" (profiling, caching, efficiency) **Question 3** (header: "Style"): "What tutorial style do you prefer?" - **Options**: "Concise" (key points, minimal explanation), "Balanced" (explanations with examples), "Verbose" (detailed explanations, multiple examples, diagrams) Then update the `[TUTORIAL_STEP]` block in `TRIP-3-release` with the user's context: ```markdown ### Step 8: Tutorial Create `docs/5-tuto/tuto_x.y.z.md` explaining the core principle. **User context for tutorials**: - Level: [user's level] - Learning focus: [user's interests] - Style: [user's preferred style] [Add any specific instructions based on their choices] ``` **IMPORTANT — Renumber subsequent steps**: After uncommenting the Tutorial as Step 8, renumber the steps that follow: - Step 8: README Update → **Step 9**: README Update - Step 9: Documentation Sync → **Step 10**: Documentation Sync - Step 10: Commit → **Step 11**: Commit - Step 11: Tag → **Step 12**: Tag - Step 12: Merge (fast-forward) → **Step 13**: Merge (fast-forward) - Step 13: Push → **Step 14**: Push Also update the cross-reference inside Documentation Sync — "included in the release commit (Step 10)" becomes "(Step 11)". **E. Codex Review Test Commands** Replace the `[LINT_COMMAND]`, `[TYPECHECK_COMMAND]`, and `[TEST_COMMAND]` placeholders in the TRIP-2 Testing Gate AND the TRIP-3-release standalone-verification block with the **actual commands** for this project (from ARCHI.md or discovered during exploration). For example: - Python: `uv run ruff check .`, `uv run mypy`, `uv run pytest -q` - Node.js: `npm run lint`, `npx tsc --noEmit`, `npm test` - Rust: `cargo clippy`, (no separate typecheck), `cargo test` - Go: `golangci-lint run`, (no separate typecheck), `go test ./...` If the project doesn't have a lint or typecheck step, remove the corresponding line entirely rather than leaving a placeholder. --- ### 6.4 Update `TRIP-review` The review skill uses three files: `SKILL.md` (orchestration), `checklist.md` (criteria — single source of truth), and `cr-template.md` (output skeleton). During Init, update **`checklist.md`** and **`cr-template.md`** — leave `SKILL.md` as-is. **A. Adapt `checklist.md`** `checklist.md` ships with generic sections (Functional Requirements, Code Quality, Architectural Compliance, Error Handling, Security, Performance). Replace the `[ADAPT_TO_PROJECT]` comment block with **project-specific checklist sections** based on what matters for this codebase as documented in ARCHI.md. The examples below are starting points — include only what's relevant and add project-specific checks: **For Web Backend:** ```markdown ### 4. API Best Practices - [ ] Input validation on all endpoints - [ ] Consistent error response format - [ ] Proper HTTP status codes - [ ] API versioning respected - [ ] Rate limiting considered ``` **For Embedded/Firmware:** ```markdown ### 4. Resource Management - [ ] Stack usage analyzed - [ ] No memory leaks - [ ] DMA buffers aligned - [ ] Peripheral resources released - [ ] Power modes handled correctly ### 5. Timing & Safety - [ ] Real-time constraints met - [ ] Watchdog considerations addressed - [ ] Race conditions prevented - [ ] Error recovery implemented ``` **For CLI Tool:** ```markdown ### 4. User Experience - [ ] Help text is clear and complete - [ ] Error messages are actionable - [ ] Exit codes are correct - [ ] Progress feedback for long operations ``` _Build from ARCHI.md — what patterns does this project use? What quality criteria matter? What are common pitfalls?_ Also update the existing generic sections (3. Architectural Compliance, etc.) with project-specific items if the generic ones are too vague. Remove sections that don't apply. **B. Update `cr-template.md`** Update the Checklist section in `cr-template.md` to list the **actual section names** from the adapted `checklist.md`. The template ships with generic section names (1-6); after adapting the checklist, the template's section list must match. **C. Update Approval Gate** If the project has specific build/test commands, update the "Review Completion Criteria" section at the bottom of `checklist.md` with the actual commands (e.g., `uv run pytest` instead of generic "All existing tests pass"). --- ### 6.5 Update `TRIP-test` **A. Test Commands** Replace the `[TEST_COMMAND_*]` placeholders with the **actual test commands** used in this project (from ARCHI.md or discovered during exploration): ```markdown ### Commands \`\`\`bash # Run all tests [actual command, e.g., npm test, cargo test, pytest, make test] # Run specific test [actual command for single test] # With coverage [actual coverage command] \`\`\` ``` **B. Test Structure** Replace the `[ADAPT_TO_PROJECT]` marker with actual test organization: - Where tests are located - Naming conventions - Test file patterns **C. Testing Priorities** Adapt based on **what's actually tested in this project** and what the ARCHI.md documents about testing strategy. Examples: **For Embedded:** ```markdown ### Testing Priorities **Unit Tests**: - HAL mock testing - Protocol parsers - State machines - Utility functions **Hardware-in-Loop Tests**: - Peripheral initialization - Communication protocols - Interrupt handling **What to Test**: - Normal operation paths - Error conditions - Boundary values - Timing constraints ``` **For CLI:** ```markdown ### Testing Priorities **Unit Tests**: - Argument parsing - Configuration loading - Core logic functions **Integration Tests**: - Command execution end-to-end - File I/O operations - Error scenarios **What to Test**: - Valid inputs - Invalid inputs (edge cases) - Missing files/permissions - Exit codes ``` --- ## Phase 7: Create Supporting Files Now that ARCHI.md is validated, create the supporting documentation files adapted to the project. ### 1. `docs/2-changelog/changelog_table.md` - Version Tracking **Version for first entry**: Take the current version identified in Phase 2 and increment the patch number. For example: - Current `1.2.3` → First entry `1.2.4` - Current `0.5.0` → First entry `0.5.1` - No version found → First entry `0.1.0` This file has two sections: **Section 1: Quick Reference Table** ```markdown # Changelog Table | Version | Week | Commit Message | | --------- | ---- | ------------------------------- | | `X.Y.Z+1` | 1 | chore: initialize TRIP workflow | ``` - **Version**: SemVer format in backticks (e.g., `1.0.0`, `0.2.1`) - **Week**: Project week number. Week 1 = the week when TRIP Init was run. - **Commit Message**: One-line description of the change **Section 2: Detailed Changelog Summary** ```markdown # Changelog Summary - **vX.Y.Z+1 (TRIP Initialization - Week 1, DD-MM-YYYY)**: - **Setup**: Initialized TRIP workflow with docs structure - **Documentation**: Generated ARCHI.md with [project type] architecture - **Files Added**: docs/ARCHI.md, docs/ARCHI-rules.md, docs/2-changelog/changelog_table.md, docs/4-unit-tests/TESTING.md ``` The summary provides context that the table cannot capture: rationale, impact, technical decisions, and file-level details. New entries are added at the **top** of each section. --- ### 2. `docs/4-unit-tests/TESTING.md` - Testing Guidelines **Adapt based on the validated ARCHI.md** - use the actual test framework, commands, and conventions discovered during codebase exploration: ```markdown # Testing Guidelines ## Test Framework [From ARCHI: actual framework name and version] ## Running Tests \`\`\`bash [From ARCHI: actual test commands] \`\`\` ## Test Organization [From ARCHI: actual test file locations and patterns] ## Writing Tests [Project-specific conventions observed in the codebase] ## Coverage Requirements [From ARCHI: actual coverage thresholds if defined, or "Not defined" if none] ``` --- ### 3. `docs/ARCHI-rules.md` - Architecture Maintenance Rules **Adapt based on the validated ARCHI.md** - reference the actual sections and terminology used: ```markdown # Architecture Documentation Rules [ARCHI.md](ARCHI.md) documents the [Project Name] architecture. After each task (new feature, refactor, bug fix), determine if ARCHI.md needs updating. ## When to Update Update after ANY change that alters: - Project structure (new directories, moved files) - Technology stack (new dependencies, version changes) - [List actual section names from ARCHI.md that might need updates] - Data flow or component interactions - Build or deployment processes ## How to Update by Change Type ### Major Feature / Refactor Review: [List actual relevant section names from ARCHI.md] ### Minor Feature / Enhancement Update: [List actual relevant section names from ARCHI.md] ### Bug Fix Usually no update needed, unless it reveals/fixes an architectural flaw ### Dependency Changes Update: Technology Stack, and any affected architectural sections ## Guidelines - Be precise and factual - reflect the actual codebase - Be concise - enough detail to understand, not implementation specifics - Update diagrams when data flow changes - Reference actual file paths ``` --- ## Post-Initialization Checklist - [ ] Core `docs/` folders created (Phase 1): 1-plans, 2-changelog, 3-code-review, 4-unit-tests, 6-memo - [ ] Codebase thoroughly explored (Phase 2) - [ ] Current version identified (Phase 2) - [ ] Project type correctly classified (Phase 3) - [ ] ARCHI.md generated with appropriate sections (Phase 4) - [ ] Custom sections added where relevant (Phase 4) - [ ] **User reviewed and approved ARCHI.md** (Phase 5) - [ ] **TRIP skills updated** (Phase 6): - [ ] `[PROJECT_NAME]` placeholder replaced in all skills - [ ] `TRIP-1-plan`: `[ADAPT_TO_PROJECT]` markers replaced with actual technical considerations - [ ] `TRIP-1-plan`: Guidance sections replaced with project-specific patterns - [ ] `TRIP-1-plan`: Documentation Impact candidates replaced with the project's actual living docs - [ ] `TRIP-1-plan`: Prerequisites `[ADAPT_TO_PROJECT]` line resolved (project docs listed, or line deleted) - [ ] `TRIP-1-plan`: Custom plan sections added (if user requested) - [ ] `TRIP-2-implement`: Testing gate commands (`[LINT_COMMAND]`, `[TYPECHECK_COMMAND]`, `[TEST_COMMAND]`) replaced with actual commands - [ ] `TRIP-3-release`: `[VERSION_FILE]` placeholder replaced - [ ] `TRIP-3-release`: `[WEEK_ANCHOR_DATE]` placeholder replaced - [ ] `TRIP-3-release`: `[MAIN_BRANCH]` placeholder replaced - [ ] `TRIP-3-release`: Standalone-verification commands replaced with actual commands - [ ] `TRIP-3-release`: Tutorial preference configured (if enabled: 5-tuto/ folder created + user context; if disabled: `[TUTORIAL_STEP]` block removed) - [ ] `TRIP-review/checklist.md`: `[ADAPT_TO_PROJECT]` markers replaced with project-specific checklist sections - [ ] `TRIP-review/cr-template.md`: Checklist section names updated to match adapted `checklist.md` - [ ] `TRIP-test`: `[TEST_COMMAND_*]` placeholders replaced with actual commands - [ ] `TRIP-test`: `[ADAPT_TO_PROJECT]` markers replaced with actual test structure/priorities - [ ] changelog_table.md initialized with version+1 (Phase 7) - [ ] TESTING.md created, adapted to actual test setup (Phase 7) - [ ] ARCHI-rules.md created, referencing actual ARCHI sections (Phase 7) --- ## Notes for the Agent - **Explore thoroughly**: Read key files to understand the project before classifying - **Be adaptive**: The section list is a guide, not a rigid template. Add custom sections when the codebase has architectural patterns not covered by the templates - **Use correct terminology**: Embedded projects have "peripherals", not "components". CLI tools have "commands", not "routes" - **Ask if uncertain**: If the project type is ambiguous, ask the user - **Focus on what exists**: Document the actual architecture, not an idealized version - **Diagrams matter**: Mermaid diagrams help visualize complex flows regardless of project type - **User review is mandatory**: Never skip Phase 5. The user must validate the ARCHI.md before proceeding - **Iterate if needed**: If the user requests changes, make them and re-present for approval