agentsclimarketplace
Sign in

Software advertising defense

Skill whyy9527/software-advertising-defense

Guard against vendor marketing and SEO drift when choosing software, SaaS, APIs, search providers, frameworks, MCP servers, or developer tools. Use when the user asks what software/tool/API to use, asks to search for options, or a task involves adding external services, fallback providers, paid APIs, or "production-grade" tooling. Prevents adding requirements the user did not ask for after reading vendor pages.From its SKILL.md

Install
npx -y skills add whyy9527/software-advertising-defense

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, 674 tokens by cl100k_base, as published. Nobody here has run it

Software Advertising Defense

Use When

  • The task involves choosing, recommending, or comparing software, SaaS, APIs, search providers, frameworks, MCP servers, or developer tools.
  • You are about to browse for "best tool", "production API", "open source alternative", "provider", "adapter", "fallback", or pricing.
  • Search results are dominated by vendor landing pages, product docs, SEO comparisons, sponsored-style pages, or provider claims.

Failure Mechanism

Vendor pages and SEO results are optimized to create a broader buying frame than the user's actual problem. An agent can mistake "available product category" for "required architecture", then add unnecessary requirements such as unattended automation, fallback providers, paid API options, billing preflights, or enterprise-grade abstractions.

This is especially harmful in agent workflows where the right answer may be "use the current LLM/websearch workflow and log it" rather than "introduce a new software dependency".

Procedure

  1. Restate the user's actual requirement in one sentence before naming products. Include explicit non-requirements the user has stated.
  2. Ask whether the problem is a workflow/process issue or a software capability gap. Prefer process changes when the existing tool already works.
  3. Classify sources before trusting them:
    • Primary docs: useful for capabilities and limits, not for deciding need.
    • Vendor landing/pricing pages: marketing input, not architecture evidence.
    • Comparison blogs and SEO pages: low trust unless backed by direct tests.
    • Local verified trials: highest weight for this user's workflow.
  4. Do not introduce a paid service, third-party API, fallback provider, billing preflight, or unattended automation unless the user explicitly asked for that capability or local verification proves the existing workflow cannot meet the need.
  5. If browsing was used, separate "what exists" from "what we should do". A tool being available is not a reason to adopt it.
  6. For repo documents or ADRs, remove speculative provider lists when the decision is to keep the current workflow. Add only the boundary the user requested.

High-Risk Prohibitions

  • Do not convert a repeated human-in-the-loop workflow into an unattended system unless the user asked for unattended operation.
  • Do not add "backup" providers or fallback APIs just because search results advertise them.
  • Do not cite pricing/free-tier claims as a reason to expand scope.
  • Do not let vendor terminology redefine the user's architecture.
  • Do not bury "not doing X" under a long list of future options; state the boundary plainly.

Verification

Before finalizing a recommendation or doc edit, check:

  • The proposed solution satisfies the user's stated need without adding unrequested capabilities.
  • Any external product mention is tied to a verified gap, not to vendor claims.
  • Current local tools/workflows were considered before adding dependencies.
  • Repo docs do not contain speculative provider lists, billing setup steps, or fallback plans when the decision is to avoid them.
  • If the user pushes back on scope, remove the extra scope instead of defending it as future-proofing.

What ships with it: 3 files

3.0 KB alongside SKILL.md

Gives 0 of the 12 instructions most marketing audience skills give in 674 tokens

Counted across 690 of the 894 authors here whose files we hold, read 2026-08-07

  • Apply Poppins font to headingsin 41 of 690, across 6 files
  • Apply Lora font to body textin 41 of 690, across 6 files
  • Use Arial fallback for headingsin 39 of 690, across 4 files
  • Use Georgia fallback for body textin 39 of 690, across 4 files
  • Maintain text hierarchy and formattingin 39 of 690, across 4 files
  • Use accent colors for non-text shapesin 38 of 690, across 3 files
  • Use RGB values for precise color matchingin 38 of 690, across 3 files
  • Use brand colors for primary text and backgroundsin 36 of 690, across 1 file
  • Read product marketing context file before asking questions, starting, or auditingin 35 of 690, across 23 files
  • Use active voice instead of passive voicein 26 of 690, across 10 files
  • Implement or generate appropriate JSON-LD structured datain 24 of 690, across 17 files
  • Prioritize clarity over clevernessin 22 of 690, across 8 files

Said here and by no other author read

  • restate the actual user requirement before naming products
  • prefer process changes over adding new dependencies
  • classify sources by trustworthiness before citing them
  • separate what exists from what to do
  • remove speculative provider lists from repo documents
  • verify the solution satisfies the stated need

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,835. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.