planflow-ai 1.1.2 → 1.1.3

package/.claude/commands/create-plan.md

@@ -25,18 +25,25 @@ DESCRIPTION:
   and tasks based on a discovery document or user input.
 
 USAGE:
-  /create-plan <discovery_document>
-  /create-plan <feature_description>
+  /create-plan [flags] <discovery_document>
+  /create-plan [flags] <feature_description>
   /create-plan -help
 
 ARGUMENTS:
   discovery_document   Path to discovery document (recommended)
   feature_description  Direct description of feature to plan (if no discovery)
 
+WORKFLOW FLAGS (optional):
+  -bugfix    Skip the discovery gate requirement. The bug report and user
+             description serve as plan input instead of a discovery document.
+             Use when fixing a bug where formal discovery is unnecessary.
+
+  Without a flag, a discovery document is required (standard behavior).
+
 EXAMPLES:
   /create-plan @flow/discovery/discovery_user_auth_v1.md
   /create-plan "Add dark mode toggle to settings page"
-  /create-plan @flow/contracts/api_contract.md
+  /create-plan -bugfix "Fix login timeout after 30 seconds of inactivity"
 
 OUTPUT:
   Creates: flow/plans/plan_<feature_name>_v<version>.md
@@ -75,7 +82,7 @@ RELATED COMMANDS:
 
 | Rule                     | Description                                              |
 | ------------------------ | -------------------------------------------------------- |
-| **Discovery Required**   | NEVER create a plan without a discovery document. If none exists, run `/discovery-plan` first. No exceptions. |
+| **Discovery Required**   | NEVER create a plan without a discovery document. If none exists, run `/discovery-plan` first. **Exception**: The `-bugfix` flag bypasses this requirement — the bug report serves as input. |
 | **No Auto-Chaining**     | NEVER auto-invoke /execute-plan - user must invoke it (unless autopilot ON) |
 | **Complete and Stop**    | After presenting results, STOP and wait for user (unless autopilot ON) |
 
@@ -83,6 +90,24 @@ RELATED COMMANDS:
 
 ## Instructions
 
+### Step 0: Parse Workflow Flag
+
+Check if the user input starts with a workflow flag:
+
+| Flag | Behavior Change |
+|------|----------------|
+| `-bugfix` | **Skip the discovery gate** (Step 2). The user's bug description + any diagnostic review serve as plan input. No discovery document required. The plan should focus on: root cause fix, regression prevention, and verification steps. |
+| (none) | Standard behavior — discovery document required |
+
+If a flag is found:
+1. Set the **workflow context** for this execution
+2. Remove the flag from the input (the rest is the user's prompt/reference)
+3. The `-bugfix` flag bypasses the discovery gate in Step 2
+
+If no flag is found: proceed with standard behavior (backward compatible).
+
+---
+
 ### Step 1: Validate Inputs
 
 | Input                | Required | Description                                        |
@@ -94,9 +119,13 @@ RELATED COMMANDS:
 
 ---
 
-### Step 2: Validate Discovery Phase Completion (HARD BLOCK)
+### Step 2: Validate Discovery Phase Completion (CONDITIONAL BLOCK)
+
+**A discovery document is REQUIRED before creating any plan — unless the `-bugfix` flag is set.**
+
+**If `-bugfix` flag is present**: Skip this step entirely. The user's bug description and any diagnostic review findings serve as plan input. Proceed directly to Step 3.
 
-**A discovery document is REQUIRED before creating any plan. No exceptions.**
+**If no `-bugfix` flag**:
 
 1. Check user input for a discovery document reference (`@flow/discovery/...`)
 2. If no reference provided, search `flow/discovery/` for a matching discovery document
@@ -114,7 +143,6 @@ RELATED COMMANDS:
 4. If a discovery document IS found: Proceed with plan creation using that document
 
 **Important**: NEVER read or reference files in `flow/archive/` - these are outdated.
-**Important**: NEVER create a plan without a discovery document. This rule has NO exceptions.
 
 ---
 

package/.claude/commands/discovery-plan.md

@@ -50,18 +50,28 @@ DESCRIPTION:
   before creating an implementation plan. This is the recommended first step.
 
 USAGE:
-  /discovery-plan <reference_document>
-  /discovery-plan <feature_description>
+  /discovery-plan [flags] <reference_document>
+  /discovery-plan [flags] <feature_description>
   /discovery-plan -help
 
 ARGUMENTS:
   reference_document   Contract, spec, or any document to analyze
   feature_description  Description of what you want to build
 
+WORKFLOW FLAGS (optional):
+  -security   Focus on threat model, attack surface, compliance needs,
+              and security requirements gathering.
+  -refactor   Focus on refactoring scope, target patterns, success criteria,
+              and what to preserve during restructuring.
+
+  Without a flag, performs standard feature requirements gathering.
+
 EXAMPLES:
   /discovery-plan @flow/contracts/api_contract.md
   /discovery-plan "User authentication with OAuth2"
   /discovery-plan @docs/feature-spec.md "Focus on the payment flow"
+  /discovery-plan -security "Review payment system security"
+  /discovery-plan -refactor "Restructure the API layer"
 
 OUTPUT:
   Creates: flow/discovery/discovery_<feature_name>_v<version>.md
@@ -108,6 +118,25 @@ These rules are mandatory. For detailed patterns and guidelines, see `.claude/re
 
 ## Instructions
 
+### Step 0: Parse Workflow Flag
+
+Check if the user input starts with a workflow flag:
+
+| Flag | Discovery Focus |
+|------|----------------|
+| `-security` | **Threat model and security requirements**. Questions focus on: auth flows, data sensitivity, encryption needs, access control, vulnerability surface, compliance requirements (SOC2, GDPR, PCI), and trust boundaries. Discovery document includes a "Threat Model" section and "Security Requirements" subsection. |
+| `-refactor` | **Refactoring scope and target patterns**. Questions focus on: current pain points, desired patterns, migration strategy, backward compatibility, what to preserve, success criteria, and acceptable breakage. Discovery document includes a "Baseline Assessment" section and "Target Architecture" subsection. |
+| (none) | Standard feature requirements gathering |
+
+If a flag is found:
+1. Set the **discovery focus** for this execution
+2. Remove the flag from the input (the rest is the user's prompt/reference)
+3. The focus affects the questions asked in Step 4 and the structure of the output document
+
+If no flag is found: proceed with standard discovery (backward compatible).
+
+---
+
 ### Step 1: Validate Inputs
 
 | Input                | Required | Description                                         |

package/.claude/commands/flow.md

@@ -24,17 +24,22 @@ The LLM pauses only at mandatory checkpoints (discovery Q&A, plan approval).
 DESCRIPTION:
   Enables or disables autopilot flow mode. When enabled, actionable requests
   automatically run the full plan-flow workflow without manual command invocation.
-  Supports 4 workflow types: feature (default), bugfix, refactor, security.
+  Supports auto-detect mode (default) and 4 locked workflow types.
 
 USAGE:
-  /flow -enable [type]   Enable autopilot mode with workflow type (default: feature)
+  /flow -enable          Enable autopilot with auto-detect (default)
+  /flow -enable [type]   Enable autopilot locked to a specific workflow type
   /flow -disable         Disable autopilot mode
   /flow -status          Show current autopilot state and workflow type
   /flow                  Same as -status
   /flow -help            Show this help
 
-WORKFLOW TYPES:
-  feature    New functionality, behavior changes (default)
+MODES:
+  auto       Auto-detect workflow type per input using signal analysis (default)
+             Each request is independently classified as feature/bugfix/refactor/security
+
+WORKFLOW TYPES (for locked mode):
+  feature    New functionality, behavior changes
              Steps: contracts → discovery → plan → execute → review → archive
   bugfix     Bug reports, error fixes, regression fixes
              Steps: review (diagnostic) → plan → execute → review (verification) → archive
@@ -44,7 +49,7 @@ WORKFLOW TYPES:
              Steps: review (audit) → discovery → plan → execute → review (verification) → archive
 
 BEHAVIOR WHEN ENABLED:
-  - Actionable requests → full flow using the active workflow type
+  - Actionable requests → full flow using auto-detected or locked workflow type
   - Trivial tasks (below workflow threshold) → executed directly, no flow
   - Questions/exploration → answered normally
   - Slash commands → run as normal
@@ -60,7 +65,13 @@ CONTEXT MANAGEMENT:
 
 STATE:
   Persisted in flow/.autopilot (survives session restarts)
-  File content determines workflow type (empty = feature)
+  File content: "auto" for auto-detect, or a specific type for locked mode
+
+EXAMPLES:
+  /flow -enable              # Auto-detect mode (recommended)
+  /flow -enable bugfix       # Lock to bugfix workflow only
+  /flow -enable security     # Lock to security workflow only
+  /flow -disable             # Turn off autopilot
 ```
 
 ---
@@ -72,23 +83,42 @@ STATE:
 
 ### When invoked with `-enable` or `-enable <type>`
 
-1. Parse the workflow type from the argument (default: `feature`)
-   - Valid types: `feature`, `bugfix`, `refactor`, `security`
+1. Parse the argument:
+   - No argument → **auto-detect mode** (default)
+   - Valid types: `feature`, `bugfix`, `refactor`, `security` → **locked mode**
    - If an invalid type is provided, show an error and list valid types
-2. Create the file `flow/.autopilot` with the workflow type as content
-   - For `feature` (default), write `feature` to the file
-   - For other types, write the type name (e.g., `bugfix`, `refactor`, `security`)
+2. Create the file `flow/.autopilot` with the mode as content:
+   - No argument: write `auto` to the file
+   - Specific type: write the type name (e.g., `bugfix`, `refactor`, `security`, `feature`)
 3. Confirm to the user:
 
+**For auto-detect mode:**
+
+```markdown
+Autopilot flow mode **enabled** (mode: **auto-detect**).
+
+From now on, each actionable request will be automatically classified:
+- Security signals → security workflow
+- Bug/error signals → bugfix workflow
+- Refactor signals → refactor workflow
+- Everything else → feature workflow
+
+Trivial tasks and questions are handled normally without the flow.
+
+Use `/flow -enable <type>` to lock to a specific workflow, `/flow -disable` to turn off, or `/flow -status` to check state.
+```
+
+**For locked mode:**
+
 ```markdown
-Autopilot flow mode **enabled** (workflow: **[type]**).
+Autopilot flow mode **enabled** (workflow: **[type]** — locked).
 
-From now on, actionable requests will automatically run the [type] workflow:
+From now on, ALL actionable requests will run the [type] workflow:
 [Show step sequence for the active workflow type]
 
 Trivial tasks and questions are handled normally without the flow.
 
-Use `/flow -enable <type>` to switch workflow, `/flow -disable` to turn off, or `/flow -status` to check state.
+Use `/flow -enable` to switch to auto-detect, `/flow -enable <type>` to switch workflow, or `/flow -disable` to turn off.
 ```
 
 ### When invoked with `-disable`
@@ -107,20 +137,28 @@ Commands will no longer auto-chain. Use individual slash commands as before:
 ### When invoked with `-status` or no arguments
 
 1. Check if `flow/.autopilot` exists
-2. If exists, read its content to determine active workflow type
+2. If exists, read its content to determine mode:
+   - Content is `auto` → auto-detect mode
+   - Content is `feature`, `bugfix`, `refactor`, or `security` → locked to that type
+   - Empty or unrecognized → treat as `auto`
 3. Check if `flow/state/autopilot-progress.md` exists — if so, read it to show workflow progress
 4. Report:
 
 ```markdown
 Autopilot flow mode: **[ENABLED/DISABLED]**
 
-[If enabled]:
-- **Workflow type**: [feature/bugfix/refactor/security]
-- **Steps**: [step sequence for active workflow]
-- Actionable requests will automatically run the [type] workflow.
+[If enabled — auto-detect]:
+- **Mode**: auto-detect
+- Each actionable request is classified independently (security > bugfix > refactor > feature)
+
+[If enabled — locked]:
+- **Mode**: locked — **[type]**
+- **Steps**: [step sequence for the locked workflow type]
+- ALL actionable requests will run the [type] workflow.
 
 [If enabled AND autopilot-progress.md exists]:
 - **Active workflow**: [feature name]
+- **Detected type**: [workflow type for current input]
 - **Progress**: Step [N] of [total] ([step name])
 - **Completed**: [list of done steps]
 - **Next**: [description of current/next step]
@@ -135,6 +173,6 @@ Autopilot flow mode: **[ENABLED/DISABLED]**
 | Rule | Description |
 | --- | --- |
 | **File-based state** | State is stored in `flow/.autopilot` - create to enable, delete to disable |
-| **Workflow type in file content** | The workflow type is written as file content (e.g., `feature`, `bugfix`, `refactor`, `security`) |
+| **Mode in file content** | File content is `auto` (auto-detect) or a specific type (`feature`, `bugfix`, `refactor`, `security`) for locked mode |
 | **No other side effects** | This command ONLY manages the marker file. It does not run any workflow steps. |
 | **Complete and stop** | After toggling state, STOP and wait for user input |

package/.claude/commands/review-code.md

@@ -23,18 +23,30 @@ DESCRIPTION:
   practices. Generates a detailed review document.
 
 USAGE:
-  /review-code [file_path] [--scope <staged|unstaged>]
+  /review-code [flags] [file_path] [--scope <staged|unstaged>]
   /review-code -help
 
 ARGUMENTS:
   file_path   Optional. Specific file to review (reviews all if not provided)
   --scope     Optional. "staged" or "unstaged" (reviews both if not provided)
 
+WORKFLOW FLAGS (optional):
+  -bugfix     Diagnostic review: focus on root cause analysis, broken behavior,
+              affected files. Use when investigating a bug.
+  -security   Security audit: focus on vulnerabilities, auth flows, data handling,
+              input validation. Use for security assessments.
+  -refactor   Baseline review: focus on current patterns, code smells, quality
+              metrics. Use before refactoring to document the current state.
+
+  Without a flag, performs a standard review (general quality, pattern compliance).
+
 EXAMPLES:
-  /review-code                              # Review all changes
+  /review-code                              # Standard review of all changes
   /review-code --scope staged               # Review only staged changes
   /review-code src/services/userService.ts  # Review specific file
-  /review-code src/api --scope unstaged     # Review unstaged in directory
+  /review-code -bugfix login timeout issue  # Diagnostic review for a bug
+  /review-code -security auth module        # Security audit of auth code
+  /review-code -refactor src/utils          # Baseline review before refactoring
 
 OUTPUT:
   Creates: flow/reviewed-code/<filename>.md
@@ -86,6 +98,26 @@ RELATED COMMANDS:
 
 ## Instructions
 
+### Step 0: Parse Workflow Flag
+
+Check if the user input starts with a workflow flag:
+
+| Flag | Review Variant | Focus |
+|------|---------------|-------|
+| `-bugfix` | Diagnostic | Diagnose root cause, identify broken behavior, affected files, reproduction steps |
+| `-security` | Security audit | Vulnerabilities, auth flows, data handling, input validation, secret exposure |
+| `-refactor` | Baseline | Current patterns, code smells, quality metrics, complexity hotspots |
+| (none) | Standard | General quality, pattern compliance |
+
+If a flag is found:
+1. Set the **review variant** for this execution
+2. Remove the flag from the input (the rest is the user's prompt/file path)
+3. The review variant affects the focus areas in Step 3
+
+If no flag is found: proceed with standard review (backward compatible).
+
+---
+
 ### Step 1: Validate Inputs
 
 | Input | Required | Description |
@@ -107,6 +139,12 @@ The skill will:
 4. Compare patterns against existing code
 5. Generate review document
 
+**Review Variant Focus** (from Step 0):
+- **Diagnostic** (`-bugfix`): Prioritize identifying what's broken, root cause analysis, affected code paths, and potential regression points. The review output should include a "Root Cause Analysis" section.
+- **Security audit** (`-security`): Prioritize OWASP top 10 checks, auth flow analysis, data handling, input validation, secret exposure, and dependency vulnerabilities. The review output should include a "Security Findings" section with severity ratings.
+- **Baseline** (`-refactor`): Prioritize documenting current patterns, code smells, complexity metrics, duplication, and coupling. The review output should include a "Baseline Metrics" section for before/after comparison.
+- **Standard** (no flag): General quality, pattern compliance, potential bugs, performance concerns.
+
 **Confidence-Based Filtering Rules**:
 - Each finding must include a **Confidence** percentage (e.g., 85%)
 - **Only include findings with >80% confidence** in the main Findings section

package/.claude/resources/core/autopilot-mode.md

@@ -14,14 +14,21 @@ When `flow/.autopilot` exists, this rule is active. It automatically orchestrate
 
 ---
 
-## Workflow Type Detection
+## Workflow Mode Detection
 
-After confirming autopilot is ON, read the **content** of `flow/.autopilot` to determine the active workflow type:
+After confirming autopilot is ON, read the **content** of `flow/.autopilot` to determine the mode:
 
-- File contains `bugfix` → **bugfix** workflow
-- File contains `refactor` → **refactor** workflow
-- File contains `security` → **security** workflow
-- File is empty, contains `feature`, or any unrecognized value → **feature** workflow (default)
+### Auto-Detect Mode
+- File contains `auto`, is empty, or contains any unrecognized value → **auto-detect mode**
+- In auto-detect mode, each actionable input is independently classified using the signal table below
+- The detected workflow type is used for that specific input only
+
+### Locked Mode
+- File contains `feature` → **locked to feature** workflow
+- File contains `bugfix` → **locked to bugfix** workflow
+- File contains `refactor` → **locked to refactor** workflow
+- File contains `security` → **locked to security** workflow
+- In locked mode, ALL actionable inputs use the locked workflow type regardless of input signals
 
 See `.claude/resources/core/orchestration-workflows.md` [COR-OW-1] for full workflow definitions.
 
@@ -46,7 +53,7 @@ When autopilot is ON, classify every new user input before acting:
 **Action**: Execute directly. Do NOT trigger the flow.
 
 ### Category 4: Actionable Request
-**Signals**: Complexity meets or exceeds the active workflow's threshold. Classify by input signals:
+**Signals**: Complexity meets or exceeds the workflow's threshold. Classify by input signals:
 
 | Priority | Workflow | Input Signals | Threshold |
 |----------|----------|---------------|-----------|
@@ -55,7 +62,11 @@ When autopilot is ON, classify every new user input before acting:
 | 3 | **refactor** | "refactor", "restructure", "clean up", "tech debt", "migrate", "reorganize" | 3+ |
 | 4 | **feature** | "add", "create", "implement", "build", "integrate" (default) | 3+ |
 
-**Action**: Trigger the flow using the **active workflow type** (from `.autopilot` file). If the input signals suggest a different workflow type than what's active, use the active type — the user chose it deliberately.
+**Action — depends on mode:**
+
+**Auto-detect mode** (`auto`): Classify the input using the signal table above (priority order: security > bugfix > refactor > feature). Use the **detected workflow type** for this specific input. Each input is classified independently.
+
+**Locked mode** (specific type): Trigger the flow using the **locked workflow type** (from `.autopilot` file). Ignore input signals — the user chose this type deliberately.
 
 ### When Uncertain
 If the input doesn't clearly fit a category, use the `AskUserQuestion` tool:

package/.claude/resources/core/orchestration-workflows.md

@@ -131,9 +131,9 @@ The active workflow type is stored in `flow/.autopilot`. If the file is empty or
 
 ## COR-OW-2: Workflow Selection Guide
 
-### Automatic Selection (Autopilot Mode)
+### Auto-Detect Mode (Default)
 
-When autopilot is ON, the active workflow type determines how the flow runs. The LLM classifies user input using the **input signals** listed above.
+When autopilot is ON with auto-detect mode (`flow/.autopilot` contains `auto`), each actionable input is independently classified using input signals:
 
 **Priority order** (when signals overlap):
 1. **security** — if input mentions security/vulnerability/auth concepts
@@ -141,13 +141,20 @@ When autopilot is ON, the active workflow type determines how the flow runs. The
 3. **refactor** — if input focuses on restructuring without new features
 4. **feature** — default for everything else
 
-### Manual Selection
+### Locked Mode
 
-Users set the workflow type via:
-- `/flow -enable feature` (default)
-- `/flow -enable bugfix`
-- `/flow -enable refactor`
-- `/flow -enable security`
+Users can lock to a specific workflow type:
+- `/flow -enable feature` — lock to feature workflow
+- `/flow -enable bugfix` — lock to bugfix workflow
+- `/flow -enable refactor` — lock to refactor workflow
+- `/flow -enable security` — lock to security workflow
+
+When locked, ALL actionable inputs use the locked type regardless of signals.
+
+### Default Behavior
+
+- `/flow -enable` (no type) → auto-detect mode (recommended)
+- `/flow -enable <type>` → locked mode
 
 ### Complexity Thresholds
 
@@ -175,4 +182,6 @@ Some workflows use `/review-code` with different focus areas:
 | Security verification | Check for new vulnerabilities, verify fixes | security (step 5) |
 | Standard | General quality, pattern compliance | feature (step 5) |
 
-The variant is communicated via the review scope/context, not a separate command. The LLM adjusts its review focus based on the active workflow step.
+The variant can be set via:
+1. **Autopilot context**: The LLM adjusts focus based on the active workflow step
+2. **Command flag**: `/review-code -bugfix`, `/review-code -security`, `/review-code -refactor` (see command help for details)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "planflow-ai",
-  "version": "1.1.2",
+  "version": "1.1.3",
   "description": "Structured AI-assisted development workflows for discovery, planning, execution, code reviews, and testing",
   "type": "module",
   "main": "dist/cli/index.js",

package/rules/core/autopilot-mode.mdc

@@ -19,14 +19,21 @@ When `flow/.autopilot` exists, this rule is active. It automatically orchestrate
 
 ---
 
-## Workflow Type Detection
+## Workflow Mode Detection
 
-After confirming autopilot is ON, read the **content** of `flow/.autopilot` to determine the active workflow type:
+After confirming autopilot is ON, read the **content** of `flow/.autopilot` to determine the mode:
 
-- File contains `bugfix` → **bugfix** workflow
-- File contains `refactor` → **refactor** workflow
-- File contains `security` → **security** workflow
-- File is empty, contains `feature`, or any unrecognized value → **feature** workflow (default)
+### Auto-Detect Mode
+- File contains `auto`, is empty, or contains any unrecognized value → **auto-detect mode**
+- In auto-detect mode, each actionable input is independently classified using the signal table below
+- The detected workflow type is used for that specific input only
+
+### Locked Mode
+- File contains `feature` → **locked to feature** workflow
+- File contains `bugfix` → **locked to bugfix** workflow
+- File contains `refactor` → **locked to refactor** workflow
+- File contains `security` → **locked to security** workflow
+- In locked mode, ALL actionable inputs use the locked workflow type regardless of input signals
 
 See `rules/core/orchestration-workflows.mdc` [COR-OW-1] for full workflow definitions.
 
@@ -58,7 +65,11 @@ When autopilot is ON, classify every new user input before acting:
 | 3 | **refactor** | "refactor", "restructure", "clean up", "tech debt", "migrate", "reorganize" | 3+ |
 | 4 | **feature** | "add", "create", "implement", "build", "integrate" (default) | 3+ |
 
-**Action**: Trigger the flow using the **active workflow type** (from `.autopilot` file). If the input signals suggest a different workflow type than what's active, use the active type — the user chose it deliberately.
+**Action — depends on mode:**
+
+**Auto-detect mode** (`auto`): Classify the input using the signal table above (priority order: security > bugfix > refactor > feature). Use the **detected workflow type** for this specific input. Each input is classified independently.
+
+**Locked mode** (specific type): Trigger the flow using the **locked workflow type** (from `.autopilot` file). Ignore input signals — the user chose this type deliberately.
 
 ### When Uncertain
 

package/rules/core/orchestration-workflows.mdc

@@ -114,7 +114,9 @@ The active workflow type is stored in `flow/.autopilot`. If the file is empty or
 
 ## COR-OW-2: Workflow Selection Guide
 
-### Automatic Selection
+### Auto-Detect Mode (Default)
+
+When autopilot is ON with auto-detect mode (`flow/.autopilot` contains `auto`), each actionable input is independently classified using input signals:
 
 **Priority order** (when signals overlap):
 1. **security** — security/vulnerability/auth concepts
@@ -122,12 +124,20 @@ The active workflow type is stored in `flow/.autopilot`. If the file is empty or
 3. **refactor** — restructuring without new features
 4. **feature** — default
 
-### Manual Selection
+### Locked Mode
+
+Users can lock to a specific workflow type:
+- `/flow -enable feature` — lock to feature workflow
+- `/flow -enable bugfix` — lock to bugfix workflow
+- `/flow -enable refactor` — lock to refactor workflow
+- `/flow -enable security` — lock to security workflow
+
+When locked, ALL actionable inputs use the locked type regardless of signals.
+
+### Default Behavior
 
-- `/flow -enable feature` (default)
-- `/flow -enable bugfix`
-- `/flow -enable refactor`
-- `/flow -enable security`
+- `/flow -enable` (no type) → auto-detect mode (recommended)
+- `/flow -enable <type>` → locked mode
 
 ### Complexity Thresholds
 

package/skills/plan-flow/flow/SKILL.md

@@ -1,27 +1,56 @@
 ---
 name: flow
-description: Toggle autopilot flow mode - automatically orchestrates discovery, planning, execution, and review for feature requests
+description: Toggle autopilot flow mode - automatically orchestrates discovery, planning, execution, and review with auto-detect or locked workflow types
 metadata: {"openclaw":{"requires":{"bins":["git"]}}}
 user-invocable: true
 ---
 
 # Flow: Autopilot Mode Toggle
 
-Enables or disables autopilot flow mode. When enabled, feature requests automatically run the full plan-flow workflow without manual command invocation.
+Enables or disables autopilot flow mode. When enabled, actionable requests automatically run the full plan-flow workflow without manual command invocation.
 
 ## Usage
 
 ```
-/flow -enable       Enable autopilot mode
-/flow -disable      Disable autopilot mode
-/flow -status       Show current state
-/flow               Same as -status
-/flow -help         Show help
+/flow -enable            Enable autopilot with auto-detect (default)
+/flow -enable [type]     Enable autopilot locked to a specific workflow type
+/flow -disable           Disable autopilot mode
+/flow -status            Show current state and mode
+/flow                    Same as -status
+/flow -help              Show help
 ```
 
+## Modes
+
+### Auto-Detect (Default)
+
+`/flow -enable` activates autopilot with auto-detect mode. Each actionable request is independently classified using signal analysis:
+
+| Priority | Workflow | Input Signals |
+|----------|----------|---------------|
+| 1 | **security** | "security", "vulnerability", "auth", "XSS", "injection", "encrypt", "permissions" |
+| 2 | **bugfix** | "fix", "bug", "broken", "error", "regression", "crash", "not working" |
+| 3 | **refactor** | "refactor", "restructure", "clean up", "tech debt", "migrate", "reorganize" |
+| 4 | **feature** | everything else (default) |
+
+### Locked Mode
+
+`/flow -enable <type>` locks autopilot to a specific workflow type. ALL actionable inputs use the locked type regardless of signals.
+
+Valid types: `feature`, `bugfix`, `refactor`, `security`
+
+## Workflow Types
+
+| Type | When to Use | Steps |
+|------|-------------|-------|
+| feature | New functionality, behavior changes | contracts → discovery → plan → execute → review → archive |
+| bugfix | Bug reports, error fixes | review (diagnostic) → plan → execute → review (verification) → archive |
+| refactor | Code restructuring, tech debt | review (baseline) → discovery → plan → execute → review (comparison) → archive |
+| security | Vulnerability fixes, auth changes | review (audit) → discovery → plan → execute → review (verification) → archive |
+
 ## How It Works
 
-**State**: Stored in `flow/.autopilot` (empty marker file). Create to enable, delete to disable.
+**State**: Stored in `flow/.autopilot`. File content: `auto` for auto-detect, or a specific type for locked mode.
 
 ### When Enabled
 
@@ -31,51 +60,47 @@ Every user input is classified:
 |----------|---------|--------|
 | Slash Command | Starts with `/` | Run normally, no flow |
 | Question/Exploration | Asking about code, explanations | Answer normally, no flow |
-| Trivial Task | Single-file, obvious fix, complexity 0-2 | Execute directly, no flow |
-| Feature Request | New functionality, multi-file, complexity 3+ | **Trigger full flow** |
-
-### Full Flow (6 Steps)
-
-1. **Check Contracts** → Look for relevant integration contracts
-2. **Discovery** (PAUSE) → Gather requirements, ask user questions
-3. **Create Plan** (PAUSE) → Create implementation plan, get user approval
-4. **Execute Plan** → Implement phases with complexity-based grouping
-5. **Review Code** → Review all uncommitted changes
-6. **Archive** → Move artifacts to `flow/archive/`, prompt for cleanup
+| Trivial Task | Single-file, obvious fix, below threshold | Execute directly, no flow |
+| Actionable Request | Meets complexity threshold | **Trigger flow** (auto-detected or locked type) |
 
 ### Mandatory Checkpoints
 
 Even in autopilot, these always pause for user input:
 
-| Checkpoint | When | Why |
-|------------|------|-----|
-| Discovery Q&A | Step 2 | User must answer requirements questions |
-| Discovery Gate | Step 2→3 | Discovery document must exist before plan. No exceptions. |
-| Plan Approval | Step 3 | User must approve plan before execution |
+| Checkpoint | Workflows | Why |
+|------------|-----------|-----|
+| Discovery Q&A | feature, refactor, security | User must answer requirements questions |
+| Plan Approval | all workflows | User must approve plan before execution |
+| Security Review | security only | User must approve post-execution security review |
 
 ### When Disabled
 
 Commands run individually as normal:
-`/discovery` → `/create-plan` → `/execute-plan` → `/review-code`
+`/discovery-plan` → `/create-plan` → `/execute-plan` → `/review-code`
 
 ## Toggle Commands
 
 ### Enable
-1. Create `flow/.autopilot` (empty file)
-2. Confirm to user that autopilot is enabled
+1. Parse argument: no type → write `auto`, specific type → write the type name
+2. Create `flow/.autopilot` with the mode as content
+3. Confirm to user with mode and workflow details
 
 ### Disable
 1. Delete `flow/.autopilot`
-2. Confirm to user that autopilot is disabled
+2. Delete `flow/state/autopilot-progress.md` (if exists)
+3. Confirm to user that autopilot is disabled
 
 ### Status
 1. Check if `flow/.autopilot` exists
-2. Report current state (ENABLED/DISABLED)
+2. Read content to determine mode (`auto` vs locked type)
+3. Check `flow/state/autopilot-progress.md` for active workflow progress
+4. Report current state
 
 ## Critical Rules
 
 | Rule | Description |
 |------|-------------|
 | **File-based state** | State is stored in `flow/.autopilot` - create to enable, delete to disable |
+| **Mode in file content** | File content is `auto` (auto-detect) or a specific type for locked mode |
 | **No other side effects** | This command ONLY manages the marker file. It does not run any workflow steps. |
 | **Complete and stop** | After toggling state, STOP and wait for user input |