.github/skills/speckit-workflows.deprecate/SKILL.md
Initiate a feature deprecation workflow with phased sunset process (warnings -> disabled -> removed).
npx skillsauth add pradeepmouli/lspeasy speckit-workflows.deprecateInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).
User input:
$ARGUMENTS
The text the user typed after /speckit.workflows.deprecate (or /speckit.deprecate) in the triggering message can be:
/speckit.workflows.deprecate <feature_number> "reason" - Direct with feature number/speckit.workflows.deprecate "reason" - Interactive (will prompt for feature selection)For example: /speckit.workflows.deprecate 014 "low usage and high maintenance burden" or /speckit.workflows.deprecate "low usage". Assume you always have it available even if $ARGUMENTS appears literally below.
DEPRECATION WORKFLOW - PHASED SUNSET
Given that input, do this:
Parse $ARGUMENTS to check if feature number is provided
If interactive mode (no feature number provided):
a. Run .specify/extensions/workflows/scripts/bash/create-deprecate.sh --list-features "$REASON" to get list of features
b. Parse the JSON output which contains: {"mode":"list","reason":"...","features":[...]}
c. Present the features list to the user in a clear, numbered format:
Which feature do you want to deprecate?
1. 001 - ability-for-new
2. 002 - ability-for-users
3. 014 - edit-profile-form
...
Type the feature number (e.g., 014) or respond with the line number (e.g., 3).
d. Wait for user response with their selection e. Extract the feature number from their response (handle both "014" and "3" formats) f. Continue to step 3 with the selected feature number
Normal workflow (feature number now available):
Run the script .specify/extensions/workflows/scripts/bash/create-deprecate.sh --json "$FEATURE_NUM" "$REASON" from repo root and parse its JSON output for DEPRECATE_ID, BRANCH_NAME, DEPRECATION_FILE, TASKS_FILE, DEPENDENCIES_FILE, FEATURE_NUM, FEATURE_NAME, and REASON. All file paths must be absolute.
IMPORTANT You must only ever run this script once per feature selection. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
Load .specify/extensions/workflows/templates/deprecate/deprecation-template.md to understand the 3-phase approach (Warnings -> Disabled -> Removed).
Read the DEPENDENCIES_FILE that was auto-generated by the scan-dependencies.sh script. This contains critical information about what code depends on the feature being deprecated.
Write a comprehensive deprecation plan to DEPRECATION_FILE using the template structure:
Report completion with Next Steps:
Deprecation workflow initialized
**Deprecation ID**: [DEPRECATE_ID]
**Feature**: specs/[FEATURE_NAME] (Feature [FEATURE_NUM])
**Reason**: [REASON]
**Branch**: [BRANCH_NAME]
**Deprecation Plan**: [DEPRECATION_FILE]
**Dependencies Scan**: [DEPENDENCIES_FILE]
**Next Steps:**
1. Review deprecation plan and dependency scan
2. Refine timeline for 3-phase sunset (typically 3-6 months)
3. Get stakeholder approvals (Product, Engineering, Support)
4. Run `/speckit.plan` to create detailed phase execution plans
5. Run `/speckit.tasks` to break down each phase into tasks
6. Run `/speckit.implement` to execute Phase 1 (warnings)
**Reminder**: 3-phase approach ensures smooth user migration
Important Notes:
Interactive Mode Usage Examples:
/speckit.workflows.deprecate "low usage" -> Shows feature list -> User selects -> Creates deprecation plan/speckit.workflows.deprecate 014 "low usage" -> Directly creates deprecation plan for feature 014tools
Use for ANY rename, file-move, or move-symbol refactor — especially rename-heavy work across multiple files. Claude Code's built-in LSP tool is READ-ONLY (find references, but no rename / file-move / move-symbol). Hand-editing those refactors silently misses re-exports, aliased imports, type-only imports, and {@link} doc references. This skill drives a real language server via the `lspeasy` CLI to apply a correct WorkspaceEdit that catches every reference. Trigger when the user asks to rename a function/class/variable/type project-wide, move a file and fix its importers, or pull a symbol out into another module.
tools
Documentation site for lspeasy Use when: You are building a browser-based LSP client, a WebSocket-backed language....
tools
Documentation site for lspeasy Use when: You are implementing a custom client layer and need the same validation....
tools
Use when working with lspeasy (client, core, server). Covers: lsp, language-server-protocol, lsp-client, language-client, jsonrpc, transport, lsp-server, language-server.