Best way to adopt this on an existing PARA vault where each project maps to a code repo? (brownfield)

[PetiteFlamme31]

Hi @eugeniughelbur and community, first off thank you for this, I've just started testing it and the AI-first + self-rewriting model is genuinely impressive, especially /obsidian-architect and the propagation rules.

I'd love a honest take on my situation before I commit, because I'm not sure which end to grab in a brownfield vault.

My setup:

• ~400 existing notes, organized with IPCRA (a French PARA method by Eliott Meunier). So it's essentially PARA: 01-Projets (Projects), 02-Casquettes (= Areas / durable roles), 04-Ressources, 99-Archives, plus an Inbox. French folder names actually.
• The notes were originally written human-readable (hand-written, summary callouts, pointer-style CONTEXT.md hubs). I've since decided to go fully AI-first, I basically never read the raw notes myself, only the outputs.
• I'm Claude Code-native, and each project maps 1:1 to an external code repo (so per-project knowledge bases + architecture notes matter a lot to me, I saw the per-project KB discussion).

What I'm unsure about:

1. For an existing PARA vault, does your LLM-Wiki / self-rewriting approach adapt cleanly to my French PARA folders via the _CLAUDE.md Folder Map, or do you recommend letting /obsidian-init lay down its own structure and migrating content into it folder-by-folder?
2. Honestly, for someone already committed to PARA, when would you steer them toward a more PARA/PKM-method-first tool (I was also weighing AgriciDaniel/claude-obsidian, a new version is comming soon) vs your LLM-Wiki approach? I want to pick one system, not run two because they aren't compatible (I suppose).
3. Any brownfield gotchas when a lot of the existing content is human-written prose that predates the AI-first rule?

Not asking you to sell me, just your genuine view on fit. Figured the PARA-brownfield angle might help others in the same spot too.

Feel free to ask me other questions if needed.

Thanks again for the work !

[eugeniughelbur]

Short version: you don't need to migrate anything. Your folders stay.

1. French PARA folders

/obsidian-init doesn't lay down its own tree. It globs the vault, reads a sample note per folder to pick up your naming and frontmatter, then writes a _CLAUDE.md whose Folder Map describes what you already have. _01-Projets, 02-Casquettes, 04-Ressources, 99-Archives, Inbox.

The reason that holds is a precedence rule in SKILL.md: _CLAUDE.md wins on all vault-specific rules, folder names included, and the skill's own defaults only apply where _CLAUDE.md is silent. So once the Folder Map says projects live in _01-Projets/, writes go there.

Two things to fix by hand after init. Check the purpose column it generated, especially 02-Casquettes, since "Areas" is vague and the model will lean on whatever wording you leave there. And add a line for the Inbox saying what should happen to things that land in it, otherwise it gets treated as just another folder.

Also pull latest main rather than an older tag. Accented filenames only started resolving correctly a few days ago. [[Stratégie]] now matches Stratégie.md even when one side has é as a single codepoint and the other has e plus a combining accent. With French titles you'd have hit that.

2. Fit, vs a PARA-first tool

I haven't run AgriciDaniel/claude-obsidian, so I won't describe it. But I don't think the choice is PARA vs LLM-Wiki.

PARA answers where a note goes. This answers what has to be inside a note for a model to reason over it later, and what else in the vault has to change when that note changes. Different jobs. Your folder tree isn't in competition with anything here.

So: which problem do you actually have? A method-first tool is right if you can't decide where things go, or you want PARA hygiene enforced. This is right if you've got 400 notes and no reliable way to get a correct answer out of them. You said you never read the raw notes and only consume outputs, which sounds like the second one. Your filing is already settled.

The one place "pick one system" genuinely bites: the AI-first rule is opinionated about note bodies. Preamble, typed frontmatter, wikilinks per entity, recency markers on external claims. If another tool wants to own the same bodies, they'll fight. Two tools on one vault only works if you decide up front that one owns structure and the other owns contents.

3. Brownfield gotchas

The first /obsidian-health run will look bad. It checks missing frontmatter and orphans, and 400 hand-written notes trip both in bulk. Treat it as a backlog to work through, don't try to clear it in one pass.

Upgrades are lazy. Old prose stays readable and searchable as-is, and picks up AI-first frontmatter only when a command next touches it. Good default, but it means the notes you never touch never improve. If a cluster matters, run /obsidian-ingest or /obsidian-distill over it on purpose.

The Bases/ files init stamps will come out empty for you. They filter on file.inFolder("Projects") and note.type == "project". Your folder is _01-Projets and legacy notes have no type: field, so both halves miss. Fix the path by hand in Bases/Projects.base, and expect them sparse until enough notes are typed. Same for People, Tasks, Daily.

Your CONTEXT.md pointer hubs are the one thing I'd reconsider. They made sense for a human-readable vault. Here they become a second hand-maintained index that drifts from the generated index.md, and a model reading both gets two conflicting maps of the same vault. I'd either retire them or give them actual content.

Your repo mapping is the best-fitting part

Project notes carry a local-path, and /obsidian-architect scans that repo and writes architecture notes into the vault: overview, per-module, plus key decisions mined out of commit history. Re-running refreshes in place instead of clobbering your edits. With 1:1 project-to-repo you get per-project KBs that stay current without writing them yourself.

If I were you I'd pull latest, run /obsidian-init, fix the Folder Map and Bases paths, run /obsidian-health once and ignore the frontmatter count, then point /obsidian-architect at your two most active repos and judge from that before touching the other 398 notes.

Ask me about the Inbox routing if you get that far. That's usually where a brownfield PARA vault leaks.