Shaduf.Research preview
Marketing Skills Catalog/One-skill install documentation boundary

Research report · 15 October 2026 · Run 25

One-skill install: documented scope, not a tested payload

The repository documents named-skill selection and a one-skill ZIP design. Neither document shows the files an actual CLI install or archive would place in a particular host. Keep four conditional active cards, two historical nonrecommendations, and the stop before any install recommendation.

What each route actually documents

Named CLI selectionThe repository README gives npx skills add coreyhaines31/marketingskills --skill cro copywriting as a specific-skills example. The linked installer README defines --skill as named selection and --list as enumeration. Project/global and symlink/copy modes are documented; none was executed here.
One-skill release ZIPThe source-owned packaging design says one archive contains the named skill folder, authored references/scripts/assets and license, excluding other skills and the rest of the repository. It says the archive does not add a CLI, MCP server, credentials or marketing context. The author says live client upload remains unverified.
Full-library routesThe repository's plugin and clone/copy options select or copy the wider library. That does not make them a prerequisite for one local draft. A documented route is not an observed install, exact file inventory, permission set or host compatibility result.

Substituting --skill emails in the example is a syntax inference, not a command run for this research. No ZIP, manifest or CLI-selected files were downloaded, hashed or inspected.

Resource boundary by selected skill

Selected sourceNamed in-skill resourcesOutside the one-skill boundaryNot established
copywritingCopy frameworks, AI-tells and natural transitions were reachable on 15 October. The ZIP design promises authored same-skill resources.Related skill names do not show that those skills are installed by a one-skill selection.Actual ZIP contents, CLI file set, selected-file SHA/date, full revision delta and host loading.
emailsSequence templates, email types and copy guidelines were reachable; same ZIP design applies.The full AI-tells page lives under copywriting. The separate tools/ registry and provider guides describe implementation routes. The ZIP design excludes other skills and the rest of the repository.Whether a CLI-selected emails payload includes or resolves cross-skill pages or tools; host/provider behavior and permissions.

Reachable URLs are not installed files. The directory listings returned by the broker were a month old. One old Copywriting listing omitted the AI-tells page reachable on 15 October; that mismatch is not proof of present absence. These age labels are crawl ages, not commit dates.

Copywriting freshness and instruction

The mutable selected text displayed version 2.2.0 on 15 October, after the 2.1.0 observation on 12 October. The currently inspected text directs supportable claims, an evidence-unlock note for declined claims, and a pre-handoff AI-tells self-check. This does not establish the latest selected-file SHA/date, full 2.1.0→2.2.0 delta, present inventory or output quality.

Source instruction versus pool treatment: The source directs the AI-tells check. This catalogue treats it only as optional style review, not a validated detector or buyer-response/conversion test. A named claim/proof/rights/CTA review and separate publication gate remain catalogue controls, not source-enforced proof that a draft is safe to publish. The emails selected text still displayed 2.1.3 on 15 October; its pin and complete delta remain open.

Stop before an install or action

The repository calls product-marketing a conceptual foundation, and both selected files conditionally direct a local product-marketing-context read if present. Neither inspected selected-file passage expressly requires installing that skill, a whole repository, credentials, ESP setup or a send to produce a local Markdown draft. Local context still needs authorization; a different host or revision could behave differently.

Before recommending an install or same-brief comparison: pin the intended selected revision; enumerate and hash the exact archive or CLI payload, including reference resolution; review installer version, mode, host and permissions; obtain a consented non-sensitive brief and read scope; use fixed omission and claim-to-proof criteria against the owner template. A named owner reviews proof and exact CTA. Recipient-policy and ESP owners separately decide eligibility, consent, suppression, overlap, timing, import, setup, test, schedule and send. No brief, package, archive, CLI, account, draft, send or outcome was tested. Documentation alone establishes no compatibility, security, privacy/legal safety, quality, deliverability or marketing result.

Current catalogue · Research library · Earlier dated boundaries: Copywriting claim/proof and Email implementation links.

Search published pools, pages, reports, and evidence.