Portable Prompt

name: portable-prompt argument-hint: [capability to portablize] [optional: audience] [--type knowledge|agent] [--check-stale] description: Turn one of your own replicable capabilities (a skill, tool, hook, script, automation such as n8n / Make / GoHighLevel, workflow, process, config, or prompt) into a self-contained, de-personalized PORTABLE PROMPT anyone can paste into their own Claude Code or AI tool to get that capability working on THEIR machine and accounts. USE WHEN the user says "create a portable prompt", "portablize this", "make this portable / replicable for colleagues or the team", "turn my skill / tool / hook / script / automation / workflow / process / config / prompt into a shareable prompt", "make this a knowledge skill", "turn my know-how into a knowledge prompt", "let others recreate / rebuild this on their own machine", "share this capability without sharing access", "portable anything", or "portable prompt generator". Ships one of two OUTPUT TYPES, auto-decided from the capability (operator can force --type): an AGENT prompt (the reader's AI builds and runs the automation) or a KNOWLEDGE prompt (the reader's AI installs the operator's source files preserved VERBATIM, targeted redactions only, structure kept; nothing is built and nothing is re-authored). Never guesses an ambiguous capability argument: it lists the found candidates and asks the operator to choose (one, several, or a merged combination) before extracting. The generated prompt is an AI runbook: addressed to the executing AI, zero human-facing prose, every decision an interactive ask made to the human at the right moment. Splits CORE (rebuild faithfully) vs SHELL (adapt to the reader's own host conventions). Strips all operator identity to placeholders under a never-leak registry, broadens swappable tools to categories, installs non-destructively, self-checks dependencies, interviews the new user, and ships only through a fail-closed four-pass leak gate. Public-safe by default; audience-tunable without ever relaxing the strip.---

/portable-prompt — Portable Anything Generator

Take ONE replicable capability the operator already has and emit a single self-contained prompt a stranger can paste into their own AI tool to rebuild it on their own machine and accounts. The capability can be ANY replicable thing: a skill, a tool, a hook, a script, an automation (such as n8n, Make, or GoHighLevel), a workflow, a process, a config, or a prompt. The output ships nothing of the operator's: no keys, no tokens, no names, no paths, no fingerprint of the operator's specific stack. The reader rebuilds from instructions and creates their OWN dependencies. Every capability ships as one of two OUTPUT TYPES: AGENT (the reader's AI builds and runs it) or KNOWLEDGE (the reader's AI absorbs the method at full fidelity and applies it across future tasks; nothing is built). The type verdict is set with the size verdict; see "Type the output".

The method, in order: extract the real system from source, set the size and type verdicts (LEAN | FULL, AGENT | KNOWLEDGE), classify every element CORE (rebuild faithfully) vs SHELL (adapt to the reader's host), strip all personalization to placeholders under a registry-driven policy, broaden swappable tools to categories, make the generated prompt detect the reader's host and map the CORE onto it, install non-destructively, self-check its dependencies by tier, interview the new user (role first), then clear a fail-closed FOUR-pass leak gate and ship with an index row. Sized to the capability, recipient-first. The numbered phases below are the authoritative spec; this paragraph is only the map.

TOP-LEVEL RULE: the generated prompt is an AI runbook, not a human document

This is the principle the whole skill serves. State it once, here, and let every phase obey it.

The GENERATED prompt is a runbook for an AI to DIGEST and EXECUTE. It is addressed to the executing AI in the second person ("you"). It contains ZERO prose meant for a human to read: no pitch, no "what you get" block, no "for the reader" notes, no checklist the human is handed to run, no "tell your agent to…" instruction aimed at the human. Every guarantee, every dependency fact, every preference, every step is written as a DIRECTIVE to the AI.

Wherever the AI needs information, a decision, a preference, or a confirmation FROM the human, the generated prompt INSTRUCTS THE AI TO ASK THE HUMAN INTERACTIVELY at that moment — in chat, or via a pop-up question (an AskUserQuestion-style multiple-choice where the answer is a CHOICE). The AI never assumes; it asks, then acts on the answer.

The human's entire experience is: paste the prompt → the AI reads it → the AI asks them questions in chat and via pop-ups → the AI builds and reports. The human never reads the prompt body. Any sentence in the generated prompt that only makes sense if a human reads it is a defect — it must become either an AI directive or an instruction for the AI to ask the human at the right moment.

What this rule does NOT touch: it is a VOICE / AUDIENCE rule about who the generated prompt addresses. It changes nothing about the safety model. Every guarantee, gate, invariant, and leak-gate pass below stays exactly as specified — the guarantees simply ship as AI directives (enforced in code) instead of as human reassurance prose. The shipped artifact carries NO provenance / meta block at all (no version, date, generator, or audience label — that bookkeeping lives only in the operator-side manifest, never in the output). The two AI-speaks-to-the-human moments that already exist — the dependency self-check's ask/suggest/guide flow (the AI asking what tools the human has, suggesting what to connect, and guiding the connection) and the role-first interview — are CORRECT as-is: they are already the AI addressing the human in chat, and they stay.

When to invoke

The trigger phrases are in the frontmatter description ("create a portable prompt", "make this replicable for the team", "turn my [skill / tool / hook / script / automation / workflow / process / config / prompt] into a shareable prompt", "portablize this", "portable anything", "share this capability without sharing access", and the rest). Skip when the user wants the capability RUN (invoke the capability instead), or wants to share access directly (refuse: see Safety — share a prompt, never access).

Inputs

1. The capability to make portable (required). A name, or a path to its source: a skill dir, scripts, config, a workflow / automation export, a hook file, process notes. This is what gets extracted and de-personalized.

   Resolution gate: never guess which capability is meant. Resolve the input to exactly one source on disk before anything else, through this ladder:

   • An explicit path, or a name matching exactly ONE capability (one skill folder, one hook, one script, one automation export): resolved. State the resolution in one line ("portablizing <capability> from <path>") and proceed.
   • Anything less is AMBIGUOUS and stops the run for a choice. That includes a bare domain word several capabilities touch (one word that could mean a strategy skill, a tactics skill, a channel-specific skill, or an automation in that domain), a partial name with more than one plausible completion, and a term matching nothing. Search the operator's capability surfaces (the skills directory, hooks, scripts, automation exports, configs) for candidates, then ask via the interactive question UI in ONE multi-select question: "I found these potential matches. Which do you mean: one of these, or a combination?", one option per candidate. Offer the 3-4 strongest, likeliest first and marked recommended when one clearly leads; name any further matches in the chat line before the pop-up; the built-in Other covers anything unlisted. Zero matches is also an ask, offering the closest fuzzy candidates: never a silent failure, never a guess.
   • The certainty bar is near-100%. Anything less than an unambiguous match gets the question. A wrong guess burns a full extraction-to-gate run on the wrong capability; the question costs seconds.
   • A multi-pick ships ONE portable prompt PER picked capability, in the order picked, because this pipeline takes one capability per output. State that default in the chat line before the pop-up; if the operator wants the picks MERGED into one combined prompt they say so, and the merged set is then treated as a single capability with all its sources extracted together (one shared type verdict, one leak gate, one output).

2. Audience spec (optional). Who the portable prompt is for and how to tune it. If absent, do NOT ask — default to the public-safe output (see The audience-customization layer). Only when an audience IS named do you tailor framing, depth, and the worked example.

The two-tier strip (absolute, registry-driven)

This is the spine of the strip. Every run loads the registry and applies its strip policy. The registry holds the operator-specific data and a Tier 0 secrets layer above the tiers; this skill describes only the mechanism.

• Tier 0 — SECRETS, above every tier. Any real secret-shaped value: an API key, service token, OAuth artifact, password / passphrase, SSH or certificate material, an auth header, a credential-bearing connection string, a .env value, a secret file PATH, a JWT, a high-entropy blob. A portable prompt has ZERO legitimate reason to contain a real secret — the reader supplies their own — so any secret-shaped value is a leak. Stripped to a placeholder. A Tier 0 hit is a HARD FAIL: never ships, no audience, no exception. Enforced by the dedicated secret-scan pass (pass 4 of the leak gate).
• Tier A — ALWAYS STRIP, every audience, no exception. The operator's side-projects, holding-company / parallel-venture activity, ALL people names (the operator's own name included), and personal infrastructure (personal emails, local machine paths, env-file paths, any real account id / database id). Tier A is removed from EVERY output regardless of audience. Replace with placeholders.
• Tier B — CONDITIONAL. A named-employer brand / context, plus its internal vocabulary and worked examples. Allowed as the worked example and framing ONLY when that specific audience is explicitly named at generation time. STRIPPED for the public default. When Tier B is allowed, Tier 0 and Tier A still apply on top (no secrets, no people names, no side-projects, ever).

State plainly, and never violate it: the audience knob NEVER relaxes Tier 0 or Tier A. Naming an audience can only unlock Tier B framing; it can never reintroduce a secret or a Tier A identifier. There is no audience for which a Tier 0 or Tier A value is acceptable.

Load the registry every run (by path)

Read the registry deterministically at the START of the verify, every single run, from ONE fixed home-relative path you choose once and never change: a never-leak-registry.md beside this skill's own configuration, in the assistant's config directory.

Write that path as home-relative and resolve ~ against the running user's home directory at runtime. Do not hard-code an absolute machine path anywhere in this skill, because an absolute home path is itself a leak signal, and a skill whose job is stripping identity must not carry one. Load the registry's current contents at runtime; do not rely on a remembered copy and do not inline its names into this skill.

The registry is YOURS and is never shipped. It holds your own identifiers, so it belongs to whoever installs this skill and it must never appear inside a portable prompt, a kit, or any artifact that leaves the machine. Build it before the first run: without it the gate fails closed by design (see Phase 11 on the N > 0 rule), and that is correct behaviour rather than a bug. The registry defines which identifiers fall in Tier 0 / Tier A / Tier B and carries the operator-specific lists and the secret prefixes/patterns. The skill scans the output against whatever the registry currently says. When a new project, person, identifier, or secret class enters the operator's world, it is added to the registry once and every future portable prompt is protected. The registry list is the FLOOR, not the ceiling (see default-deny and the high-entropy catch-all below).

Size the output to the capability (generation rule, decided before authoring)

The generated prompt scales to the SIZE of the capability. A small capability gets a LEAN prompt; the full multi-phase scaffold is reserved for capabilities that earn it. Decide which at the end of Phase 1, from the extracted spec, and carry the verdict into authoring.

• LEAN when the capability is a single-file hook, a one-step script, or a single prompt with no hard guarantee and at most one dependency. In LEAN mode every heavyweight mechanism COLLAPSES: host-detection (Phase 5) collapses to a one-line runtime check ("confirm [runtime] is present, e.g. node -v"); the optional-feature choice (Phase 8) collapses to the AI stating its single-line skip-cost note; the personalization interview (Phase 9) collapses to the one or two questions that actually re-tune the thing; the build-safety contract (Phase 4) collapses to "write the one file; if it already exists, back it up beside it first, then ask before overwriting". The interactive open (Phase 3.5), the go-live the AI self-verifies plus the usage handoff (Phase 9.5), the injection guard (if it ingests third-party content), and the full 4/4 leak gate still ship in full — those do not scale down.
• FULL when the capability spans multiple scripts or modules, touches more than one dependency, or carries any hard guarantee (a never-send / never-delete / reversible invariant). Run the whole scaffold as written.

Hard line: do not push a 12-line hook through the heavyweight scaffold, and do not strip a multi-guarantee tool down to LEAN. The size verdict (LEAN | FULL) is recorded in the Phase 11 publish gate.

Paste budget and kit split (both types; most acute for FULL-FIDELITY knowledge builds). The default deliverable is ONE paste-able file. Target budget: a single-paste runbook stays under roughly 1,000 lines / 15k words. Over budget, compress PROSE first (dedupe, tighten, merge repetition) and never RULES: fidelity means every rule, ordering, threshold slot, and invariant survives; verbatim bulk is not fidelity. If it still exceeds the budget after prose compression, ship a KIT: one entry runbook plus numbered part files, where the entry runbook directs the executing AI to ingest every part in order before acting and to confirm the part count before proceeding. Every part clears the same leak gate. Record the deliverable form (single paste, or kit with N parts) in the publish gate.

Precedence with KNOWLEDGE mode: the type collapse (see Type the output) wins over this section's LEAN collapse list. Redact-in-place knowledge builds are EXEMPT from prose compression entirely (compression breaks byte-fidelity): when a knowledge source is large, the kit form IS the budget mechanism, never rewriting.

Type the output: AGENT vs KNOWLEDGE (generation rule, decided with the size verdict)

Every capability ships as exactly one of two OUTPUT TYPES. Decide it at the end of Phase 1, from the extracted spec, alongside the LEAN | FULL size verdict, and record it in the Phase 11 publish gate. The two verdicts are independent axes: size scales HOW MUCH scaffold ships; type decides WHICH scaffold.

• AGENT when the capability's value requires something BUILT and RUN on the reader's machine: a script, hook, automation, config, scheduled job, anything with dependencies or a runtime guarantee. The reader's AI rebuilds it. Run the pipeline exactly as the phases are written.
• KNOWLEDGE when the capability's value is a METHOD the reader's AI can apply with nothing built: a domain framework, heuristics, decision rules, checklists, an evaluation rubric, a process executed from understanding alone. The reader's AI ABSORBS it and applies it across future tasks: a knowledge base for many purposes, not a one-shot answer.
• A hybrid defaults to AGENT. An automation that carries a methodology inside it ships as AGENT: the build subsumes the knowledge, and the method rides inside the built tool.
• Operator override (--type knowledge | --type agent). The operator can force the verdict at invocation. Main use: the KNOWLEDGE cut of a hybrid, extracting the method that lives inside an automation and shipping it as a knowledge skill with the build machinery left out of the spec. A forced verdict runs that mode's full pipeline and never changes the safety model. If the forced type plainly cannot fit (a pure automation with no articulable method forced to KNOWLEDGE), say so and ask instead of shipping a hollow prompt.

In KNOWLEDGE mode the build-shaped phases COLLAPSE into their knowledge analogs. Everything else runs unchanged.

1. The deliverable directive: REDACT-IN-PLACE, never re-author. Ship the capability's SOURCE FILES VERBATIM, changed only by targeted redactions (identity, rig-specific references and cross-links, personalized examples, excluded third-party IP). Do not re-author, summarize, compress, or restructure the method: for knowledge the content IS the capability, provable fidelity beats asserted fidelity, and the diff between source and shipped files is the complete audit of what changed. Preserve the capability's own file structure: a small router plus on-demand reference files survives as exactly that, because the separation is load-bearing (it keeps the skill from occupying context it does not need on hosts that load files on demand). The deliverable is a short INSTALL PROMPT shipped WITH the files, directing the reader's AI to install them unchanged and apply the method whenever the domain comes up, unprompted. Two mechanical assemblies of the same redacted files cover distribution: a folder kit (install prompt + files) for direct sharing, and, where delivery needs one paste-able block, the install prompt with the files embedded as clearly delimited blocks the AI writes out to their paths.
2. Interactive open (Phase 3.5): retuned, still first. The AI's first action: state in one or two lines what know-how it is receiving, that nothing will be installed beyond one skill file and nothing connected, then ask to proceed.
3. Build-safety contract (Phase 4) collapses to persist-safely. Write the files, unchanged and layout preserved, into ONE clearly named folder where the host persists reusable knowledge. On a host that holds only a single instruction blob, concatenate the files router-first (lossless; the routing table then points at the sections below it). If a skill of that name already exists, back it up beside itself and ask before overwriting. Nothing else is written.
4. Host detection (Phase 5) collapses to one probe. Detect where this host persists reusable knowledge: a skills directory, custom instructions, project knowledge, a system-prompt slot. Ask only to disambiguate. If the host persists nothing, apply the method in-conversation and tell the human it will not survive the session.
5. Dependency self-check (Phase 6) collapses to one line. A knowledge capability normally needs no accounts, keys, or tools; the AI says so in its open. In the rare case the method requires a tool to execute, tier that one dependency exactly as Phase 6 defines.
6. Extend-don't-duplicate (Phase 7) stays in full; it is load-bearing here too. If the host already carries a comparable skill or instruction set over the same domain, the AI stops and reconciles with the human: extend it, replace it, or keep both under clearly distinct names. Two overlapping instruction sets silently steering the same answers is the knowledge analog of two mutators on one resource.
7. Optional-feature choice (Phase 8): nothing to wire. Skip it entirely; do not stage an empty pop-up.
8. Interview (Phase 9) collapses to a minimal calibration. At most one or two questions, via the interactive question UI: the reader's industry or business model, or whichever single axis most changes the method's defaults. Persist the answers next to the skill so every later application starts pre-fitted. Skippable on request; never the full role-first interview. Why minimal: a knowledge install must feel like zero setup, and one calibration question is the difference between generic advice and fitted advice.
9. Go-live (Phase 9.5) becomes proof-of-absorption. The AI asks the human for ONE real, current example in the method's domain and applies the freshly installed skill to it end to end, so the human sees the know-how working on their own material before trusting it. The placeholder sweep runs as written. The usage handoff closes: how to invoke it later, how to re-calibrate, how to remove the skill file.
10. CORE vs SHELL (Phase 2) still runs, with the knowledge twist. CORE: the files themselves, verbatim, INCLUDING their structure (the router-plus-references separation is part of the capability). SHELL: only the persistence location, the single-blob concatenation fallback, and the calibration values.

The repeatable knowledge build procedure (run it the same way every time):

1. Copy, never retype. Create the kit folder (named for the capability slug, in the library) and copy the in-scope source files into it with the filesystem, preserving names and layout. Byte-fidelity starts here: a retyped file is a re-authored file. Excluded files (operator IP calls, per-context config, runtime state) are excluded by not copying them.
2. Build the redaction target list from extraction, then redact by minimal in-place edits on the copies. The standard hunt list for a knowledge source: cross-references to the operator's OTHER skills, slash-commands, or rig components (routers, scoring rubrics, optimizer and scheduler hooks); the operator's assistant-tool names (generalize to the generic mechanism); operator-flavored example values (swap to synthetic values of the same shape); references to operator-private frameworks defined OUTSIDE the shipped files (remove, generalize, or inline the definition, because a stranger's AI must never hit an undefined reference); and any mention of an excluded file (table rows, links).
3. Residual sweep until zero. After redacting, grep EVERY target term across the ENTIRE kit and iterate until the total is 0. A first pass reliably misses repeat mentions of the same term in a file judged clean on a different target; the sweep is what catches them.
4. Isolation check: the kit must stand alone. Confirm the kit references nothing outside itself except optional third-party tools: no slash-command patterns, no excluded-file names, no rig component names; internal references point only at files inside the kit. Zero hits, or the build is not done.
5. Instantiate the install prompt from references/knowledge-install-prompt.md. Fill every [SLOT] (capability name, file list in router-first order, calibration question and what it re-tunes, proof shape) and ship the instantiated INSTALL-PROMPT.md inside the kit. The template itself is never shipped, and the wrapper is never re-invented per run.

What never changes in KNOWLEDGE mode: Phase 1 extraction fidelity, the full Phase 3 strip (registry tiers, tool categories, synthetic data), the AI-runbook voice, the conditional injection guard, the 4/4 leak gate (which adds knowledge-only checks; see Phase 10 pass 3), and the Phase 11 ship mechanics. The size verdict still applies: a small heuristic set ships LEAN, a multi-part framework ships FULL. In the publish gate, the per-mechanism lines record the collapsed knowledge analog where one applies (persist-safely on the build-safety line, proof-of-absorption on the go-live line), never a false "n/a".

Lifecycle: manifest sidecar, drift detection (operator-side, NEVER shipped)

A shipped prompt detaches from its source the moment it leaves the machine. These mechanisms link a detached copy back to its source and flag when it has gone stale, WITHOUT ever putting operator data into a shared artifact. Everything here is operator-private, lives beside the library, never inside a prompt.

Manifest sidecar (written on ship). When a prompt ships (Phase 11), write a manifest at the library's _manifests/<capability-slug>.json recording:

• capability_slug — the generic slug used in the filename and index.
• shipped_file — the path of the prompt that shipped.
• prompt_version — integer, incremented each time this capability is regenerated (operator-side only; NOT stamped into the shipped prompt).
• generated_date — the generation date (operator-side only; NOT stamped into the shipped prompt).
• source_paths — the source files the spec was extracted from (Phase 1).
• source_fingerprint — a hash of that source AT GENERATION TIME, so later drift is detectable.
• skill_version — this skill's version.
• audience_class — public-safe or the named audience class.
• output_type — agent or knowledge (the Phase 1 type verdict).
• published_copies — optional list of paths the shipped file was copied to for publishing (a website's public folder, a docs repo). Operator-side; extends drift detection to deployed copies.

This file is operator-side ONLY and is NEVER part of a shipped or shared artifact. Its source_paths and source_fingerprint are operator data and would fail the leak gate; it exists so the operator can trace a shipped prompt back to its source and detect drift. The shipped prompt itself carries NO embedded provenance, so the manifest is the SOLE record of version, date, fingerprint, and audience; _manifests/ is never distributed — same never-share posture as the registry.

Check-stale drift mode (portable-prompt --check-stale). A maintenance invocation: walk every manifest in _manifests/, re-hash each manifest's source_paths, and compare to the stored source_fingerprint. Report which shipped prompts were generated from since-changed source, as an actionable list (capability, shipped version, what changed). This turns a silently-stale fork into a regenerate list. It is cheap (hashing only — no extraction, no authoring), runs entirely operator-side, ships nothing, and touches no reader. It does not regenerate anything; it only reports what is stale so the operator can choose what to re-ship. When a manifest lists published_copies, also hash the shipped file against each listed copy and report any deployed copy that no longer matches the current shipped version: a regenerated library prompt must not leave a stale copy live where the operator publishes.

The pipeline (numbered phases)

Run these in order. Phase 1 extracts; phase 2 classifies every element CORE vs SHELL; phase 3 strips and broadens; phase 3.5 writes the interactive OPEN the AI runs first; phases 4–9 are the self-contained mechanisms the generated prompt MUST carry, all written as AI directives per the top-level rule; phase 9.5 is the go-live the AI self-verifies plus the usage handoff; phase 10 is the fail-closed leak gate; phase 11 ships with a printed, self-falsifying publish gate.

Phase 1 — Extract the real system from source (never from memory)

Read the actual source that implements the capability — the skill doc, scripts, config, hook file, automation export (such as an n8n / Make / GoHighLevel export), or process notes. Capture the architecture, the hard guarantees, the pipeline, the schema, the exact responsibilities of each part, and every dependency the capability touches. Verify EVERY claimed capability against source.

• Never transcribe the operator's recollection as fact. They may misremember a feature the live system does not have.
• A capability the source does not have is not a rule. Drop it, or label it NET-NEW (see Safety) and get an explicit yes before adding it.
• Parallel readers: fan out one reader per source file (the doc, each script, each config, the workflow export) so the spec is assembled from what the system actually does, not a single skim.
• Read code for BEHAVIOR only — STRIP every comment at the source boundary. Never copy a source comment, docstring, commit message, changelog line, or TODO/FIXME into the spec or the output. These are the highest-density identity leak: they carry the author's name, project names, internal reasoning, ticket ids, dates, and in-jokes. Extract what the code DOES, then write fresh generic prose. A surviving comment block is caught again at the gate (Phase 10, default-deny sub-check), but the discipline starts here.
• Extract the universal skeleton; exclude per-context config and runtime state at the source boundary. When a capability separates a universal core from per-context / per-tenant configuration (context config dirs, audience-specific rule files) or from runtime state (ledgers, caches, processed-ID stores), read ONLY the universal core for a public-safe build. Config and state are operator data: what never enters the spec can never leak, so exclusion here beats stripping later. A named-audience build may read that audience's OWN config as Tier B material, under the audience rules.

Phase 2 — Classify every element CORE vs SHELL (the spine that lets "rebuild faithfully" and "adapt to my system" coexist)

Before authoring, tag every element the extraction surfaced as exactly one of two kinds. This split is what lets the generated prompt rebuild the capability faithfully AND fit the reader's own machine at the same time. Output is a two-column CORE-vs-SHELL table the author phase (Phase 3) consumes.

• CORE — rebuild byte-faithfully. The parts that ARE the capability and carry its guarantees: the safety guarantees, the gates, the invariants, the algorithm, the separation-of-concerns / responsibilities, the ordering that makes it correct, the failure-mode handling. CORE is reproduced exactly. It does not bend to the host.
• SHELL — adapt to the host. The parts that are incidental to the operator's machine and MUST be re-fitted to the reader's: implementation language, file layout, file count, module / directory naming, the scheduler, the secrets location and format, the config format, the install root. SHELL is a contract to satisfy, not a layout to copy.

State BOTH failure modes plainly, because they pull in opposite directions and the table is what keeps them apart:

• Adapting a CORE element is a bug — it drops a guarantee. Re-implementing the gate "a bit looser", reordering steps that were ordered for safety, or paraphrasing an invariant until it no longer holds, all silently break the capability. CORE is faithful or it is broken.
• Failing to adapt a SHELL element is the over-faithfulness bug — it clones the operator's exact tree onto the reader. Shipping the operator's file paths, language choice, directory names, or scheduler as if they were the capability fingerprints the operator AND forces a layout the reader does not use. SHELL is mapped to the host or it is over-faithful.

The CORE-vs-SHELL table is mandatory and feeds Phase 3 directly: Phase 3 broadens and host-recasts only the SHELL rows, and preserves the CORE rows verbatim.

Phase 3 — De-personalize hard, broaden swappable tools to categories, and recast SHELL as a responsibility spec

Strip ALL owner-specific data per the registry policy and replace every real value with a placeholder. Strip the full Tier 0 (secrets) and Tier A (people / personal infrastructure / side-projects) sets as the two-tier-strip section defines them — that is the canonical target list; do not re-judge it here. ON TOP of those tiers, Phase 3 also strips three presentation-level tells the tiers do not name: personal voice idiosyncrasies / brand casing / any one person's forbidden-word list; multi-context routing and any owner-specific category set; any single named channel, inbox, account, platform tenant, or destination. Replace with placeholders: [YOUR_WORK_EMAIL], [API_TOKEN], [ROLE_OR_TITLE], [CONTEXT_NAME], <namespace>, [YOUR_PROJECT_PATH], and so on. Keep ONLY the generic system. The base must run for any operator, any account, with zero owner residue.

Classify every personal element three ways — do NOT treat all personalization as strip. Stripping every preference over-strips USEFUL, non-identifying defaults and hands the reader a hollow tool. Tag each personal element the extraction surfaced as exactly one of three kinds, and act on it here:

1. IDENTITY-PERSONAL → STRIP, absolute. Anything that reveals who / what / which: a person name, the operator's specific people / VIPs, a project, an employer, a secret, or a distinctive constant that fingerprints the operator. This is the Tier 0 / Tier A set above. NEVER kept, under any audience. The 4/4 leak gate (Phase 10) enforces it regardless of anything below.
2. READER-SPECIFIC CHOICE → RE-SET via the interview (do NOT keep the operator's value). A preference whose RIGHT value differs per person: the operator's own VIP list, their category names, their voice, their personal thresholds. Strip the operator's value and leave the slot for the reader — the role-first new-user interview (Phase 9) sets the reader's own value.
3. TRANSFERABLE PREFERENCE → KEEP as a labeled, changeable DEFAULT. A preference that (a) reveals NO identity / project / employer / secret AND (b) is genuinely useful general advice most readers would benefit from (generic shapes: "batch meetings and propose afternoon slots", "book the latest acceptable slot", "archive newsletters aggressively"). Do NOT strip these. Carry them into the generated prompt as an AI directive that names the default and tells the AI to surface it in the interview for a keep / change: Default (a sensible preference from the original build): <rule>. Treat it as the starting value and offer the human a keep-or-change in the interview. The Phase 9 interview surfaces each kept default.

THE HARD GUARD (this is the whole point): a preference qualifies as TRANSFERABLE only if it passes ALL FOUR leak-gate passes. "It's a useful preference" NEVER overrides the leak gate. If a rule names a person / project / employer, encodes a secret, or is a distinctive constant that fingerprints the operator, it is IDENTITY-PERSONAL and is stripped — no exception. When unsure whether a preference reveals identity, treat it as identity-personal (strip) or reader-specific (re-set via interview); only a clearly-clean, clearly-useful general preference is KEPT. The carve-out RELAXES nothing in the gate: it changes only whether a GATE-CLEAN preference is deleted or kept as a labeled default.

Recast every SHELL element as a RESPONSIBILITY spec, not a prescriptive layout. Phase 2 tagged the file tree, module names, language, and scheduler as SHELL. Here, do NOT carry "create THIS exact layout" into the output. Convert any prescriptive file tree into a list of RESPONSIBILITIES and their safety boundaries — the responsibilities and boundaries are CORE and stay; the file / module layout that realizes them is the reader's and becomes a directive: "place these responsibilities wherever they fit in the host project, one module per responsibility, keeping the boundary between [X] and [Y]". The host-detection step (Phase 5) then maps these responsibilities onto the reader's actual conventions.

Broaden swappable tools to categories (also a leak-prevention measure). Wherever the source names a tool that is interchangeable (a SHELL choice), recommend it in the generated prompt as a CATEGORY with two or three interchangeable examples, never as the one named product the operator happens to use: "a task manager such as Notion, Airtable, or similar"; "an automation platform such as n8n, Make, or Zapier"; "a CRM such as HubSpot, GoHighLevel, or similar"; "a spreadsheet such as Google Sheets or Excel". This does two jobs at once: it lets the reader use what they already have, and it stops the output from fingerprinting the operator's specific stack (which is itself a Tier A leak signal — a distinctive tool combination can identify a person). Name a tool specifically ONLY when it is structurally inherent to the capability itself (e.g. the IMAP / SMTP protocol for an email tool, OAuth for a consent flow, the runtime a script is written in). Even then, frame it as the READER's own account / install, never the operator's, and never tie it to the operator by name.

The widen test: run it on EVERY named tool, and know which of three things a narrow name costs you. Ask one question per named tool: if the reader used a different tool in this category, would this instruction still be correct? A YES means the tool is SWAPPABLE and gets widened to itself plus two or three equivalents. A NO, because the capability genuinely depends on that tool's protocol, format, or behaviour, means it is STRUCTURALLY INHERENT: name it alone, and say in one clause what it stands in for, so a reader on a different stack knows what to substitute rather than guessing. Do not decide by how famous the tool is. A single named host, deploy platform, code host, browser driver, static server, or config format is swappable far more often than it looks.

Three distinct failure modes, and the third is the one that actually breaks a reader's build:

1. Over-strip. Widening a structurally inherent tool into a vague category leaves the reader unable to act ("use a version-control host" when the capability parses one host's specific API response shape).
2. Over-faithful. Keeping the operator's single tool narrows the advice and fingerprints the stack. This is the well-known one.
3. Silent wrong answer (highest priority to fix). When the named tool sets a FORMAT the capability READS or a PATH it WRITES, naming only that tool does not merely narrow the advice: the capability returns a confidently WRONG result for every reader on a different tool, with no error. A parity checker that only understands one deploy platform's redirect file reports another platform's correctly-redirected URLs as MISSING. A scanner that only knows one config filename reports a configured project as unconfigured. Hunt these first: any place the capability reads a named tool's file format, config path, or API shape is a silent-wrong-answer site until widened or explicitly scoped.

How widening works in KNOWLEDGE mode (where redact-in-place forbids re-authoring). These two rules collide, so resolve it the same way every time: tool-widening is a BOUNDED ADDITIVE EDIT, not a rewrite. You may add equivalents alongside the tool the source already names, and add a short clause naming what a reader on another stack substitutes. You may NOT restructure the surrounding prose, re-order the method, or drop the original tool: the source's own example stays, it simply stops being the only option. Every widening is recorded in the manifest as its own change class, separate from the redactions, so the fidelity diff still audits cleanly.

Do not over-widen. Two cases are already correct and must be left alone. First, a list that already carries two or more equivalents is done ("Astro, Next.js export, Hugo, Eleventy, plain HTML, anything producing a dist/out/build folder" needs nothing). Second, a tool-SELECTION capability, where comparing named tools IS the method: widening the names there deletes the content. In that case record the decision rather than applying the rule blindly.

Synthetic data only — never lift an example value. Every illustrative value in the generated prompt — names, emails, domains, companies, figures, dates, scenarios — MUST be synthetic and obviously generic: "Acme Ltd", "jane@example.com", "example.com", "$X", "[N] days", "Q[N]". Never lift an example from source, and never lift one from any first-scan output th

…(truncated)