organize-changes

Preconditions

• Ordering law: Read skills/organize-file/SKILL.md before moving code; placement always defers to it (including LiveView lifecycle, describe/test clustering, and do not reorder clauses when that would change pattern match order).
• Single path: If the user gives one file path, only that file is in scope; merge-base comparison still applies.

Orchestrator edit policy (non-negotiable)

• The agent running this skill as orchestrator performs triage, git inspection, and launching workers only. It must not edit any *.ex / *.exs file (or otherwise apply reorders) in its own turn.
• Every path that needs organize work—including exactly one path—must be handled by a subagent (e.g. Cursor Task with generalPurpose or equivalent). There is no “small enough to do inline” exception.
• If triage yields zero paths, the orchestrator still does not edit sources; it finishes and replies to the user with exactly complete (see step 6).
• If a subagent cannot be spawned (tool unavailable, policy block, etc.), the orchestrator stops, replies with one line stating that blocker only, and does not substitute by editing files itself. (That reply is not complete.)

Global placement (workers — read before moving)

• Merge-base / git diff shows what changed, not where definitions belong. Never place or keep candidates together because they were added in one PR, sit next to each other in the patch, or call each other. That is wrong.
• Each candidate’s target location is its proper place in the whole file per organize-file: build the ordered list of every def / defp / defmacro (and every describe / test in tests) in that module, then put each candidate in the slot that list dictates—global order, same as if you were organizing the entire module from scratch.
• Candidates may land far apart. Example: several new defps belong in different alphabetical (or lifecycle) positions; do not leave them stacked above interpolate_variables (or any unrelated neighbor) just so “branch changes stay together.”
• Plain modules (defp) — mechanical merge, not a “candidate stack”: Per organize-file, private functions are last and alphabetically by function name. Take every defp name already in the file (including non-candidates), add each new/changed candidate name, then sort that whole set of names lexicographically (string order on the function atom). The file order of defp units must match that merged sorted list. If name interpolate_variables sorts between check_campaign_limit and lock_account_and_check_campaign_limit, then the interpolate_variables definition (non-candidate) must sit between those two in the source—never place lock_… and put_… directly under check_… and skip over names that belong in between. Same rule for any other gap in the sorted list.
• Call graph does not override sort order. put_campaign_limit_check calling lock_account… does not mean those two may be adjacent if other defp names sort between them.