Share Code

Refactor one bounded folder to discover real shared-code opportunities and bug-revealing seams without changing intended behavior.

Quick start

Identify the target folder. If none is named, pick smartly instead of asking by running candidates-folder-refactor (or reading its latest log) and selecting the highest-signal bounded candidate with duplicate/reuse evidence, real callers, and non-generated source files; do not start at repo root.
Inspect git status --short --branch, repo instructions, existing maps (codebase-map-understand.md when present), folder tree, imports/callers, package/module boundaries, and related tests only when they already exist or the user asked for test work. Use codebase map to spot cross-file reuse/caller leads, then prove duplicates in source.
Baseline behavior before edits with the lightest existing validation seam (typecheck/build/lint/smoke/related tests). Do not add tests just to enable a refactor unless the user explicitly asked for tests or a behavior bug needs a focused assertion.
Use skill-folder-refactor mechanics for safe move-only slices, then run a reuse-and-bug pass over the new seams.