tyrex-framework 0.1.1 → 0.2.0

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

@@ -32,19 +32,18 @@ Show ALL commands grouped by category:
 TYREX Help
 ═══════════════════════════════════════
 
-  Workflow principal:
+  Core Workflow:
     /tyrex-init       Initialize Tyrex in a project (map codebase, configure)
-    /tyrex-new        Start a new feature/demand
-    /tyrex-plan       Plan tasks with dependencies and parallelism
-    /tyrex-do         Execute implementation tasks
-    /tyrex-review     Review implementation, finalize docs
+    /tyrex-new        Start a new feature/demand (interactive quiz)
+    /tyrex-plan       Plan tasks with security-first approach
+    /tyrex-do         Execute tasks [--auto-approve]
+    /tyrex-review     Senior code review with 4 lenses [--do-all | --do-critical] [full]
 
   Exploration:
     /tyrex-discuss    Explore the project, ask questions, brainstorm architecture
 
-  Shortcuts:
-    /tyrex-quick      Quick task without full ceremony (bug fix, tweak)
-    /tyrex-handoff    Autopilot — chains new→plan→do→review automatically
+  Fast Track:
+    /tyrex-quick      Unified new→plan→do from a single prompt [--auto-approve]
 
   Management:
     /tyrex-status     Show current project and feature status
@@ -61,6 +60,9 @@ TYREX Help
 
   Meta:
     /tyrex-help       This command. Use /tyrex-help <command> for details.
+
+  Deprecated:
+    /tyrex-handoff    → Use /tyrex-quick --auto-approve instead
 ```
 
 #### Step 3: Show workflow diagram
@@ -68,21 +70,21 @@ TYREX Help
 ```
   Typical workflow:
 
-    /tyrex-init → /tyrex-discuss → /tyrex-new → /tyrex-plan → /tyrex-do → /tyrex-review
-                  (optional)                          ↑                         │
-                                                      └─── fix tasks ───────────┘
-
-  Greenfield:
-    /tyrex-init → /tyrex-discuss (brainstorm) → /tyrex-new → ...
+    /tyrex-init → /tyrex-new → /tyrex-plan → /tyrex-do → /tyrex-review
+                  (quiz)       (security)    [--auto]     (4 lenses)
+                                                ↑              │
+                                                └── fix tasks ─┘
 
-  Anytime Q&A:
-    /tyrex-discuss  (explore the project, ask questions at any point)
+  Fast track (from single prompt):
+    /tyrex-quick [--auto-approve]
+      = /tyrex-new + /tyrex-plan + /tyrex-do in one command
 
-  Fast mode:
-    /tyrex-handoff  (runs the entire workflow, stops at checkpoints)
+  Review with auto-fix:
+    /tyrex-review --do-all       (fix everything)
+    /tyrex-review --do-critical  (fix only HIGH/CRITICAL)
 
-  Quick fix:
-    /tyrex-quick    (skip spec/plan, just fix and commit)
+  Exploration (anytime):
+    /tyrex-discuss  (explore the project, ask questions at any point)
 ```
 
 #### Step 4: Contextual suggestion
@@ -93,19 +95,19 @@ Based on the current state, suggest the next action. Use EXACTLY ONE of these:
   > "You haven't initialized Tyrex yet. Start with `/tyrex-init` to map your project and configure the framework."
 
 - **`.tyrex/` exists but no active feature (or last feature is `done`):**
-  > "Tyrex is initialized. Use `/tyrex-new` to start a new feature, or `/tyrex-handoff` for autopilot mode."
+  > "Tyrex is initialized. Use `/tyrex-new` to start a new feature, or `/tyrex-quick` for a fast-track task."
 
 - **Active feature with status `spec` (no plan yet):**
   > "You have a feature spec ready. Run `/tyrex-plan` to plan the implementation tasks."
 
 - **Active feature with status `planned` (plan approved, no tasks started):**
-  > "Your plan is approved. Run `/tyrex-do` to start implementing."
+  > "Your plan is approved. Run `/tyrex-do` to start implementing, or `/tyrex-do --auto-approve` for autopilot."
 
 - **Active feature with tasks `in_progress` or `pending`:**
   > "You have tasks in progress. Run `/tyrex-do` to continue, or `/tyrex-resume` if this is a new session."
 
 - **Active feature with ALL tasks `completed`:**
-  > "All tasks are done! Run `/tyrex-review` to review the implementation."
+  > "All tasks are done! Run `/tyrex-review` to review, or `/tyrex-review --do-all` to review and auto-fix."
 
 - **Cannot determine state (cursor.yml missing or corrupted):**
   > "Run `/tyrex-status` to see where things stand, or `/tyrex-init` to start fresh."
@@ -124,7 +126,9 @@ All resolve to the same command.
 #### Step 1: Identify the command
 
 Strip any `/tyrex-` or `tyrex-` prefix from the argument. Match against the known commands:
-`init`, `new`, `plan`, `do`, `review`, `quick`, `handoff`, `status`, `resume`, `settings`, `evolve`, `skills`, `context`, `discuss`, `readme`, `openapi`, `wiki`, `help`
+`init`, `new`, `plan`, `do`, `review`, `quick`, `status`, `resume`, `settings`, `evolve`, `skills`, `context`, `discuss`, `readme`, `openapi`, `wiki`, `help`
+
+Also match deprecated: `handoff` → redirect to `quick`.
 
 If no match: show "Command not found" and list all available commands.
 
@@ -139,6 +143,9 @@ For the matched command, present a structured summary:
   What it does:
     [1-2 sentence description of purpose]
 
+  Flags:
+    [list of flags and their effects, or "None"]
+
   When to use:
     [Context — when should the user reach for this command]
 
@@ -161,6 +168,7 @@ Use the reference below for each command:
 
 **init:**
 - What: Maps your codebase, detects stack/architecture/security issues, configures Tyrex.
+- Flags: None
 - When: First time using Tyrex in a project, or re-initializing after major changes.
 - Steps: Codebase analysis → Generate TYREX.md + constitution → Interactive config → Summary
 - Prerequisites: None (this is the starting point)
@@ -168,62 +176,63 @@ Use the reference below for each command:
 
 **discuss:**
 - What: Interactive exploration and technical discussion. In codebase mode, answers questions about existing code with file references. In greenfield mode, brainstorms architecture, stack, and scope. Loads relevant skills as perspective automatically.
+- Flags: None
 - When: You're new to a project and want to understand it, or starting from scratch and want to brainstorm before building. Can be used anytime for Q&A.
 - Steps: Detect mode (codebase/greenfield/hybrid) → Load skills → Multi-turn conversation → Save conclusions on demand (user-initiated only)
 - Prerequisites: `.tyrex/` initialized (recommended but not required for basic Q&A)
 - Next: `/tyrex-new` (to act on what was discussed) or `/tyrex-evolve` (to record decisions)
 
 **new:**
-- What: Starts a new feature/demand. Checks the roadmap for planned features first, captures requirements, analyzes required skills, configures docs/git, generates feature spec, and updates the roadmap. Supports documentation types: ADR, RFC, Wiki, SPEC, SRS, PRD.
+- What: Starts a new feature/demand. All decisions are made via interactive quizzes. Checks the roadmap, captures requirements, analyzes required skills (including DevSec), configures docs/git, generates feature spec, and updates TYREX.md.
+- Flags: None
 - When: You have something to build and want to go through the full workflow.
-- Steps: Check roadmap for planned features → Describe demand → Clarification questions → Context ingestion → Skill analysis & suggestion → Config (docs, branch, commits) → Generate docs first → Create feature spec → Create branch → Update roadmap
+- Steps: Check roadmap (quiz) → Describe demand → Clarification (quiz) → Context ingestion (quiz) → Skill analysis with DevSec check (quiz) → Config docs/git (quiz) → Generate docs first → Create feature spec → Create branch → Update TYREX.md
 - Prerequisites: `.tyrex/` initialized (`/tyrex-init`)
 - Next: `/tyrex-plan`
 
 **plan:**
-- What: Breaks the feature into executable tasks with dependencies, parallelism, skill assignments, and quality strategy.
+- What: Breaks the feature into tasks with dependencies, parallelism, skill assignments, quality strategy, and security-first analysis. Every task gets a SPEC draft. Security-sensitive tasks get the devsec skill auto-assigned.
+- Flags: None
 - When: After creating a feature spec with `/tyrex-new`.
-- Steps: Load feature → Propose tasks → Show execution graph → Human approval → Save plan
+- Steps: Load context → Security-first analysis → Propose tasks with security attributes → Generate SPECs → Show execution graph → Human approval (quiz) → Save plan
 - Prerequisites: Active feature in `spec` status
 - Next: `/tyrex-do`
 
 **do:**
-- What: Executes tasks from the plan. Handles TDD, parallelization, commits, and state updates.
+- What: Executes tasks from the plan. Handles TDD, parallelization, commits, and state updates. Auto-updates TYREX.md when macro docs are generated.
+- Flags: `--auto-approve` (skip ALL human checkpoints, full autopilot)
 - When: After the plan is approved with `/tyrex-plan`.
-- Steps: Load state → Find ready tasks → Ask about parallelization → Execute with TDD → Commit → Update state → Repeat
+- Steps: Load state → Find ready tasks → Parallelization (quiz or auto) → Execute with TDD → Commit (quiz or auto) → Update state + TYREX.md → Repeat
 - Prerequisites: Active feature with approved plan
 - Next: `/tyrex-review` (when all tasks done)
 
 **review:**
-- What: Reviews the completed implementation against acceptance criteria, checks quality, finalizes docs.
+- What: Senior code review through 4 lenses: Pattern Compliance, Code Quality & DRY, Business & Technical Compliance, Security First. Can auto-create fix tasks and enter the plan/do loop.
+- Flags: `--do-all` (fix all findings), `--do-critical` (fix HIGH/CRITICAL only), `full` (codebase-wide review instead of branch diff)
 - When: All implementation tasks are complete.
-- Steps: Automated checks → Code review → Documentation finalization → TYREX.md evolution → Human approval
+- Steps: Automated checks → 4-lens review → TYREX.md evolution → Present findings (quiz) → Requested changes loop (if needed) → Finalize
 - Prerequisites: All tasks in active feature completed
-- Next: `/tyrex-new` (next feature) or `/tyrex-status`
+- Next: `/tyrex-new` (next feature) or done
 
 **quick:**
-- What: Handles a small task without the full spec/plan ceremony. Still requires tests and CHANGELOG.
-- When: Bug fixes, config tweaks, small changes that don't need a feature spec.
-- Steps: Describe task → Implement with TDD → Commit
-- Prerequisites: `.tyrex/` initialized
-- Next: Nothing specific — back to normal flow
-
-**handoff:**
-- What: Deterministic autopilot. Chains the entire workflow (new→plan→do→review) automatically, stopping only at defined checkpoints for human decisions.
-- When: You want to describe what to build and let Tyrex drive the entire process.
-- Steps: Context load → Demand capture [CHECKPOINT] → Config [CHECKPOINT] → Planning [CHECKPOINT] → Execution (with checkpoints per parallel decision and commit approval) → Review [CHECKPOINT]
+- What: Fast-track workflow — unified new/plan/do from a single prompt. Same quality guardrails, fewer steps. All decisions via quizzes.
+- Flags: `--auto-approve` (full autopilot from prompt to implementation)
+- When: Bug fixes, config tweaks, small features — anything that doesn't need extensive ceremony but still needs quality.
+- Steps: Capture demand (quiz) → Quick config (quiz) → Skill + security check → Quick plan (quiz) → Execute (same as /tyrex-do) → Update TYREX.md
 - Prerequisites: `.tyrex/` initialized
-- Next: Nothing — it runs the full cycle
+- Next: `/tyrex-review` (optional) or done
 
 **status:**
-- What: Shows a comprehensive dashboard: features, active tasks, project roadmap (planned/future features), health diagnostics (TYREX.md completeness, stale branches, context/skills coverage), documentation coverage, and actionable suggestions.
-- When: You want a full overview of where things stand — what's done, what's active, what's planned, and what needs attention.
+- What: Shows a comprehensive dashboard: features, active tasks, project roadmap, health diagnostics, documentation coverage, and actionable suggestions.
+- Flags: None
+- When: You want a full overview of where things stand.
 - Steps: Read state + roadmap + health checks → Display comprehensive summary
 - Prerequisites: `.tyrex/` initialized
 - Next: Whatever the status suggests
 
 **resume:**
 - What: Recovers session state from cursor.yml with minimal token usage. Picks up where you left off.
+- Flags: None
 - When: Starting a new agent session and wanting to continue previous work.
 - Steps: Read cursor.yml → Show resume summary → Continue from last state
 - Prerequisites: Previous Tyrex session with state saved
@@ -231,41 +240,47 @@ Use the reference below for each command:
 
 **settings:**
 - What: Shows and lets you modify Tyrex configuration (commit mode, branch mode, docs, quality, parallelism, git).
+- Flags: None
 - When: You want to change how Tyrex behaves.
-- Steps: Display current settings → Ask what to change → Save
+- Steps: Display current settings → Ask what to change (quiz) → Save
 - Prerequisites: `.tyrex/tyrex.yml` exists
 - Next: Changes apply from next demand onward
 
 **evolve:**
 - What: Updates TYREX.md with new patterns, hurdles, architecture decisions, or context discovered during work.
+- Flags: None
 - When: You learned something about the project that future sessions should know.
 - Steps: Describe discovery → Update TYREX.md → Commit
 - Prerequisites: `.tyrex/TYREX.md` exists
 - Next: Nothing specific
 
 **skills:**
-- What: Manages reusable skills — persona-based agent contexts (Role, Expertise, Guidelines, Patterns, Review Criteria). Can list, create, and sync skills across providers.
-- When: You want to improve implementation quality by giving agents specialized perspectives. Also auto-suggested during `/tyrex-new`.
-- Steps: (list) Scan `.tyrex/skills/` + providers → Display. (create) Gather role/expertise/guidelines → Generate skill file. (sync) Copy to all providers.
+- What: Manages reusable skills — persona-based agent contexts. Can list, create, and sync skills. DevSec skill is available as a built-in template.
+- Flags: `create [name]`, `sync`
+- When: You want to improve implementation quality by giving agents specialized perspectives.
+- Steps: (list) Scan `.tyrex/skills/` + providers → Display. (create) Gather role/expertise/guidelines (quiz) → Generate skill file. (sync) Copy to all providers.
 - Prerequisites: `.tyrex/` initialized
 - Next: Skills are automatically loaded during `/tyrex-do` when assigned to tasks
 
 **context:**
-- What: Ingests and manages project context (business rules, legacy system constraints, external docs) for better AI decisions. Supports free text, file paths, and URLs.
-- When: After `/tyrex-init` to add project background, during `/tyrex-new` for demand-specific context, or anytime you have new context to add.
-- Steps: Show existing context → Choose scope (project/demand) → Choose input type (text/file/URL) → Process and save → Confirm
+- What: Ingests and manages project context (business rules, legacy system constraints, external docs) for better AI decisions.
+- Flags: None
+- When: After `/tyrex-init` to add project background, during `/tyrex-new` for demand-specific context, or anytime.
+- Steps: Show existing context → Choose scope (quiz) → Choose input type (quiz) → Process and save → Confirm
 - Prerequisites: `.tyrex/` initialized (`/tyrex-init`)
 - Next: Context is automatically read by `/tyrex-plan` and `/tyrex-do`
 
 **readme:**
 - What: Generates a comprehensive README.md with architecture diagrams, setup instructions, and API overview.
+- Flags: None
 - When: Your project needs a README, or the existing one is outdated.
-- Steps: Deep project analysis → Generate README → Handle existing (replace/merge) → Commit
+- Steps: Deep project analysis → Generate README → Handle existing (quiz) → Commit
 - Prerequisites: A project with code to document
 - Next: Nothing specific
 
 **openapi:**
 - What: Analyzes your API endpoints and generates OpenAPI 3.1 documentation WITHOUT modifying source code.
+- Flags: None
 - When: Your project has an API and you need documentation for it.
 - Steps: Detect framework → Map endpoints (read-only) → Generate openapi.yaml + readable docs → Commit
 - Prerequisites: A project with HTTP endpoints
@@ -273,13 +288,19 @@ Use the reference below for each command:
 
 **wiki:**
 - What: Generates wiki-style documentation pages in docs/wiki/ covering architecture, getting started, domain areas, deployment, and troubleshooting.
+- Flags: None
 - When: You need internal documentation for the team.
-- Steps: Project analysis → Propose wiki structure → Generate pages → Handle existing → Commit
+- Steps: Project analysis → Propose wiki structure (quiz) → Generate pages → Handle existing (quiz) → Commit
 - Prerequisites: A project with code to document
 - Next: Nothing specific
 
+**handoff (DEPRECATED):**
+- What: Replaced by `/tyrex-quick --auto-approve`. See migration guide in the command file.
+- When: Never — use `/tyrex-quick --auto-approve` instead.
+
 **help:**
 - What: This command. Shows all available commands and suggests what to do next.
+- Flags: `<command-name>` for detailed help
 - When: You're not sure what command to use.
 - Steps: Display command list → Show workflow → Suggest next action
 - Prerequisites: None
@@ -291,3 +312,4 @@ Use the reference below for each command:
 - When showing details for a specific command, do NOT dump the entire command file — summarize for humans
 - The workflow diagram should be ASCII-compatible (no special Unicode beyond box-drawing)
 - If the user asks `/tyrex-help` with a command that doesn't exist, be helpful: suggest the closest match
+- ALWAYS mention flags for commands that have them — this is a key differentiator

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

@@ -11,19 +11,23 @@ You are the Tyrex Framework orchestrator. The user is starting a new implementat
 This command runs in **plan** mode. Set `agent_mode: "plan"` in `cursor.yml` as the FIRST action.
 You MUST NOT write source code. You may create/modify only `.tyrex/`, `docs/`, and configuration files.
 
+## 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: roadmap selection, clarification questions, context ingestion, skill selection, documentation configuration, branch configuration, and any other decision point.
+
 ## Behavior
 
 ### Step 0: Check roadmap
 Before asking the user to describe the demand:
 1. Read `.tyrex/roadmap.yml` (if exists) and check for `planned` features.
-2. If there are planned features in the roadmap, show them:
+2. If there are planned features, present interactive quiz:
    ```
-   Planned features in roadmap:
-     003-discuss-command        /tyrex-discuss — Structured technical discussions
-     004-review-knowledge-base  Skill evolution via /tyrex-review
-     005-research-command       /tyrex-research — AI-powered research
+   Start a planned feature or describe something new?
    
-   Start one of these? Or describe a new demand?
+     [ ] 003-discuss-command — Structured technical discussions
+     [ ] 004-review-knowledge — Skill evolution via /tyrex-review
+     [ ] 005-research-command — AI-powered research
+     [ ] Describe a new demand
    ```
 3. If the user picks a roadmap feature:
    - Use its description as the starting point for Step 1
@@ -36,73 +40,108 @@ Before asking the user to describe the demand:
 Ask the user: "Describe what you want to implement."
 Listen to their description. This is the WHAT and WHY.
 
-### Step 2: Clarification (max 5 questions)
-Analyze the description and ask UP TO 5 targeted clarification questions.
-Focus on:
-- Ambiguous requirements
-- Edge cases that would affect architecture
-- Scope boundaries (what's NOT included)
-Do NOT ask trivial questions. If the description is clear, skip this step.
+### Step 2: Clarification (max 5 questions, quiz format)
+Analyze the description and ask UP TO 5 targeted clarification questions **using interactive quizzes**:
+
+Example quiz formats for common clarifications:
+```
+What's the primary scope of this feature?
+  [ ] New API endpoints
+  [ ] Frontend/UI changes
+  [ ] Data model changes
+  [ ] Infrastructure/config
+  [ ] Cross-cutting (multiple areas)
+```
+
+```
+Who are the primary users of this feature?
+  [ ] End users (customers)
+  [ ] Internal team/admins
+  [ ] API consumers (developers)
+  [ ] System/automated processes
+```
+
+```
+What's the expected data volume/scale?
+  [ ] Low (< 1K records/requests)
+  [ ] Medium (1K-100K)
+  [ ] High (100K-1M)
+  [ ] Very high (> 1M)
+  [ ] Unknown / not applicable
+```
+
+Adapt quizzes to the specific demand context. If the description is clear and complete, skip this step entirely. Do NOT ask trivial questions.
 
 ### Step 3: Context Ingestion
-Before configuring or generating documentation, offer the user a chance to provide demand-specific context:
-
-1. Ask: "Do you have additional context for this demand? (legacy system constraints, business rules, external docs, related code, etc.) [y/N]"
-2. If yes: follow the `/tyrex-context add` flow with scope set to `demand`
-   - Accept free text, file paths, or URLs
-   - Store in `.tyrex/features/NNN-context.md`
-   - This context will inform documentation generation and planning
-3. If no: proceed to configuration
-4. Note: the user can always add more context later with `/tyrex-context`
+Present quiz to the user:
+```
+Do you have additional context for this demand?
+  [ ] Yes — I have docs, constraints, or business rules to share
+  [ ] No — proceed with what I described
+```
+
+If yes: follow the `/tyrex-context add` flow with scope set to `demand`
+- Accept free text, file paths, or URLs
+- Store in `.tyrex/features/NNN-context.md`
+- This context will inform documentation generation and planning
+Note: the user can always add more context later with `/tyrex-context`
 
 ### Step 3b: Skill Analysis & Suggestion
 After ingesting context, analyze the demand to identify relevant skills:
 
 1. **Identify expertise domains** from the demand description (e.g., "backend API" → backend-engineer, "database migration" → dba, "security audit" → security-engineer, "product requirements" → product-manager).
 2. **Scan `.tyrex/skills/`** for existing skills matching the identified domains.
-3. **If matching skills exist:**
-   - Show: "Skills that match this demand: [list with name + role]"
-   - Ask: "Use these skills? [Y/n]"
-   - Selected skills will be loaded during planning and execution.
-4. **If NO matching skills exist (or partial match):**
-   - Show: "No skills found for: [unmatched domains]. Skills improve implementation quality by providing specialized context."
-   - Ask: "Create skills for these areas now? [Y/n]"
-   - If yes: For each missing skill, ask for a brief role description, then generate the skill file in `.tyrex/skills/{name}.md` using:
+3. **ALWAYS check for DevSec skill:** If the demand touches any security-sensitive area (auth, data, APIs, user input, encryption), check for `devsec.md`:
+   - If doesn't exist: present quiz:
      ```
-     # Skill: {Name}
-     ## Role
-     ## Expertise
-     ## Guidelines
-     ## Patterns
-     ## Review Criteria
+     This demand has security implications but no DevSec skill is installed.
+       [ ] Create DevSec skill now from built-in template (Recommended)
+       [ ] Continue without DevSec skill
      ```
-   - If no: Continue without skills (they can be created later with `/tyrex-skills create`).
-5. **Record selected skills** — they will be included in the feature spec (Step 6) as a `Skills:` field.
-
-### Step 4: Demand configuration
-Read defaults from `.tyrex/tyrex.yml` and present configuration for THIS demand:
-
-Ask the user (suggest based on the nature of the demand):
-
-"Configuration for this demand:"
-
-1. **Documentation bundle:**
-   - [x] CHANGELOG (mandatory, always)
-   - [x] SPEC - Technical Specification (mandatory, always — generated per task during /tyrex-plan)
-   - [ ] SRS - Software Requirements Specification (suggest for features with clear functional requirements)
-   - [ ] PRD - Product Requirements Document (suggest if user provides product-level context, or offer to generate)
-   - [ ] ADR - Architecture Decision Record (suggest if there's an architecture choice)
-   - [ ] RFC - Technical proposal (suggest if it's a complex system)
-   - [ ] Wiki update
-   - [ ] Flow diagram
-   
-   "Use full documentation bundle? Or select individually? Or use defaults from tyrex.yml?"
-
-2. **Git:**
-   - Suggest branch name based on the description (e.g., `feat/oauth-system`)
-   - "Commits: approve or auto for this demand?"
-   
-3. "Use defaults from tyrex.yml for everything else? [Y/n]"
+   - If "Create": copy from `templates/skills/devsec.md` to `.tyrex/skills/devsec.md`
+4. **If matching skills exist:** present quiz:
+   ```
+   Skills that match this demand:
+     [x] backend-engineer — Senior Backend Engineer
+     [x] devsec — Security-First Developer
+     [ ] Don't use any skills
+   ```
+5. **If NO matching skills exist (or partial match):** present quiz:
+   ```
+   No skills found for: [unmatched domains].
+     [ ] Create skills for these areas now (Recommended)
+     [ ] Continue without skills
+   ```
+   - If yes: For each missing skill, ask for a brief role description, then generate the skill file
+6. **Record selected skills** — they will be included in the feature spec (Step 6) as a `Skills:` field.
+
+### Step 4: Demand configuration (interactive quiz)
+Read defaults from `.tyrex/tyrex.yml` and present configuration via quiz:
+
+```
+Documentation bundle for this demand:
+  [x] CHANGELOG (mandatory, always)
+  [x] SPEC per task (mandatory, always)
+  [ ] SRS — Software Requirements Specification
+  [ ] PRD — Product Requirements Document
+  [ ] ADR — Architecture Decision Record
+  [ ] RFC — Technical proposal
+  [ ] Wiki update
+  [ ] Flow diagram
+
+Defaults from tyrex.yml are pre-selected. Modify as needed.
+```
+
+```
+Git configuration:
+  Branch name: feat/[suggested-slug]
+    [ ] Accept suggested name
+    [ ] Custom name
+
+  Commit mode:
+    [ ] Approve each commit (from tyrex.yml default)
+    [ ] Auto-commit for this demand
+```
 
 ### Step 5: Documentation First
 Generate documentation BEFORE any code, in this order:
@@ -113,7 +152,13 @@ Generate documentation BEFORE any code, in this order:
 4. **RFC** (if configured): Create in `docs/rfcs/`. Present for review.
 5. **Diagrams** (if configured): Create in `docs/diagrams/`. Present for review.
 
-Wait for approval of all generated docs before proceeding.
+Present quiz for doc approval:
+```
+Generated documentation:
+  [ ] Approve all documents
+  [ ] Review and edit individual docs
+  [ ] Regenerate with feedback
+```
 
 Note: SPEC documents are NOT generated here — they are generated per task during `/tyrex-plan`.
 
@@ -128,8 +173,10 @@ Create `.tyrex/features/NNN-feature-name.md` with:
 - Status: `spec`
 
 ### Step 7: Create branch (if configured)
-If branch mode is `approve`: show suggested branch name, wait for approval.
-If branch mode is `auto`: create it automatically.
+Based on Step 4 quiz response:
+- If accepted suggested name: create branch automatically
+- If custom name: use the provided name
+- Always respect `approve`/`auto` mode from tyrex.yml
 
 ### Step 8: Update state
 Update `.tyrex/state/cursor.yml`:
@@ -142,15 +189,25 @@ Update `.tyrex/roadmap.yml`:
 - If this is a NEW feature not in the roadmap: add it to the roadmap with status `in_progress`
 - This ensures the roadmap always reflects reality
 
-### Step 9: Next step
+### Step 9: Auto-update TYREX.md
+If any macro documentation was generated (PRD, SRS, ADR), automatically update TYREX.md:
+- PRD → add business rules summary to `## Business Rules` section
+- SRS → add requirements summary to `## Requirements Summary` section
+- ADR → add decision to `## Architecture Decisions` table
+This keeps TYREX.md as the single living index of all project knowledge.
+
+### Step 10: Next step
 Tell the user: "Feature spec created. Run /tyrex-plan to plan the implementation."
 
 ## Important Rules
 - Feature spec MUST be under 50 lines
 - ALWAYS generate CHANGELOG entry (even if just "Feature X started")
+- ALWAYS use interactive quiz for ALL decisions — never open-ended questions for configuration
 - Documentation is generated BEFORE code — the human reviews docs first
 - SPEC is always mandatory — it is generated per task during `/tyrex-plan`, not here
 - SRS and PRD are suggested based on demand nature — not forced
 - Context ingestion happens BEFORE documentation to inform doc generation
+- ALWAYS check for DevSec skill when the demand has security implications
 - If the user says "use defaults" or "just go", use tyrex.yml defaults without asking each question
 - The user can override ANY default for this specific demand
+- When macro docs (ADR, PRD, SRS) are generated, ALWAYS update TYREX.md with summaries