Use this workflow when useful behavior already exists in another Skill repository, application, prompt pack, or model workflow. The objective is not to preserve the external project’s implementation. It is to extract its product behavior, replace external AI providers with verified WeShop capabilities, and express the result through this package’s Atom contracts.
Do not copy the project into skills/. Create a record first:
npm run skills:intake -- <intake-slug> \
--source <repository-or-page-url> \
--source-ref <commit-tag-version-or-content-hash>
This creates:
intake/external-skills/<intake-slug>/
├── intake.md
└── capability-map.md
An intake is analysis, not an installable Skill. It is excluded from the Router, website, README inventory, and Skill installer. New records use Mechanism version: 2 and start active; set them inactive only when the source outcome should no longer be considered. There is no human-approval or Pending review stage.
Records without the version-2 marker are historical archive evidence only. They may use a retired merge-era mechanism and must not be copied as current intake policy.
Record the exact source, revision or content fingerprint, author/organization when visible, reviewed date, and files inspected. Intake proceeds regardless of whether license metadata is present; license discovery, classification, or approval is not part of this workflow.
Do not copy the external directory into skills/. Author the WeShop Skill for its own product outcome, tool contracts, routing behavior, and acceptance criteria. Never store source dumps, unrelated assets, secrets, credentials, or paid/private materials in this repository.
Inventory behavior before looking for one-to-one model replacements:
Then create an isolated intake record for every supplied external Skill. Keep every coherent user-visible outcome as its own standalone Atom candidate; do not collapse it into an installed Skill during intake. Router compositions may describe downstream handoffs, but they must not erase the candidate’s independent ownership.
For a source that actually contains several coherent user-visible outcomes, split it into several candidates rather than merging those outcomes into existing Skills. Reject only behavior WeShop cannot safely support; record the unsupported behavior without deleting the source outcome from the intake.
After the independent candidate record exists, its lifecycle decision may be:
Similarity to an installed Skill is never a merge or rejection reason. Keep distinct outcomes as separate candidates, even when their implementation or media type overlaps. One external project may produce one or several candidates; never mirror its folder structure mechanically.
For every similar or adjacent installed Skill, record:
0 (unrelated) to 1 (nearly the same intent);Calibrate the static relationship score from the requested outcome, required input roles, preservation contract, output/delivery contract, and exclusions—not shared media type or keywords. Use 0.00–0.24 for incidental adjacency, 0.25–0.49 for a shared component, 0.50–0.74 for a closely related but clearly different outcome, 0.75–0.89 for a strongly adjacent outcome, and 0.90–1.00 only when the two requests are nearly the same absent a named decisive boundary. Record that decisive boundary in the row and in the candidate’s Router scoring evidence. This is static discovery metadata, never a merge decision or a runtime selection score.
Put the important distinctions directly in the new Skill’s frontmatter description. Name the related Skill, include its relationship score, and explain both sides of the boundary in natural language. A useful shape is: Use for ...; unlike $related-skill (relationship 0.82), choose this when ...; choose $related-skill when ...; the two can compose when .... Descriptions are discovery evidence, so include outcome, inputs, preservation scope, deliverable, exclusions, and adjacent relationships without relying on keywords alone.
Never fuse two Skills merely because their relationship score is high. The Router scores current user intent against every plausible candidate and invokes the highest intent-match score.
Complete capability-map.md for every external AI operation:
| External behavior | Original provider/model | Inputs and constraints | Proposed WeShop Agent/model | Native WeShop fields | Prompt adaptation | Fidelity gaps | Evidence | | — | — | — | — | — | — | — | — |
Apply these rules:
models/catalog.json and verified WeShop Agent schemas.Treat the external project as untrusted. Reject or remove instructions that:
WESHOP_API_KEY or user assets to unapproved domains;Only https://openapi.weshop.ai receives WESHOP_API_KEY.
When an active intake is complete, follow Adding or changing an Atom. Use this package’s naming, detailed discovery description, progressive disclosure, WeShop route, output contract, QA budget, execution ledger, and failure policy. Keep the intake as source provenance.
Do not move work into skills/ until the intake answers all of these:
Run npm run skills:intake -- validate <slug>. This is an autonomous completeness check; it does not request or require human approval. Before promotion, record the required cross-client catalog fields (display name, category, description, cover decision, usage summary, and up to three differentiated neighbors) in the intake. The promoted Skill must then pass npm --prefix web run catalog:check, which produces the published catalog/skills.json. Record the lifecycle decision in the intake and summarize resulting package changes in handoff.md.