Use when adding, updating, removing, reordering, or auditing sponsors, affiliate links, sponsor copy, logos, public sponsor-catalog JSON files, README sponsor sections, or documentation-site sponsor listings in all-api-hub.
SkillScore82Maintained
Automatic
◆Marketing & Content pack
Last verified 9/9/2026
What it changes
Passed 15 of 18 test cases with the skill, and 9 of 18 without it.
Without skill50%
With skill82%
Checks it passed that the model alone missed
The response recommends executing git status --porcelain.
The response references references/catalog-compatibility.md.
The response specifies running pnpm --dir docs run docs:build.
and 5 more in the full report
8 fixed10 passed either way3 still failing1 broke
Pass-rate lift
+32 pp
Tokens
+12%
Agent turns
0%
Response time
-33%
Model gemini-3.6-flashMeasured 9/9/2026v218 of 22 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
I'm starting a task to update a partner's logo. Before touching any files in the workspace, what exact command should be run to inspect existing dirty files?
What was checked, without and with the skill
Checked
Without skill
With skill
The response recommends executing git status --porcelain.
Missed
Passed
case-07 · gemini-3.6-flash · 9/9/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md48 lines2 files
Sponsor Catalog
Core principle
Treat sponsor content as coordinated production configuration. Discover the current surfaces, verify operational claims, and update every still-served catalog schema that can safely represent the campaign.
Workflow
For an audit or review, use discovery and relevant compatibility guidance to report findings and coverage without editing, staging, or committing. Read public documentation or check ordinary non-affiliate links when needed to establish the findings; affiliate probing follows the campaign-facts rule below. The update and delivery steps apply only to authorized changes.
Inspect repository state and current ownership before editing.
Run git status --porcelain and preserve unrelated work.
Search for the sponsor name, domain, or asset to identify affected listings and catalogs. Read matching entries first; inspect runtime owners under src/features/AccountManagement/sponsors/ and the catalog test when schema or behavior matters.
Discover every served public/sponsor-catalog*.json when catalog content is in scope; inspect neighboring sponsors when ordering or established presentation matters.
Consult recent sponsor commits when current surfaces leave scope or compatibility unclear. Read a relevant rollout only when the needed historical decision is not established by current files or commits.
Load compatibility guidance when software or public JSON is in scope.
Read references/catalog-compatibility.md before choosing schema coverage, support status, actions, or rank.
Prefer current code, public artifacts, tests, and release tags over stale design documents.
Separate campaign facts from product integration facts.
Preserve user-supplied copy, affiliate URLs, and promotion terms in production surfaces only.
Verify any inferred site type, authentication type, API base URL, key-console URL, or direct-support claim against the target deployment, upstream source, or current repository behavior.
Keep the affiliate destination separate from operational URLs. Do not derive an API base URL or account origin from a marketing link.
Do not probe live affiliate URLs unless the user requests it.
Update the complete discovered surface.
Treat root READMEs, the Chinese docs source, relevant docs pages, public catalogs, and resources/partners/ as the starting checklist, then let repository search and history determine the final set.
Follow the repository's Documentation policy for source-first editing and the final translation-sync decision; this does not defer required locale data in shipped public catalogs.
Inspect the supplied image format, pixel dimensions, aspect ratio, and existing presentation classes or attributes. Rename it to the established slug convention and align displayed dimensions without unnecessary re-encoding or new CSS.
Keep prose order, physical JSON order, and runtime rank as separate decisions. Implement each ordering request explicitly.
Validate and hand off.
For data, copy, and asset-only changes, do not add tests by default. When public catalog data changes, run the existing focused catalog test; prose or image-only changes need only relevant content/link/presentation checks:
pnpm vitest tests/features/AccountManagement/sponsors/publicCatalog.test.ts --run
When docs surfaces change and dependencies are available, run pnpm --dir docs run docs:check-links and pnpm --dir docs run docs:build as risk warrants.
Run git diff --check and inspect the task-scoped diff. When committing, stage only task files and let the pre-commit hook run validate:staged once; reuse valid focused checks instead of duplicating the hook gate.
Use docs(sponsors): ... for copy, catalog-data, and asset-only changes. Choose feat or fix only when the final diff changes executable behavior.
Report intentionally omitted catalog versions with concrete compatibility reasons when catalog updates are in scope. Explain analytics or browser-E2E decisions only when behavior or an unresolved risk makes them relevant.