/plumb-line-adopt

name: plumb-line-adopt
description: "Use when a builder wonders what plumb-line would do for their codebase or which part to adopt, or when, mid-task, they are building with a stand-in: stubbing a service that is not built yet, falling back to cached or last-known values when a source fails, filling a field with generated or sample data, mixing fixture, cached or LLM-produced data with real data. It answers yes, and: add it, and here is how to keep track of it (a label or marker, or plumb-line's provenance primitive where it fits). Inspects the repo and routes to the right skills and primitive integration. Read-only: recommends and hands off, never edits or installs."

Adopt plumb-line — which part, on what

REQUIRED READING FIRST: `reference/fit-map.md` (plugin root). If this file cannot be read, stop immediately and report: "Cannot route: `reference/fit-map.md` is missing or unreadable. Do not recommend from memory — the fit map is the source of truth for what the primitives are for." Read `reference/portable-principles.md` only if the conversation needs the principles named; the fit map is sufficient for routing.

This skill is a concierge for the whole toolkit — the four sibling skills AND the run-time primitives. Its job is the question the docs cannot answer for a specific repo: *"what would I use this on, here?"* It recommends only. It never edits files, installs anything, or scaffolds code; every action belongs to the skill it hands off to, or, for a stand-in met mid-task, to the agent or builder doing the task.

1. Look — a lightweight, read-only scan

Scan the repository for **routing signals only** (this is not an audit — do not read whole files; filenames, imports, and greps suffice):

• HTTP ingestion: `requests` / `httpx` / `fetch` / `axios` whose results

feed computation; caching or retry-with-cache logic.

• Dataframes: `pandas` / `numpy` imports; `fixtures/`, `sample_data/`,

or demo CSVs loadable by production-adjacent code.

• LLM or agent surface: LLM SDK calls; fallback/canned-response branches;

agent-generated artifacts consumed downstream.

• Fakery near production paths: mock flags, `USE_MOCK`-style toggles,

stub data on non-test paths.

• Existing adoption: `plumb-line-provenance` already imported; a ruleset

file (`AGENTS.md` / `CLAUDE.md`) declaring layers; installed hooks.

**State your denominator.** Say in one line what the scan covered (e.g. "scanned imports and top-level layout; did not read function bodies") — a routing recommendation must not imply deeper knowledge than the scan had.

2. Ask — at most three questions

Fill only the gaps scanning cannot see. Good questions: what the builder is actually worried about; whether the mock/fixture data ever reaches users or stored outputs; whether they want enforcement or just visibility. Skip any question the scan already answered. If no builder is present to answer, route from the scan alone and say so.

3. Route — both surfaces, explicitly

Always answer both halves, in plain language, assuming no prior reading:

**Skills surface (applies to every repo).** Recommend which of the four to run and in what order, with one line each on what it produces:

• `plumb-line-method` — first if the builder wants the reasoning; teaches

the discipline in minutes.

• `plumb-line-audit` — the zero-setup first taste: reviews the diff or

repo and reports; needs nothing installed.

• `plumb-line-bootstrap` — when they want the discipline wired in

(ruleset, hooks, boundary checks).

• `plumb-line-remediate` — only after an audit report exists.

**Primitives surface (fit-mapped).** Match the scan + answers against the fit map's profiles and say which profile matched and *why, citing what was seen* ("you call OpenAI with a static fallback in `llm/client.py` — profile 1"). Before showing code, give a one-minute mechanics primer in plain words — builders hesitate when the envelope feels opaque: `mark` wraps a value with metadata at the point it enters; `derive` runs the builder's own function on the plain values and combines the metadata by law (taint ORs and cannot be cleared, confidence takes the weakest); `metaOf`/`meta_of` reads it back; `auditMeta`/`audit_meta` checks the envelope is consistent; `guard` stops a value at an output point: by default one that is unmarked, malformed, flagged by the audit or tainted by mock, and one below a source or confidence floor when the output sets one. Say plainly what this bounds: the library never computes or modifies a value, so a labeling mistake misdescribes data but cannot corrupt it, and a forgotten `mark` fails visibly rather than silently (the fit map's "Worried about using it wrong?" section is the source). Then show the profile's smallest useful integration **adapted to the builder's actual code**: their filenames, their variable names, the right language, and the right adapter (`taggedFetch` / `tag_requests` / `PlumbDataFrame` / plain `mark`+`derive`) for their stack. Show the pattern as a suggestion in conversation — never apply it.

**Non-fit is a first-class outcome.** If the repo matches the fit map's anti-profile, say plainly: "you do not need the primitives" — then still give the skills-surface answer, and name what future change would revisit the verdict (the fit map's anti-profile section closes the same way). Do not soften the no; a wrong-fit adoption costs the builder more than an honest walk-away.

**Defuse the greenfield misconception.** Builders commonly assume provenance must be adopted at a project's start and hesitate on an existing codebase. When that worry appears — or when the repo is clearly mature — say what the fit map's "Mid-project is the normal case" section says: envelopes attach at boundaries, the smallest integration is a few lines at one call site, nothing is retrofitted, and repo-wide enforcement is a separate, opt-in, later decision.

**Mixed or uncertain fit is stated as such.** If signals are ambiguous, say what would sett