Skip to main content
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 that runs each stage: Below them are the two tracks, the usual paths through the stages:
The last line, /help · every other command, points to the session commands. Type a command in your session, followed by its arguments: /dispatch 42.

Choose a track

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.
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/<feature>/, 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. 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.
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.
What happens:
  1. Plan. The architect writes plan.md in .memory/features/<slug>/. 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/<slug>, 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.
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: 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.
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.
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 feature, which watches processes in your session.

Session commands

Orchestrator and agents

Who plans, builds and reviews your work.

Software Factory

Run the same lifecycle for your board, locally or on Mutagent Cloud.