tyrex-framework 0.1.1 → 0.2.0

package/README.md

@@ -96,16 +96,16 @@ For **new/empty projects**, Tyrex creates a minimal structure and suggests `/tyr
 | `/tyrex-init` | Map codebase, configure project, generate TYREX.md |
 | `/tyrex-discuss` | Explore project interactively, brainstorm architecture |
 | `/tyrex-new` | Start a new feature (requirements, docs, skills, branch) |
-| `/tyrex-plan` | Plan tasks with dependencies, parallelism, and SPEC per task |
-| `/tyrex-do` | Execute tasks (TDD, skill-aware, parallel sub-agents) |
-| `/tyrex-review` | Review implementation, finalize docs, evolve TYREX.md |
+| `/tyrex-plan` | Security-first planning with dependencies, parallelism, and SPEC per task |
+| `/tyrex-do` | Execute tasks (TDD, skill-aware, parallel sub-agents). Supports `--auto-approve` |
+| `/tyrex-review` | 4-lens senior code review. Supports `--do-all`, `--do-critical`, `full` |
 
 ### Shortcuts
 
 | Command | Purpose |
 |---------|---------|
-| `/tyrex-quick` | Fast task without full ceremony (bug fixes, tweaks) |
-| `/tyrex-handoff` | Autopilot: chains new -> plan -> do -> review |
+| `/tyrex-quick` | Fast-track unified `new → plan → do` from a single prompt |
+| `/tyrex-quick --auto-approve` | Full autopilot (replaces deprecated `/tyrex-handoff`) |
 
 ### Management
 
@@ -140,9 +140,10 @@ For **new/empty projects**, Tyrex creates a minimal structure and suggests `/tyr
 /tyrex-init --> /tyrex-discuss (brainstorm) --> /tyrex-new --> ...
 ```
 
-**Quick fix:**
+**Quick fix or small feature:**
 ```
-/tyrex-quick  (skip spec/plan, just fix and commit)
+/tyrex-quick              (unified new → plan → do, single prompt)
+/tyrex-quick --auto-approve  (full autopilot, no checkpoints)
 ```
 
 ## Key Concepts
@@ -173,6 +174,37 @@ REST APIs, database design, authentication, performance optimization.
 
 Skills are auto-suggested during `/tyrex-new` and loaded during `/tyrex-do` for specialized implementation quality.
 
+### Security-First Planning
+
+`/tyrex-plan` performs a security assessment before proposing tasks. Security-sensitive tasks automatically get the `devsec` skill assigned and `quality: required`. Features with security implications get a dedicated hardening task.
+
+### 4-Lens Senior Code Review
+
+`/tyrex-review` evaluates through 4 critical lenses:
+1. **Pattern Compliance** — does the code follow project patterns from TYREX.md?
+2. **Code Quality & DRY** — duplication, complexity, maintainability
+3. **Business & Technical Compliance** — does it meet the SPEC and acceptance criteria?
+4. **Security First** — OWASP top 10, input validation, secrets management
+
+Use `--do-all` or `--do-critical` to auto-create fix tasks from review findings.
+
+### Interactive Quiz UX
+
+All user decisions across all commands use interactive quiz format (multiple-choice selection). This ensures consistent UX and reduces cognitive load — no open-ended questions when a quiz can be used.
+
+### Built-in DevSec Skill
+
+A security engineering skill (`devsec`) ships with the framework. It's auto-suggested when security-sensitive areas are detected during `/tyrex-new` and `/tyrex-plan`, providing OWASP/SANS coverage out of the box.
+
+### Command Flags
+
+| Flag | Commands | Effect |
+|------|----------|--------|
+| `--auto-approve` | `/tyrex-do`, `/tyrex-quick` | Skip all human checkpoints |
+| `--do-all` | `/tyrex-review` | Auto-create fix tasks for all findings |
+| `--do-critical` | `/tyrex-review` | Auto-create fix tasks for critical findings only |
+| `full` | `/tyrex-review` | Codebase-wide re-scan (default is PR scope) |
+
 ### Roadmap — Forward Visibility
 
 `.tyrex/roadmap.yml` tracks planned, in-progress, and completed features. The `/tyrex-status` command shows what's done, what's active, and what's next. `/tyrex-new` checks the roadmap before asking for a new demand.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tyrex-framework",
-  "version": "0.1.1",
+  "version": "0.2.0",
   "description": "Human-driven, AI-accelerated pair programming framework. Orchestrates AI agents with guardrails, parallelization, and shared memory.",
   "bin": {
     "tyrex": "./bin/tyrex.js"

package/templates/AGENTS.md

@@ -9,27 +9,29 @@ This project uses the Tyrex Framework for human-driven, AI-accelerated pair prog
 3. **Check mode:** Read `agent_mode` from `cursor.yml`. In `plan` mode, NEVER write source code — only `.tyrex/`, `docs/`, and config files. In `build` mode, follow TDD and commit rules.
 4. **Use commands:** The `/tyrex-*` slash commands orchestrate the development workflow.
 5. **Update state:** After every task, update the cursor and task state files.
+6. **Interactive quiz:** ALL user decisions use interactive quiz format (multiple-choice). Never ask open-ended questions when a quiz can be used.
+7. **Security first:** Always consider security implications during planning and review. The DevSec skill (`templates/skills/devsec.md`) is auto-suggested for security-sensitive work.
 
 ## Commands Available
 
-| Command | Purpose |
-|---------|---------|
-| `/tyrex-init` | Initialize Tyrex in a project (map codebase, configure) |
-| `/tyrex-settings` | View/modify Tyrex configuration |
-| `/tyrex-new` | Start a new feature/demand (with docs config per demand) |
-| `/tyrex-plan` | Plan implementation tasks with dependencies and parallelism |
-| `/tyrex-do` | Execute tasks (sequential or parallel, with TDD) |
-| `/tyrex-review` | Review implementation, finalize docs, refactor |
-| `/tyrex-status` | Show current project and feature status |
-| `/tyrex-resume` | Resume from last session (fast recovery via cursor) |
-| `/tyrex-quick` | Quick task without full ceremony (bug fixes, tweaks) |
-| `/tyrex-evolve` | Update TYREX.md with new patterns/knowledge |
-| `/tyrex-handoff` | Deterministic autopilot (chains new→plan→do→review) |
-| `/tyrex-skills` | Manage and apply reusable skills |
-| `/tyrex-readme` | Generate or update project README.md |
-| `/tyrex-openapi` | Generate or update OpenAPI documentation |
-| `/tyrex-wiki` | Generate or update project wiki pages |
-| `/tyrex-help` | Show commands, workflow guide, and contextual suggestions |
+| Command | Flags | Purpose |
+|---------|-------|---------|
+| `/tyrex-init` | | Initialize Tyrex in a project (map codebase, configure) |
+| `/tyrex-settings` | | View/modify Tyrex configuration |
+| `/tyrex-new` | | Start a new feature/demand (interactive quiz workflow) |
+| `/tyrex-plan` | | Plan tasks with security-first analysis |
+| `/tyrex-do` | `--auto-approve` | Execute tasks (sequential or parallel, with TDD) |
+| `/tyrex-review` | `--do-all` `--do-critical` `full` | Senior code review with 4 lenses + auto-fix loop |
+| `/tyrex-status` | | Show current project and feature status |
+| `/tyrex-resume` | | Resume from last session (fast recovery via cursor) |
+| `/tyrex-quick` | `--auto-approve` | Fast-track: unified new→plan→do from single prompt |
+| `/tyrex-evolve` | | Update TYREX.md with new patterns/knowledge |
+| `/tyrex-skills` | `create` `sync` | Manage and apply reusable skills |
+| `/tyrex-readme` | | Generate or update project README.md |
+| `/tyrex-openapi` | | Generate or update OpenAPI documentation |
+| `/tyrex-wiki` | | Generate or update project wiki pages |
+| `/tyrex-help` | `<command>` | Show commands, workflow guide, and contextual suggestions |
+| `/tyrex-handoff` | | **DEPRECATED** — use `/tyrex-quick --auto-approve` |
 
 ## Core Rules
 
@@ -38,11 +40,13 @@ This project uses the Tyrex Framework for human-driven, AI-accelerated pair prog
 3. **Every commit passes CI.** No broken commits, ever.
 4. **CHANGELOG is mandatory.** Update `docs/CHANGELOG.md` on every change.
 5. **Small commits.** One task = one atomic, revertible commit.
-6. **Ask, don't assume.** When in doubt, ask the human.
+6. **Interactive quiz for all decisions.** Use multiple-choice, not open-ended questions.
 7. **Simplicity wins.** Propose the simplest solution first.
 8. **Documentation first.** When configured, generate docs before code.
-9. **Update state.** Always update cursor.yml after completing tasks.
-10. **Respect parallelism rules.** Sub-agents only modify their own files and state.
+9. **Security first.** Evaluate security implications during planning and review.
+10. **Update state.** Always update cursor.yml after completing tasks.
+11. **Respect parallelism rules.** Sub-agents only modify their own files and state.
+12. **TYREX.md is the living index.** Auto-update when macro docs (ADR, PRD, SRS) are generated.
 
 ## File Structure
 
@@ -58,6 +62,9 @@ This project uses the Tyrex Framework for human-driven, AI-accelerated pair prog
 ├── templates/         # Document templates
 ├── skills/            # Reusable skills (synced across agents)
 └── map/               # Project mapping (generated on init)
+templates/
+├── skills/
+│   └── devsec.md      # Built-in DevSec skill template
 docs/
 ├── CHANGELOG.md       # Mandatory changelog
 ├── adrs/              # Architecture Decision Records
@@ -66,9 +73,27 @@ docs/
 └── diagrams/          # Flow diagrams
 ```
 
+## Workflow
+
+```
+Full workflow:
+  /tyrex-init → /tyrex-new → /tyrex-plan → /tyrex-do → /tyrex-review
+                (quiz)       (security)    [--auto]     (4 lenses)
+                                              ↑              │
+                                              └── fix tasks ─┘
+
+Fast track:
+  /tyrex-quick [--auto-approve]
+    = new + plan + do in one command
+
+Review with auto-fix:
+  /tyrex-review --do-all       (fix everything)
+  /tyrex-review --do-critical  (fix HIGH/CRITICAL only)
+```
+
 ## On Parallelization
 
-When tasks can run in parallel, ask the human before spawning sub-agents.
+When tasks can run in parallel, ask the human before spawning sub-agents (or auto-decide with `--auto-approve`).
 Each sub-agent receives: task description + TYREX.md + constitution.md.
 Each sub-agent writes ONLY to its own task state file.
 The orchestrator (main agent) handles commits, CHANGELOG, and cursor updates.

package/templates/commands/unified/tyrex-do.md

@@ -11,6 +11,15 @@ You are the Tyrex Framework orchestrator. Execute tasks from the active feature'
 This command runs in **build** mode. Set `agent_mode: "build"` in `cursor.yml` as the FIRST action.
 You may create, edit, and delete source code files following TDD, small commits, and all constitution rules.
 
+## Parameters
+
+- **`/tyrex-do`** (default) — Execute tasks with human approval at each checkpoint
+- **`/tyrex-do --auto-approve`** — Execute ALL tasks automatically: commits, parallelism decisions, and all checkpoints are auto-approved. Only stops on failures after 3 retries.
+
+## Interactive Quiz Rule
+
+**ALL decisions in this command MUST use the interactive quiz format** (multiple-choice selection). Never ask open-ended questions when a quiz can be used. This applies to: parallelization choices, failure handling, commit approval, and any other decision point.
+
 ## Behavior
 
 ### Step 1: Load state
@@ -35,17 +44,17 @@ These are the "ready" tasks.
 ### Step 3: Parallelization decision
 If there are MULTIPLE ready tasks that are marked as `parallel: true`:
 
-**Ask the user:**
+**If `--auto-approve`:** automatically choose parallel execution for all eligible tasks.
+
+**Otherwise, present interactive quiz:**
 ```
 Tasks [2, 3, 4] are ready and can run in parallel.
 
-[1] Execute all in parallel (3 agents)
-[2] Execute sequentially (one at a time)
-[3] Choose which to parallelize
+  [ ] Execute all in parallel (3 agents)
+  [ ] Execute sequentially (one at a time)
+  [ ] Choose which to parallelize
 ```
 
-If the user chose parallel in previous interaction for this feature AND `auto_suggest: true`, you can suggest the same choice again.
-
 ### Step 4: Execute tasks
 
 **For SEQUENTIAL execution:**
@@ -68,36 +77,47 @@ For each ready task, one at a time:
      - If the skill's `## Expertise` doesn't match the current task's domain, log a note but still apply (the human selected it)
    - Before marking the task complete, use `## Review Criteria` from the skill as a self-check
 3. Update task state to `in_progress`
-3. Update cursor.yml with current task
-4. **Implement following quality strategy:**
+4. Update cursor.yml with current task
+5. **Implement following quality strategy:**
    - Check the task's `quality` attribute (required | recommended | optional)
    - `required`: TDD mandatory — write tests first, implement, tests MUST pass
    - `recommended`: write tests alongside code, warn if skipped
-   - `optional`: ask user "Write tests for this task? [y/N]"
+   - `optional`: present quiz: `[ ] Write tests for this task` / `[ ] Skip tests`
+   - **If `--auto-approve`:** for `optional` quality, default to writing tests
    - Run lint if configured — it MUST pass
    - Run security scan if configured
-4. **On success:**
+6. **On success:**
    - If the implementation deviated from the SPEC's draft, update the SPEC file to reflect the actual approach taken
    - Update task state to `completed` with files_changed and output
    - Prepare commit message (conventional format)
    - Update `docs/CHANGELOG.md` with what changed
-   - **If commit mode is `approve`:**
+   - **If `--auto-approve`:**
+     - Make the commit automatically (overrides `approve` mode from tyrex.yml)
+   - **Else if commit mode is `approve`:**
      - Show: diff summary, commit message, changelog entry
-     - Ask: "Approve this commit? [Y/n/edit]"
-     - If edit: let user modify commit message
-     - If approved: make the commit
-   - **If commit mode is `auto`:**
+     - Present quiz: `[ ] Approve commit` / `[ ] Edit commit message` / `[ ] Reject and redo`
+   - **Else if commit mode is `auto`:**
      - Make the commit automatically
    - Update cursor.yml: last_task_completed, tasks_summary, next_tasks
-5. **On failure:**
+   - **Auto-update TYREX.md:** If this task generated or updated any ADR, PRD, SRS, or other macro documentation, automatically update TYREX.md:
+     - Add a summary entry in the appropriate section (Architecture Decisions for ADR, Business Rules for PRD, Requirements for SRS)
+     - Add any new patterns discovered to the Patterns section
+     - This keeps TYREX.md as the living index of all project knowledge
+7. **On failure:**
    - Update task state to `failed` with error details
    - Show the error to the user
-   - Ask: "Want me to fix it and retry? Or skip this task?"
+   - **If `--auto-approve`:** automatically retry up to 3 times, then mark as `failed` and continue to next task
+   - **Otherwise, present quiz:**
+     ```
+     [ ] Fix and retry
+     [ ] Skip this task
+     [ ] Stop execution
+     ```
    - If retry: fix and go back to step 3 of the task
    - If skip: mark as `failed`, check if any tasks are now `blocked`
 
-6. After task completion, check for newly unlocked tasks
-7. If new parallel tasks are available, go back to Step 3 (ask about parallelization)
+8. After task completion, check for newly unlocked tasks
+9. If new parallel tasks are available, go back to Step 3 (ask about parallelization)
 
 **For PARALLEL execution:**
 1. For each parallel task, spawn a sub-agent (Task tool) with:
@@ -112,7 +132,7 @@ For each ready task, one at a time:
 3. Collect results from task state files
 4. For each completed sub-task:
    - Validate the implementation (tests pass, lint clean)
-   - Handle commits (based on mode: approve or auto)
+   - Handle commits (based on mode: approve, auto, or `--auto-approve`)
    - Update CHANGELOG.md (sequentially, after all parallel tasks finish)
 5. Update cursor.yml with all completed tasks
 6. Check for newly unlocked tasks → go to Step 3
@@ -127,7 +147,10 @@ When ALL tasks are `completed`:
 - NEVER make a commit that breaks CI
 - ALWAYS update cursor.yml after each task — this enables session recovery
 - ALWAYS update CHANGELOG.md — it's mandatory
+- ALWAYS use interactive quiz for decisions — never open-ended questions
 - Sub-agents for parallel tasks should ONLY modify files listed in their task
 - If two parallel tasks need to modify the same file, they CANNOT be parallel — execute sequentially
 - The orchestrator (you) handles commits and state updates, NOT sub-agents
 - If the user interrupts ("stop", "wait", "pause"), immediately save state and stop
+- `--auto-approve` is a trust accelerator — it skips ALL human checkpoints but still runs all quality checks (tests, lint, security)
+- When macro docs (ADR, PRD, SRS) are created/updated, ALWAYS update TYREX.md with a summary

package/templates/commands/unified/tyrex-handoff.md

@@ -1,215 +1,27 @@
 ---
-description: "Deterministic autopilot - Tyrex takes full control of the development flow"
+description: "[DEPRECATED] Use /tyrex-quick --auto-approve instead"
 ---
 
-# /tyrex-handoff - Deterministic Autopilot Mode
+# /tyrex-handoff - DEPRECATED
 
-You are now operating under **Tyrex Handoff Protocol**. This is a deterministic mode where you MUST follow the Tyrex workflow step-by-step with ZERO deviation. Think of this as the user handing you the controls — but you fly strictly by the instrument panel.
+> **This command has been deprecated.** Use `/tyrex-quick --auto-approve` instead.
 
-## Agent Mode
+The handoff command was replaced by the redesigned `/tyrex-quick` which now provides a unified `new → plan → do` pipeline with the `--auto-approve` flag for full autopilot mode.
 
-This command transitions between modes as it progresses through phases:
-- **PHASE 0-3** (Context, Demand, Config, Planning): set `agent_mode: "plan"` — no source code writing
-- **PHASE 4** (Execution): set `agent_mode: "build"` — source code writing allowed
-- **PHASE 5-6** (Documentation, Review): set `agent_mode: "plan"` — no source code writing
-Update `agent_mode` in `cursor.yml` at each phase transition.
+## Migration Guide
 
-## CRITICAL RULES (NON-NEGOTIABLE)
+| Old command | New equivalent |
+|-------------|----------------|
+| `/tyrex-handoff` | `/tyrex-quick --auto-approve` |
+| `/tyrex-handoff` (with checkpoints) | `/tyrex-quick` (interactive mode) |
 
-1. You MUST read and obey `.tyrex/constitution.md` before ANY action. If it doesn't exist, STOP and tell the user to run `/tyrex-init` first.
-2. You MUST read `.tyrex/tyrex.yml` for all configuration. Do NOT ask the user things already configured.
-3. You MUST read `.tyrex/state/cursor.yml` to know current state. Do NOT start from scratch if there is state.
-4. You MUST follow the phase sequence below. Do NOT skip phases. Do NOT reorder.
-5. You MUST update state files after EVERY action. If you crash, the next session resumes from the last recorded state.
-6. You MUST NOT implement anything without an approved plan.
-7. You MUST NOT commit without tests passing (respecting quality strategy for the context).
-8. You MUST update `docs/CHANGELOG.md` on every change. No exceptions.
-9. You MUST ask the human for decisions at defined checkpoints (marked with [CHECKPOINT] below). Between checkpoints, operate autonomously.
-10. When a task specifies a skill, you MUST load that skill before executing.
+## Why deprecated?
 
-## PHASE SEQUENCE
+- `/tyrex-quick` now covers the entire `new → plan → do` pipeline
+- `--auto-approve` flag provides the same autopilot behavior
+- `/tyrex-review` now has its own `--do-all` and `--do-critical` flags for the review→fix loop
+- Having two commands that do the same thing adds confusion without value
 
-Execute these phases IN ORDER. Do not proceed to the next phase until the current one is complete.
+## If you're here by accident
 
-### PHASE 0: Context Load
-```
-READ .tyrex/state/cursor.yml
-IF active_feature exists AND status != "done":
-  → Resume from last recorded state (skip to appropriate phase)
-IF no .tyrex/ directory:
-  → STOP. Tell user: "Run /tyrex-init first."
-READ .tyrex/TYREX.md
-READ .tyrex/constitution.md
-READ .tyrex/tyrex.yml
-REPORT current state to user
-```
-
-### PHASE 1: Demand Capture
-```
-ASK user: "What do you want to implement?"
-LISTEN to description
-ANALYZE description for:
-  - Ambiguities (ask max 5 clarification questions)
-  - Scope boundaries (what's NOT included)
-  - Affected project areas (API? Mobile? Web? Workers?)
-
-[CHECKPOINT] Present understanding back to user. Wait for confirmation.
-```
-
-### PHASE 2: Configuration
-```
-READ defaults from tyrex.yml
-DETECT project context for quality strategy:
-  - Check for test frameworks (jest, rspec, pytest, etc.)
-  - Check for existing coverage config
-  - Identify area type (api/mobile/web/worker/infra)
-
-PRESENT configuration:
-  - Documentation: CHANGELOG (mandatory) + suggest ADR/RFC/Wiki/Diagrams based on complexity
-  - Documentation generation: suggest /tyrex-readme, /tyrex-openapi, /tyrex-wiki as final tasks if relevant
-  - Branch name suggestion
-  - Commit mode (from tyrex.yml or ask)
-  - Quality strategy for this context
-  - Skills: identify required skills, check if installed
-
-[CHECKPOINT] User approves or modifies configuration.
-
-CREATE feature spec in .tyrex/features/NNN-feature-name.md
-CREATE branch (if mode = auto) or suggest (if mode = approve)
-UPDATE cursor.yml
-GENERATE documentation artifacts FIRST (ADR, RFC if configured)
-
-[CHECKPOINT] If docs were generated, user reviews before proceeding.
-```
-
-### PHASE 3: Planning
-```
-READ feature spec
-READ TYREX.md for project patterns
-SCAN for available skills in:
-  - .tyrex/skills/
-  - .claude/skills/
-  - .opencode/skills/
-  - .agents/skills/
-  - .cursor/rules/ (skill-like files)
-
-GENERATE task list with:
-  - Dependencies (depends_on, unlocks)
-  - Parallelism markers (parallel: true/false)
-  - Skill assignment per task
-  - Quality strategy per task
-  - File targets per task
-  - IF relevant: add documentation tasks at the end (/tyrex-readme, /tyrex-openapi, /tyrex-wiki)
-
-DISPLAY execution graph (waves)
-
-[CHECKPOINT] User approves plan. Can add/remove/reorder tasks.
-
-CREATE .tyrex/state/tasks/*.state files
-UPDATE cursor.yml
-UPDATE feature spec with tasks
-```
-
-### PHASE 4: Execution
-```
-LOOP until all tasks complete:
-  
-  IDENTIFY next executable tasks (dependencies satisfied)
-  
-  IF multiple parallel tasks available:
-    [CHECKPOINT] "Tasks [N, M, P] can run in parallel. Execute in parallel or sequential?"
-  
-  FOR each task to execute:
-    IF task has skill assigned:
-      LOAD skill content
-      IF skill not found:
-        [CHECKPOINT] "Skill 'X' not installed. Create now, skip, or install?"
-    
-    UPDATE task state → in_progress
-    UPDATE cursor.yml
-    
-    IMPLEMENT following quality strategy:
-      IF strategy = "required": TDD mandatory, tests MUST pass
-      IF strategy = "recommended": write tests, warn if skipped
-      IF strategy = "optional": ask "Write tests? [y/N]"
-    
-    RUN tests (if applicable)
-    RUN lint (if configured)
-    RUN security scan (if configured)
-    
-    IF all checks pass:
-      UPDATE CHANGELOG.md
-      IF commit mode = "approve":
-        [CHECKPOINT] Show diff + commit message. Wait for approval.
-      IF commit mode = "auto":
-        COMMIT automatically
-      UPDATE task state → completed
-      UPDATE cursor.yml
-    
-    IF checks fail:
-      SHOW error to user
-      FIX and retry (max 3 attempts)
-      IF still failing:
-        [CHECKPOINT] "Task failed after 3 attempts. Skip or debug?"
-  
-  CHECK for newly unlocked tasks → continue loop
-```
-
-### PHASE 5: Documentation (if configured)
-```
-IF /tyrex-readme was added as task: EXECUTE it
-IF /tyrex-openapi was added as task: EXECUTE it
-IF /tyrex-wiki was added as task: EXECUTE it
-
-Each generates docs WITHOUT touching source code.
-COMMIT documentation updates.
-```
-
-### PHASE 6: Review
-```
-READ review checklist from .tyrex/templates/review-checklist.md
-CHECK all acceptance criteria
-CHECK code quality
-CHECK test coverage
-CHECK security
-CHECK documentation completeness
-
-PRESENT review summary
-
-[CHECKPOINT] User approves or requests changes.
-IF changes requested: go back to PHASE 4 with fix tasks.
-
-UPDATE TYREX.md if new patterns emerged
-UPDATE feature status → done
-UPDATE cursor.yml → clear active feature
-FINAL COMMIT with any review updates
-```
-
-### PHASE 7: Handoff Complete
-```
-REPORT:
-  - Feature summary
-  - Files changed
-  - Tests added
-  - Documentation generated
-  - Commits made
-  - Next suggested action
-
-"Handoff complete. The controls are yours again."
-```
-
-## FAILURE RECOVERY
-
-If at ANY point the session is interrupted:
-1. cursor.yml has the last known state
-2. Task state files have individual task progress
-3. Next session: read cursor.yml → resume from exact point
-4. Tasks marked `in_progress` when session dropped → reset to `pending`
-
-## WHAT THIS IS NOT
-
-- This is NOT autonomous "go build everything". The human is still in control at every [CHECKPOINT].
-- This is NOT vibe coding. Every step has verification.
-- This is NOT a suggestion engine. Between checkpoints, the agent EXECUTES, not suggests.
-
-The difference from normal Tyrex commands: handoff mode chains ALL phases automatically. The user doesn't need to type `/tyrex-new`, then `/tyrex-plan`, then `/tyrex-do`, then `/tyrex-review`. They type `/tyrex-handoff` ONCE and the system drives through the entire workflow, stopping only at checkpoints for human decisions.
+Run `/tyrex-quick` for the fast-track workflow, or `/tyrex-help` to see all available commands.