📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,102 @@
|
||||
---
|
||||
name: doc2math
|
||||
description: Convert narrative technical documents into grounded Mathematical Problem Specifications with variables, constraints, objectives, and uncertainty.
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-05-31"
|
||||
---
|
||||
|
||||
# DOC2MATH — Document-to-Mathematics Problem Specification
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- "Formalize this problem statement into math"
|
||||
- "Extract the mathematical structure from this research paper section"
|
||||
- "What variables, constraints, and objectives are in this spec?"
|
||||
- "Convert this word problem to a structured MPS"
|
||||
- "Find what's missing in this problem formulation"
|
||||
|
||||
## Zero-Inference Protocol (Mandatory)
|
||||
|
||||
1. **Closed World** — if it is not stated in the document, it does not exist in output
|
||||
2. **Grounding Rule** — every element must cite the exact source phrase (`"evidence"` field)
|
||||
3. **No Silent Filling** — unknown values use `null`; ambiguous types use `"ambiguous"`
|
||||
4. **Inference Tagging** — structural inferences tagged `"inferred": true` with `"inference_basis"`
|
||||
5. **MISSING Markers** — elements mentioned but insufficiently defined get `"status": "MISSING"` with `"missing_reason"`
|
||||
6. **No Hallucinated Math** — never introduce equations or values not in the source text
|
||||
|
||||
## Limitations
|
||||
|
||||
- Does not invent missing equations, domains, values, or assumptions that are absent from the source document.
|
||||
- Requires enough source text to cite every extracted element; sparse prompts should be returned with explicit missing-information markers.
|
||||
- Produces a formal specification, not a solved optimization model or proof.
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1 — Receive Document
|
||||
|
||||
Accept the document text, research excerpt, problem description, or specification as input.
|
||||
|
||||
### Step 2 — Classify
|
||||
|
||||
Identify `problem_class`: `optimization | classification | simulation | proof | estimation | other`
|
||||
|
||||
### Step 3 — Extract MPS Components
|
||||
|
||||
**Variables** — `id`, `name`, `symbol`, `type`, `domain`, `units`, `role`, `evidence`, `inferred`, `status`
|
||||
|
||||
**Operators** — `id`, `name`, `symbol`, `arity`, `acts_on`, `produces`, `evidence`, `inferred`
|
||||
|
||||
**Constraints** — `id`, `type`, `expression`, `variables_involved`, `evidence`, `hardness`, `inferred`, `status`
|
||||
|
||||
**Objectives** — `id`, `direction` (minimize/maximize/satisfy/find/prove), `expression`, `variables_involved`, `evidence`, `inferred`
|
||||
|
||||
**Uncertainty** — `id`, `type` (stochastic/epistemic/measurement/model/none_stated), `affects`, `characterization`, `evidence`, `status`
|
||||
|
||||
### Step 4 — Surface Missing Information
|
||||
|
||||
Identify what the document implies but doesn't state: `missing_information[]` with `element`, `needed_for`, `missing_reason`.
|
||||
|
||||
### Step 5 — Validate and Score
|
||||
|
||||
`validation_flags`:
|
||||
- `has_complete_objectives`: true/false/partial
|
||||
- `has_bounded_variables`: true/false/partial
|
||||
- `has_evidence_for_all_elements`: true/false/partial
|
||||
- `inference_count`: integer
|
||||
- `missing_count`: integer
|
||||
- `overall_formalizability`: HIGH/MEDIUM/LOW
|
||||
|
||||
## Output Format
|
||||
|
||||
Produce the complete MPS as a JSON object:
|
||||
|
||||
```json
|
||||
{
|
||||
"mps_version": "1.0",
|
||||
"source_title": "...",
|
||||
"problem_class": "optimization",
|
||||
"variables": [...],
|
||||
"operators": [...],
|
||||
"constraints": [...],
|
||||
"objectives": [...],
|
||||
"uncertainty": [...],
|
||||
"missing_information": [...],
|
||||
"validation_flags": {
|
||||
"overall_formalizability": "HIGH"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Apply all 6 Zero-Inference Protocol rules before outputting any element
|
||||
- ✅ Surface MISSING markers rather than silently inferring — incomplete formalization is valid output
|
||||
- ✅ Cite the exact source phrase in every `evidence` field
|
||||
- ❌ Never introduce mathematical relationships not grounded in the source text
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- Repository: [thebrierfox/doc2math-skill](https://github.com/thebrierfox/doc2math-skill)
|
||||
- Full BYOK tool: [ace-license-server-production.up.railway.app/byok/doc2math](https://ace-license-server-production.up.railway.app/byok/doc2math)
|
||||
- Built by [IntuiTek¹](https://intuitek.ai) (~K¹) — MIT License
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: moatmri
|
||||
description: Analyze AI disruption pressure across a business, map competitive exposure, and produce a 90-day defensive action plan.
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-05-31"
|
||||
---
|
||||
|
||||
# MoatMRI — AI Disruption Pressure Analysis
|
||||
|
||||
*Where does intelligence pressure break this system first?*
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- "Is my business at risk from AI? Where am I most exposed?"
|
||||
- "How would an AI-native startup take over my market?"
|
||||
- "What should I do in the next 90 days to defend against AI disruption?"
|
||||
- "I'm doing due diligence on [company] — what's their AI displacement risk?"
|
||||
- "Where does my competitive moat actually hold against AI pressure?"
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1 — Gather Inputs
|
||||
|
||||
Ask if not provided:
|
||||
- **Industry** (e.g., "real estate", "community banking", "retail pharmacy", "law firm")
|
||||
- **Entity type** (e.g., "independent broker", "solo practitioner", "regional franchise")
|
||||
- **Target name** (optional — specific organization for named analysis)
|
||||
|
||||
## Limitations
|
||||
|
||||
- Produces strategic risk analysis, not audited market research or investment advice.
|
||||
- Depends on current company, market, regulatory, and competitive context supplied by the user or gathered from reliable sources.
|
||||
- Treats disruption scenarios as planning tools; scores should be revisited as new evidence appears.
|
||||
|
||||
### Step 2 — 10-Vector Pressure Map
|
||||
|
||||
Score AI disruption pressure across exactly these 10 vectors (0–10):
|
||||
|
||||
| # | Vector | What to Measure |
|
||||
|---|--------|----------------|
|
||||
| 1 | **labor_substitution** | Which roles/functions are directly automatable |
|
||||
| 2 | **customer_interface** | How AI changes how customers reach this entity |
|
||||
| 3 | **knowledge_commoditization** | Does AI commoditize the expertise this entity sells |
|
||||
| 4 | **pricing_pressure** | Does AI enable lower-cost competitors to undercut |
|
||||
| 5 | **supply_chain_automation** | Does AI change input costs or supplier relationships |
|
||||
| 6 | **data_moat** | Does this entity have proprietary data AI can't replicate |
|
||||
| 7 | **trust_relationship_moat** | How much does customer loyalty protect against displacement |
|
||||
| 8 | **distribution_channel_disruption** | Does AI create new channels that bypass this entity |
|
||||
| 9 | **regulatory_compliance_exposure** | Does AI alter the regulatory or liability landscape |
|
||||
| 10 | **decision_speed_gap** | Does AI accelerate decisions in ways that disadvantage this entity |
|
||||
|
||||
For each vector produce: **score**, **headline**, **near_term** (12 months), **far_term** (3 years).
|
||||
|
||||
**Aggregate risk score:** mean of all 10 vectors. Flag any vector ≥ 7 as critical.
|
||||
|
||||
### Step 3 — AI Front-Door Takeover Storyboard
|
||||
|
||||
6-step narrative of how an AI-native competitor displaces this entity:
|
||||
1. The entry point
|
||||
2. The wedge (first 10% of market)
|
||||
3. The acceleration (what makes it compound)
|
||||
4. The tipping point (when incumbent can't recover)
|
||||
5. The aftermath
|
||||
6. The survivor profile
|
||||
|
||||
### Step 4 — 90-Day Counterstrike Plan
|
||||
|
||||
- **Track A (Days 0–30):** Immediate defense — what to stop, what to protect
|
||||
- **Track B (Days 31–60):** Intelligence-layer build — data/relationships to fortify
|
||||
- **Track C (Days 61–90):** Offensive positioning — use AI pressure as competitive weapon
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Score all 10 vectors before calculating aggregate — resist stopping at obvious ones
|
||||
- ✅ Keep the storyboard specific to industry/entity, not generic disruption narrative
|
||||
- ✅ Track C should be actionable within 90 days, not aspirational 3-year strategy
|
||||
- ❌ Don't conflate data_moat with trust_relationship_moat — they protect differently
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- Repository: [thebrierfox/moatmri-skill](https://github.com/thebrierfox/moatmri-skill)
|
||||
- Full BYOK tool: [ace-license-server-production.up.railway.app/byok/moatmri](https://ace-license-server-production.up.railway.app/byok/moatmri)
|
||||
- Built by [IntuiTek¹](https://intuitek.ai) (~K¹) — MIT License
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
name: nextjs-seo-indexing
|
||||
description: "Fix SEO indexing issues, crawl budget problems, and Search Console coverage errors for Next.js apps. Covers canonical tags, noindex audits, sitemap health, static rendering, and internal linking."
|
||||
category: seo
|
||||
risk: safe
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-05-31"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [seo, indexing, nextjs, search-console, crawl-budget, canonical, sitemap]
|
||||
tools: [claude, cursor, gemini, claude-code]
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Next.js SEO Indexing & Crawl Budget Skill
|
||||
|
||||
Fix Google Search Console coverage issues, canonical problems, sitemap errors, and crawl budget waste in Next.js apps.
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- Use when a Next.js site has Google Search Console coverage issues such as duplicate canonicals, accidental noindex, crawl waste, or discovered-but-not-indexed URLs.
|
||||
- Use when auditing sitemap, robots.txt, redirect, internal-linking, or static-rendering problems before an SEO release.
|
||||
- Use when you need framework-specific examples for Next.js App Router metadata, `generateMetadata`, `robots.js`, and sitemap routes.
|
||||
|
||||
---
|
||||
|
||||
## Understanding Search Console Coverage States
|
||||
|
||||
| Status | Meaning | Fix |
|
||||
|--------|---------|-----|
|
||||
| Crawled – not indexed | Google crawled but chose not to index | Improve content quality + canonical + internal links |
|
||||
| Duplicate without canonical | Multiple URLs serve same content, no canonical | Add explicit canonical to the preferred URL |
|
||||
| Excluded by noindex | `noindex` tag present | Remove noindex if page should be indexed |
|
||||
| Duplicate, Google chose different canonical | Google prefers a different URL than you specified | Align canonical with the URL Google naturally picks |
|
||||
| Alternative page with proper canonical | Correct — non-preferred duplicate pointing to canonical | Expected behavior, not a problem |
|
||||
| Not found 404 | Page deleted or URL changed | Add redirect or restore page |
|
||||
| Discovered – not indexed | Google knows it exists but hasn't crawled it | Improve internal linking + crawl budget |
|
||||
| Page with redirect | Redirect chain or redirect to wrong target | Shorten redirect chain, verify destination |
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Canonical Audit
|
||||
|
||||
### Next.js App Router (metadata export)
|
||||
```js
|
||||
// app/blog/my-post/page.js
|
||||
export const metadata = {
|
||||
title: 'My Post Title',
|
||||
alternates: {
|
||||
canonical: 'https://www.yourdomain.com/blog/my-post',
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
### Next.js App Router (generateMetadata)
|
||||
```js
|
||||
export async function generateMetadata({ params }) {
|
||||
return {
|
||||
alternates: {
|
||||
canonical: `https://www.yourdomain.com/blog/${params.slug}`,
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Common canonical mistakes to fix:
|
||||
```js
|
||||
// ❌ WRONG — relative URL
|
||||
canonical: '/blog/my-post'
|
||||
|
||||
// ❌ WRONG — missing trailing slash inconsistency
|
||||
// (pick one and stick with it sitewide)
|
||||
|
||||
// ✓ CORRECT — absolute URL, consistent scheme + subdomain
|
||||
canonical: 'https://www.yourdomain.com/blog/my-post'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Noindex Audit
|
||||
|
||||
Find pages that are accidentally noindexed:
|
||||
|
||||
```bash
|
||||
# Search for noindex in metadata
|
||||
grep -r "noindex\|robots.*noindex" --include="*.{js,ts,jsx,tsx}" app/ pages/ -l
|
||||
|
||||
# Check layout.js — a noindex here affects ALL pages
|
||||
grep -n "robots" app/layout.js
|
||||
```
|
||||
|
||||
In Next.js App Router, `robots` in the root layout applies globally. Only set it there if you want the whole site affected.
|
||||
|
||||
```js
|
||||
// app/layout.js — only set robots if you need sitewide control
|
||||
export const metadata = {
|
||||
// ✓ Allow indexing
|
||||
robots: { index: true, follow: true },
|
||||
// ❌ This would noindex the entire site:
|
||||
// robots: { index: false }
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Sitemap Health
|
||||
|
||||
### Verify sitemap routes return 200 + valid XML
|
||||
```bash
|
||||
curl -sI https://www.yourdomain.com/sitemap.xml | grep -i "content-type\|status"
|
||||
curl -s https://www.yourdomain.com/sitemap.xml | head -20
|
||||
```
|
||||
|
||||
### Next.js App Router sitemap (recommended pattern)
|
||||
```js
|
||||
// app/sitemap.js
|
||||
export default async function sitemap() {
|
||||
const baseUrl = 'https://www.yourdomain.com';
|
||||
|
||||
// Static pages
|
||||
const staticPages = [
|
||||
{ url: baseUrl, lastModified: new Date(), changeFrequency: 'daily', priority: 1.0 },
|
||||
{ url: `${baseUrl}/about`, lastModified: new Date(), changeFrequency: 'monthly', priority: 0.8 },
|
||||
];
|
||||
|
||||
// Dynamic pages (fetch from DB or CMS)
|
||||
const posts = await getPosts(); // your data fetch
|
||||
const dynamicPages = posts.map(post => ({
|
||||
url: `${baseUrl}/blog/${post.slug}`,
|
||||
lastModified: new Date(post.updatedAt),
|
||||
changeFrequency: 'weekly',
|
||||
priority: 0.7,
|
||||
}));
|
||||
|
||||
return [...staticPages, ...dynamicPages];
|
||||
}
|
||||
```
|
||||
|
||||
### Multiple sitemaps (sitemap index)
|
||||
```js
|
||||
// app/sitemap-tools/sitemap.js
|
||||
// app/sitemap-blog/sitemap.js
|
||||
// Each returns an array of URL entries
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Static Rendering Verification
|
||||
|
||||
Pages must be statically generated (or SSR with metadata in HTML) for Google to see SEO tags.
|
||||
|
||||
```bash
|
||||
# Check build output — pages should show ● (static) not λ (dynamic)
|
||||
npm run build 2>&1 | grep -E "○|●|λ|/blog|/tools"
|
||||
```
|
||||
|
||||
```
|
||||
○ /about (static)
|
||||
● /blog/[slug] (SSG) ← good
|
||||
λ /api/data (serverless) ← expected for APIs
|
||||
```
|
||||
|
||||
If important pages are `λ` (fully dynamic with no static generation), add:
|
||||
|
||||
```js
|
||||
// app/blog/[slug]/page.js
|
||||
export async function generateStaticParams() {
|
||||
const posts = await getPosts();
|
||||
return posts.map(post => ({ slug: post.slug }));
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Internal Linking Audit
|
||||
|
||||
Pages with zero internal links are rarely indexed. Every important page should be reachable from:
|
||||
1. Homepage or navigation
|
||||
2. A sitemap
|
||||
3. At least one other content page
|
||||
|
||||
```bash
|
||||
# Find pages that have no inbound links from other pages
|
||||
# (manual check — grep for the slug across all files)
|
||||
grep -r "/blog/my-orphan-post" --include="*.{js,ts,jsx,tsx,md}" . | grep -v "sitemap\|the-page-itself"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Redirect Audit
|
||||
|
||||
```bash
|
||||
# Find all redirects in Next.js config
|
||||
grep -A 3 "redirects" next.config.js
|
||||
|
||||
# Check for redirect chains (A → B → C — should be A → C)
|
||||
# Test a suspected chain:
|
||||
curl -sI https://www.yourdomain.com/old-url | grep -i location
|
||||
```
|
||||
|
||||
```js
|
||||
// next.config.js — keep redirects flat (no chains)
|
||||
async redirects() {
|
||||
return [
|
||||
{
|
||||
source: '/old-url',
|
||||
destination: '/new-url', // Must NOT itself redirect
|
||||
permanent: true, // 308 for SEO
|
||||
},
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — robots.txt Check
|
||||
|
||||
```bash
|
||||
curl -s https://www.yourdomain.com/robots.txt
|
||||
```
|
||||
|
||||
```
|
||||
# ✓ Good
|
||||
User-agent: *
|
||||
Allow: /
|
||||
Sitemap: https://www.yourdomain.com/sitemap.xml
|
||||
|
||||
# ❌ Bad — disallows crawling of important content
|
||||
Disallow: /blog/
|
||||
Disallow: /tools/
|
||||
```
|
||||
|
||||
```js
|
||||
// app/robots.js (Next.js App Router)
|
||||
export default function robots() {
|
||||
return {
|
||||
rules: { userAgent: '*', allow: '/' },
|
||||
sitemap: 'https://www.yourdomain.com/sitemap.xml',
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Indexing Checklist
|
||||
|
||||
- [ ] All important pages have absolute canonical URLs
|
||||
- [ ] No important pages accidentally noindexed
|
||||
- [ ] Sitemap routes return 200 with valid XML
|
||||
- [ ] Sitemap submitted to Google Search Console
|
||||
- [ ] Important pages statically generated (●) in build output
|
||||
- [ ] No redirect chains (A→B→C should be A→C)
|
||||
- [ ] robots.txt allows important content
|
||||
- [ ] Every important page has ≥1 internal inbound link
|
||||
- [ ] `generateStaticParams` added for dynamic routes with known slugs
|
||||
|
||||
## Limitations
|
||||
|
||||
- Does not guarantee Google will index a page; final indexing decisions remain with the search engine.
|
||||
- Requires access to the codebase, deployed URLs, and ideally Google Search Console data for confident diagnosis.
|
||||
- Treat recommendations that change URL structure, redirects, or canonical policy as production-impacting and review them before deployment.
|
||||
@@ -0,0 +1,319 @@
|
||||
---
|
||||
name: schema-markup-generator
|
||||
description: "Generate and implement JSON-LD structured data for web apps, tool pages, blogs, FAQs, and SaaS sites. Supports WebSite, SoftwareApplication, BlogPosting, FAQPage, HowTo, BreadcrumbList, and Organization schemas."
|
||||
category: seo
|
||||
risk: safe
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-05-31"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [seo, schema, json-ld, structured-data, rich-results, nextjs, technical-seo]
|
||||
tools: [claude, cursor, gemini, claude-code]
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Schema Markup Generator Skill
|
||||
|
||||
Add JSON-LD structured data to pages to unlock rich results, improve CTR, and signal context to Google and AI systems.
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- Use when adding or auditing JSON-LD schema for websites, SaaS apps, tools, articles, FAQs, breadcrumbs, or organization pages.
|
||||
- Use when schema must be implemented in Next.js App Router or validated against Google Rich Results and Schema.org tooling.
|
||||
- Use when a page has strong content but lacks structured data for search engines and rich-result eligibility.
|
||||
|
||||
---
|
||||
|
||||
## How to Add Schema in Next.js App Router
|
||||
|
||||
The cleanest approach is a reusable `JsonLd` component:
|
||||
|
||||
```jsx
|
||||
// components/JsonLd.jsx
|
||||
export function JsonLd({ data }) {
|
||||
return (
|
||||
<script
|
||||
type="application/ld+json"
|
||||
dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }}
|
||||
/>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Use it in any page:
|
||||
```jsx
|
||||
import { JsonLd } from '@/components/JsonLd';
|
||||
|
||||
export default function MyPage() {
|
||||
return (
|
||||
<>
|
||||
<JsonLd data={mySchemaObject} />
|
||||
{/* rest of page */}
|
||||
</>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Schema Types by Page Type
|
||||
|
||||
### WebSite + Sitelinks Searchbox (homepage only)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "WebSite",
|
||||
"name": "100 SEO Tools",
|
||||
"url": "https://www.100seotools.com",
|
||||
"description": "Free online SEO tools for keyword research, technical audits, and more.",
|
||||
"potentialAction": {
|
||||
"@type": "SearchAction",
|
||||
"target": {
|
||||
"@type": "EntryPoint",
|
||||
"urlTemplate": "https://www.100seotools.com/search?q={search_term_string}"
|
||||
},
|
||||
"query-input": "required name=search_term_string"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### SoftwareApplication (tool / SaaS app pages)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "SoftwareApplication",
|
||||
"name": "Keyword Density Checker",
|
||||
"applicationCategory": "WebApplication",
|
||||
"operatingSystem": "Web",
|
||||
"url": "https://www.100seotools.com/tools/keyword-density-checker",
|
||||
"description": "Free keyword density checker tool. Analyze keyword frequency and optimize your content for SEO.",
|
||||
"offers": {
|
||||
"@type": "Offer",
|
||||
"price": "0",
|
||||
"priceCurrency": "USD"
|
||||
},
|
||||
"featureList": [
|
||||
"Analyze keyword frequency",
|
||||
"Detect over-optimization",
|
||||
"Export results as CSV"
|
||||
],
|
||||
"provider": {
|
||||
"@type": "Organization",
|
||||
"name": "100 SEO Tools",
|
||||
"url": "https://www.100seotools.com"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Article / BlogPosting (blog posts)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "BlogPosting",
|
||||
"headline": "How to Improve Your Core Web Vitals in 2025",
|
||||
"description": "A practical guide to improving LCP, FID, and CLS scores for better rankings.",
|
||||
"url": "https://www.100seotools.com/blog/improve-core-web-vitals",
|
||||
"datePublished": "2025-01-15",
|
||||
"dateModified": "2025-03-20",
|
||||
"author": {
|
||||
"@type": "Person",
|
||||
"name": "Jane Smith",
|
||||
"url": "https://www.100seotools.com/author/jane-smith"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "100 SEO Tools",
|
||||
"logo": {
|
||||
"@type": "ImageObject",
|
||||
"url": "https://www.100seotools.com/logo.png"
|
||||
}
|
||||
},
|
||||
"image": {
|
||||
"@type": "ImageObject",
|
||||
"url": "https://www.100seotools.com/images/blog/core-web-vitals.jpg",
|
||||
"width": 1200,
|
||||
"height": 630
|
||||
},
|
||||
"mainEntityOfPage": {
|
||||
"@type": "WebPage",
|
||||
"@id": "https://www.100seotools.com/blog/improve-core-web-vitals"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### FAQPage (FAQ sections, tool help pages)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "FAQPage",
|
||||
"mainEntity": [
|
||||
{
|
||||
"@type": "Question",
|
||||
"name": "What is keyword density?",
|
||||
"acceptedAnswer": {
|
||||
"@type": "Answer",
|
||||
"text": "Keyword density is the percentage of times a keyword appears in a piece of content relative to the total word count. A healthy keyword density is typically 1-3%."
|
||||
}
|
||||
},
|
||||
{
|
||||
"@type": "Question",
|
||||
"name": "Is this tool free to use?",
|
||||
"acceptedAnswer": {
|
||||
"@type": "Answer",
|
||||
"text": "Yes, our keyword density checker is completely free with no registration required."
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### HowTo (step-by-step tool guides)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "HowTo",
|
||||
"name": "How to Check Keyword Density",
|
||||
"description": "Step-by-step guide to analyzing keyword density using our free tool.",
|
||||
"totalTime": "PT2M",
|
||||
"step": [
|
||||
{
|
||||
"@type": "HowToStep",
|
||||
"position": 1,
|
||||
"name": "Paste your content",
|
||||
"text": "Copy your article or webpage content and paste it into the text area.",
|
||||
"image": "https://www.100seotools.com/images/how-to/step1.jpg"
|
||||
},
|
||||
{
|
||||
"@type": "HowToStep",
|
||||
"position": 2,
|
||||
"name": "Enter your target keyword",
|
||||
"text": "Type the keyword you want to analyze in the keyword field."
|
||||
},
|
||||
{
|
||||
"@type": "HowToStep",
|
||||
"position": 3,
|
||||
"name": "Click Analyze",
|
||||
"text": "Press the Analyze button to get your keyword density report instantly."
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### BreadcrumbList (all non-homepage pages)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "BreadcrumbList",
|
||||
"itemListElement": [
|
||||
{
|
||||
"@type": "ListItem",
|
||||
"position": 1,
|
||||
"name": "Home",
|
||||
"item": "https://www.100seotools.com"
|
||||
},
|
||||
{
|
||||
"@type": "ListItem",
|
||||
"position": 2,
|
||||
"name": "SEO Tools",
|
||||
"item": "https://www.100seotools.com/tools"
|
||||
},
|
||||
{
|
||||
"@type": "ListItem",
|
||||
"position": 3,
|
||||
"name": "Keyword Density Checker",
|
||||
"item": "https://www.100seotools.com/tools/keyword-density-checker"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Organization (about, contact pages)
|
||||
```js
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "Organization",
|
||||
"name": "100 SEO Tools",
|
||||
"url": "https://www.100seotools.com",
|
||||
"logo": "https://www.100seotools.com/logo.png",
|
||||
"sameAs": [
|
||||
"https://twitter.com/100seotools",
|
||||
"https://www.linkedin.com/company/100seotools"
|
||||
],
|
||||
"contactPoint": {
|
||||
"@type": "ContactPoint",
|
||||
"contactType": "customer support",
|
||||
"email": "hello@100seotools.com"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Combining Multiple Schemas on One Page
|
||||
|
||||
A tool page can have BreadcrumbList + SoftwareApplication + FAQPage:
|
||||
|
||||
```jsx
|
||||
export default function ToolPage() {
|
||||
return (
|
||||
<>
|
||||
<JsonLd data={breadcrumbSchema} />
|
||||
<JsonLd data={softwareApplicationSchema} />
|
||||
<JsonLd data={faqSchema} />
|
||||
{/* page content */}
|
||||
</>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Each schema lives in its own `<script>` tag — do NOT merge them into one object.
|
||||
|
||||
---
|
||||
|
||||
## Validation
|
||||
|
||||
Always validate schema before deploying:
|
||||
|
||||
1. **Google Rich Results Test** — https://search.google.com/test/rich-results
|
||||
2. **Schema.org Validator** — https://validator.schema.org/
|
||||
3. **Google Search Console** → Enhancements → check for warnings after deployment
|
||||
|
||||
```bash
|
||||
# Quick check: schema appears in HTML
|
||||
curl -s https://www.yourdomain.com/tools/keyword-density | grep -A 5 "application/ld+json"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Schema Markup Checklist
|
||||
|
||||
- [ ] Homepage has `WebSite` schema
|
||||
- [ ] Tool/app pages have `SoftwareApplication` schema
|
||||
- [ ] Blog posts have `BlogPosting` / `Article` schema
|
||||
- [ ] FAQ sections have `FAQPage` schema
|
||||
- [ ] Step-by-step guides have `HowTo` schema
|
||||
- [ ] All non-homepage pages have `BreadcrumbList`
|
||||
- [ ] About/contact page has `Organization` schema
|
||||
- [ ] All URLs in schema are absolute HTTPS
|
||||
- [ ] Schema validated with Google Rich Results Test
|
||||
- [ ] No schema errors in Google Search Console
|
||||
|
||||
## Limitations
|
||||
|
||||
- Does not guarantee rich-result eligibility or display; Google and other consumers decide whether to use valid schema.
|
||||
- Generated examples must be adapted to the site's real content, legal entity details, ratings, pricing, and availability.
|
||||
- Always validate deployed HTML, not only source code, because frameworks and rendering modes can change the final markup.
|
||||
@@ -0,0 +1,230 @@
|
||||
---
|
||||
name: social-metadata-hardening
|
||||
description: "Fix social sharing previews so URLs render as rich cards on Facebook, LinkedIn, X/Twitter, WhatsApp, Telegram, Slack, and Discord. Covers OG tags, Twitter cards, absolute image URLs, and metadata debugging."
|
||||
category: seo
|
||||
risk: safe
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-05-31"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [seo, open-graph, twitter-card, social-sharing, og-image, nextjs, metadata]
|
||||
tools: [claude, cursor, gemini, claude-code]
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Social Metadata Hardening Skill
|
||||
|
||||
Fix social sharing so every important URL unfurls as a rich card across all platforms.
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- Use when shared links show missing, stale, cropped, or incorrect previews on social and chat platforms.
|
||||
- Use when auditing Open Graph, Twitter/X card, image URL, alt text, or `metadataBase` coverage in a web app.
|
||||
- Use before launch when every public page needs predictable rich previews across LinkedIn, X, Facebook, WhatsApp, Slack, Discord, and Telegram.
|
||||
|
||||
---
|
||||
|
||||
## Why Previews Break
|
||||
|
||||
| Problem | Root Cause |
|
||||
|---------|-----------|
|
||||
| No preview at all | Missing og:title, og:description, or og:image |
|
||||
| Broken image | Relative URL (must be absolute) |
|
||||
| Wrong image size | Image not 1200×630px (OG standard) |
|
||||
| Plain text card | Twitter card type missing or set to `summary` |
|
||||
| Stale preview | Platform caching old metadata |
|
||||
| Metadata missing on crawl | Tags added by client-side JS (crawlers don't run JS) |
|
||||
|
||||
---
|
||||
|
||||
## The Gold Standard Metadata Block
|
||||
|
||||
Every shareable page needs ALL of these in static HTML:
|
||||
|
||||
```js
|
||||
// Next.js App Router — lib/socialMetadata.js
|
||||
export function buildSocialMetadata({
|
||||
title,
|
||||
description,
|
||||
path, // '/blog/my-post'
|
||||
image, // '/images/og/my-post.jpg' or full URL
|
||||
imageAlt,
|
||||
imageWidth = 1200,
|
||||
imageHeight = 630,
|
||||
}) {
|
||||
const baseUrl = process.env.NEXT_PUBLIC_BASE_URL || 'https://www.yourdomain.com';
|
||||
|
||||
// Always produce an absolute URL
|
||||
const imageUrl = image?.startsWith('http') ? image : `${baseUrl}${image}`;
|
||||
const pageUrl = `${baseUrl}${path}`;
|
||||
|
||||
// Detect MIME type from extension
|
||||
const ext = imageUrl.split('.').pop().toLowerCase();
|
||||
const mimeMap = { jpg: 'image/jpeg', jpeg: 'image/jpeg', png: 'image/png', webp: 'image/webp' };
|
||||
const imageType = mimeMap[ext] || 'image/jpeg';
|
||||
|
||||
return {
|
||||
title,
|
||||
description,
|
||||
alternates: { canonical: pageUrl },
|
||||
openGraph: {
|
||||
title,
|
||||
description,
|
||||
url: pageUrl,
|
||||
type: 'website', // use 'article' for blog posts
|
||||
images: [{
|
||||
url: imageUrl,
|
||||
secureUrl: imageUrl, // explicit HTTPS version
|
||||
width: imageWidth,
|
||||
height: imageHeight,
|
||||
alt: imageAlt || title,
|
||||
type: imageType,
|
||||
}],
|
||||
},
|
||||
twitter: {
|
||||
card: 'summary_large_image', // NOT 'summary' — that shows a tiny image
|
||||
title,
|
||||
description,
|
||||
images: [imageUrl],
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Applying the Helper
|
||||
|
||||
### Static page
|
||||
```js
|
||||
// app/about/page.js
|
||||
import { buildSocialMetadata } from '@/lib/socialMetadata';
|
||||
|
||||
export const metadata = buildSocialMetadata({
|
||||
title: 'About Us | My Site',
|
||||
description: 'Learn about our team and mission.',
|
||||
path: '/about',
|
||||
image: '/images/og/about.jpg',
|
||||
imageAlt: 'The My Site team',
|
||||
});
|
||||
```
|
||||
|
||||
### Dynamic page (blog post, tool page)
|
||||
```js
|
||||
// app/blog/[slug]/page.js
|
||||
import { buildSocialMetadata } from '@/lib/socialMetadata';
|
||||
|
||||
export async function generateMetadata({ params }) {
|
||||
const post = await getPost(params.slug);
|
||||
return buildSocialMetadata({
|
||||
title: `${post.title} | My Blog`,
|
||||
description: post.excerpt,
|
||||
path: `/blog/${params.slug}`,
|
||||
image: post.ogImage || '/images/og/default.jpg',
|
||||
imageAlt: post.title,
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### Homepage (app/layout.js or app/page.js)
|
||||
```js
|
||||
export const metadata = {
|
||||
metadataBase: new URL('https://www.yourdomain.com'), // REQUIRED for absolute URLs
|
||||
...buildSocialMetadata({
|
||||
title: 'My Site — Tagline Here',
|
||||
description: 'Site-wide description.',
|
||||
path: '/',
|
||||
image: '/images/og/home.jpg',
|
||||
}),
|
||||
};
|
||||
```
|
||||
|
||||
> ⚠️ **`metadataBase` is critical.** Without it, Next.js generates relative OG image URLs that every platform rejects.
|
||||
|
||||
---
|
||||
|
||||
## OG Image Checklist
|
||||
|
||||
Good OG images:
|
||||
- **1200 × 630px** (2:1 ratio — works on all platforms)
|
||||
- **Under 8MB** (Facebook limit)
|
||||
- Served over **HTTPS**
|
||||
- File name has **no spaces** (use hyphens)
|
||||
- Format: **JPEG or PNG** (WebP works on most but not all crawlers)
|
||||
- **Accessible via GET** with no authentication
|
||||
|
||||
```bash
|
||||
# Verify your OG image is reachable and correct size
|
||||
curl -sI https://www.yourdomain.com/images/og/home.jpg | grep -i "content-type\|content-length\|status"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Platform-Specific Notes
|
||||
|
||||
### Facebook / Meta
|
||||
- Caches aggressively — use the [Sharing Debugger](https://developers.facebook.com/tools/debug/) to force recrawl
|
||||
- Minimum image: 200×200px (but use 1200×630 for quality)
|
||||
- Needs: `og:title`, `og:description`, `og:image`, `og:url`
|
||||
|
||||
### X / Twitter
|
||||
- Use `twitter:card = summary_large_image` for full-width images
|
||||
- `twitter:image` must be an absolute URL
|
||||
- Use the [Card Validator](https://cards-dev.twitter.com/validator) to test
|
||||
|
||||
### LinkedIn
|
||||
- Caches hard — use [Post Inspector](https://www.linkedin.com/post-inspector/) to refresh
|
||||
- Respects `og:` tags; ignores `twitter:` tags
|
||||
- Image must be ≥1.91:1 aspect ratio
|
||||
|
||||
### WhatsApp / Telegram
|
||||
- Read OG tags on first share; cache can last hours
|
||||
- Re-share after a few hours for the cache to clear naturally
|
||||
|
||||
### Slack / Discord
|
||||
- Both use OG tags; both cache
|
||||
- Discord also supports `og:type = article` for richer embeds
|
||||
|
||||
---
|
||||
|
||||
## Debugging Social Previews
|
||||
|
||||
### 1. Check raw HTML for tags
|
||||
```bash
|
||||
curl -s https://www.yourdomain.com/blog/my-post | grep -i "og:\|twitter:"
|
||||
```
|
||||
If tags don't appear → they're being added by JavaScript (not crawlable). Fix: move to `export const metadata` or `generateMetadata`.
|
||||
|
||||
### 2. Validate with platform tools
|
||||
| Platform | Tool |
|
||||
|----------|------|
|
||||
| Facebook | https://developers.facebook.com/tools/debug/ |
|
||||
| LinkedIn | https://www.linkedin.com/post-inspector/ |
|
||||
| Twitter/X | https://cards-dev.twitter.com/validator |
|
||||
| General | https://metatags.io |
|
||||
|
||||
### 3. Force cache refresh
|
||||
After deploying fixes, paste the URL into each platform's debugger and click "Fetch new scrape information" (or equivalent).
|
||||
|
||||
---
|
||||
|
||||
## Social Metadata Checklist
|
||||
|
||||
- [ ] `metadataBase` set in root layout
|
||||
- [ ] All shareable pages use shared `buildSocialMetadata` helper
|
||||
- [ ] OG image URLs are absolute (start with `https://`)
|
||||
- [ ] `secureUrl` set equal to `url` in OG image block
|
||||
- [ ] Image is 1200×630px, under 8MB, HTTPS
|
||||
- [ ] `twitter:card` is `summary_large_image` (not `summary`)
|
||||
- [ ] Image alt text present
|
||||
- [ ] Tags visible in raw HTML (not JavaScript-rendered)
|
||||
- [ ] All platform debuggers show correct preview
|
||||
- [ ] Cache refreshed on all platforms after deployment
|
||||
|
||||
## Limitations
|
||||
|
||||
- Cannot force immediate cache refresh on every social platform; some previews may remain stale after a correct fix.
|
||||
- Requires deployed, publicly reachable URLs for reliable validation with platform debuggers.
|
||||
- Does not replace brand, accessibility, or legal review of image text, alt text, and preview copy.
|
||||
@@ -0,0 +1,231 @@
|
||||
---
|
||||
name: vibe-code-cleanup
|
||||
description: "Safe production cleanup and hardening for vibe-coded fullstack apps (Next.js, React, Node.js, etc.). Removes dead imports, unused files, broken references, and standardizes helpers without breaking routes or APIs."
|
||||
category: fullstack
|
||||
risk: safe
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-05-31"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [cleanup, refactor, nextjs, production, vibe-code, fullstack, nodejs]
|
||||
tools: [claude, cursor, gemini, claude-code]
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Vibe-Code Cleanup — Production Refactor Skill
|
||||
|
||||
A safe, incremental cleanup workflow for AI-generated / vibe-coded fullstack apps.
|
||||
The goal is to make the codebase production-ready **without** breaking anything that already works.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Use when a rapidly built app works but has broken imports, duplicated logic, dead code, unclear environment variables, or fragile release hygiene.
|
||||
- Use before launch or handoff to convert exploratory code into a maintainable production baseline.
|
||||
- Use when cleanup must preserve existing behavior and avoid broad rewrites of routes, APIs, auth, data models, or integrations.
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
> **Surgery, not demolition.** Remove only what is provably dead. Preserve everything else.
|
||||
|
||||
Never:
|
||||
- Rewrite working systems for cosmetic reasons
|
||||
- Rename routes, slugs, or API endpoints that may be indexed or cached
|
||||
- Change tool inputs/outputs, API contracts, DB schema, or auth flow
|
||||
- Delete files you haven't verified are unused
|
||||
- Make broad sweeping changes in a single commit
|
||||
|
||||
Always:
|
||||
- Make small, targeted, reversible changes
|
||||
- Validate after every meaningful batch of changes
|
||||
- Prefer shared helpers over copy-pasted blocks
|
||||
- Keep backward compatibility
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Reconnaissance (read before touching)
|
||||
|
||||
Before changing anything, map the codebase:
|
||||
|
||||
```bash
|
||||
# List all pages/routes
|
||||
find . -path "*/app/**/page.{js,jsx,ts,tsx}" | sort
|
||||
find . -path "*/pages/**/*.{js,jsx,ts,tsx}" | grep -v "_" | sort
|
||||
|
||||
# Find broken imports (TS projects)
|
||||
npx tsc --noEmit 2>&1 | head -80
|
||||
|
||||
# Find unused exports (optional, for larger projects)
|
||||
npx ts-prune 2>/dev/null | head -40
|
||||
|
||||
# Check for console.log / debug leftovers
|
||||
grep -r "console\.log\|debugger\|TODO\|FIXME\|HACK" --include="*.{js,ts,jsx,tsx}" -l
|
||||
```
|
||||
|
||||
Document what you find. Do NOT change yet.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Fix Broken Imports First
|
||||
|
||||
Broken imports cause build failures and should be fixed before anything else.
|
||||
|
||||
```bash
|
||||
# TypeScript: list all errors
|
||||
npx tsc --noEmit 2>&1
|
||||
|
||||
# Common patterns to fix:
|
||||
# - Missing file (file was deleted or renamed)
|
||||
# - Wrong relative path (../lib vs ../../lib)
|
||||
# - Named export that doesn't exist
|
||||
```
|
||||
|
||||
**Fix rule:** Fix the import reference. Do NOT delete the referenced file unless you've confirmed it's unused everywhere.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Identify Dead Code (verify before removing)
|
||||
|
||||
A file/export is safe to remove **only if**:
|
||||
1. No other file imports it (grep-confirmed)
|
||||
2. It's not referenced in config, sitemap, or route manifest
|
||||
3. It's not a public-facing URL (page.js, route.js)
|
||||
|
||||
```bash
|
||||
# Check if a file is imported anywhere
|
||||
grep -r "from.*my-file\|require.*my-file" --include="*.{js,ts,jsx,tsx}" .
|
||||
|
||||
# Check if a component is used anywhere
|
||||
grep -r "MyComponent" --include="*.{js,ts,jsx,tsx}" .
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Consolidate Repeated Logic into Helpers
|
||||
|
||||
Look for repeated patterns (metadata blocks, API fetch wrappers, error handlers) that appear in 3+ places.
|
||||
|
||||
**Good consolidation targets:**
|
||||
- Page-level SEO metadata (Open Graph, Twitter cards, canonical)
|
||||
- Fetch wrappers with error handling
|
||||
- Repeated utility functions (slugify, formatDate, truncate)
|
||||
|
||||
**Bad consolidation targets (leave alone):**
|
||||
- One-off business logic
|
||||
- Route handlers with different contracts
|
||||
- Anything touching DB schema or auth
|
||||
|
||||
**Pattern for shared metadata helper (Next.js):**
|
||||
```js
|
||||
// lib/socialMetadata.js
|
||||
export function buildPageMetadata({ title, description, path, image }) {
|
||||
const baseUrl = process.env.NEXT_PUBLIC_BASE_URL || 'https://yourdomain.com';
|
||||
const imageUrl = image?.startsWith('http') ? image : `${baseUrl}${image}`;
|
||||
|
||||
return {
|
||||
title,
|
||||
description,
|
||||
openGraph: {
|
||||
title,
|
||||
description,
|
||||
url: `${baseUrl}${path}`,
|
||||
images: [{ url: imageUrl, width: 1200, height: 630, alt: title }],
|
||||
},
|
||||
twitter: {
|
||||
card: 'summary_large_image',
|
||||
title,
|
||||
description,
|
||||
images: [imageUrl],
|
||||
},
|
||||
alternates: {
|
||||
canonical: `${baseUrl}${path}`,
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Environment Variable Audit
|
||||
|
||||
```bash
|
||||
# List all env vars used in code
|
||||
grep -r "process\.env\." --include="*.{js,ts,jsx,tsx}" . | grep -oP 'process\.env\.\w+' | sort -u
|
||||
|
||||
# Compare against .env.example or .env.local
|
||||
cat .env.example 2>/dev/null || cat .env.local 2>/dev/null
|
||||
```
|
||||
|
||||
Flag any env vars used in code but missing from `.env.example`. Never add secrets to version control.
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Validate After Every Batch
|
||||
|
||||
Run this after every meaningful batch of cleanup changes:
|
||||
|
||||
```bash
|
||||
# TypeScript check
|
||||
npx tsc --noEmit
|
||||
|
||||
# Lint
|
||||
npx eslint . --ext .js,.jsx,.ts,.tsx --max-warnings 0
|
||||
|
||||
# Build (catches runtime issues TypeScript misses)
|
||||
npm run build
|
||||
|
||||
# Tests (if present)
|
||||
npm test -- --runInBand --passWithNoTests
|
||||
```
|
||||
|
||||
If build or typecheck breaks → **revert the last batch** before continuing.
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Commit Strategy
|
||||
|
||||
Each commit should be a single logical unit:
|
||||
|
||||
```
|
||||
fix: remove broken import in app/blog/page.js
|
||||
refactor: consolidate social metadata into lib/socialMetadata.js
|
||||
chore: remove verified-unused utils/oldHelper.js
|
||||
fix: standardize env var references to NEXT_PUBLIC_BASE_URL
|
||||
```
|
||||
|
||||
Never bundle UI changes + logic changes + file deletions in one commit. Smaller commits = easier rollback.
|
||||
|
||||
---
|
||||
|
||||
## What NOT to Clean Up
|
||||
|
||||
Treat these as off-limits unless there's a verified bug:
|
||||
|
||||
| Area | Why |
|
||||
|------|-----|
|
||||
| Route slugs / page paths | May be indexed by Google |
|
||||
| API route contracts | Callers depend on exact shape |
|
||||
| DB schema / Prisma models | Migration required |
|
||||
| Auth flow logic | Security-sensitive |
|
||||
| Third-party integration configs | Keys/webhooks are environment-specific |
|
||||
| Working tool pages | User-facing functionality |
|
||||
|
||||
---
|
||||
|
||||
## Cleanup Checklist
|
||||
|
||||
- [ ] TypeScript errors fixed
|
||||
- [ ] No broken imports
|
||||
- [ ] Dead code removed (grep-verified)
|
||||
- [ ] Shared helpers created for repeated patterns (3+ uses)
|
||||
- [ ] No hardcoded secrets or local-only URLs
|
||||
- [ ] All env vars documented in `.env.example`
|
||||
- [ ] Build passes
|
||||
- [ ] Tests pass (or no tests exist)
|
||||
- [ ] Lint passes
|
||||
- [ ] Each commit is scoped and explainable
|
||||
|
||||
## Limitations
|
||||
|
||||
- Does not infer product intent from code alone; confirm behavior before deleting routes, components, API contracts, or data models.
|
||||
- Cleanup should be applied in small reviewed batches because broad refactors can hide regressions.
|
||||
- Avoid changing auth, billing, persistence, or third-party integration behavior without explicit requirements and tests.
|
||||
@@ -0,0 +1,237 @@
|
||||
---
|
||||
name: vibecode-production-qa-validator
|
||||
description: "End-to-end production QA, build verification, and launch-readiness checklist for fullstack Next.js apps before going live or shipping a major update. Covers TypeScript, linting, tests, build, SEO tags, route regression, and sitemap validation."
|
||||
category: devops
|
||||
risk: safe
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-05-31"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [qa, testing, nextjs, production, build-validation, deployment, seo]
|
||||
tools: [claude, cursor, gemini, claude-code]
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Production QA Validator Skill
|
||||
|
||||
The end-to-end launch checklist for fullstack Next.js apps. Run this before every production deployment or after any major change.
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- Use before deploying a vibe-coded or fast-built app to production.
|
||||
- Use when validating build output, SEO tags, sitemap routes, API routes, git diff cleanliness, and post-deploy smoke checks.
|
||||
- Use when you need a concrete definition of done for release readiness across code, runtime behavior, and public URLs.
|
||||
|
||||
---
|
||||
|
||||
## The Full Validation Command Sequence
|
||||
|
||||
Run in order — stop and fix on any failure before continuing:
|
||||
|
||||
```bash
|
||||
# 1. TypeScript — catches type errors and broken imports
|
||||
npx tsc --noEmit
|
||||
|
||||
# 2. Custom validation scripts (if present)
|
||||
npm run validate 2>/dev/null || echo "No validate script"
|
||||
|
||||
# 3. Canonical/SEO linting (if present)
|
||||
npm run lint:canon 2>/dev/null || echo "No canon lint"
|
||||
npm run lint:anchors 2>/dev/null || echo "No anchor lint"
|
||||
npm run lint:links 2>/dev/null || echo "No link lint"
|
||||
|
||||
# 4. ESLint
|
||||
npx eslint . --ext .js,.jsx,.ts,.tsx --max-warnings 0
|
||||
|
||||
# 5. Tests
|
||||
npm test -- --runInBand --passWithNoTests
|
||||
|
||||
# 6. Production build — the final arbiter
|
||||
npm run build
|
||||
```
|
||||
|
||||
All 6 must pass before committing.
|
||||
|
||||
---
|
||||
|
||||
## Reading the Build Output
|
||||
|
||||
```bash
|
||||
npm run build 2>&1 | tee build.log
|
||||
|
||||
# Check for errors
|
||||
grep -i "error\|failed\|cannot" build.log | grep -v "no errors"
|
||||
|
||||
# Check static page count
|
||||
grep "Static pages\|○\|●" build.log | tail -5
|
||||
```
|
||||
|
||||
### Route symbols explained
|
||||
| Symbol | Meaning | Expected? |
|
||||
|--------|---------|-----------|
|
||||
| `○` | Static (rendered at build time) | ✓ Good for most pages |
|
||||
| `●` | SSG (generated from `generateStaticParams`) | ✓ Good for dynamic pages |
|
||||
| `λ` | Serverless (dynamic, rendered on request) | ✓ APIs and truly dynamic pages only |
|
||||
| `⊕` | Partial prerender | ✓ Fine |
|
||||
|
||||
If an important SEO page shows `λ` and should be static, add `generateStaticParams` or use `export const dynamic = 'force-static'`.
|
||||
|
||||
---
|
||||
|
||||
## SEO Tags in Raw HTML Verification
|
||||
|
||||
Crawlers don't run JavaScript. Metadata must be in the raw HTML response.
|
||||
|
||||
```bash
|
||||
# Check a page's metadata
|
||||
curl -s https://www.yourdomain.com/blog/my-post | grep -i \
|
||||
"og:title\|og:description\|og:image\|twitter:card\|canonical\|description"
|
||||
|
||||
# Expected output should include all of these:
|
||||
# <meta property="og:title" content="..." />
|
||||
# <meta property="og:description" content="..." />
|
||||
# <meta property="og:image" content="https://..." />
|
||||
# <meta name="twitter:card" content="summary_large_image" />
|
||||
# <link rel="canonical" href="https://..." />
|
||||
# <meta name="description" content="..." />
|
||||
```
|
||||
|
||||
If tags are missing from raw HTML: they're added by client-side JavaScript. Fix: move to `export const metadata` or `generateMetadata`.
|
||||
|
||||
---
|
||||
|
||||
## Route Regression Testing
|
||||
|
||||
After any major change, verify all critical route types still return 200:
|
||||
|
||||
```bash
|
||||
BASE="https://www.yourdomain.com"
|
||||
|
||||
# Core pages
|
||||
for path in "/" "/about" "/contact" "/privacy" "/terms" "/faq"; do
|
||||
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE$path")
|
||||
echo "$STATUS $BASE$path"
|
||||
done
|
||||
|
||||
# Sitemaps
|
||||
for path in "/sitemap.xml" "/robots.txt"; do
|
||||
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE$path")
|
||||
echo "$STATUS $BASE$path"
|
||||
done
|
||||
|
||||
# Sample dynamic routes (test a few real slugs)
|
||||
for path in "/tools/keyword-density-checker" "/blog/my-post-slug"; do
|
||||
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE$path")
|
||||
echo "$STATUS $BASE$path"
|
||||
done
|
||||
```
|
||||
|
||||
All should return `200`. Investigate anything returning `404`, `500`, or `301`/`302` when a direct URL was expected.
|
||||
|
||||
---
|
||||
|
||||
## Sitemap Validation
|
||||
|
||||
```bash
|
||||
# Fetch and validate sitemap XML
|
||||
curl -s https://www.yourdomain.com/sitemap.xml | python3 -c "
|
||||
import sys, xml.etree.ElementTree as ET
|
||||
try:
|
||||
ET.parse(sys.stdin)
|
||||
print('✓ Valid XML')
|
||||
except Exception as e:
|
||||
print(f'✗ Invalid XML: {e}')
|
||||
"
|
||||
|
||||
# Count URLs in sitemap
|
||||
curl -s https://www.yourdomain.com/sitemap.xml | grep -c "<loc>"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## API Route Testing
|
||||
|
||||
```bash
|
||||
# Test API endpoints return expected content-type and status
|
||||
for path in "/api/health" "/api/tools"; do
|
||||
RESULT=$(curl -s -o /dev/null -w "%{http_code} %{content_type}" "$BASE$path")
|
||||
echo "$RESULT $path"
|
||||
done
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pre-Commit Git Checklist
|
||||
|
||||
Before committing:
|
||||
|
||||
```bash
|
||||
# Review what's changed
|
||||
git diff --stat HEAD
|
||||
|
||||
# Ensure no secrets or local-only files
|
||||
git diff HEAD | grep -i "password\|secret\|api_key\|localhost:3000" | grep "^+"
|
||||
|
||||
# Confirm no build artifacts are staged
|
||||
git status | grep -E "\.next|node_modules"
|
||||
```
|
||||
|
||||
Good commit message format:
|
||||
```
|
||||
type(scope): brief description
|
||||
|
||||
fix(seo): add canonical tags to all blog pages
|
||||
feat(tools): add keyword density checker page
|
||||
refactor(metadata): consolidate OG/Twitter tags into shared helper
|
||||
chore(cleanup): remove unused utils/oldHelper.js
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Post-Deployment Smoke Test
|
||||
|
||||
Run 5–10 minutes after deployment:
|
||||
|
||||
```bash
|
||||
PROD="https://www.yourdomain.com"
|
||||
|
||||
# Homepage loads
|
||||
curl -sI "$PROD" | grep -i "http\|status"
|
||||
|
||||
# Key page loads
|
||||
curl -sI "$PROD/tools/keyword-density-checker" | grep "200\|301\|404"
|
||||
|
||||
# No JS errors (requires manual browser check)
|
||||
# Open browser → Console → look for red errors
|
||||
|
||||
# OG image loads
|
||||
curl -sI "$PROD/images/og/home.jpg" | grep -i "200\|content-type"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Definition of Done
|
||||
|
||||
A change is **production-ready** only when ALL of the following are true:
|
||||
|
||||
- [ ] `npx tsc --noEmit` passes
|
||||
- [ ] `npm run validate` passes (or no script)
|
||||
- [ ] `npm run lint:canon` passes (or no script)
|
||||
- [ ] `npx eslint .` passes with 0 warnings
|
||||
- [ ] `npm test` passes or no tests exist
|
||||
- [ ] `npm run build` completes successfully
|
||||
- [ ] Important pages show `○` or `●` in build output (not `λ`)
|
||||
- [ ] SEO tags visible in `curl` output for key pages
|
||||
- [ ] All sitemap routes return valid XML
|
||||
- [ ] No new 404s on previously working routes
|
||||
- [ ] No secrets in git diff
|
||||
- [ ] Commit message is scoped and descriptive
|
||||
- [ ] Social preview platforms show correct card after cache refresh
|
||||
|
||||
## Limitations
|
||||
|
||||
- Passing this checklist reduces release risk but does not prove the absence of production bugs.
|
||||
- Some checks depend on project-specific scripts, deployment topology, and external services that may not exist in every app.
|
||||
- Manual exploratory testing is still required for critical user journeys, payments, auth, and data mutation flows.
|
||||
+226
-159
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: wordpress-centric-high-seo-optimized-blogwriting-skill
|
||||
description: "Create long-form, high-quality, SEO-optimized blog posts ready for WordPress with truth boxes and FAQ schema."
|
||||
description: "Generate clean, human-sounding, SEO-optimized WordPress blog posts with optional Yoast metadata, JSON-LD schema markup, and image SEO planning. Supports modular batch output."
|
||||
category: content
|
||||
risk: safe
|
||||
source: self
|
||||
@@ -9,266 +9,333 @@ date_added: "2026-04-12"
|
||||
author: Whoisabhishekadhikari
|
||||
tags: [writing, blog, seo, content, wordpress]
|
||||
tools: [claude, cursor, gemini]
|
||||
version: 1.0.3
|
||||
version: 1.1.0
|
||||
---
|
||||
|
||||
# WordPress Centric High SEO Optimized Blog Writing Skill
|
||||
# WordPress SEO Blog Writing Skill
|
||||
|
||||
## Overview
|
||||
|
||||
This skill is designed for Senior Content Strategists and Expert Copywriters to create high-quality, long-form blog posts that are ready for direct publication in WordPress. It emphasizes professional structure, factual accuracy (Truth Boxes), and comprehensive SEO optimization (Yoast elements and Schema markup).
|
||||
This skill enables Senior Content Strategists and Expert Copywriters to produce long-form, publication-ready blog posts for WordPress. It enforces professional structure, factual rigor, and comprehensive SEO optimization — including Yoast metadata and JSON-LD schema markup.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- Use when you need to write a professional blog post or article.
|
||||
- Use when creating SEO-optimized content for a WordPress site.
|
||||
- Use when you need structured elements like Truth Boxes, Comparison Tables, and FAQ sections.
|
||||
- Use when the user requires Yoast SEO metadata and JSON-LD schema.
|
||||
- Writing a professional blog post or article for WordPress
|
||||
- Creating SEO-optimized content targeting a specific keyword and intent
|
||||
- Structuring content with Truth Boxes, Comparison Tables, and FAQ sections
|
||||
- Generating Yoast SEO metadata and JSON-LD schema markup
|
||||
|
||||
---
|
||||
|
||||
## Inputs Required
|
||||
|
||||
| Field | Required | Description |
|
||||
|---|---|---|
|
||||
| Title | Yes | The blog post headline |
|
||||
| Primary Keyword | Yes | The target SEO keyword |
|
||||
| Intent | Yes | Informational, Commercial, or Transactional |
|
||||
| Niche / Industry | Yes | The subject area or vertical |
|
||||
| Yoast SEO | Ask if missing | Whether to include Yoast metadata |
|
||||
| Image Count | Ask if missing | Number of images to plan SEO for |
|
||||
| Brand | Optional | Brand name for tone alignment |
|
||||
| Target Audience | Optional | Intended reader profile |
|
||||
| Key Themes / Context | Optional | Specific locations, products, or pain points |
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Gather Inputs
|
||||
The skill requires a Title, Primary Keyword, Intent, and Niche/Industry. It also prompts for Yoast SEO preference and image count if not provided.
|
||||
### Step 1 — Gather Inputs
|
||||
Collect all required fields. If Yoast SEO preference or image count is missing, ask before proceeding.
|
||||
|
||||
### Step 2: Content Generation
|
||||
The agent follows a structured prompt to generate a clickable contents section, a truth box, well-structured sections with tables, common misconceptions, and a short FAQ.
|
||||
### Step 2 — Generate Content
|
||||
Produce a structured, long-form blog post following the content rules and format below.
|
||||
|
||||
### Step 3: SEO & Schema (Optional)
|
||||
If requested, the agent provides Yoast SEO metadata (Social titles, meta descriptions) and JSON-LD Schema (BlogPosting, FAQPage).
|
||||
### Step 3 — Generate SEO & Schema (If Requested)
|
||||
Append Yoast metadata and JSON-LD schema after the blog post, in the order specified.
|
||||
|
||||
---
|
||||
|
||||
## Prompt Template
|
||||
|
||||
FINAL MASTER PROMPT (Refined & Generalized Version)
|
||||
```text
|
||||
You are a Senior Content Strategist, Expert Copywriter, and Subject Matter Expert
|
||||
in the provided niche.
|
||||
|
||||
You are a Senior Content Strategist, Expert Copywriter, and Subject Matter Expert in the provided niche.
|
||||
Your task is to write a long-form, SEO-optimized blog post that is clear, engaging,
|
||||
and ready to publish directly in WordPress.
|
||||
|
||||
Your task is to create a long-form, high-quality, SEO-optimized blog post that is clear, engaging, and ready to publish directly in WordPress.
|
||||
---
|
||||
|
||||
INPUT
|
||||
|
||||
Title: {Insert Title}
|
||||
Primary Keyword: {Insert Primary Keyword}
|
||||
Intent: {Informational / Commercial / Transactional}
|
||||
Niche/Industry: {Insert Industry or Subject Area}
|
||||
Title: {Insert Title}
|
||||
Primary Keyword: {Insert Primary Keyword}
|
||||
Intent: {Informational / Commercial / Transactional}
|
||||
Niche/Industry: {Insert Industry or Subject Area}
|
||||
|
||||
USER PREFERENCES (ASK IF MISSING)
|
||||
Yoast SEO: {Are Yoast SEO elements like meta descriptions and focus keyphrases needed?}
|
||||
Image Count: {How many images should be included in the SEO plan?}
|
||||
OPTIONAL CONTEXT
|
||||
|
||||
Optional Context
|
||||
Brand: {Insert Brand Name}
|
||||
Target Audience: {Insert Target Audience}
|
||||
Key Themes/Context: {Insert any specific context, locations, products, or pain points to highlight}
|
||||
Brand: {Insert Brand Name}
|
||||
Target Audience: {Insert Target Audience}
|
||||
Key Themes / Context: {Insert specific context, locations, products, or pain points}
|
||||
|
||||
---
|
||||
|
||||
RESEARCH REQUIREMENT
|
||||
|
||||
If web browsing access is available:
|
||||
- Review at least 10 reliable sources related to the topic to ensure accuracy, depth, and credibility.
|
||||
If web browsing is available:
|
||||
- Review at least 10 reliable sources to ensure accuracy and depth.
|
||||
|
||||
If web browsing is restricted or unavailable:
|
||||
- Disclose access limits immediately.
|
||||
- Forbid claiming a specific source count.
|
||||
- Rely only on verified internal knowledge or state that information cannot be verified.
|
||||
If web browsing is unavailable:
|
||||
- Disclose the limitation immediately.
|
||||
- Do not claim a specific source count.
|
||||
- Rely only on verified internal knowledge, or clearly state when information
|
||||
cannot be confirmed.
|
||||
|
||||
---
|
||||
|
||||
WRITING RULES
|
||||
Use simple, natural, human language
|
||||
Avoid robotic or AI-like tone
|
||||
Keep sentences short and clear
|
||||
Keep paragraphs concise
|
||||
Avoid long dashes
|
||||
Avoid unnecessary symbols
|
||||
Minimize use of brackets
|
||||
Do not number headings
|
||||
Maintain clean and consistent formatting
|
||||
Make content easy to scan and copy
|
||||
|
||||
FACT AND ACCURACY RULES
|
||||
- Use simple, natural, human language.
|
||||
- Avoid robotic or AI-like tone.
|
||||
- Keep sentences short and paragraphs concise.
|
||||
- Do not use long dashes, unnecessary symbols, or brackets.
|
||||
- Do not number headings.
|
||||
- Maintain clean, consistent formatting throughout.
|
||||
- Prioritize readability and scannability.
|
||||
|
||||
Do not guess or fabricate data.
|
||||
- Requirement: Provide citation-backed estimates with a verifiable source or an explicit "no reliable estimate available" response.
|
||||
- Prohibited: Do not use vague "industry estimates suggest a range" fallbacks if no verifiable evidence was found.
|
||||
---
|
||||
|
||||
Avoid fake or unreliable sources
|
||||
Keep all information practical, realistic, and up-to-date
|
||||
ACCURACY RULES
|
||||
|
||||
- Do not guess or fabricate data.
|
||||
- Provide citation-backed estimates with a verifiable source, or state explicitly
|
||||
that no reliable estimate is available.
|
||||
- Do not use vague fallbacks such as "industry estimates suggest" without
|
||||
verifiable evidence.
|
||||
- Avoid fake or unreliable sources.
|
||||
- Keep all information practical, realistic, and current.
|
||||
|
||||
---
|
||||
|
||||
CONTENTS SECTION
|
||||
|
||||
Create a clickable contents section with:
|
||||
Generate a clickable table of contents using this structure:
|
||||
|
||||
Contents
|
||||
Contents
|
||||
|
||||
Introduction
|
||||
[Core Topic Section 1 - e.g., Overview/Key Concepts]
|
||||
[Core Topic Section 2 - e.g., Deep Dive/Analysis]
|
||||
[Core Topic Section 3 - e.g., Practical Application/Steps]
|
||||
[Comparison/Alternatives Section]
|
||||
[Industry/Market Context]
|
||||
Misconceptions
|
||||
FAQ
|
||||
Conclusion
|
||||
Introduction
|
||||
[Core Topic Section 1 — e.g., Overview or Key Concepts]
|
||||
[Core Topic Section 2 — e.g., Deep Dive or Analysis]
|
||||
[Core Topic Section 3 — e.g., Practical Application or Steps]
|
||||
[Comparison or Alternatives Section]
|
||||
[Industry or Market Context]
|
||||
Common Misconceptions
|
||||
FAQ
|
||||
Conclusion
|
||||
|
||||
Do not use hyphen bullets
|
||||
Do not use hyphen bullets in the final output.
|
||||
|
||||
---
|
||||
|
||||
MAIN BLOG STRUCTURE
|
||||
|
||||
Main Title
|
||||
Main Title
|
||||
|
||||
Introduction
|
||||
Introduction
|
||||
|
||||
Truth Box
|
||||
Truth Box
|
||||
|
||||
[Core Topic Section 1]
|
||||
[Relevant Table 1 — e.g., Key Features, Pros/Cons, Pricing, or Summary]
|
||||
|
||||
[Core Topic Section 1]
|
||||
[Core Topic Section 2]
|
||||
[Relevant Table 2 — e.g., Data, Comparison, or Checklist]
|
||||
|
||||
[Relevant Output Table 1 - e.g., Key Features, Pros/Cons, Pricing, or Summary]
|
||||
[Core Topic Section 3]
|
||||
|
||||
[Core Topic Section 2]
|
||||
[Comparison / Alternatives Section]
|
||||
|
||||
[Relevant Output Table 2 - e.g., Data, Comparison, or Checklist]
|
||||
Common Misconceptions
|
||||
|
||||
[Core Topic Section 3]
|
||||
FAQ
|
||||
|
||||
[Comparison/Alternatives Section]
|
||||
Conclusion
|
||||
|
||||
Common Misconceptions
|
||||
|
||||
FAQ
|
||||
|
||||
Conclusion
|
||||
---
|
||||
|
||||
TRUTH BOX
|
||||
|
||||
Create a table with 5 strong insights relevant to the topic.
|
||||
A table with 5 strong, topic-relevant insights.
|
||||
|
||||
Example columns:
|
||||
Key Point | Insight
|
||||
Columns: Key Point | Insight
|
||||
|
||||
TABLE USAGE
|
||||
---
|
||||
|
||||
Use clean tables where helpful, such as:
|
||||
TABLES
|
||||
|
||||
Features or Pricing comparison
|
||||
Pros & Cons
|
||||
Industry or category comparisons
|
||||
Step-by-step summaries
|
||||
Use clean markdown tables where they add clarity, such as:
|
||||
- Feature or pricing comparisons
|
||||
- Pros and cons
|
||||
- Industry or category breakdowns
|
||||
- Step-by-step summaries
|
||||
|
||||
WRITING STYLE
|
||||
Clear and direct
|
||||
Professional yet simple
|
||||
No fluff
|
||||
Logical flow
|
||||
Break long sections into small readable parts
|
||||
---
|
||||
|
||||
COMMON MISCONCEPTIONS
|
||||
|
||||
Include 3 common myths with simple corrections
|
||||
Include 3 common myths about the topic with clear, simple corrections.
|
||||
|
||||
---
|
||||
|
||||
FAQ SECTION
|
||||
Add 5 real user questions relevant to the intent and target keywords.
|
||||
Keep answers short and clear
|
||||
|
||||
Include 5 real user questions relevant to the topic, intent, and target keywords.
|
||||
Keep answers short and direct.
|
||||
|
||||
---
|
||||
|
||||
IMAGE SEO SECTION
|
||||
|
||||
Include {User Requested Count} images
|
||||
Plan SEO for {User Requested Count} images.
|
||||
|
||||
For each image, provide:
|
||||
- Alt Text (at least one must include the primary keyword)
|
||||
- Title
|
||||
- Caption
|
||||
- Description
|
||||
- Placement in the post
|
||||
|
||||
Alt Text
|
||||
Title
|
||||
Caption
|
||||
Description
|
||||
Placement
|
||||
Always include one Featured Image.
|
||||
|
||||
Requirements:
|
||||
|
||||
Include one Feature Image
|
||||
At least one alt text must contain the primary keyword
|
||||
---
|
||||
|
||||
FINAL CHECKLIST
|
||||
Remove unnecessary symbols
|
||||
Ensure no numbered headings
|
||||
Ensure no long dashes
|
||||
Ensure readability
|
||||
Ensure WordPress-ready formatting
|
||||
Ensure clean and consistent structure
|
||||
|
||||
OUTPUT REQUIREMENT
|
||||
Before delivering the output, confirm:
|
||||
- No unnecessary symbols
|
||||
- No numbered headings
|
||||
- No long dashes
|
||||
- Content is readable and well-paced
|
||||
- Formatting is WordPress-ready and consistent
|
||||
```
|
||||
|
||||
The final output must be generated in this order:
|
||||
1. The full blog post (from Main Title to Conclusion)
|
||||
---
|
||||
|
||||
## Output Order
|
||||
|
||||
In default (non-batch) mode, deliver output in this sequence:
|
||||
|
||||
1. Full blog post (Main Title through Conclusion)
|
||||
2. SEO Section (if requested)
|
||||
3. Schema Markup (if requested)
|
||||
|
||||
The content must be:
|
||||
When a batch mode is selected, return only the requested component(s).
|
||||
|
||||
Clean and well-structured
|
||||
SEO optimized
|
||||
Human-sounding
|
||||
Professional quality
|
||||
Ready to copy and paste into WordPress
|
||||
---
|
||||
|
||||
SEO SECTION (YOAST)
|
||||
*Only provide this section if the user requested Yoast SEO elements.*
|
||||
## Batch Output Options
|
||||
|
||||
Provide the following:
|
||||
Use batch mode when the user requests individual components separately.
|
||||
|
||||
Focus Keyphrase
|
||||
SEO Title
|
||||
Slug
|
||||
Meta Description
|
||||
Social Title
|
||||
Social Description
|
||||
### Batch 1 — Blog Post Only
|
||||
Full blog post from title to conclusion. No SEO metadata, schema, or image SEO.
|
||||
|
||||
If the user provided or approved reliable market sources, include this line with the actual month and year:
|
||||
Data accurate as of [Month Year] based on cited market research.
|
||||
### Batch 2 — SEO Metadata
|
||||
Yoast SEO elements only:
|
||||
- Focus keyphrase
|
||||
- SEO title
|
||||
- Slug
|
||||
- Meta description
|
||||
- Social title
|
||||
- Social description
|
||||
- Suggested internal links
|
||||
- Suggested external link types
|
||||
|
||||
If no reliable market sources were provided or reviewed, omit the line instead of implying research was performed.
|
||||
### Batch 3 — Image SEO
|
||||
Image SEO assets only:
|
||||
- Featured image concept
|
||||
- Supporting image concepts
|
||||
- Alt text, title, caption, description, and placement for each
|
||||
|
||||
SCHEMA MARKUP
|
||||
*Only provide this section if the user requested Yoast/SEO schema.*
|
||||
### Batch 4 — Schema Markup
|
||||
JSON-LD schema only:
|
||||
- `BlogPosting` schema
|
||||
- `FAQPage` schema
|
||||
|
||||
Add clean JSON-LD for:
|
||||
---
|
||||
|
||||
BlogPosting
|
||||
FAQPage
|
||||
## SEO Section (Yoast)
|
||||
|
||||
Use placeholder URLs if needed
|
||||
*Generate only if the user requested Yoast SEO elements.*
|
||||
|
||||
## Examples
|
||||
Provide:
|
||||
- Focus Keyphrase
|
||||
- SEO Title
|
||||
- Slug
|
||||
- Meta Description
|
||||
- Social Title
|
||||
- Social Description
|
||||
|
||||
### Example 1: Informational Blog Post
|
||||
**User:** Write a blog post about "Sustainable Gardening for Beginners".
|
||||
**Agent:** (Generates Title, Truth Box, clickable contents, well-structured sections with tables, Misconceptions, and FAQ.)
|
||||
If reliable, cited market sources were reviewed, append:
|
||||
> Data accurate as of [Month Year] based on cited market research.
|
||||
|
||||
If no reliable sources were reviewed, omit this line entirely.
|
||||
|
||||
---
|
||||
|
||||
## Schema Markup
|
||||
|
||||
*Generate only if the user requested schema markup.*
|
||||
|
||||
Provide clean JSON-LD for:
|
||||
- `BlogPosting`
|
||||
- `FAQPage`
|
||||
|
||||
Use placeholder URLs where actual URLs are unavailable.
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Use short, punchy sentences.
|
||||
- ✅ Ensure tables are clean and use `|` markdown syntax.
|
||||
- ✅ Maintain the Truth Box at the very beginning of the post for high engagement.
|
||||
- ❌ Avoid using numbered headings; stick to standard markdown `#`, `##`, `###`.
|
||||
- ❌ Do not use hyphen bullets in the contents section.
|
||||
- Write short, direct sentences.
|
||||
- Use `|` markdown syntax for clean, readable tables.
|
||||
- Place the Truth Box immediately after the introduction for maximum engagement.
|
||||
- Use `#`, `##`, and `###` for headings — never number them.
|
||||
- Avoid hyphen bullets in the contents section.
|
||||
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
- This skill does not replace environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, or safety boundaries are missing.
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- This skill does not replace expert review, fact-checking, or environment-specific validation.
|
||||
- Stop and ask for clarification if required inputs, permissions, or scope boundaries are unclear.
|
||||
- Use this skill only for tasks that match the scope described above.
|
||||
|
||||
## Security & Safety Notes
|
||||
---
|
||||
|
||||
- This skill focuses on content generation and does not involve shell commands or direct system mutation.
|
||||
- Ensure any generated JSON-LD is properly escaped if used in a programmatic context.
|
||||
## Security and Safety Notes
|
||||
|
||||
- This skill is limited to content generation. It does not execute shell commands or mutate system state.
|
||||
- Ensure any generated JSON-LD is properly escaped before use in a programmatic context.
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Problem:** Missing Primary Keyword in Alt Text.
|
||||
**Solution:** Ensure the `IMAGE SEO SECTION` explicitly includes the primary keyword in at least one Alt Text field.
|
||||
- **Problem:** AI-sounding or repetitive tone.
|
||||
**Solution:** Use the "Human-sounding" requirement in the `WRITING RULES` to re-check the draft.
|
||||
**Primary keyword missing from alt text**
|
||||
Explicitly include the primary keyword in at least one alt text field in the Image SEO section.
|
||||
|
||||
**AI-sounding or repetitive tone**
|
||||
Revisit the Writing Rules. Shorten sentences, vary structure, and remove filler phrases.
|
||||
|
||||
---
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `@seo-plan` - Use for high-level SEO strategy before writing.
|
||||
- `@seo-content` - For broader SEO content optimization across different platforms.
|
||||
- `@copywriting` - General professional writing and marketing copy.
|
||||
- `@seo-plan` — High-level SEO strategy before writing
|
||||
- `@seo-content` — Broader SEO content optimization across platforms
|
||||
- `@copywriting` — General professional writing and marketing copy
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: yield-intelligence
|
||||
description: Passive income portfolio analysis — activate when user asks about dividend yields, Treasury rates, REIT income, monthly passive income goals, or portfolio yield optimization. Scans 4 asset classes, ranks by risk-adjusted return, and builds allocations targeting a specific monthly income.
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-05-31"
|
||||
---
|
||||
|
||||
# Yield Intelligence
|
||||
|
||||
Passive income analysis across US Treasuries, dividend ETFs, REITs, and preferred stocks. Given a target monthly income and investment amount, returns a ranked opportunity table and optimal allocation.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- "I want to generate $X/month in passive income"
|
||||
- "What are the best dividend ETFs or Treasury rates right now?"
|
||||
- "Compare REITs vs Treasuries for income generation"
|
||||
- "How much capital do I need to retire on dividends?"
|
||||
- "Build me a conservative income portfolio"
|
||||
|
||||
## Limitations
|
||||
|
||||
- Provides portfolio research support, not personalized financial advice.
|
||||
- Requires live yield, price, tax, and risk data for current recommendations.
|
||||
- Does not account for every user-specific constraint unless the user provides it, including jurisdiction, tax status, and liquidity needs.
|
||||
|
||||
## Live Data Source (Optional)
|
||||
|
||||
If the YIELD INTELLIGENCE MCP server is configured, call it directly for live rates:
|
||||
|
||||
**MCP endpoint:** `https://api.intuitek.ai/yield/mcp` (no auth required, open access)
|
||||
|
||||
**Tools:**
|
||||
- `analyze_yield_opportunities` — Scans dividend ETFs, REITs, preferred stocks, and Treasuries; returns ranked opportunities with yield, risk score, and liquidity
|
||||
- `optimize_income_portfolio` — Builds a portfolio allocation targeting a specific monthly income goal
|
||||
|
||||
**Quick config (Claude Desktop / Claude Code):**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"yield-intelligence": {
|
||||
"url": "https://api.intuitek.ai/yield/mcp"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Standalone Workflow (No MCP Required)
|
||||
|
||||
### Step 1 — Gather Parameters
|
||||
|
||||
Ask if not provided:
|
||||
- **Target monthly income** (e.g., $500)
|
||||
- **Available capital** (e.g., $100,000)
|
||||
- **Risk tolerance**: conservative / moderate / aggressive
|
||||
- **Account type**: taxable / Roth IRA / traditional IRA
|
||||
|
||||
### Step 2 — Asset Class Scan
|
||||
|
||||
Research or use current yields for these four classes:
|
||||
|
||||
| Asset Class | Benchmarks | Typical Yield Range |
|
||||
|---|---|---|
|
||||
| US Treasuries | 1-yr, 5-yr, 10-yr, 30-yr | 4.0–5.5% |
|
||||
| Dividend ETFs | SCHD, VYM, JEPI, JEPQ | 3.5–10% |
|
||||
| REITs | O, MAIN, STAG | 4–12% |
|
||||
| Preferred Stocks | PFF, PFFD | 5–7% |
|
||||
|
||||
### Step 3 — Score and Rank
|
||||
|
||||
Score each opportunity: **yield × (1 − risk_penalty) × liquidity_factor**
|
||||
|
||||
| Category | Risk Penalty |
|
||||
|---|---|
|
||||
| US Treasuries | 0.00 |
|
||||
| Investment-grade dividend ETF | 0.05 |
|
||||
| REIT / preferred | 0.15 |
|
||||
| High-yield / speculative | 0.25 |
|
||||
|
||||
### Step 4 — Build Allocation
|
||||
|
||||
Given monthly target **T** and available capital **C**:
|
||||
1. Sort opportunities by risk-adjusted score (descending)
|
||||
2. Assign 30–40% to highest-conviction position
|
||||
3. Diversify remaining 60–70% across 3–5 positions
|
||||
4. Verify: `Σ(allocation_i × yield_i × C) ≥ T × 12`
|
||||
|
||||
Conservative portfolios: cap any single position at 25%.
|
||||
|
||||
### Step 5 — Present Results
|
||||
|
||||
```
|
||||
YIELD INTELLIGENCE REPORT
|
||||
─────────────────────────────────────────
|
||||
Target: $[X]/month Required yield: [Y]%
|
||||
Capital: $[Z] Account: [type]
|
||||
|
||||
OPPORTUNITY SCAN
|
||||
┌──────────────────┬───────┬──────┬──────────────┐
|
||||
│ Asset │ Yield │ Risk │ $/mo per 100K│
|
||||
├──────────────────┼───────┼──────┼──────────────┤
|
||||
│ [Top pick] │ X.X% │ Low │ $XXX │
|
||||
└──────────────────┴───────┴──────┴──────────────┘
|
||||
|
||||
RECOMMENDED ALLOCATION ($[Z] capital)
|
||||
[Asset A] 40% → $[amount] → $[X]/month
|
||||
Total monthly income: $[X]/month ✓
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Verify coverage ratios for high-yield REITs before recommending
|
||||
- ✅ Note duration risk for long-term Treasuries when rates are rising
|
||||
- ✅ Consider account type tax efficiency (Roth vs. taxable vs. traditional IRA)
|
||||
- ❌ Don't chase yield without checking dividend sustainability
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- Repository: [thebrierfox/yield-intelligence-skill](https://github.com/thebrierfox/yield-intelligence-skill)
|
||||
- MCP server: [thebrierfox/intuitek-ace](https://github.com/thebrierfox/intuitek-ace)
|
||||
- Built by [IntuiTek¹](https://intuitek.ai) (~K¹) — MIT License
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: youtube-full
|
||||
description: "Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server."
|
||||
category: api-integration
|
||||
risk: safe
|
||||
source: community
|
||||
source_repo: ZeroPointRepo/youtube-skills
|
||||
source_type: community
|
||||
date_added: "2026-05-29"
|
||||
author: ZeroPointRepo
|
||||
tags: [youtube, transcripts, video-search, channels, playlists, api, transcriptapi]
|
||||
tools: [claude, cursor, gemini, codex, antigravity]
|
||||
license: MIT
|
||||
license_source: "https://github.com/ZeroPointRepo/youtube-skills/blob/main/LICENSE"
|
||||
upstream: "https://github.com/ZeroPointRepo/youtube-skills"
|
||||
plugin:
|
||||
setup:
|
||||
type: automatic
|
||||
summary: "TranscriptAPI OAuth provisions the API key on first skill invocation. No manual credential setup. 100 free credits included."
|
||||
docs: "https://transcriptapi.com/docs"
|
||||
---
|
||||
|
||||
# youtube-full — YouTube transcript, search, channels & playlists via TranscriptAPI
|
||||
|
||||
YouTube transcripts, video search, channel browsing, in-channel search, playlist extraction, and new-upload monitoring — all via [TranscriptAPI](https://transcriptapi.com). Processes 500K+ transcripts daily, fast. No yt-dlp, no headless browsers, no Google API key.
|
||||
|
||||
This is the API-backed alternative to `ingest-youtube`. Where `ingest-youtube` uses yt-dlp (which stops working on cloud server IPs), `youtube-full` calls TranscriptAPI's API and works from any runtime — local machine, cloud server, serverless function, or CI environment. 686 installs via the `skills` CLI (skills.sh/zeropointrepo/youtube-skills).
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- User asks to get, fetch, or retrieve a YouTube video transcript
|
||||
- User asks to search YouTube for videos on a topic
|
||||
- User wants to monitor a channel for new uploads
|
||||
- User needs channel metadata, video lists, or playlist contents
|
||||
- Agent is deployed on a cloud server where yt-dlp calls fail (YouTube blocks cloud IPs)
|
||||
- Building a research corpus from YouTube conference talks, tutorials, or interviews
|
||||
- Competitive intelligence: monitoring competitor channels for new content
|
||||
|
||||
Do NOT use for:
|
||||
- Downloading actual video or audio files (use yt-dlp directly with `-f best`)
|
||||
- YouTube comments, likes, or engagement data (not in API)
|
||||
- Private or age-restricted videos (not accessible without user authentication)
|
||||
- Live stream transcripts (not stable until stream ends)
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Install the skill
|
||||
|
||||
```bash
|
||||
npx skills add ZeroPointRepo/youtube-skills --skill youtube-full
|
||||
```
|
||||
|
||||
100 free credits included. API key is provisioned automatically via TranscriptAPI OAuth on first invocation — no manual setup.
|
||||
|
||||
### Step 2: Use it by asking Claude
|
||||
|
||||
```text
|
||||
Get the transcript of https://www.youtube.com/watch?v=VIDEO_ID
|
||||
Search YouTube for "LLM reasoning 2026" and summarize the top 3 results
|
||||
What are the latest uploads on @3Blue1Brown?
|
||||
List all videos in this playlist: https://www.youtube.com/playlist?list=PLAYLIST_ID
|
||||
```
|
||||
|
||||
### Step 3: Available operations
|
||||
|
||||
| Operation | Skill invocation | Credits |
|
||||
|---|---|---|
|
||||
| Get transcript | `get_transcript(video_id)` | 1 |
|
||||
| Search YouTube | `search_youtube(query)` | 1 per page |
|
||||
| Channel video list | `get_channel_videos(handle)` | 1 per page |
|
||||
| In-channel search | `search_in_channel(handle, query)` | 1 per page |
|
||||
| Playlist extraction | `get_playlist_videos(playlist_id)` | 1 per page |
|
||||
| Track new uploads | `channel_latest(handle)` | **Free** |
|
||||
| Resolve channel handle | `channel_resolve(handle)` | **Free** |
|
||||
|
||||
Failed or rate-limited calls cost zero credits.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Research corpus from conference talks
|
||||
|
||||
```text
|
||||
Search YouTube for "NeurIPS 2025 keynote" and get transcripts for the top 5 results.
|
||||
Summarize the main themes across all talks.
|
||||
```
|
||||
|
||||
The agent calls `search_youtube`, selects the top 5 results, calls `get_transcript` for each, and synthesizes.
|
||||
|
||||
### Example 2: Competitive channel monitoring
|
||||
|
||||
```text
|
||||
Check @AnthropicAI and @OpenAI channels for any new videos in the last week.
|
||||
For each new video, get the transcript and extract any product announcements.
|
||||
```
|
||||
|
||||
The agent calls `channel_latest` (free) for each channel, fetches transcripts of new uploads, and extracts signal.
|
||||
|
||||
### Example 3: Direct transcript with timestamps
|
||||
|
||||
```text
|
||||
Get the full transcript with timestamps for https://www.youtube.com/watch?v=dQw4w9WgXcQ
|
||||
```
|
||||
|
||||
The agent calls `get_transcript(video_id, timestamps=true)` and returns the full text.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Use `channel_latest` (free) before `get_transcript` to check if a video is new
|
||||
- Cache transcripts in your workflow — each `get_transcript` call costs 1 credit
|
||||
- Use `search_in_channel` when you already know the channel to avoid broad search noise
|
||||
- Prefer `get_playlist_videos` for course or lecture series — cheaper than searching by query
|
||||
- Don't batch-transcribe entire channels unless the user explicitly requested it
|
||||
- Don't use `search_youtube` when you already have the video URL — jump straight to `get_transcript`
|
||||
|
||||
## Limitations
|
||||
|
||||
- This skill does not replace environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, or safety boundaries are missing.
|
||||
- Transcripts are available only when YouTube has captions (manual or auto-generated). Some videos have no captions.
|
||||
- API key is required for paid usage beyond the free 100-credit tier. Get one at transcriptapi.com.
|
||||
- Rate limits apply: 200 RPM on Monthly plan, 300 RPM on Annual. Contact support for higher limits.
|
||||
|
||||
## Security & Safety Notes
|
||||
|
||||
- This skill makes HTTPS API calls to `transcriptapi.com`. No local data is written.
|
||||
- The API key is stored in the agent's credential store, not in this SKILL.md.
|
||||
- No shell commands, no binary execution, no local system mutation. Risk level: `safe`.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Problem:** `yt-dlp` fails when the agent runs on a cloud server.
|
||||
**Solution:** This is exactly the use case for `youtube-full`. The API routes through TranscriptAPI's infrastructure and works from any cloud runtime.
|
||||
|
||||
- **Problem:** Credit balance runs out mid-workflow.
|
||||
**Solution:** Use `channel_latest` (free) to check before fetching; use targeted search to fetch only the videos you need.
|
||||
|
||||
- **Problem:** Transcript is not available for a video.
|
||||
**Solution:** The API returns a structured error (zero credits charged). Ask the user to provide an alternative source.
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `@ingest-youtube` — yt-dlp-based local ingestion to a markdown vault; works locally but not on cloud servers
|
||||
- `@deep-research` — General-purpose research skill that can incorporate youtube-full as a data source
|
||||
- `@ai-research-corpus` — Building searchable knowledge bases; pairs well with youtube-full for video content
|
||||
Reference in New Issue
Block a user