ynh-adopt

Topics in the source

• Adopt an existing setup
• Before you start
• Step 1 — Inventory, out loud
• Step 2 — Deal with the instructions file first
• Step 3 — Pick a strategy
• A. Include in place — config stays in this repo
• B. Move into a harness — config becomes reusable
• Step 4 — Legacy manifest

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. references/what-moves-where.md — the decision table, the traps, and the two adoption strategies in full Look, and tell them what you found. Do not guess. 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 question that decides everything else: Do you want this

This is an excerpt. Refer to the complete source and its current requirements.