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

name, description, category, tags

name	description	category	tags
OPSX: Extract Feature	Extract a feature into a minimal, printable code recipe for manual reimplementation	Workflow	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