/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)

`/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

**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.

Step 3: Draft, with the evidence class the material actually has

Write to canvas ONLY what the code supports, and tag every entry:

provenance:
  evidence_type: anecdotal
  source_classes:
    - internal_desk        # derived from artifacts, NOT from anyone
  evidence_sources:
    - "codebase read <date> @ <commit>: <file> — <what it showed>"

**HARD GUARDRAIL.** Extracted material is never `external_human`. Nobody said it. If code-derived inference gets recorded as user evidence, the framework has automated the consistency-as-evidence failure it exists to prevent, and a canvas full of code-derived "evidence" is worse than an empty one. Confidence on anything extracted starts low and says why.

**THREE TIERS, NOT TWO — and phase 2 moves material between them.** This is the distinction that keeps the guardrail honest once the user starts talking:

| tier | what it is | when | |---|---|---| | `internal_desk` | inferred from artifacts. Nobody said it. | phase 1 | | `internal_stakeholder` | the maintainer's own testimony about their own product | phase 2 | | `external_human` | someone who is NOT the maintainer — a user, a customer |