extract-engine
Skill26 starsChanged 4 months agoMITView on GitHub
Use when extracting a host-app feature into a Rails engine. Do not change behavior in the same step. Trigger words: extract to engine, move feature, host coupling.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- apply-code-conventionsSkill
- apply-stack-conventionsSkill
- code-reviewSkill
- create-engine-installerSkill
- create-engineSkill
- document-engineSkill
- generate-api-collectionSkill
- implement-authorizationSkill
- implement-background-jobSkill
- implement-graphqlSkill
- implement-hotwireSkill
- load-contextSkill
- optimize-performanceSkill
- plan-testsSkill
- rails-featureSkill
- rails-maintenanceSkill
- rails-reviewSkill
- refactor-codeSkill
- release-engineSkill
- review-architectureSkill
- review-engineSkill
- review-migrationSkill
- security-checkSkill
- seed-databaseSkill
- setup-environmentSkill
- test-engineSkill
- test-serviceSkill
- upgrade-engineSkill
- version-apiSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Use this skill when the task is to move existing code out of a Rails app and into an engine.
- Distinctive: line 18
Prefer incremental extraction over big-bang rewrites.
- Distinctive: line 42
Add adapters or configuration seams for host-owned dependencies.
- Distinctive: line 44
Keep regression coverage green throughout each slice.
- Distinctive: line 82
Verify regression coverage still passes before proceeding:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Extract Engine
Use this skill when the task is to move existing code out of a Rails app and into an engine. Prefer incremental extraction over big-bang rewrites. Preserve behavior first, then improve design.
Quick Reference
| Phase | Focus |
| Prep | Identify bounded feature and host dependencies |
| Logic | Move stable domain logic (POROs, services) first |
| Seams | Add adapters/config for host dependencies |
| Web | Move controllers, routes, views last |
HARD-GATE
DO NOT extract and change behavior in the same step.
Extraction must preserve existing behavior; refactoring and improvements belong in a separate step after the move is complete and verified.Core Process
- Identify the bounded feature to extract — one coherent responsibility.
- List hard dependencies on the host app (models, services, config).
- Define the future engine boundary and host contract.
- Move stable domain logic first: POROs, services, value objects, policies, query objects. Delay direct host model references, authentication, route ownership, and asset integration.
- Add adapters or configuration seams for host-owned dependencies. Replace hardcoded host references with config values, adapter objects, or service interfaces.
- Move controllers, routes, views, or jobs only after seams are clear.
- Keep regression coverage green throughout each slice.
Each slice must have: one coherent responsibility, minimal new public API, passing regression tests, and a clear next step.
Extended Resources
Pitfalls
| Pitfall | What to do |
| Extracting too much at once | One bounded slice per step |
| Direct host references in engine | Use adapters or config |
| Behavior changes mixed with extraction | Preserve behavior first; refactor after |
| Circular dependencies introduced | Verify import graph before each slice |
| Implicit host contract | Explicitly document and test the host app contract |
Examples
First slice (move PORO, no host model yet):
mkdir -p my_engine/app/services/my_engine
mv app/services/pricing/calculator.rb my_engine/app/services/my_engine/pricing_calculator.rb# Before (in host app): module Pricing; class Calculator
# After (in engine):
module MyEngine
class PricingCalculator
def initialize(line_items)
@line_items = line_items
end
def total
@line_items.sum { |item| item.price * item.quantity }
end
end
endVerify regression coverage still passes before proceeding:
bundle exec rspec spec/services/pricing/ spec/requests/orders/Adapter for host dependency:
module MyEngine
def self.current_user_for(request)
config.current_user_provider.call(request)
end
end
# usage
OrderCreator.for_request(request) # resolves via MyEngine.current_user_for(request)Output Style
- Propose one small, bounded extraction slice at a time.
- Outline the files moving, the new boundaries, and the regression tests to run.
- Language — Must be in English unless explicitly requested otherwise.
Integration
| Skill | When to chain |
| create-engine | Engine structure, host contract, namespace design after extraction |
| test-engine | Dummy app, regression tests, integration verification |
| refactor-code | Behavior-preserving refactors before or after extraction slices |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

