--- title: How It Works description: An overview of the cross-cutting mechanisms that underpin NexusArchitect seo: image: /ogp.png --- This page describes the cross-cutting mechanisms that underpin NexusArchitect, as revealed through implementation. Which skills run and in what order is defined in a file called `skill-dependencies.yaml`. This section also covers the four profiles you can choose from depending on your use case: `mvp`, `core-only`, `ux-to-spec`, and `full`. A Go/No-Go decision mechanism that runs immediately after Phase 1, the first stage of the pipeline, to determine whether work should proceed. A terminal screen that shows in real time which phase is currently running and the status of the validation gate decision and cost. A collection of team-shared knowledge that is loaded at the start of every implementation run. The mechanism that advances issue labels through the sequence `todo` → `doing` → `review` → `done`. It also defines which labels each skill is permitted to change. Three distinct checklist types: a child task list that breaks down the work, acceptance criteria that define the definition of done, and a Delivery Status that tracks progress from implementation through merge. Each type restricts which skills are allowed to check off items. Progress is written to files even when a run stops mid-way. Covers how to resume from where you left off using the same command, and how to check your current position in the pipeline. What drives cost, how to review actual spend after a run, and the command for estimating cost upfront.