feat: add extract-feature and export-spec portability skills

Two new OpenSpec skills for porting features to sandboxed codebases:
- /opsx:extract-feature generates minimal, printable code recipes
- /opsx:export-spec generates compact specs for AI-assisted reimplementation
Both support cumulative dependency analysis across archived changes.

Includes first export of migrate-to-semantic-kernel in all three formats:
code recipe (~120 lines), portable spec (~40 lines), OpenSpec variant (~25 lines).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.claude/commands/opsx/extract-feature.md

@@ -0,0 +1,113 @@
+---
+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