adopt — Claude Code skill: audit existing project artifacts
Checks whether your GDDs, ADRs and stories match the template's format, then writes a numbered migration plan. Useful when the template's skills fail on a project that already has docs.
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a claude-codeWhat adopt does
adopt is a brownfield skill. It does not ask what exists — it asks whether what exists will work with the template's skill pipeline. A project can have GDDs, ADRs and stories, and every format-sensitive skill will still fail silently or return wrong results if those files use the wrong internal format.
It runs in seven phases: detect project state, audit formats, classify and prioritise gaps, build the migration plan, present a summary, write the file, offer a first action. Output lands in docs/adoption-plan-[date].md as a persistent, checkable plan. The argument scopes the audit: blank or full covers all artifact types, gdds, adrs and stories narrow it to one format, infra looks at infrastructure gaps such as registry, manifest, sprint-status and stage.txt.
Automation mode resolves from project.local.yaml, then project.yaml, defaulting to collaborative — the skill asks before writing the plan file. It never regenerates artifacts that already have content, so do not expect it to rewrite your existing GDDs or stories.
What it helps with
- find out why template skills misread existing project docs
- check GDD, ADR and story formats before wiring up the pipeline
- get a numbered migration plan instead of a vague to-do list
- spot gaps in registry, manifest, sprint-status and stage.txt
- tell missing artifacts apart from ones in the wrong format
Example prompts for the agent
- /adopt
- /adopt gdds
- /adopt infra
How to install adopt
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a claude-code2Manually: put the files in place
~/.claude/skills/adopt/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/adopt/
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a codex2Manually: put the files in place
.agents/skills/adopt/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a cursor2Manually: put the files in place
.cursor/skills/adopt/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install Donchitos/Claude-Code-Game-Studios adopt2Manually: put the files in place
.github/skills/adopt/SKILL.md1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a gemini-cli2Platform CLI
gemini skills install https://github.com/Donchitos/Claude-Code-Game-Studios --path .claude/skills/adoptManually: put the files in place
.devin/skills/adopt/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about adopt
How do I install adopt in Claude?
Run npx skills add Donchitos/Claude-Code-Game-Studios --skill adopt -a claude-code. The skill file lands at ~/.claude/skills/adopt/SKILL.md.
What does adopt do?
It audits existing project artifacts for format compliance with the template and produces a numbered migration plan at docs/adoption-plan-[date].md.
How is adopt different from /project-stage-detect?
/project-stage-detect answers what exists. adopt answers whether it will work with the template's skills, so it checks compliance rather than existence.
Source text
SKILL.md · MIT
---
name: adopt
description: "Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence."
argument-hint: "[focus: full | gdds | adrs | stories | infra]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash "*/.claude/skills/adopt/../../hooks/yaml-helper.sh" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)
model: sonnet
---
!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,automation_always_ask,workflow`
Resolved above — use as-is. `/adopt` also inspects `project.yaml` and the legacy
config files directly when reporting and writing migration state; that raw
inspection is deliberate and separate from the resolved values above.
# Adopt — Brownfield Template Adoption
This skill audits an existing project's artifacts for **format compliance** with
the template's skill pipeline, then produces a prioritised migration plan.
**This is not `/project-stage-detect`.**
`/project-stage-detect` answers: *what exists?*
`/adopt` answers: *will what exists actually work with the template's skills?*
A project can have GDDs, ADRs, and stories — and every format-sensitive skill
will still fail silently or produce wrong results if those artifacts are in the
wrong internal format.
**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.
**Argument modes:**
**Audit mode:** `$ARGUMENTS` (blank = `full`)
- **No argument / `full`**: Complete audit — all artifact types
- **`gdds`**: GDD format compliance only
- **`adrs`**: ADR format compliance only
- **`stories`**: Story format compliance only
- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)
---
**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →
`project.yaml` → default `collaborative`). Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`
(collaborative asks always · guided major-only · autonomous logs and proceeds;
`automation_always_ask` categories always prompt).
**`workflow`** (per `.claude/docs/workflow-modes.md`). It scopes the Phase 2 audit and
Phase 3 severity: `full` audits all doc types at full structure; `standard` audits
only the required docs/sections (optional sections are informational, not gaps);
`minimal` is a `design/game-brief.md` format check — GDDs/ADRs/UX are not expected. See Phase 2.
## Phase 1: Detect Project State
**Read `references/1-detect.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 2: Format Audit
**Read `references/2-format-audit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 3: Classify and Prioritise Gaps
**Read `references/3-classify.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 4: Build the Migration Plan
**Read `references/4-migration-plan.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 5: Present Summary and Ask to Write
**Read `references/5-summary.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 6: Write the Adoption Plan
**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 7: Offer First Action
**Read `references/7-first-action.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Collaborative Protocol
**Applies in `collaborative` mode (the default).** For `guided` and
`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below
describe what collaborative mode requires, not universal behavior.
1. **Read silently** — complete the full audit before presenting anything
2. **Show the summary first** — let the user see scope before asking to write
3. **Ask before writing** — always confirm before creating the adoption plan file
4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when
5. **One action at a time** — after handing off the plan, offer one specific next step,
not a list of six things to do simultaneously
6. **Never regenerate existing artifacts** — only fill gaps in what exists;
do not rewrite GDDs, ADRs, or stories that already have content
© Donchitos · MIT · Donchitos/Claude-Code-Game-Studios