sauron-cli 1.2.0 → 1.3.0

package/OpenSpec-main/openspec/changes/simplify-skill-installation/proposal.md

@@ -0,0 +1,202 @@
+## Why
+
+Users have complained that there are too many skills/commands (currently 10) and new users feel overwhelmed. We want to simplify the default experience while preserving power-user capabilities and backwards compatibility.
+
+The goal: **get users to an "aha moment" in under a minute**.
+
+```text
+0:00  $ openspec init
+      ✓ Done. Run /opsx:propose "your idea"
+
+0:15  /opsx:propose "add user authentication"
+
+0:45  Agent creates proposal.md, design.md, tasks.md
+      "Whoa, it planned the whole thing for me" ← AHA
+
+1:00  /opsx:apply
+```
+
+Additionally, users have different preferences for how workflows are delivered (skills vs commands vs both), but this should be a power-user configuration, not something new users think about.
+
+## What Changes
+
+### 1. Smart Defaults Init
+
+Init auto-detects tools and asks for confirmation:
+
+```text
+$ openspec init
+
+Detected tools:
+  [x] Claude Code
+  [x] Cursor
+  [ ] Windsurf
+
+Press Enter to confirm, or Space to toggle
+
+Setting up OpenSpec...
+✓ Done
+
+Start your first change:
+  /opsx:propose "add dark mode"
+```
+
+**No prompts for profile or delivery.** Defaults are:
+- Profile: core
+- Delivery: both
+
+Power users can customize via `openspec config profile`.
+
+### 2. Tool Detection Behavior
+
+Init scans for existing tool directories (`.claude/`, `.cursor/`, etc.):
+- **Tools detected (interactive):** Shows pre-selected checkboxes, user confirms or adjusts
+- **No tools detected (interactive):** Prompts for full tool selection
+- **Non-interactive (CI):** Uses detected tools automatically, fails if none detected
+
+### 3. Fix Tool Selection UX
+
+Current behavior confuses users:
+- Tab to confirm (unexpected)
+
+New behavior:
+- **Space** to toggle selection
+- **Enter** to confirm
+
+### 4. Introduce Profiles
+
+Profiles define which workflows to install:
+
+- **core** (default): `propose`, `explore`, `apply`, `archive` (4 workflows)
+- **custom**: User-selected subset of workflows
+
+The `propose` workflow is new - it combines `new` + `ff` into a single command that creates a change and generates all artifacts.
+
+### 5. Improved Propose UX
+
+`/opsx:propose` should naturally onboard users by explaining what it's doing:
+
+```text
+I'll create a change with 3 artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+```
+
+This teaches as it goes - no separate onboarding needed for most users.
+
+### 6. Introduce Delivery Config
+
+Delivery controls how workflows are installed:
+
+- **both** (default): Skills and commands
+- **skills**: Skills only
+- **commands**: Commands only
+
+Stored in existing global config (`~/.config/openspec/config.json`). Not prompted during init.
+
+### 7. New CLI Commands
+
+```shell
+# Profile configuration (interactive picker for delivery + workflows)
+openspec config profile          # interactive picker
+openspec config profile core     # preset shortcut (core workflows, preserves delivery)
+```
+
+The interactive picker allows users to configure both delivery method and workflow selection in one place:
+
+```
+$ openspec config profile
+
+Delivery: [skills] [commands] [both]
+                              ^^^^^^
+
+Workflows: (space to toggle, enter to save)
+[x] propose
+[x] explore
+[x] apply
+[x] archive
+[ ] new
+[ ] ff
+[ ] continue
+[ ] verify
+[ ] sync
+[ ] bulk-archive
+[ ] onboard
+```
+
+### 8. Backwards Compatibility & Migration
+
+**Existing users keep their current setup.** When `openspec update` runs on a project with existing workflows and no `profile` in global config, it performs a one-time migration:
+
+1. Scans installed workflow files across all tool directories in the project
+2. Writes `profile: "custom"`, `delivery: "both"`, `workflows: [<detected>]` to global config
+3. Refreshes templates but does NOT add or remove any workflows
+4. Displays: "Migrated: custom profile with N existing workflows"
+
+After migration, subsequent `init` and `update` commands respect the migrated config.
+
+**Key behaviors:**
+- Existing users' workflows are preserved exactly as-is (no `propose` added automatically)
+- Both `init` (re-init) and `update` trigger migration on existing projects if no profile is set
+- `openspec init` on a **new** project (no existing workflows) uses global config, defaulting to `core`
+- `init` with a custom profile applies the configured workflows directly (no profile confirmation prompt)
+- `init` validates `--profile` values (`core` or `custom`) and errors on invalid input
+- Migration message mentions `propose` and suggests `openspec config profile core` to opt in
+- After migration, users can opt into `core` profile via `openspec config profile core`
+- Workflow templates conditionally reference only installed workflows in "next steps" guidance
+- Delivery changes are applied: switching to `skills` removes command files, switching to `commands` removes skill files
+- Re-running `init` applies delivery cleanup on existing projects (removes files that no longer match delivery)
+- `update` treats profile/delivery drift as update-required even when template versions are already current
+- `update` treats command-only installs as configured tools
+- All workflows remain available via custom profile
+
+## Capabilities
+
+### New Capabilities
+
+- `profiles`: Workflow profiles (core, custom), delivery preferences, global config storage, interactive picker
+- `propose-workflow`: Combined workflow that creates change + generates all artifacts
+
+### Modified Capabilities
+
+- `cli-init`: Smart defaults with tool auto-detection, profile-based skill/command generation
+- `cli-update`: Profile support, delivery changes, one-time migration for existing users
+
+## Impact
+
+### New Files
+- `src/core/templates/workflows/propose.ts` - New propose workflow template
+- `src/core/profiles.ts` - Profile definitions and logic
+- `src/core/available-tools.ts` - Detect what AI tools user has from directories
+
+### Modified Files
+- `src/core/init.ts` - Smart defaults, auto-detection, tool confirmation
+- `src/core/config.ts` - Add profile and delivery types
+- `src/core/global-config.ts` - Add profile, delivery, workflows fields to schema
+- `src/core/shared/skill-generation.ts` - Filter by profile, respect delivery
+- `src/core/shared/tool-detection.ts` - Update SKILL_NAMES and COMMAND_IDS to include propose
+- `src/commands/config.ts` - Add `profile` subcommand with interactive picker
+- `src/core/update.ts` - Add profile/delivery support, file deletion for delivery changes
+- `src/prompts/searchable-multi-select.ts` - Fix keybindings (space/enter)
+
+### Global Config Schema Extension
+```json
+// ~/.config/openspec/config.json (extends existing)
+{
+  "telemetry": { ... },          // existing
+  "featureFlags": { ... },       // existing
+  "profile": "core",             // NEW: core | custom
+  "delivery": "both",            // NEW: both | skills | commands
+  "workflows": ["propose", ...]  // NEW: only if profile: custom
+}
+```
+
+## Profiles Reference
+
+| Profile | Workflows | Description |
+|---------|-----------|-------------|
+| core | propose, explore, apply, archive | Streamlined flow for most users (default) |
+| custom | user-defined | Pick exactly what you need via `openspec config profile` |

package/OpenSpec-main/openspec/changes/simplify-skill-installation/specs/cli-init/spec.md

@@ -0,0 +1,199 @@
+## Purpose
+
+The init command SHALL provide a streamlined setup experience that auto-detects tools and uses smart defaults, getting users to their first change in under a minute.
+
+## MODIFIED Requirements
+
+### Requirement: Skill generation per tool (REPLACES fixed 9-skill mandate)
+The init command SHALL generate skills based on the active profile, not a fixed set.
+
+#### Scenario: Core profile skill generation
+- **WHEN** user runs init with profile `core`
+- **THEN** the system SHALL generate skills for workflows in CORE_WORKFLOWS constant: propose, explore, apply, archive
+- **THEN** the system SHALL NOT generate skills for workflows outside the profile
+
+#### Scenario: Custom profile skill generation
+- **WHEN** user runs init with profile `custom`
+- **THEN** the system SHALL generate skills only for workflows listed in config `workflows` array
+
+#### Scenario: Propose workflow included in skill templates
+- **WHEN** generating skills
+- **THEN** the system SHALL include the `propose` workflow as an available skill template
+
+### Requirement: Command generation per tool (REPLACES fixed 9-command mandate)
+The init command SHALL generate commands based on profile AND delivery settings.
+
+#### Scenario: Skills-only delivery
+- **WHEN** delivery is set to `skills`
+- **THEN** the system SHALL NOT generate any command files
+
+#### Scenario: Commands-only delivery
+- **WHEN** delivery is set to `commands`
+- **THEN** the system SHALL NOT generate any skill files
+
+#### Scenario: Both delivery
+- **WHEN** delivery is set to `both`
+- **THEN** the system SHALL generate both skill and command files for profile workflows
+
+#### Scenario: Propose workflow included in command templates
+- **WHEN** generating commands
+- **THEN** the system SHALL include the `propose` workflow as an available command template
+
+### Requirement: Tool auto-detection
+The init command SHALL detect installed AI tools by scanning for their configuration directories in the project root.
+
+#### Scenario: Detection from directories
+- **WHEN** scanning for tools
+- **THEN** the system SHALL check for directories matching each supported AI tool's configuration directory (e.g., `.claude/`, `.cursor/`, `.windsurf/`)
+- **THEN** all tools with a matching directory SHALL be returned as detected
+
+#### Scenario: Detection covers all supported tools
+- **WHEN** scanning for tools
+- **THEN** the system SHALL check for all tools defined in the supported tools configuration that have a configuration directory
+
+#### Scenario: No tools detected
+- **WHEN** no tool configuration directories exist in project root
+- **THEN** the system SHALL return an empty list of detected tools
+
+### Requirement: Smart defaults init flow
+The init command SHALL work with sensible defaults and tool confirmation, minimizing required user input.
+
+#### Scenario: Init with detected tools (interactive)
+- **WHEN** user runs `openspec init` interactively and tool directories are detected
+- **THEN** the system SHALL show detected tools pre-selected
+- **THEN** the system SHALL ask for confirmation (not full selection)
+- **THEN** the system SHALL use default profile (`core`) and delivery (`both`)
+
+#### Scenario: Init with no detected tools (interactive)
+- **WHEN** user runs `openspec init` interactively and no tool directories are detected
+- **THEN** the system SHALL prompt for tool selection
+- **THEN** the system SHALL use default profile (`core`) and delivery (`both`)
+
+#### Scenario: Non-interactive with detected tools
+- **WHEN** user runs `openspec init` non-interactively (e.g., in CI)
+- **AND** tool directories are detected
+- **THEN** the system SHALL use detected tools automatically without prompting
+- **THEN** the system SHALL use default profile and delivery
+
+#### Scenario: Non-interactive with no detected tools
+- **WHEN** user runs `openspec init` non-interactively
+- **AND** no tool directories are detected
+- **THEN** the system SHALL fail with exit code 1
+- **AND** display message to use `--tools` flag
+
+#### Scenario: Non-interactive with explicit tools
+- **WHEN** user runs `openspec init --tools claude`
+- **THEN** the system SHALL use specified tools
+- **THEN** the system SHALL NOT prompt for any input
+
+#### Scenario: Interactive with explicit tools
+- **WHEN** user runs `openspec init --tools claude` interactively
+- **THEN** the system SHALL use specified tools (ignoring auto-detection)
+- **THEN** the system SHALL NOT prompt for tool selection
+- **THEN** the system SHALL proceed with default profile and delivery
+
+#### Scenario: Init success message (propose installed)
+- **WHEN** init completes successfully
+- **AND** `propose` is in the active profile
+- **THEN** the system SHALL display a tool-appropriate success message
+- **THEN** for tools using colon syntax (Claude Code): "Start your first change: /opsx:propose \"your idea\""
+- **THEN** for tools using hyphen syntax (Cursor, others): "Start your first change: /opsx-propose \"your idea\""
+
+#### Scenario: Init success message (propose not installed, new installed)
+- **WHEN** init completes successfully
+- **AND** `propose` is NOT in the active profile
+- **AND** `new` is in the active profile
+- **THEN** for tools using colon syntax: "Start your first change: /opsx:new \"your idea\""
+- **THEN** for tools using hyphen syntax: "Start your first change: /opsx-new \"your idea\""
+
+#### Scenario: Init success message (neither propose nor new)
+- **WHEN** init completes successfully
+- **AND** neither `propose` nor `new` is in the active profile
+- **THEN** the system SHALL display: "Done. Run 'openspec config profile' to configure your workflows."
+
+### Requirement: Init performs migration on existing projects
+The init command SHALL perform one-time migration when re-initializing an existing project, using the same shared migration logic as the update command.
+
+#### Scenario: Re-init on existing project (no profile set)
+- **WHEN** user runs `openspec init` on a project with existing workflow files
+- **AND** global config does not contain a `profile` field
+- **THEN** the system SHALL perform one-time migration before proceeding (see `specs/cli-update/spec.md`)
+- **THEN** the system SHALL proceed with init using the migrated config
+
+#### Scenario: Init on new project (no existing workflows)
+- **WHEN** user runs `openspec init` on a project with no existing workflow files
+- **AND** global config does not contain a `profile` field
+- **THEN** the system SHALL NOT perform migration
+- **THEN** the system SHALL use `core` profile defaults
+
+### Requirement: Init respects global config
+The init command SHALL read and apply settings from global config.
+
+#### Scenario: User has profile preference
+- **WHEN** global config contains `profile: "custom"` with custom workflows
+- **THEN** init SHALL install custom profile workflows
+
+#### Scenario: User has delivery preference
+- **WHEN** global config contains `delivery: "skills"`
+- **THEN** init SHALL install only skill files, not commands
+
+#### Scenario: Override via flags
+- **WHEN** user runs `openspec init --profile core`
+- **THEN** the system SHALL use the flag value instead of config value
+- **THEN** the system SHALL NOT update the global config
+
+#### Scenario: Invalid profile override
+- **WHEN** user runs `openspec init --profile <invalid>`
+- **AND** `<invalid>` is not one of `core` or `custom`
+- **THEN** the system SHALL exit with code 1
+- **THEN** the system SHALL display a validation error listing allowed profile values
+
+### Requirement: Init applies configured profile without confirmation
+The init command SHALL apply the resolved profile (`--profile` override or global config) directly without prompting for confirmation.
+
+#### Scenario: Init with custom profile (interactive)
+- **WHEN** user runs `openspec init` interactively
+- **AND** global config specifies `profile: "custom"` with workflows
+- **THEN** the system SHALL proceed directly using the custom profile workflows
+- **AND** the system SHALL NOT show a profile confirmation prompt
+
+#### Scenario: Non-interactive init with custom profile
+- **WHEN** user runs `openspec init` non-interactively
+- **AND** global config specifies a custom profile
+- **THEN** the system SHALL proceed without confirmation
+
+#### Scenario: Init with core profile
+- **WHEN** user runs `openspec init` interactively
+- **AND** profile is `core` (default)
+- **THEN** the system SHALL proceed directly without a profile confirmation prompt
+
+### Requirement: Init preserves existing workflows
+The init command SHALL NOT remove workflows that are already installed, but SHALL respect delivery setting.
+
+#### Scenario: Existing custom installation
+- **WHEN** user has custom profile with extra workflows and runs `openspec init` with core profile
+- **THEN** the system SHALL NOT remove extra workflows
+- **THEN** the system SHALL regenerate core workflow files, overwriting existing content with latest templates
+
+#### Scenario: Init with different delivery setting
+- **WHEN** user runs `openspec init` on existing project
+- **AND** delivery setting differs from what's installed (e.g., was `both`, now `skills`)
+- **THEN** the system SHALL generate files matching current delivery setting
+- **THEN** the system SHALL delete files that don't match delivery (e.g., commands removed if `skills`)
+- **THEN** this applies to all workflows, including extras not in profile
+
+#### Scenario: Re-init applies delivery cleanup even when templates are current
+- **WHEN** user runs `openspec init` on an existing project
+- **AND** existing files are already on current template versions
+- **AND** delivery changed since the previous init
+- **THEN** the system SHALL still remove files that no longer match delivery
+- **THEN** for example, switching from `both` to `skills` SHALL remove generated command files
+
+### Requirement: Init tool confirmation UX
+The init command SHALL show detected tools and ask for confirmation.
+
+#### Scenario: Confirmation prompt
+- **WHEN** tools are detected in interactive mode
+- **THEN** the system SHALL display: "Detected: Claude Code, Cursor"
+- **THEN** the system SHALL show pre-selected checkboxes for confirmation
+- **THEN** the system SHALL allow user to deselect unwanted tools

package/OpenSpec-main/openspec/changes/simplify-skill-installation/specs/cli-update/spec.md

@@ -0,0 +1,177 @@
+## Purpose
+
+The update command SHALL apply global configuration changes to existing projects, syncing profile and delivery preferences without requiring full re-initialization.
+
+## MODIFIED Requirements
+
+### Requirement: Update respects global profile config
+The update command SHALL read global config and apply profile settings to the project.
+
+#### Scenario: Update adds missing workflows from config
+- **WHEN** user runs `openspec update`
+- **AND** global config specifies workflows not currently installed in the project
+- **THEN** the system SHALL generate skill/command files for missing workflows
+- **THEN** the system SHALL display: "Added: <workflow-names>"
+
+#### Scenario: Update refreshes existing workflows
+- **WHEN** user runs `openspec update`
+- **AND** workflows are already installed in the project
+- **THEN** the system SHALL refresh those workflow files with latest templates
+- **THEN** the system SHALL display: "Updated: <workflow-names>"
+
+#### Scenario: Update with no changes needed
+- **WHEN** user runs `openspec update`
+- **AND** installed workflows match global config
+- **AND** all templates are current
+- **AND** delivery setting matches installed files
+- **THEN** the system SHALL display: "Already up to date."
+
+#### Scenario: Profile or delivery drift with current templates
+- **WHEN** user runs `openspec update`
+- **AND** workflow templates are current for the installed skills
+- **AND** project files do not match current profile and/or delivery config
+- **THEN** the system SHALL treat this as an update-required state (not "Already up to date.")
+- **THEN** the system SHALL add/remove files to match current profile and delivery settings
+
+#### Scenario: Update summary output
+- **WHEN** update completes with changes
+- **THEN** the system SHALL display a summary:
+  - "Added: propose, explore" (new workflows installed)
+  - "Updated: apply, archive" (existing workflows refreshed)
+  - "Removed: 4 command files" (if delivery changed)
+- **THEN** the system SHALL list affected tools: "Tools: Claude Code, Cursor"
+
+### Requirement: Update respects delivery setting
+The update command SHALL add or remove files based on the delivery setting.
+
+#### Scenario: Delivery changed to skills-only
+- **WHEN** user runs `openspec update`
+- **AND** global config specifies `delivery: skills`
+- **AND** project has command files installed
+- **THEN** the system SHALL delete command files for workflows in the profile
+- **THEN** the system SHALL generate/update skill files only
+- **THEN** the system SHALL display: "Removed: <count> command files (delivery: skills)"
+
+#### Scenario: Delivery changed to commands-only
+- **WHEN** user runs `openspec update`
+- **AND** global config specifies `delivery: commands`
+- **AND** project has skill files installed
+- **THEN** the system SHALL delete skill directories for workflows in the profile
+- **THEN** the system SHALL generate/update command files only
+- **THEN** the system SHALL display: "Removed: <count> skill directories (delivery: commands)"
+
+#### Scenario: Delivery is both
+- **WHEN** user runs `openspec update`
+- **AND** global config specifies `delivery: both`
+- **THEN** the system SHALL generate/update both skill and command files
+
+### Requirement: Update detects configured tools from skills or commands
+The update command SHALL treat a tool as configured if it has either generated skill files or generated command files.
+
+#### Scenario: Commands-only installation
+- **WHEN** user runs `openspec update`
+- **AND** a tool has generated OpenSpec command files
+- **AND** that tool has no OpenSpec skill files (commands-only delivery)
+- **THEN** the tool SHALL still be treated as configured
+- **THEN** the system SHALL apply profile and delivery sync for that tool
+
+### Requirement: One-time migration for existing users
+The update command SHALL detect existing users (no `profile` in global config + existing workflows) and migrate them to `custom` profile before applying updates.
+
+#### Scenario: First update after upgrade (existing user)
+- **WHEN** user runs `openspec update`
+- **AND** global config does not contain a `profile` field
+- **AND** project has existing workflow files installed
+- **THEN** the system SHALL scan installed workflows across all tool directories in the project
+- **THEN** the system SHALL only match workflow names present in `ALL_WORKFLOWS` constant (ignoring user-created custom skills)
+- **THEN** the system SHALL take the union of detected workflow names across all tools
+- **THEN** the system SHALL write to global config: `profile: "custom"`, `delivery: "both"`, `workflows: [<detected>]`
+- **THEN** the system SHALL display: "Migrated: custom profile with <count> workflows (<workflow-names>)"
+- **THEN** the system SHALL display: "New in this version: /opsx:propose (combines new + ff). Try 'openspec config profile core' for the streamlined 4-workflow experience."
+- **THEN** the system SHALL proceed with normal update logic (using the migrated config)
+- **THEN** the result SHALL be template refresh only (no workflows added or removed)
+
+#### Scenario: Migration with partial workflows (user manually removed some)
+- **WHEN** user runs `openspec update`
+- **AND** global config does not contain a `profile` field
+- **AND** project has fewer than the original 10 workflows installed
+- **THEN** the system SHALL migrate with only the workflows that are actually present
+- **THEN** the migrated `workflows` array SHALL reflect the user's current state, not the original set
+
+#### Scenario: Migration with multiple tools having different workflow sets
+- **WHEN** user runs `openspec update`
+- **AND** project has multiple tools configured (e.g., Claude Code, Cursor)
+- **AND** different tools have different workflows installed
+- **THEN** the system SHALL take the union of all detected workflows across all tools
+- **THEN** the migrated `workflows` array SHALL include any workflow that exists in at least one tool
+
+#### Scenario: No migration needed (profile already set)
+- **WHEN** user runs `openspec update`
+- **AND** global config already contains a `profile` field
+- **THEN** the system SHALL NOT perform migration
+- **THEN** the system SHALL proceed with normal update logic using existing config
+
+#### Scenario: No migration needed (no existing workflows)
+- **WHEN** user runs `openspec update`
+- **AND** global config does not contain a `profile` field
+- **AND** project has no existing workflow files
+- **THEN** the system SHALL NOT perform migration
+- **THEN** the system SHALL use `core` profile defaults
+
+#### Scenario: Migration is idempotent
+- **WHEN** user runs `openspec update` multiple times
+- **THEN** migration SHALL only occur on the first run (when `profile` field is absent)
+- **THEN** subsequent runs SHALL use the existing global config without re-scanning
+
+#### Scenario: Non-interactive migration
+- **WHEN** user runs `openspec update` non-interactively (e.g., in CI)
+- **AND** migration is triggered
+- **THEN** the system SHALL perform migration without prompting
+- **THEN** the system SHALL display the migration summary to stdout
+
+### Requirement: Update detects new tool directories
+The update command SHALL notify the user if new AI tool directories are detected that aren't currently configured.
+
+#### Scenario: New tool directory detected
+- **WHEN** user runs `openspec update`
+- **AND** a new tool directory is detected (e.g., `.windsurf/` exists but Windsurf is not configured)
+- **THEN** the system SHALL display: "Detected new tool: Windsurf. Run 'openspec init' to add it."
+- **THEN** the system SHALL NOT automatically add the new tool
+- **THEN** the system SHALL proceed with update for currently configured tools only
+
+#### Scenario: Multiple new tool directories detected
+- **WHEN** user runs `openspec update`
+- **AND** multiple new tool directories are detected (e.g., `.github/` and `.windsurf/` exist but neither tool is configured)
+- **THEN** the system SHALL display one consolidated message listing all detected tools, for example: "Detected new tools: GitHub Copilot, Windsurf. Run 'openspec init' to add them."
+- **THEN** the system SHALL NOT automatically add any new tools
+- **THEN** the system SHALL proceed with update for currently configured tools only
+
+#### Scenario: No new tool directories
+- **WHEN** user runs `openspec update`
+- **AND** no new tool directories are detected
+- **THEN** the system SHALL NOT display any tool detection message
+
+### Requirement: Update requires an OpenSpec project
+The update command SHALL only run inside an initialized OpenSpec project.
+
+#### Scenario: Update outside a project
+- **WHEN** user runs `openspec update`
+- **AND** no `openspec/` directory exists in the current working directory
+- **THEN** the system SHALL display: "No OpenSpec project found. Run 'openspec init' to set up."
+- **THEN** the system SHALL exit with code 1
+
+### Requirement: Extra workflows synchronized to active profile
+The update command SHALL remove workflow files that are no longer selected in the current profile.
+
+#### Scenario: Deselected workflows from previous profile
+- **WHEN** user runs `openspec update`
+- **AND** project has workflows not in current profile (e.g., user switched from custom to core or deselected workflows via `openspec config profile`)
+- **THEN** the system SHALL delete skill and command workflow files for deselected workflows (respecting active delivery mode)
+- **THEN** the system SHALL keep only workflows currently selected in profile
+
+#### Scenario: Delivery change with extra workflows
+- **WHEN** user runs `openspec update`
+- **AND** delivery changed (e.g., `both` → `skills`)
+- **AND** project has extra workflows not in current profile
+- **THEN** the system SHALL delete files for extra workflows that match the removed delivery type
+- **THEN** for example: if switching to `skills`, all command files are deleted (including for extra workflows)