Feature request: a built-in skill to wire a repo's context layout

Related to my earlier post about remapping the memory folder. Doing that setup by hand across several repos is the actual friction, and it's the same handful of steps every time. Right now, pointing a project at an existing docs layout (rather than `.fredrin/memory/`) means: flip the memory folder in project settings, hand-write an override paragraph into FREDRIN.md so Workers actually read the new paths, decide where concept docs go (or declare there are none), and make sure whatever agent-facing docs the repo already has name Fredrin as the issue tracker instead of GitHub Issues. Miss the FREDRIN.md paragraph and the setting is invisible to Workers — they keep writing to `.fredrin/memory/adr/` while the rest of the repo reads `docs/adr/`, and you end up with two homes for decisions and no error anywhere. I have four repos in this state, three of them still split, and the only thing telling me which is which is grepping FREDRIN.md. Fredrin already ships built-in skills, so this seems like a natural fit — something like `/fredrin-setup-context` that: 1. Detects what the repo already has (`CONTEXT.md`, `docs/adr/`, `AGENTS.md`/`CLAUDE.md`, an existing `.fredrin/memory/` bundle) and reports the current memory-folder setting. 2. Confirms the target layout with the human, then writes the FREDRIN.md override paragraph itself. 3. Covers the whole bundle explicitly — decisions, glossary, concepts — including letting you say "this repo has no concepts layer," so `context-classify`'s significant branch stops pointing at a directory that doesn't exist. 4. Flags the split case: ADRs already in `.fredrin/memory/adr/` and in `docs/adr/`, so you find out before it compounds. Bonus: if it could also migrate an existing `.fredrin/memory/` bundle into the target layout, adopting this on a repo that's already been running Workers would stop being a manual merge.