---
name: "OPSX: Extract Feature"
description: Extract a feature into a minimal, printable code recipe for manual reimplementation
category: Workflow
tags: [workflow, portability, experimental]
---

Extract a feature into a minimal, printable code recipe for manual reimplementation.

Generates a markdown document with:
- Package dependencies
- Ordered code blocks (no comments, no boilerplate)
- Clear markers for generic vs domain-specific code

Print it, take it to the sandbox, type it in.

---

**Input**: The argument after `/opsx:extract-feature` is a change name (active or archived), a git commit range, or a list of files. If omitted, prompt for selection.

**Steps**

1. **Identify the source feature**

   If a change name is provided:
   - Check active changes: `openspec list --json`
   - Check archive: look in `openspec/changes/archive/` for directories ending with the name
   - If found, read its artifacts: `proposal.md`, `design.md`, `tasks.md`

   If no name provided:
   - Run `openspec list --json` and list archived changes
   - Use **AskUserQuestion tool** to let the user select

   If a file list or commit range is provided instead:
   - Read those files directly
   - Identify the feature from the code

2. **Analyze dependency chain (cumulative mode)**

   Features often build on each other. Before generating the recipe, determine
   what the target feature depends on.

   a. Read all archived change proposals in `openspec/changes/archive/` (sorted by date).
   b. Build a dependency graph: what does the target require? What's superseded?
   c. Ask the user:
      > "This feature depends on earlier changes. How should I scope the recipe?"
      > 1. **Cumulative** — include all foundation code (recommended for fresh codebase)
      > 2. **Delta only** — just this change's code (target already has foundation)
      > 3. **Custom** — pick which dependencies to include

   d. In cumulative mode: merge the chain, skip superseded code, use final file versions.
   e. In delta mode: include only the selected change's code.

3. **Analyze the feature scope**

   From the change artifacts and/or code (across full dependency chain if cumulative), determine:
   - Which files were created or modified
   - What NuGet/npm packages were added
   - What the dependency order is (e.g., models before controllers)
   - What is generic infrastructure vs domain-specific logic

   Read all relevant source files. Always read the final current version of each file.

4. **Generate the code recipe**

   Create a markdown document with these sections, in this order:

   **Header**: Feature name, source change, date

   **Prerequisites**: Package references with exact versions

   **Steps**: Ordered by dependency. Each step contains:
   - Step number and action (e.g., "New file", "Add to existing file", "Modify")
   - Target path (relative, adaptable)
   - Namespace placeholder: `__YOUR_NAMESPACE__` where the target project namespace goes
   - **Code block**: The actual code, stripped of:
     - All comments (// and /* */ and /// XML docs)
     - Redundant blank lines
     - Verbose variable names that can be shortened
     - Any code not directly related to the feature
   - If the step modifies an existing file: show only the code to add, with a brief marker for insertion point (e.g., "Add after AddControllers()")

   **Domain-Specific Sections**: Clearly marked with `// ADAPT:` prefix explaining what to change for the target domain

5. **Optimize for retyping**

   Review the generated document and:
   - Merge small files if they can be combined
   - Remove any using statements that the IDE will auto-add
   - Shorten any unnecessarily verbose code
   - Ensure no step exceeds ~40 lines (split if needed)
   - Add line counts per step so the user can estimate effort
   - Total the overall line count at the top

6. **Write the output**

   Save to: `openspec/exports/<change-name>-recipe.md`

   Also display the full content so the user can review it immediately.

**Guardrails**
- Never include comments in code blocks — the goal is minimum keystrokes
- Always read the actual current source files, not just the change artifacts
- Preserve compilation order: models -> services -> controllers -> DI registration
- Mark domain-specific code clearly so the user knows what to adapt vs copy verbatim
- Keep each step self-contained — the user may take breaks between steps
- If a feature spans more than ~200 lines of stripped code, warn the user and suggest using `/opsx:export-spec` instead
- Output must be valid markdown that renders well when printed
- When in cumulative mode, skip superseded code — always use the latest version of each file
- In the output header, show which changes were included and which were skipped
- If a dependency chain is long (4+ changes), suggest `/opsx:export-spec` as more efficient

ARGUMENTS:  based on the above