Adopt Existing logo

Adopt Existing

Community
llopresto87
adopt-existing

Source-first growth of an existing single- or multi-repository project into CYPRESS's unified docs/graph knowledge system. Use from initialize when code already exists, or for a graph refresh after material code changes. Scout executable evidence, model subsystem nodes, build project-specific architecture/product/API/data/dependency/prompt/operations leaves, connect them for progressive discovery, and validate navigation. Never trust centralized prose without source corroboration, invent specs or ADRs, modify application files, run application builds, or push Git.

Overview

Publisherllopresto87
RepositoryCypress
Skill nameadopt-existing
Stars
113
Forks
6
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by llopresto87 on GitHub. Read the source before you install it.

Installation

Install the Adopt Existing AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/llopresto87/Cypress/tree/main/skills/adopt-existing
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/llopresto87/Cypress.git /tmp/Cypress
mkdir -p .claude/skills
cp -r /tmp/Cypress/skills/adopt-existing .claude/skills/adopt-existing
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Adopt Existing in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Adopt Existing on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Adopt Existing is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Adopt an existing project

Turn a generic installed seed into a project-specific knowledge plant. Follow docs/graph/protocols/initialize.md; this skill supplies the existing-project discovery and authoring discipline.

Invariants

  • docs/graph/ is the only maintained knowledge root. The router, nodes, LLM wiki, provenance, plans, runbooks, contracts, and deep dives are layers of this one graph (rule.knowledge).
  • Executable source outranks prose. Manifests, entry points, routes, schemas, migrations, config, deployment, tests, CI, prompts, and evals are primary evidence. Existing docs are corroborating evidence only.
  • Make additive knowledge changes. Preserve application code and unrelated existing files. Leave competing AI configurations in place; deleting or relocating one is the owner's call.
  • Adoption ONLY records build and test commands: extract each exact command and label it discovered, not executed, with where it was found (path:line) and, when they hold, target absent or declared, non-functional (the states are verify.gate-states; the growth gate is grow.gate.executed). An inherited suite stays untrusted until proven RED by mutation (docs/graph/protocols/test-first.md), so record it as discovered.
  • Git stays read-only: record the repository revision as provenance; fetch, pull, switch, commit, and push each need a separate explicit request.
  • Record observed behaviour and observed choices as node facts. Specs and ADRs record intent, which only an existing record or the owner supplies. Unknown means unknown.

Scout pass

Establish the governed boundary first: one repo, workspace/monorepo, or an umbrella of sibling repos. For each repository record path, branch, HEAD, worktree state, role, manifests, stack, and the natural language of its identifiers and domain vocabulary. A non-English (or otherwise non-default) language is an explicit graph fact, because downstream agents grep and reason in it and an unrecorded mismatch silently defeats every later search. A glossary entry for a term in that language is checked against the fields and code that use the term: the obvious translation, or a plausible cognate, is a hypothesis until the code agrees, and a wrong gloss sends every later search to code that does not exist. Boundaries follow capabilities, not repository count.

Inventory cheaply, excluding generated/vendor/cache/build output; the inventory of source-index.py build --json, run once, is the scouts' file list. Then open the smallest authoritative files needed to trace:

  1. bootstrap and runtime entry points;
  2. module/service/package boundaries and imports;
  3. inbound APIs, messages, scheduled work, and outbound integrations;
  4. entities, schemas, migrations, storage, and data movement;
  5. config/secrets interfaces, deployment, and observability;
  6. tests, CI, scripts, prompts, evaluations, and operational commands;
  7. direct dependencies and evidence of their actual usage.

Return facts with exact paths and symbols. Find source corroboration for each claim prose makes, or record it as untrusted/unverified; repetition across central docs adds no corroboration.

Every delegated worker's brief embeds the canonical block from docs/graph/templates/prompts/graph-session-bootstrap.md.

Librarian pass

Normalize the evidence into single fact owners:

  • configure ROOT_ID and KINDS in docs/graph/graph-lint.py;
  • author a root node and capability/subsystem nodes;
  • factor shared stack, platform, data, domain, and cross-cutting facts into their own nodes only where this reduces duplication;
  • give nodes concrete load_when triggers and source paths;
  • keep requires minimal and acyclic; use peers for boundaries, and composes where an expertise.* node offers sub-expertises the router should descend into only when the task names one;
  • link detailed leaves using artifacts: and dependency wiki pages using libraries:.

Then enrich the leaf collections under docs/graph/:

CollectionSource-grounded content
product/actors, capabilities, flows, observed constraints
architecture/context, components, runtime flows, integrations, sharp edges
api/observed HTTP/RPC/event/job contracts with code locations
data/ownership, schemas, persistence, migrations, lineage
libraries/all direct deps indexed; critical deps richly wikified (which ones, and from what: skill.library-wiki, "Depth when adopting an existing project")
sources/provenance for external information actually used
prompts/discovered prompt contracts, versions, and call sites
evaluations/discovered datasets, rubrics, gates, and failure modes
runbooks/exact operational and verification commands, with status
plans/evidence gaps, drift/backfill work, next useful increment; when the project is automation that converges live systems, a backfill increment that imports the records those systems already hold as an unmanaged baseline, promoted one at a time by owner decision (design-posture.converge-on-drift owns the rule). The plan names the increment; the adoption pass does not write it
best-practices/conventions demonstrated by this project

Keep specs/ and decisions/ indexes, and fill them only from genuine intent records that already exist and can be preserved with provenance. Put implementation observations in nodes or architecture leaves.

When the sweep confirms zero test or gate infrastructure, write an absent (YYYY-MM-DD) — <reason> row for each standard gate in the verification runbook: a blank runbook is indistinguishable from one nobody checked, and a row for each gate turns an unknown into a stated finding.

When a legacy or parallel documentation source predates and conflicts with the evidence-derived graph, give the exclusion a real, routable node that states (a) the source is excluded as evidence, (b) what supersedes it, and (c) that this is a trust/evidence decision only: the artifact itself stays untouched (Invariants). A silent skip reads to a later agent as no decision, and the artifact gets re-trusted. The Handoff's excluded-docs report then points at this node rather than standing in for it. An agent-operations system is not such a source: protocol.grow Phase 4 says what each of its parts yields.

Refreshing an existing graph

Treat graph prose as a read model to verify against current source:

  1. compare repository revisions with the graph changelog/provenance;
  2. scout changed areas and their dependency/data/API blast radius (source-index.py impact, run once over the moved paths);
  3. update the existing fact owner instead of creating a duplicate;
  4. preserve valid hand-authored context;
  5. remove or supersede stale seed-owned claims only with cited contrary evidence;
  6. record conflicts and unanswered questions in the plan.

Report a refresh as partial, naming each unavailable source, whenever part of the governed source was out of reach.

Validation

Run knowledge checks only:

sh
python3 docs/graph/graph-lint.py
python3 docs/graph/graph-lint.py --plan "change a representative capability"

Verify all graph links resolve; every Tier-3 leaf is reachable from an owning node; no duplicate fact homes exist; representative task routes are small and relevant; commands say whether they were executed; the verification runbook carries the absent-gate rows where no infrastructure was found (Librarian pass); each recorded command carries its found-at, not-executed and target labels (Invariants); and no template placeholders, fabricated success, inferred specs, or invented rationale remain.

Use known-answer navigation questions from several capabilities plus an adversarial false-premise question. A wrong or bulk-read answer is a graph defect: improve ownership, routing, or leaf content and rerun, for at most two fix-and-rerun rounds per defect; with the authoring pass they are the three attempts docs/graph/protocols/recover.md allows. A defect that survives them goes to the user as an honest unknown.

Handoff (the stopping condition)

Adoption is done when validation passes within its bounded rounds and the open defects are recorded; completeness is measured by reliable progressive discovery. End with the payload from docs/graph/templates/prompts/handback-payload.md, and report: repository revisions, evidence inspected, graph artifacts created or refreshed, validation outcomes, docs deliberately excluded as untrusted (each named by its exclusion node), remaining unknowns, and one highest-leverage next action with its tier.

Frequently asked questions

What does the Adopt Existing AI skill do?

Source-first growth of an existing single- or multi-repository project into CYPRESS's unified docs/graph knowledge system. Use from initialize when code already exists, or for a graph refresh after material code changes. Scout executable evidence, model subsystem nodes, build project-specific architecture/product/API/data/dependency/prompt/operations leaves, connect them for progressive discovery, and validate navigation. Never trust centralized prose without source corroboration, invent specs or ADRs, modify application files, run application builds, or push Git.

Why use Adopt Existing on TypingMind?

Because you install it once and use it with any model. Adopt Existing is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Adopt Existing in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/llopresto87/Cypress/tree/main/skills/adopt-existing. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Adopt Existing?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Adopt Existing?

As many as you like. As long as a model supports skills, you can use Adopt Existing with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Adopt Existing AI skill free?

Yes. It is published on GitHub by llopresto87 under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇