The first focus area for Rfx and Sourceror will be Credo. Auto-refactoring for Credo suggestions is something that people seem to understand easily, and it's an opportunity that was highlighted by the Thinking Elixir hosts on today's podcast.

Beyond that, the code style of Rfx and Credo is similar. Each tool uses a single-module per Rfx-Operation/Credo-Check. Integration ought to be straightforward.

Here's a rough plan for prototype development:

1. add a meta-data option to each Rfx Operation, so that developers can specify the related Credo Check.

defmodule Rfx.Operation.Credo.MultiAlias do
  @tags %{
    credo_check: Credo.Check.Design.AliasUsage,
    another_tag: "whatever"
  }

  ...

end

2. add a Rfx.Operation.Catalog lookup function to return a list of Operations that match a meta-data tag Catlog.find_by_tag(credo_check: Credo.Check.Design.AliasUsage).

3. Work with @doorgan to write a handful of high-quality Credo Operations, with good test coverage.

4. write a minimal UI that has the following data-flow.
   4.1 Run credo analysis and return a JSON (or equivalent) data structure
   4.2 For each credo suggestion, look to see if there is a related Rfx Operation
   4.3 Display a list of credo suggestions, showing the related Rfx Operation if it is available
   4.4 Allow the user to select an Rfx Operation to apply (for CLI: use IO.gets(), for Web: click a button)

5. the priority of UI development will be:
   5.1 a very simple CLI, probably repl-style
   5.2 a Neovim plugin that uses the quick-fix list
   5.3 a Web UI

Probably I'll only have time to do 5.1. UI development will be done in the rfxi repo.

The overall goal here will be to write a fast and rough prototype that shows end-to-end flow, that helps to envision how all the pieces fit together, and to set the stage for production-quality integration in a follow-on phase.

Sound OK?