ynh-adoptlisted

# Adopt an existing setup Almost nobody starts from nothing. They arrive with a `.claude/` folder someone added six months ago, a `.cursorrules` from before that, and a `CLAUDE.md` that has grown by accretion. The question is never "how do I build a harness". It is **"what happens to what I already have?"** Answer that first, or nothing else lands. If they genuinely have nothing, use `ynh-create-harness` instead. ## Before you start - `references/what-moves-where.md` — the decision table, the traps, and the two adoption strategies in full ## Step 1 — Inventory, out loud Look, and tell them what you found. Do not guess. ```bash ls -a ls .claude .cursor .github 2>/dev/null find . -maxdepth 2 \( -name 'CLAUDE.md' -o -name 'AGENTS.md' -o -name '.cursorrules' \ -o -name 'copilot-instructions.md' -o -name '.harness.json' \) 2>/dev/null ``` What tends to be there: | Found | What it is | |---|---| | `.claude/skills/`, `.claude/agents/`, `.claude/commands/` | already in the artifact format ynh uses | | `.claude/settings.json` | permissions and hooks — **not** an artifact, stays put | | `CLAUDE.md` | project instructions, Claude-specific filename | | `.cursorrules` | project instructions, Cursor's legacy filename | | `.cursor/rules/*.mdc` | Cursor rules with frontmatter | | `.github/copilot-instructions.md` | Copilot instructions | | `AGENTS.md` | already the cross-vendor form — the easy case | | `.harness.json` | a legacy ynh manifest — run `ynd migrate` | Then ask the