d3300c7db9
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>
114 lines
4.8 KiB
Markdown
114 lines
4.8 KiB
Markdown
---
|
|
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
|