跳到正文
cccskills
免费在 GitHub 公开

docs-seo

Audit and improve the discoverability of the timepicker-ui documentation site (docs-app/) across the full modern discoverability stack — SEO (ranking), AEO (answer engines / featured snippets), GEO (citations inside ChatGPT/Gemini/Perplexity/Claude), and AIO (Google AI Overviews). Use when the user wants to optimize docs SEO, improve Google ranking/positioning, win featured snippets or AI-answer boxes, get the docs cited by AI engines, add or fix sitemap/robots/manifest, fill in page metadata, add Open Graph/Twitter cards, answer-first copy, or JSON-LD (FAQPage/SoftwareApplication/TechArticle/BreadcrumbList). Drives the seo-optimizer subagent with an audit → approve → apply flow.

中文简介正在准备中。当前显示原文说明。

集成工具X (Twitter)Gemini
查看安装方法

包含的文件(1)

  • SKILL.md7.2 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Docs Discoverability (SEO + AEO + GEO + AIO)

Make docs-app/ (the Next.js 16 documentation site for timepicker-ui) found, read, and cited by people, search crawlers, and AI answer engines — so it is the answer a developer, Google, and ChatGPT all reach for when someone wants a time picker. This skill is a thin orchestrator: the real work is done by the seo-optimizer subagent (which covers the full four-layer stack, not just classic SEO). The skill exists to manage the human approval gate the subagent can't do itself.

Default production URL: https://timepicker-ui.vercel.app (use unless the user gives another).

This is a fully public open-source site: everything here is meant to be indexed and cited. There is no private data and no protected branding. The subagent's guardrail is truthfulness (never describe a feature the library lacks) and quality (no AI slop), not privacy.

Arguments (optional)

  • A focus area narrows the run, e.g. /docs-seo metadata, /docs-seo sitemap, /docs-seo structured-data, /docs-seo opengraph, /docs-seo aeo (answer-first + FAQ), /docs-seo geo (entity footprint + citations). No argument = full audit of all layers.
  • --apply-all skips the per-area approval prompt and applies every audited change (still reports at the end). Use only when the user explicitly wants unattended changes.

Workflow

Phase 1 — Audit (read-only)

Dispatch the seo-optimizer subagent (Task tool, subagent_type: seo-optimizer) in audit mode. Brief it with the production URL and the focus area (if any), and tell it to discover the current state for itself rather than trusting any baseline — what was missing last run may already be fixed. Ask it to return a prioritized, file-level change plan grouped into:

  1. SEO — technical files (sitemap / robots / manifest / metadataBase)
  2. SEO — per-page metadata (the missing/duplicate titles + descriptions)
  3. SEO — root + Open Graph / Twitter (+ OG image)
  4. AEO — answer-first copy + question-formatted headings + FAQPage on Q&A pages
  5. GEO — consistent entity footprint + concrete facts + SoftwareApplication/JSON-LD
  6. AIO / AI-crawler / Core Web Vitals flags (llms.txt + robots AI user-agents are the owner's call; default is to welcome AI crawlers on a public OSS site)

The subagent's own definition already sets the checks below — this is the reminder to put in its brief, not a second source of truth (if the agent's rules change, its file wins).

  • Today's date from your context: the agent has no Bash to look it up.
  • Check the web first in audit mode (in apply mode only when an approved item rests on a fact it doubts). Use today's date from the brief and web-search the current best practice across all four layers — Next.js APIs, Google ranking + AI-slop + AI-features guidance, AEO/GEO/AIO tactics, the AI-crawler / llms.txt state — rather than optimizing from memory. Live sources win over anything hardcoded; it cites sources + dates.
  • Run the AI-slop check on text AND icons in both modes. Scan existing and proposed titles/descriptions/ FAQ copy for slop and long dashes (—/–), and the SEO/OG surface for stray Unicode emojis or native/system icons (the site draws its few icons as inline SVG in components/icons.tsx; emoji/native icons are a defect to flag, not ship).

It makes NO edits in this phase.

Phase 2 — Present & approve (gate)

Relay the audit plan to the user concisely (counts + the concrete titles/descriptions/FAQ Q&A and files per group). Then use AskUserQuestion to let the user choose which groups (and, where it matters, which items) to apply. AskUserQuestion caps at 4 options per question, so present the six groups as a multi-select batched into two questions when needed, then a follow-up for item-level choices where it matters. This is a mandatory gate — do not skip it unless --apply-all was passed. Capture the approved set.

Phase 3 — Apply

Dispatch the seo-optimizer subagent again in apply mode with the exact approved list (files + the decided titles/descriptions/answer-first copy/structured data). It implements the changes under docs-app/ using real Next 16 typed APIs, keeping titles/descriptions unique, on-keyword, answer-first where it's a docs page, and written like a human — short, specific, no AI slop, no long dashes, and no emojis/native icons (the site's own SVG icons or none). It keeps the entity footprint consistent across hero copy, metadata, OG, and JSON-LD.

Phase 4 — Verify & report

  • Run cd docs-app && npm run build to confirm the site still builds, then /verify per HARD RULES §5. Report pass/fail honestly with output.
  • Summarize what changed, grouped by the six areas, with the file list.
  • Give the manual verification checklist: open /sitemap.xml, /robots.txt, /manifest.webmanifest; view-source a couple of routes for <title>, OG/Twitter tags, and JSON-LD; validate structured data with Google Rich Results Test / Schema.org validator. Note that AEO/GEO wins (featured snippets, AI-Overview appearance, ChatGPT/Perplexity citations) show up over time and are tracked separately from classic rankings.
  • Note that git is the user's job — propose a commit message but do not commit.

Guardrails

  • The subagent edits ONLY docs-app/; it never touches the library in app/ or dist/.
  • Truthfulness over reach. Metadata, keywords, FAQ answers, and JSON-LD must match the real library — a fabricated fact is what gets the entity distrusted by AI engines and demoted by Google. When unsure a feature exists, verify against app/src/types/options.d.ts or the docs.
  • Don't regress existing good metadata/JSON-LD — extend it (FAQ/TechArticle JSON-LD already ships).
  • Best practices are re-derived live in every audit from today's real date, never from memory or a hardcoded year — for all four layers. An audit today and one months from now both research the current guidance.
  • The generated copy is human, short, slop-free: no filler openers or empty intensifiers, no keyword stuffing, no long dashes (—/–, use short hyphens), and no Unicode emojis or native icons (use the SVG icons in components/icons.tsx, or none).
  • Keep this skill, the agent file and docs-app/ files in CRLF; otherwise follow docs-app's own conventions.
  • One run optimizes discoverability; it does not redesign the site. Visual/content rewrites beyond SEO/answer-first copy belong to the docs-site agent.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

a11y

免费

Audit and improve the accessibility of the timepicker-ui LIBRARY (app/src) - ARIA, keyboard operability, focus trap/management, screen-reader announcements, labels - against WCAG 2.2 AA and the WAI-ARIA Authoring Practices. Use when the user wants an a11y audit/fix of the picker itself (clock, wheel, plugins, modal, inputs). Drives the accessibility subagent in an audit → approve → apply flow. Does NOT cover docs-app (use /docs-a11y for that).

中文简介正在准备中。当前显示原文说明。

pglejzer/timepicker-ui1002026年10月17日 更新

docs-a11y

免费

Audit and improve the accessibility of the timepicker-ui documentation site (docs-app/) - landmarks, heading order, skip links, keyboard nav, focus management in the command menu / sidebar / dialogs, color contrast, alt text, ARIA on custom components (tabs, native dialogs), reduced motion - against WCAG 2.2 AA. Use when the user wants an a11y audit/fix of the docs site. Drives the docs-accessibility subagent in an audit → approve → apply flow. Does NOT cover the library (use /a11y for that).

中文简介正在准备中。当前显示原文说明。

pglejzer/timepicker-ui1002026年10月17日 更新

release

免费

Cut a new timepicker-ui release. Use when the user wants to bump the version, prepare a release, write/update the changelog, or sync version + changelog across README, CHANGELOG.md and the docs-app (changelog/what's-new/version strings). Drives the build-release subagent in an audit → approve → apply flow, then runs a sanity build. Does NOT git-commit/tag or npm-publish — proposes those for the user to run.

中文简介正在准备中。当前显示原文说明。

pglejzer/timepicker-ui1002026年10月17日 更新

Full repository maintenance pipeline that orchestrates all project agents in sequence - code review, accessibility, bundle size, security, API stability, test coverage, ecosystem, and release preparation. Acts as a quality gate before publishing or merging major changes. Use when: maintenance, health check, pre-release audit, quality gate, full pipeline, repo health, pre-merge check, release readiness, audit all.

中文简介正在准备中。当前显示原文说明。

pglejzer/timepicker-ui1002026年10月17日 更新

verify

免费

Browser-check what a change could have broken in timepicker-ui (library demo and docs-app, before/after). Use at the end of a task that changed library behavior or styles (app/src) or docs-app pages, or when the user asks to check that nothing broke. Not for demo examples in app/docs, copy/typo/comment edits or one-line fixes (HARD RULES §5 in CLAUDE.md). Main agent only, never delegated to a subagent.

中文简介正在准备中。当前显示原文说明。

pglejzer/timepicker-ui1002026年10月17日 更新

查看 pglejzer 的全部技能

报告此技能的问题