# TRIP-init

> Initialize TRIP workflow in a new project (creates docs structure and generates ARCHI.md)

- Skill: `pilastdigit/trip-init` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pilastdigit/trip-init`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pilastdigit/trip-init/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: pilastdigit (https://skillmd.com/u/pilastdigit)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pilastdigit/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
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