/adopt

name: adopt
description: "Bring Mycelium into a project that already has code. Detects that the repo predates the framework, asks before touching anything, then reads the codebase to draft what it CAN establish (delivery, solution shape) and — the actual point — names what it cannot (purpose, strategy, real user evidence). The output is a discovery backlog with a head start, never a filled canvas."
metadata:
  instruction_budget: "60"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Adopt (brownfield entry)

First: are Mycelium's hooks running here? (v0.286.0)

Run `find .claude/state/hooks-alive "${TMPDIR:-/tmp}/mycelium-hooks-alive-$(id -u)" -mmin -60 2>/dev/null`. If it prints a path (since v0.318.0 the hooks also stamp the temp folder in a project with no Mycelium state yet, where they do nothing else), say nothing about it and go on. If it prints nothing, Mycelium's hooks did not run in this session: its gates and the rules it gives the agent at session start are off, and nothing else will say so. Tell the user in one line before anything else: "Mycelium's hooks are not running in this session, so its gates are off. On Codex CLI, open `/hooks`, trust Mycelium's hooks and start a new session; on Claude Code, check the plugin is enabled in `/plugin`." Then carry on with this skill.

`/mycelium:start` assumes a blank page. Most projects are not a blank page. This skill is the entry point when the code came first.

When to Use

• A repo with existing source and no populated canvas (the SessionStart

brownfield check points here).

• A maintainer who wants discovery on a product that already ships.
• NOT for a new idea — that is `/mycelium:start`.

The shape of the run: two phases, one session

**Phase 1 — populate from the codebase.** Read the repo and fill in what the code can actually establish, at the right evidence class.

**Phase 2 — patch the holes with the user, exactly as a greenfield project would.** The gaps left by phase 1 are not a backlog to hand over. They are the agenda for the rest of the session, worked with the same discovery discipline `/mycelium:start` would apply — the only difference is that the canvas is not empty when you begin.

Do not stop between the phases and present a list. Ending at a fork is the failure this skill exists to remove: a maintainer offered "run the greenfield brief or skip" has no good option, and "here is your discovery backlog" is the same fork with extra steps.

**Why phase 1 cannot be the whole thing.** A codebase answers *what was built* and *how it ships*. It is nearly silent on *why it exists* and *who decided that*. Extraction is asymmetric, and inverted from where discovery value lives:

| scale | what code yields | |---|---| | L4 Delivery | STRONG — stack, release cadence, distribution, CI, test posture | | L3 Solution | STRONG — feature surface, module structure, what shipped when | | L2 Opportunity | INFERENCE ONLY — you see what was built, not the problem it solved. Real demand signal lives in the ISSUE TRACKER, which a clone does not contain. | | L5 Market | THIN — category and channels, rarely positioning | | L1 Strategy | USUALLY EMPTY | | L0 Purpose | USUALLY NEAR-EMPTY — READMEs state a *what* and a stack, seldom a *why* |

So phase 1 reliably fills the layers that never needed discovery and leaves empty the ones that did. That is not a defect in the extraction — it is the map of what phase 2 has to work on. Never present a phase-1 canvas as though discovery happened; it is a starting position, and say so.

**Watch for drift.** The sharpest thing this skill can surface is a mismatch between what the project *says* it is and what it has *become*. A README that describes the original scope while five years of changelog show the product moved somewhere else is a real finding, visible in minutes, and a maintainer recognises it immediately. Look for it explicitly: compare the stated purpose against the feature surface and the most recent changelog entries.

Workflow

Step 1: Confirm before anything

Do not scan and present as a fait accompli. Say what you propose to read and ask.

> "This project has code but no Mycelium discovery state. I can read the repo > and draft what it can establish — roughly the delivery and solution picture — > and then show you what it cannot: purpose, strategy, and any real user > evidence. That second list is the useful half. About N minutes. Go ahead?"

If declined, stop. Do not leave partial state. Offer `/mycelium:start` (blank page) or nothing.

Step 2: Read, in this order

Cheapest signal first; stop when you have enough rather than reading everything.

1. `README`, docs index — stated purpose, category, audience 2. `CHANGELOG`, release history — what the product actually became, and how fast 3. Manifest (`package.json`, `pyproject.toml`, …) — stack, distribution, scripts 4. Top-level source tree — feature surface and module boundaries 5. `CONTRIBUTING`, CI config — delivery posture 6. Tests — what the team considers worth protecting 7. Deploy config: run `python3 "${CLAUDE_PLUGIN_ROOT}/scripts/scale_locks.py" --project-dir . --deploy-sign`. It prints the file that shows this project deploys (a host's config, a workflow that deploys, a `Procfile`), or says there is none, or that it could not look

**Do not read the whole codebase.** You are establishing shape, not comprehension. If the repo is large, breadth beats depth.

**Issue tracker**: if the host is reachable and the user consents, open issues are the only real L2 signal available. Without them, say L2 is un-evidenced rather than inferring it from code.

**Is something already live?** (v0.322.0) Item 7 shows the project CAN deploy, not that anythi