project-adopt
Adopt the SDD flow into an existing (brownfield) codebase - detect code and docs, infer the domain, scaffold the 8-layer structure, and reverse-engineer draft baseline artifacts. Use once on an existing project; then hand off to doc-flow and the per-layer audits.
What this skill does
# project-adopt
## Purpose
Onboard an **existing codebase** (brownfield) into the SDD flow: detect the
current code and any docs, infer the domain, scaffold the 8-layer `docs/`
structure, and **reverse-engineer baseline artifacts** from the code at
`draft` status — the one-time setup that gives a running system its SDD
backbone. It is the brownfield counterpart to `../project-init/SKILL.md`.
**Layer**: cross-cutting utility (precedes BRD).
## When to Use
The greenfield/brownfield boundary is the deciding factor:
**Use `project-adopt` when** (brownfield):
- Source code already exists, but there is no `docs/` SDD structure.
- You need baseline SDD artifacts derived from the running system.
**Use `../project-init/SKILL.md` instead when** (greenfield):
- No code and no docs yet — a brand-new project to be built SDD-first.
**Do NOT use** when `docs/01_BRD/` etc. already exist — go straight to
`../doc-flow/SKILL.md`.
## Behavior
Run the steps in order; mirror the greenfield setup, then add the
reverse-engineering pass. Every derived artifact starts at **`draft`** status —
adoption seeds the baseline; the layer skills raise it to ready.
### 1. Detect existing code and docs (first)
Survey the repository: source modules, public interfaces, configuration,
existing READMEs/ADRs/design notes, and any tests. Record what exists so the
reverse-engineering pass has sources to cite. Note tests as evidence for
BDD/TDD baselines.
### 2. Infer the domain
Infer the domain from the code and docs (Financial / Software-SaaS /
Healthcare / E-commerce / IoT / Generic) and confirm with the user; this drives
the same terminology mappings `project-init` applies. Default to Generic if
ambiguous.
### 3. Scaffold the 8-layer structure
Create the artifact directories plus support folders (same as greenfield):
```bash
mkdir -p docs/{01_BRD,02_PRD,03_EARS,04_BDD,05_ADR,06_SPEC,07_TDD,08_IPLAN}
mkdir -p docs/08_IPLAN/tmp plans
```
### 4. Reverse-engineer baseline artifacts (the brownfield step)
Derive a baseline for each of the 8 artifacts from the existing system, working
**from the code upward and downward**, all at `draft` status. Use the layer
registry (`${CLAUDE_PLUGIN_ROOT}/framework/registry/LAYER_REGISTRY.yaml`) for the artifact set and
each template under `${CLAUDE_PLUGIN_ROOT}/framework/layers/NN_<X>/`:
| Layer | Artifact | Reverse-engineered from |
|-------|----------|-------------------------|
| 6 | SPEC | Module/interface signatures, data models, contracts in code |
| 5 | ADR | Existing design notes; decisions implied by the architecture |
| 3-4 | EARS, BDD | Observable behavior; existing tests → scenarios |
| 1-2 | BRD, PRD | Product behavior and capabilities the system delivers |
| 7-8 | TDD, IPLAN | Existing test suites and the as-built file layout |
Mark inferred content explicitly and never invent placeholder IDs for gaps —
leave them for the audits to surface. Add upstream `@` tags only where the
real upstream artifact now exists; record unknowns as gaps, not fabricated
references.
### 5. Register indexes
Create the per-layer index files so derived artifacts are discoverable:
```bash
touch docs/01_BRD/BRD-00_index.md docs/02_PRD/PRD-00_index.md \
docs/03_EARS/EARS-00_index.md docs/04_BDD/BDD-00_index.md \
docs/05_ADR/ADR-00_index.md docs/06_SPEC/SPEC-00_index.md \
docs/07_TDD/TDD-00_index.md docs/08_IPLAN/IPLAN-00_index.yaml
```
### 6. Validate
Confirm all 8 directories, the index files, `plans/`, and one draft baseline
artifact per layer exist. If anything is missing, re-run the relevant step.
### 7. Hand off to gap-closing
Report adoption complete with the list of draft artifacts and known gaps, then
direct the user to:
- `../doc-flow/SKILL.md` to drive the layers forward, and
- the per-layer `-audit` skills (`../doc-brd-audit/SKILL.md` …
`../doc-iplan-audit/SKILL.md`) to score each draft and produce fix reports
for the matching `-fixer` skills,
so the drafts close their gaps and rise from `draft` to ready. Run
`../doc-validator/SKILL.md` once baselines link up to confirm traceability.
## Adaptation
Before scaffolding, read the project adaptation profile
(`.aidoc/profile.yaml`). Honor `active_layers`: create structure for the
active layers only — do not scaffold a disabled skippable layer. Ignore any
unknown or out-of-surface key.
Authority: `${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md`.
## Related Resources
- Greenfield counterpart: `../project-init/SKILL.md`
- Next: `../doc-flow/SKILL.md` · per-layer `-audit` skills (e.g.
`../doc-spec-audit/SKILL.md`)
- Layer registry (the 8 artifacts): `${CLAUDE_PLUGIN_ROOT}/framework/registry/LAYER_REGISTRY.yaml`
- Templates & READMEs: `${CLAUDE_PLUGIN_ROOT}/framework/layers/NN_<X>/`
- Traceability check: `../doc-validator/SKILL.md`
- Diagrams: `../charts-flow/SKILL.md`
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.