Run any Skill in Manus with one click

share-ready

Stars2

Forks0

UpdatedJuly 6, 2026 at 11:23

Audits and fully configures how a website looks when shared (Open Graph, Twitter/X cards, WhatsApp/Discord/Slack previews) and in the browser (title, favicons, theme-color, web manifest), generating missing assets and verifying the result locally. Use when setting up link previews, og:image, favicons, social sharing metadata, or when a shared link "looks wrong" on a platform.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tomimor

tomimor/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Web DevelopersComputer and Mathematical Occupations·SOC 15-1254

File Explorer

8 files

SKILL.md

readonly

name	share-ready
description	Audits and fully configures how a website looks when shared (Open Graph, Twitter/X cards, WhatsApp/Discord/Slack previews) and in the browser (title, favicons, theme-color, web manifest), generating missing assets and verifying the result locally. Use when setting up link previews, og:image, favicons, social sharing metadata, or when a shared link "looks wrong" on a platform.

Share Ready

Make a site's link previews and browser presentation complete: audit what exists, implement what's missing in the project's idiomatic way, generate the image assets, and verify everything end-to-end.

Workflow

Five phases, in order. Don't skip the audit — most projects have partial metadata, and duplicating tags is itself a bug (scrapers pick one arbitrarily).

Phase 1 — Detect the framework

Check, in order: next.config.* (Next.js — App Router if app/ exists), astro.config.* (Astro), nuxt.config.* (Nuxt), svelte.config.* (SvelteKit), vite.config.* + index.html (Vite SPA), plain *.html (static). The implementation route for each is in references/frameworks.md — read it before writing any code in Phase 4.

Phase 2 — Audit what exists

Find the current <head> (or metadata config) and every existing asset. Build a three-column table: tag/asset → present? → correct?, covering every row of the checklist in references/checklist.md. "Present but wrong" matters as much as missing: relative og:image URLs, SVG og:images, oversized images, duplicate tags, twitter:card absent so X renders a small summary instead of a large card.

Show the audit table to the user before changing anything.

Phase 3 — Gather content: infer first, ask only gaps

Infer from the repo before asking anything:

Field	Infer from
Site name	`package.json` name, README H1, existing `<title>`
Description	`package.json` description, README first paragraph, hero copy
Canonical URL	`homepage` in package.json, CNAME file, deploy config, README links
Theme color	CSS custom props / tailwind config primary color, existing `theme-color`
Source logo	`logo`, `icon` in `public/`, `assets/`, `static/`, root; existing favicon
Locale	`<html lang>`, i18n config

Then ask the user — one batched round of questions — only the fields that are missing or ambiguous — typically: marketing-quality description (the inferred one is often dev-facing), production URL if not deployed yet, X/Twitter handle (twitter:site), and which image to use as the icon source if none found. Propose the inferred values as defaults so a single "looks good" answer can approve everything.

Phase 4 — Implement

Write the complete metadata set using the framework-idiomatic route from references/frameworks.md. The canonical target — every tag, attribute, and recommended value — is references/checklist.md. Rules that apply regardless of framework:

Fix, don't append. Replace wrong/duplicate tags; never leave two og:titles in the document. When a replacement orphans an old asset file (a retired favicon, a superseded og image), list it in the report so the user can delete it — don't delete user-created files yourself.
og:image and og:url must be absolute URLs (scheme + host). This is the single most common breakage.
Per-page vs site-wide. Site-wide defaults (site_name, favicon, theme-color, manifest) go in the root layout/template; page-level tags (title, description, og:title, og:image, canonical) should be overridable per page. For content sites, wire the per-page mechanism, don't hardcode.
Platform quirks that shape values (WhatsApp image weight, Discord theme_color, iMessage rules) are in references/platforms.md — consult it when the user cares about a specific platform.

Assets. Generate what the audit marked missing:

Favicons/app icons from the source logo: scripts/generate-favicons.sh <logo> <public-dir> --pad-maskable (ImageMagick, falls back to npx sharp-cli). If the logo is an SVG, also ship it directly as <link rel="icon" type="image/svg+xml">.
og:image 1200×630: copy assets/og-template.html into the project (keep the filled copy committed so the card is regenerable), fill brand colors/copy, render with scripts/render-og-image.mjs <template> <out.png>. The script imports playwright from the project — npm i -D playwright if absent (browser download can be skipped when a system Chromium exists; the script falls back to it automatically). In Next.js App Router prefer the native opengraph-image.tsx + ImageResponse route instead — see frameworks.md. If the user already has a designed og:image, use it — never overwrite existing brand assets, only add missing ones.
site.webmanifest with name, short_name, icons (192, 512, and a purpose: "maskable" 512), theme_color, background_color, display: "standalone".

Phase 5 — Verify

Start the dev server (or build+preview for SSG so meta tags are in the actual HTML response, not client-rendered — scrapers don't run JS).
Run node scripts/verify-share-ready.mjs <url> — it parses the rendered head, checks every required tag, fetches each asset (status, content-type, weight), and validates the manifest. Fix every FAIL; report WARNs to the user with a recommendation. On a not-yet-deployed site the production og:image URL can't resolve — the script detects this (same path serves locally) and reports it as a WARN to re-verify after deploy, not a FAIL.
Spot-check with curl -A "facebookexternalhit/1.1" <url> that the tags are present in the raw HTML for a scraper user-agent.
Close with the post-deploy checklist (these need a public URL):
- Facebook Sharing Debugger — also the way to bust FB/WhatsApp's cache ("Scrape Again")
- LinkedIn Post Inspector — busts LinkedIn's ~7-day cache
- X/Twitter: paste the URL in a draft post to preview
- Discord/Slack/Telegram: paste in a private channel/saved messages
- Remind the user: scrapers cache aggressively — after changing an og:image, either bust caches via the debuggers or version the image URL (og.png?v=2).

Scope

In scope: OG core + image tags, Twitter/X cards, title/description, favicons (ico/PNG/SVG/apple-touch-icon), theme-color, canonical, web app manifest, per-platform preview quirks. Out of scope (mention, don't implement unless asked): JSON-LD structured data, oEmbed endpoints, robots/sitemap, analytics.

More from this repository

same repository

loop-react-doctor

tomimor/skills

Iterative React-health loop: inventory every React app in the repo, baseline with the latest react-doctor (pinned for the rest of the run), fix one root cause per iteration, and re-verify until every app scores 100/100 or every remaining finding has a user-approved written justification. Never silences findings with ignores, exclusions, or deleted behavior, and stops itself after two iterations without measurable progress. Use when the user mentions react-doctor, React health score, React anti-patterns cleanup, or driving a React codebase to a clean scan.

2026-07-042

loop-cve-audit

tomimor/skills

Iterative dependency-CVE remediation loop: scan with ecosystem-native advisory tooling, assess whether each high/critical finding is actually reachable (with call-path evidence, not vibes), fix the highest-risk reachable one with the smallest credible change, re-verify, and repeat. Terminates when no exploitable high/critical CVE remains or every remaining finding has an evidence-backed reachability assessment and an approved risk decision. Use when the user mentions CVEs, vulnerability scanning, dependency security, npm/pip/cargo audit, security patching, or wants a recurring dependency-security loop.

2026-07-042

ui-review

tomimor/skills

Orchestrates a comprehensive frontend UI review by running parallel analysis across typography, layout, accessibility, responsiveness, copy, visual polish, and design critique. Uses browser inspection for visual context. Produces a prioritized plan of small, concrete fixes -- never rewrites. Use when the user mentions UI review, frontend review, page review, design review, visual review, audit my page, or review my UI.

2026-06-252

pr-dashboard

tomimor/skills

Review open PRs authored by the user for a given repo, showing title, status, review state, open comments, CI checks, and recommended next steps. Use when the user mentions PR review, my PRs, open PRs, PR status, PR dashboard, or wants an overview of their pull requests.

2026-06-252

whats-missing

tomimor/skills

Surfaces the single most important blindspot in a plan, decision, or situation by checking whether the frame is right, generating candidates across 8 lenses (hidden constraints, false assumptions, second-order effects, stakeholders, blast radius, base rates, time horizon, counter-positions), then either committing to one or returning a calibrated "no blindspot" when none is load-bearing -- never a list of risks. Use when the user asks "what am I missing", "what's the most important thing I'm missing about this situation or decision", "what's my blindspot", "what's the biggest risk I'm not seeing", or wants a single sharp second opinion before committing.

2026-06-172

grid-review

tomimor/skills

Read-only audit of a web page's layout grid. Measures column adherence, baseline rhythm, and optical ink alignment in pixels (Müller-Brockmann), then critiques grid appropriateness, type scale, flush-left, white space, measure, and color-as-identifier (Vignelli). Mechanical px violations first, principled critique second, each with a minimal fix -- never rewrites. Works rigorously on pages with a declared CSS grid; falls back to inferred-grid plus principled checks on arbitrary pages. Use when the user mentions grid review, grid audit, layout grid, column alignment, baseline grid, is my grid aligned, Swiss grid, Müller-Brockmann, or Vignelli.

2026-06-152

name	share-ready
description	Audits and fully configures how a website looks when shared (Open Graph, Twitter/X cards, WhatsApp/Discord/Slack previews) and in the browser (title, favicons, theme-color, web manifest), generating missing assets and verifying the result locally. Use when setting up link previews, og:image, favicons, social sharing metadata, or when a shared link "looks wrong" on a platform.

Share Ready

Make a site's link previews and browser presentation complete: audit what exists, implement what's missing in the project's idiomatic way, generate the image assets, and verify everything end-to-end.

Workflow

Five phases, in order. Don't skip the audit — most projects have partial metadata, and duplicating tags is itself a bug (scrapers pick one arbitrarily).

Phase 1 — Detect the framework

Phase 2 — Audit what exists

Show the audit table to the user before changing anything.

Phase 3 — Gather content: infer first, ask only gaps

Infer from the repo before asking anything:

Field	Infer from
Site name	`package.json` name, README H1, existing `<title>`
Description	`package.json` description, README first paragraph, hero copy
Canonical URL	`homepage` in package.json, CNAME file, deploy config, README links
Theme color	CSS custom props / tailwind config primary color, existing `theme-color`
Source logo	`logo`, `icon` in `public/`, `assets/`, `static/`, root; existing favicon
Locale	`<html lang>`, i18n config

Phase 4 — Implement

Fix, don't append. Replace wrong/duplicate tags; never leave two og:titles in the document. When a replacement orphans an old asset file (a retired favicon, a superseded og image), list it in the report so the user can delete it — don't delete user-created files yourself.
og:image and og:url must be absolute URLs (scheme + host). This is the single most common breakage.
Per-page vs site-wide. Site-wide defaults (site_name, favicon, theme-color, manifest) go in the root layout/template; page-level tags (title, description, og:title, og:image, canonical) should be overridable per page. For content sites, wire the per-page mechanism, don't hardcode.
Platform quirks that shape values (WhatsApp image weight, Discord theme_color, iMessage rules) are in references/platforms.md — consult it when the user cares about a specific platform.

Assets. Generate what the audit marked missing:

Favicons/app icons from the source logo: scripts/generate-favicons.sh <logo> <public-dir> --pad-maskable (ImageMagick, falls back to npx sharp-cli). If the logo is an SVG, also ship it directly as <link rel="icon" type="image/svg+xml">.
og:image 1200×630: copy assets/og-template.html into the project (keep the filled copy committed so the card is regenerable), fill brand colors/copy, render with scripts/render-og-image.mjs <template> <out.png>. The script imports playwright from the project — npm i -D playwright if absent (browser download can be skipped when a system Chromium exists; the script falls back to it automatically). In Next.js App Router prefer the native opengraph-image.tsx + ImageResponse route instead — see frameworks.md. If the user already has a designed og:image, use it — never overwrite existing brand assets, only add missing ones.
site.webmanifest with name, short_name, icons (192, 512, and a purpose: "maskable" 512), theme_color, background_color, display: "standalone".

Phase 5 — Verify

Start the dev server (or build+preview for SSG so meta tags are in the actual HTML response, not client-rendered — scrapers don't run JS).
Run node scripts/verify-share-ready.mjs <url> — it parses the rendered head, checks every required tag, fetches each asset (status, content-type, weight), and validates the manifest. Fix every FAIL; report WARNs to the user with a recommendation. On a not-yet-deployed site the production og:image URL can't resolve — the script detects this (same path serves locally) and reports it as a WARN to re-verify after deploy, not a FAIL.
Spot-check with curl -A "facebookexternalhit/1.1" <url> that the tags are present in the raw HTML for a scraper user-agent.
Close with the post-deploy checklist (these need a public URL):
- Facebook Sharing Debugger — also the way to bust FB/WhatsApp's cache ("Scrape Again")
- LinkedIn Post Inspector — busts LinkedIn's ~7-day cache
- X/Twitter: paste the URL in a draft post to preview
- Discord/Slack/Telegram: paste in a private channel/saved messages
- Remind the user: scrapers cache aggressively — after changing an og:image, either bust caches via the debuggers or version the image URL (og.png?v=2).