TRIP-workflow: three slash commands and one ARCHI.md for coding agents

Three numbered skills and one architecture file

The core of TRIP is small enough to state in a table, and the README states it in a table.

`/TRIP-1-plan` is for thinking before you code. `/TRIP-2-implement` is for implementing, testing and reviewing. `/TRIP-3-release` is for versioning, changelogs, docs, commit, tag, merge and push. The README summarizes it as three numbered skills, one architecture file, and no PhD required, and puts the onboarding as copy the folder, run init, start coding.

The name is the historical four-phase development cycle reversed. TRIP is Plan, Implement, Review, Test, and the README notes that since v2.0.0 the flow is simpler still: Plan, Implement, Release, with review and test moved inside Implement as a testing gate and an automatic Codex review loop, so every feature passes through all four phases with fewer commands.

The design target is stated explicitly. The workflow should disappear into the background, not become a project of its own, and the goal is to ship features, not to master a workflow. The README also positions the project against the crowded field of AI workflows, naming Superpowers, BMAD and Gastown, and arguing that the alternatives bring dozens of commands, sub-agent swarms and multi-chapter courses. TRIP's claim is deliberately minimal by comparison.

The project was initially designed for Claude Code using the Agent Skills open standard with its `SKILL.md` format, and the README says it is also compatible with OpenCode, Codex CLI, Mistral Vibe and more.

ARCHI.md is the memory, and the reasoning is about tokens

If you remember one thing about TRIP it is ARCHI.md, which the README calls the central nervous system of the workflow and the agent's long-term memory of the codebase.

The problem it solves is that agents have no memory between sessions. Every new conversation starts from zero, so the agent has to rediscover the project each time, and the README describes the failure mode with a specific kind of quote in mind: a project probably has a utils folder, this project likely uses Redux. Without a written architecture, the agent guesses, and it guesses in a way that wastes tokens and produces plausible wrong answers.

ARCHI.md answers that with one file. The agent reads it at the start of each task and gets the full picture in a single read, with minimal exploration. The README contrasts this with tool-specific files such as `CLAUDE.md` or `AGENTS.md`: ARCHI.md is purely about architecture, and it is tool-agnostic, so it works with any agent. You can still reference it from your `CLAUDE.md` if you want it loaded in every conversation.

The design criteria are stated as a balance. It should be detailed enough to provide meaningful context and concise enough not to waste tokens, structured for quick navigation, and updated after every architectural change. The README is explicit that it is not a dump of the entire codebase but a curated architectural guide.

That last clause is the operational risk. A file that is supposed to be curated and current only helps if somebody keeps it current, and the workflow's answer is that the plan and release phases are where that happens.

Init bootstraps the whole thing in any repository

The `TRIP-init` skill is described as a script written in human language that programmatically bootstraps the TRIP workflow in any repository, and it does five things in order.

It creates the docs structure, with folders for plans, changelogs, reviews, tests and memos. It explores your codebase, identifying languages, frameworks, patterns and conventions. It classifies your project, asking whether it is a web frontend, a CLI tool, embedded firmware or a library. It generates ARCHI.md, tailored to the specific project type rather than generic. And it customizes the skills by replacing placeholders with your project's specifics.

The placeholder system is what makes the last step work. The generic skills contain placeholders like `[PROJECT_NAME]` for the project name, `[VERSION_FILE]` for where the version is stored, pointing at package.json, Cargo.toml and similar, and `[ADAPT_TO_PROJECT: ...]` for sections to customize. Init walks you through questions and substitutes your answers, producing a workflow tailored to your repository.

The setup itself is manual, and the README is direct about it. You copy the `skills/` folder contents into your repo's `.claude/skills/` directory, or the equivalent for whichever agent you use, then run `/TRIP-init [YourProjectName]`, follow the interactive prompts, and review and approve the generated ARCHI.md. That last step is a human gate on the file the whole workflow depends on.

There is one extra step for Mistral users, described as conditional on such users existing. Copy the `AskUserQuestion/` folder to your agent's `/skills/` directory, because it provides the `AskUserQuestion` hook that the TRIP workflow relies on.

The default flow chains plan into implementation without you

The behavior of `/TRIP-1-plan` depends on a flag, and the default is the interesting case.

By default, `/TRIP-1-plan` chains straight into implementation once the Codex plan review approves. The README describes it as: answer the discovery questions, walk away, and come back to an implemented feature. If you want to read the plan before any code is written, you add `--review`. And `/TRIP-2-implement` still runs on its own for a plan written earlier or a resumed session.

So the workflow has a built-in quality gate in the plan phase, performed by Codex rather than by the agent you are talking to, and a switch to stop in front of it. The gate is a Codex review of the plan, and the plan is what the implement phase consumes.

The extra skills extend this. `/codex-implement` delegates implementation to Codex CLI in a workspace-write sandbox, which is a different execution context from an agent that can reach the rest of your machine. `/codex-plan-review` and `/codex-code-review` are iterative review loops powered by Codex CLI, with a code review checklist and a code-review record template in `codex-code-review/` that init adapts to your project. `/codex-ask` is a grounded second opinion on anything, and TRIP-research uses it to brainstorm findings before presenting them.

The last one is `/TRIP-upgrade`, which upgrades an existing project's TRIP skills to the latest release without losing project customizations. It fetches this repository itself, and the README says you can pass a version to pin one or a local folder to upgrade from a fork. Under the hood it recovers the generic template you installed before applying the new release, which is the mechanism that makes customizations survive an upgrade.

Compared with writing your own prompt files and with a rich skill ecosystem

There are two other approaches to the same problem, and the difference in approach is about where the knowledge lives.

Writing your own prompt files is the baseline. A `CLAUDE.md` with a few rules, a handful of slash commands, and a convention of asking for a plan first is a perfectly reasonable setup, and it has the advantage of being entirely yours with nothing to upgrade. What it lacks is the machinery TRIP provides around the agent's memory. A `CLAUDE.md` is instructions for the agent, not a description of the architecture, and a description of the architecture is what stops the guessing described earlier. A team that writes an ARCHI.md by hand and tells the agent to read it gets most of the benefit, and that is a reasonable path if you dislike the three-command structure.

A rich skill ecosystem is the other direction. The README names Superpowers, BMAD and Gastown as examples of workflows that offer far more commands, sub-agents and course material. That is a real choice for someone who wants a full methodology, and a bad one for someone who wants to ship a feature this week. The README's own framing of the trade is that the simple workflows come with 47 commands to memorize, sub-agent swarms, and sometimes paid courses.

TRIP sits in the middle and makes a bet on minimalism. Three commands, one file, and the workflow disappears into the background.

The honest weakness is that the bet can be wrong. A three-command workflow assumes the phases are the ones you need, and it assumes the reviewer role is filled by Codex rather than by a colleague. A team with a real review culture, or one that needs to trace decisions across a long project, will want more than this and will find the missing parts quickly.

The licence situation is also worth flagging. The repository metadata reports the licence as unknown, while the README badge says MIT and links to a LICENSE file. The badge and the file are the better evidence, but if you plan to redistribute the skill files inside a proprietary repository, read the LICENSE file yourself first, and this is not legal advice.

Editorial conclusion

Adopt TRIP-workflow if you use an AI coding agent daily, your project has an architecture worth writing down, and you want a repeatable cycle with review gates rather than ad hoc prompting. Do not adopt it if your work is throwaway scripts, if you cannot commit to keeping ARCHI.md current, since a stale architecture file is worse than none, or if you want a rich skill ecosystem, since the whole pitch is three commands. Verify first that your agent supports the Agent Skills format and the `AskUserQuestion` hook the workflow depends on, and confirm the release step matches how your repository versions and publishes.

Frequently asked questions

Official sources

1. Issues
2. PiLastDigit/TRIP-workflow on GitHub
3. README
4. Releases