> ## Documentation Index > Fetch the complete documentation index at: https://docs.mutagent.io/llms.txt > Use this file to discover all available pages before exploring further. # Lifecycle commands > The commands on Architech's start screen: plan, build, review, ship and monitor, and the two tracks that connect them. > [!NOTE] > > **Early Access.** Commands and behavior can change between releases. When you start Architech, its start screen lists the lifecycle commands under **LIFECYCLE COMMANDS**. Each one moves a change through a stage: **plan**, **build**, **review**, **ship** and **monitor**. The screen also names the [agent](https://docs.mutagent.io/architech/agents.md) that runs each stage: | Stage | Command | On the start screen | | - | - | - | | **PLAN** · architect | `/spec` | requirements → design → tasks | | | `/publish` | tasks → GitHub issues | | **BUILD** · orchestrator | `/dispatch` | Full-Loop · issues → parallel agents | | | `/execute` | Fast Mode · plan and act in one pass | | **REVIEW** · developer | `/review` | code review of an issue or PR | | **SHIP** · orchestrator | `/ship` | review + CI + merge + watch | | **MONITOR** · orchestrator | `/monitor` | CI/CD, deploy health, production | Below them are the two tracks, the usual paths through the stages: ```text theme={null} Full-Loop /spec → /publish → /dispatch → /review → /ship Fast Mode /execute → /review → /ship ``` The last line, `/help · every other command`, points to the [session commands](#session-commands). Type a command in your session, followed by its arguments: `/dispatch 42`. ## Choose a track | Track | Use it for | What you approve | | - | - | - | | **Full-Loop** | Features that need requirements, a design and an acceptance spec, often across several tasks or repositories. | The plan and its acceptance spec, then each merge. | | **Fast Mode** | Small to medium changes you can describe in a sentence or two. | The merge (and the plan too, with `--interactive`). | ### Full-Loop **1. /spec — plan** The architect writes requirements, a design, tasks and an acceptance spec. You answer its questions and sign the acceptance spec. **2. /publish — turn the plan into issues** First run `/adversarial-review`, the design review that critiques the finished design. Once it has passed, or you've accepted its risks, the plan becomes a GitHub issue with one sub-issue per task, on your project board. **3. /dispatch — build** Agents build the tasks in parallel. Each pull request is reviewed by an agent that didn't build it. **4. /review — review again when you need to** Ask for a fresh review of a pull request or an issue, for example after a change. **5. /ship — land it** Review, CI, merge and post-merge monitoring for one pull request. ### Fast Mode `/execute` compresses `/spec`, `/publish` and `/dispatch` into one command: it plans, opens one issue, builds the change and has its pull request reviewed. `/review` and `/ship` are the same stages as in Full-Loop: run them on the pull request `/execute` opened when you want another review, or to land it if `/execute` hasn't merged it. ## Plan ### /spec Plans a feature before anything is built: **requirements → design → tasks**, with an acceptance spec that defines when the feature is done. Run by the architect. ```text theme={null} /spec Add single sign-on for the admin dashboard ``` | Flag | What it does | | - | - | | `--feature` | A feature or change to your existing code. The default: it first shows which repositories the feature spans. | | `--project` | The same as `--feature`, in a monorepo. | | `--new-app` | A new application from scratch; skips the analysis of existing code. | | `--ui` | Frontend-focused; skips backend design. | | `--service` | Backend or API-focused; skips UI design. | | `--mobile` | A mobile application. | | `--interactive` | Asks you for decisions at each phase. Combines with the others. | | `--no-html` | Skips rendering and publishing the PRD (no `prd.html`). Combines with the others. | | `--auto` | No stops: each decision is made and recorded for you, and the design review runs at the end. It ends before `/publish`. | **It stops for you** at up to four points: to confirm which repositories the feature spans, to review the open decisions and to lock them (these two only when there are open decisions), and to sign the acceptance spec. **It produces** a folder, `.memory/features//`, with `requirements.md`, `design.md`, `tasks.md` and `acceptance.md`, a decisions page and a rendered PRD (`prd.html`). A feature that spans two or more repositories or packages, or adds a component, also gets a system map. ### /publish Turns a finished spec into GitHub issues, so it can be built and tracked. | Flag | What it does | | - | - | | `--dry-run` | Writes every issue body to `.memory/features//_work/publish-preview/` and runs the checks. Nothing is sent to GitHub. | | `--force` | Publishes even if the spec's validation or design review is incomplete. Never past an unsigned acceptance spec. | | `--auto` | Accepts an acceptance spec that `/spec --auto` drafted, and the risks its design review recorded. Marks the spec as auto-signed in the issue. | **Before you run it:** * `/spec` has finished and its validation passed. * The acceptance spec is signed. * The design review, `/adversarial-review`, has passed, or you've accepted the risks it found. It critiques the finished design for security, scale, maintainability, extensibility, testability and bottlenecks. * The GitHub CLI is signed in (`gh auth status`). `/publish --dry-run` checks the signature, the locked decisions and the design review, without calling GitHub, and names the fix for each blocker. **It produces** a parent issue with the full plan: a link to the PRD, the decisions with their reasons, and the acceptance spec. It adds one sub-issue per task and puts them on your project board. ## Build ### /dispatch Builds a planned issue: its sub-issues go to agents that work in parallel. ```text theme={null} /dispatch 42 ``` | Argument or flag | What it does | | - | - | | `` | The parent issue to build. Required. | | `--no-status-update` | Doesn't move items on the board. Comments are still posted. | **What happens:** * Each task goes to the right agent: the Developer, or the LLM-Whisperer for AI work. * Independent fixes get their own pull requests. A planned feature is built in waves on a shared branch, with one pull request per repository for the whole feature. * Board items move to **In Progress**, then **In Review**. * Each pull request, or the whole feature, is reviewed by an agent that didn't build it. A review that asks for changes goes back to the builder; after two rounds, it comes to you. * If the issue has an acceptance spec, a separate verifier runs its journeys at the end and writes a report for you to sign. **It produces** reviewed pull requests and a summary comment on the parent issue. `/dispatch` doesn't merge into your default branch: land each pull request with `/ship`. ### /execute Plans and builds a change in one pass. ```text theme={null} /execute "Fix the session cookie's httpOnly flag" ``` | Flag | What it does | | - | - | | `--interactive` | Pauses after the plan, so you can review it before anything is built. | | `--dry-run` | Writes the plan only, then stops. | | `--local` | No GitHub issue, and no monitoring. For trivial changes to one to three files. | | `--no-monitor` | Skips monitoring after the merge. | | `--sequential` | Runs the developers one at a time instead of as a team. | **What happens:** 1. **Plan.** The architect writes `plan.md` in `.memory/features//`. A small change gets a compact plan: one wave, one task. No flag skips this step. 2. **Issue.** One GitHub issue, titled `[Execute] …` and labelled `execute`, holds the plan for visibility. `--local` skips it. 3. **Build.** A small change, with a compact plan, is one pull request against your usual branch, reviewed by an agent that didn't build it. A larger plan is built in waves on a feature branch, `feat/`, with one final pull request that gets one full code review. Review findings are fixed before the merge. 4. **Merge and watch.** The reviewed pull request is merged as your merge rules allow, then `/monitor` runs in the background. `plan.md` is never committed: it's deleted when the run ends, and the issue keeps the plan. ## Review ### /review Reviews a pull request, or the work for an issue, against your engineering rules and the issue's acceptance criteria. ```text theme={null} /review 128 ``` | Argument | What it does | | - | - | | `` or `` | What to review. Architech tells a pull request from an issue. | The review is done by a fresh agent that didn't write the change: the Developer, or the LLM-Whisperer for AI work. It ends in one of three verdicts: | Verdict | Meaning | | - | - | | **APPROVE** | No blocking finding. | | **WATCH** | Mergeable, with follow-ups to do and something to watch after the merge. | | **NEEDS-CHANGES** | At least one blocking finding: fix it, then review again. | **It produces** a GitHub review on the pull request and a **🔍 Review Verdict** comment listing each finding. Missing rules or memory never stop a review: they're reported as findings, and the review still ends in a verdict. ## Ship ### /ship Lands one pull request: review, CI, merge and monitoring in one guarded command. ```text theme={null} /ship 128 ``` | Argument or flag | What it does | | - | - | | `` | The pull request to land. Required. | | `--no-monitor` | Stops after the merge, without monitoring. | | `--admin` | Merges past branch protection. Use it only when you've decided to. | **What happens:** 1. **Checks.** It refuses a draft, a closed pull request, merge conflicts, or a hold label (`merge:hold` by default). `--admin` never overrides a hold. 2. **Review.** A fresh review. Mechanical findings get up to two automatic fix cycles. Design-level findings, such as authorization, security, the data model, an API contract or concurrency, come to you without an automatic fix. 3. **CI.** It waits for the checks. If one fails, it posts an analysis and decides whether to retry, stop, or ask you. 4. **Merge.** A squash merge, which deletes the branch. A feature with an acceptance spec merges only with a signed acceptance report. Auto-merge is never turned on. 5. **Monitor.** `/monitor` follows the merge commit, and a post-deploy scorecard is posted. If it finds something severe, it proposes a revert for you to approve; it never reverts on its own. **It produces** a comment on the pull request at each step, so the pull request records why it merged, stopped or proposed a revert. ## Monitor ### /monitor Follows a merge through CI, deployment and production health. `/ship` and `/execute` start it for you after a merge; run it yourself at any time. ```text theme={null} /monitor #128 ``` | Argument or flag | What it does | | - | - | | (none) | The latest commit on `main`: CI, deployment, health, then a commit status. Up to 20 minutes. | | `#` | That pull request's merge commit. If it isn't merged yet, shows its checks. | | `""` | Focuses each phase on a problem you describe, such as `"504 timeout"`. | | `--ci` | CI status only. | | `--health` | A quick production health check, about 10 seconds. | | `--rollback` | Finds the last stable deployment. | | `--live` | Follows production logs and investigates problems it detects. Add a service name, or `--since 1h`. | It reads your deployment details (platform, services, health endpoints) from `.memory/deployment.md`. It runs in the background, so you can keep working, and **sets a GitHub commit status** on the merge commit when it finishes. This is not the [Monitor](https://docs.mutagent.io/architech/features/monitor.md) feature, which watches processes in your session. ## Session commands | Command | What it does | | - | - | | `/help` | Prints the start screen again, refreshed from your project's current state, with every other command grouped by purpose. It runs instantly, without a model turn. | | `/exit` | Ends the Architech session cleanly. | > [card] [Orchestrator and agents](https://docs.mutagent.io/architech/agents.md) > > Who plans, builds and reviews your work. > [card] [Software Factory](https://docs.mutagent.io/factory/overview.md) > > Run the same lifecycle for your board, locally or on Mutagent Cloud. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.