keploy-blog-generator-skill 1.0.0

package/README.md

@@ -0,0 +1,30 @@
+# keploy-blog-generator-skill
+
+NPM package for the `keploy-blog-generator` skill content.
+
+## Contents
+
+- `SKILL.md`
+- `references/seo-guidelines.md`
+
+## Install
+
+```bash
+npm install keploy-blog-generator-skill
+```
+
+## Usage
+
+```js
+const skill = require("keploy-blog-generator-skill");
+
+console.log(skill.name);
+console.log(skill.skillFile);
+console.log(skill.referencesDir);
+```
+
+## Publish
+
+```bash
+npm publish --access public
+```

package/SKILL.md

@@ -0,0 +1,285 @@
+---
+name: keploy-blog-generator
+description: Generates SEO-optimized blog posts for Keploy following strict internal SEO guidelines. Use this skill whenever someone asks to write, generate, create, or draft a blog post for Keploy — whether they mention a keyword, topic, or just say "write a blog". Also triggers for requests like "generate blog content", "write a technical post", "create a community blog", or any task that involves producing long-form content for Keploy's website. Always use this skill for Keploy blog creation — do not write blogs freehand.
+---
+
+# Keploy Blog Generator
+
+Generates complete, SEO-optimized blog posts for Keploy strictly following the internal SEO guidelines.
+
+**Always read** `references/seo-guidelines.md` before generating any content — it is the source of truth and every single rule in it must be followed without exception.
+
+---
+
+## Step 1: Gather Inputs
+
+Before writing anything, collect the following from the user if not already provided:
+
+**Required:**
+- Primary keyword
+- Blog type: **Community** or **Technical** (ask if not specified)
+
+**Optional (but use if provided):**
+- Secondary keywords (list)
+- Tertiary keywords (list)
+- Any specific angle, talking points, or competitor URLs to reference
+
+---
+
+## Step 2: Ask Blog Type
+
+If the user hasn't specified, ask:
+
+> "Is this a **Community blog** or a **Technical blog**?"
+>
+> - **Community blogs** are accessible, story-driven, and written for a broader developer audience — less deep on implementation, more on concepts, impact, and real-world context.
+> - **Technical blogs** are in-depth, implementation-focused, and written for engineers who want to understand the how and why at a code/architecture level.
+
+---
+
+## Step 3: Suggest a Persona (or Persona Blend)
+
+Based on the blog type and keyword, recommend the most fitting persona from the list below. Show the user:
+- The **recommended persona** (mark it clearly as ⭐ Recommended)
+- 2–3 **alternative personas**
+- A **1-line description** of each
+
+Then tell the user:
+> "You can also **mix 2–3 personas** for a more nuanced voice. For example: *Senior Backend Engineer + Open Source Developer* gives you technical depth with a community-friendly, peer-to-peer tone. Just tell me which ones to blend!"
+
+**Blending rules (max 3 personas):**
+- Assign a **primary persona** (dominant voice, ~60%) and one or two **secondary personas** (flavour, ~40% split)
+- Clearly state the blend before writing, e.g.: `Voice: Senior Backend Engineer (primary) + Open Source Developer (secondary)`
+- The primary persona sets the overall tone, vocabulary level, and sentence structure
+- Secondary personas contribute specific traits — see the blend trait table below
+- Cross-track blending (Technical + Community persona) is allowed and often produces the most natural-sounding blogs
+
+Let the user confirm the single persona or blend before proceeding.
+
+---
+
+## Persona Library
+
+### Technical Blog Personas
+
+**1. Senior Backend Engineer** *(recommended for API testing, mocking, integration testing topics)*
+> 5+ years building distributed systems. Writes with authority, goes deep on architecture decisions, references trade-offs, and isn't afraid to call out bad patterns. Tone: direct, confident, no fluff.
+
+**2. Staff Engineer / Tech Lead** *(recommended for platform engineering, testing strategy, DevOps topics)*
+> Thinks at system scale. Focuses on team impact, long-term maintainability, and engineering culture. References real org-level decisions. Tone: thoughtful, experienced, slightly opinionated.
+
+**3. Open Source Developer** *(recommended for OSS tooling, developer experience, CLI, SDK topics)*
+> Lives in the terminal and GitHub. Passionate about developer ergonomics, clean APIs, and community-driven tools. References open source projects by name. Tone: enthusiastic, peer-to-peer, pragmatic.
+
+**4. Professional QA / SDET Engineer** *(recommended for test automation, test coverage, flaky tests topics)*
+> Deeply specialized in quality engineering. Knows the pain of brittle test suites, flaky CI, and untested edge cases. Writes from the trenches of real QA workflows. Tone: precise, practical, detail-oriented.
+
+**5. DevOps / Platform Engineer** *(recommended for CI/CD, containerization, deployment pipeline topics)*
+> Owns the pipeline. Writes about reliability, speed, and eliminating developer friction. References tools like GitHub Actions, Jenkins, Docker, k8s naturally. Tone: pragmatic, systems-thinker, efficiency-focused.
+
+**6. Security-Conscious Developer** *(recommended for API security, data privacy, compliance testing topics)*
+> Thinks about every endpoint as a potential attack surface. References CVEs, OWASP, and real breach case studies. Tone: cautious, thorough, evidence-driven.
+
+---
+
+### Community Blog Personas
+
+**7. Developer Advocate** *(recommended for concept explainers, "what is X", intro-to-testing topics)*
+> Bridges the gap between engineering and the community. Makes hard concepts feel approachable without dumbing them down. References talks, blog posts, and real developer conversations. Tone: warm, energetic, storytelling-forward.
+
+**8. Junior Developer (Learning in Public)** *(recommended for beginner guides, "I tried X and here's what happened" topics)*
+> Recently shipped their first production feature. Writes from genuine curiosity and the experience of figuring things out. Relatable, honest about mistakes, celebrates small wins. Tone: conversational, humble, encouraging.
+
+**9. Startup CTO / Founding Engineer** *(recommended for build vs buy, testing culture, scaling engineering topics)*
+> Wore every hat at a 5-person startup. Now has opinions on everything — especially what slows teams down. References real startup war stories. Tone: opinionated, fast-paced, pragmatic.
+
+**10. Developer Community Lead** *(recommended for ecosystem, open source contribution, community building topics)*
+> Runs meetups, mentors contributors, and lives for developer collaboration. Focuses on the human side of engineering. Tone: inclusive, community-first, motivating.
+
+---
+
+## Step 4: Generate the Blog
+
+After confirming persona and blog type, read `references/seo-guidelines.md` fully, then generate the complete blog output.
+
+### Output Format
+
+Produce all sections in this exact order:
+
+---
+
+### OUTPUT TEMPLATE
+
+```
+## Meta
+**Meta Title:** [≤60 chars, primary keyword near start, unique, search-intent-aware, not a copy of competitors]
+**Meta Description:** [150–160 chars, includes primary keyword, clickbait, unique]
+**URL Slug:** [/primary-keyword-slug — <60 chars, exact primary keyword, hyphens only where needed]
+
+---
+
+## H1
+[Different from Meta Title. Clickbait. Primary keyword near start. Max 60 chars.]
+
+---
+
+## Blog Content
+
+[Full blog body — see content rules below]
+
+---
+
+## Instagram Carousel Outline
+
+**Slide 1 (Cover):** [Topic/keyword as title, bold, minimal]
+**Slide 2 (Intro/Definition):** [3–5 bullets: what/why]
+**Slide 3 (Key Insight 1):** [3–5 bullets]
+**Slide 4 (Key Insight 2):** [3–5 bullets]
+**Slide 5 (Benefits/Examples):** [3–5 bullets]
+**Slide 6 (Outro/CTA):** ["Follow @Keploy for more!" + one closing line]
+```
+
+---
+
+## Content Generation Rules (apply every time, no exceptions)
+
+Pull these from `references/seo-guidelines.md` — summarized here as a quick checklist to verify before outputting:
+
+### Structure
+- [ ] Intro: max 2 paras, 5–6 lines each
+- [ ] Hook in first sentence
+- [ ] Primary keyword in first paragraph / first 10% of intro
+- [ ] No "this blog is about..." or TOC repetition in intro
+- [ ] Comparison table included (if topic is comparative)
+- [ ] Listicles included where relevant
+- [ ] All paragraphs max 4 lines
+- [ ] Min 1500 words (aim 1500–2500)
+- [ ] One H1 only, different from meta title
+
+### Keyword Usage
+- [ ] Primary keyword: match search intent, in first 10% of content
+- [ ] Secondary keywords: in headings/subheadings, not forced
+- [ ] Tertiary keywords: 0.5–0.75% density
+- [ ] LSI keywords: used throughout
+- [ ] Keyword variations: 0.5–1% of word count
+
+### Writing Quality
+- [ ] First person, story narration style
+- [ ] Active voice dominant
+- [ ] Transition words sufficient
+- [ ] No consecutive same-structure sentences
+- [ ] Real company names/examples referenced
+- [ ] No babysitting, no analogies, no filler
+- [ ] Inclusive, respectful language throughout
+- [ ] Q&A format used where appropriate (AIO optimization)
+- [ ] Writing style modeled after BrowserStack / TestSigma / Katalon
+
+### Links (note in output where links should go)
+- [ ] Internal links: max 5 per 1000 words, targeted anchor text
+- [ ] External links: reputable sources, generic anchor text, target="_blank"
+
+### SEO Metadata
+- [ ] Meta title: ≤60 chars, primary keyword near start, unique
+- [ ] Meta description: 150–160 chars, clickbait, unique
+- [ ] URL slug: <60 chars, exact primary keyword, minimal hyphens
+
+### Instagram Carousel
+- [ ] 4–7 slides outlined
+- [ ] Dark mode, 1080×1350 px noted
+- [ ] 3–5 bullets per slide
+- [ ] Educational + engaging tone
+- [ ] CTA on final slide: "Follow @Keploy for more!"
+
+---
+
+## Persona Voice Application
+
+### Single Persona Reference Table
+
+| Persona | Vocabulary level | Sentence style | What to emphasize |
+|---|---|---|---|
+| Senior Backend Engineer | Technical, precise | Declarative, no hedging | Architecture, trade-offs, real code patterns |
+| Staff Engineer | Strategic, measured | Longer, nuanced | Team impact, scalability, org context |
+| Open Source Developer | Casual-technical | Energetic, peer-to-peer | DX, tooling, community proof points |
+| Professional QA/SDET | Specialist, methodical | Step-by-step, evidence-based | Test coverage, CI pain, reliability metrics |
+| DevOps/Platform Engineer | Systems-thinker | Efficient, tool-named | Pipeline speed, integration, automation |
+| Security-Conscious Dev | Cautious, thorough | Evidence-first | Risks, CVEs, compliance, real incidents |
+| Developer Advocate | Warm, energetic | Storytelling, inclusive | Concepts, community, approachability |
+| Junior Dev (Learning) | Conversational, honest | Short, curious | Discovery, mistakes, relatable journey |
+| Startup CTO | Opinionated, fast | Direct, war-story style | Build vs buy, speed, scaling decisions |
+| Community Lead | Inclusive, motivating | Human, collaborative | Culture, contribution, belonging |
+
+---
+
+### Persona Blending — How It Works
+
+When the user selects a blend, apply it like this:
+
+**Structure:**
+- **Primary persona (~60%)**: sets overall tone, vocabulary, sentence rhythm, POV
+- **Secondary persona(s) (~40% split)**: inject specific traits at natural moments — transitions, examples, callouts, closing sections
+
+**What each persona contributes as a secondary:**
+
+| Used as secondary | What it adds to the blend |
+|---|---|
+| Senior Backend Engineer | Sharpens technical claims, adds architecture depth to key sections |
+| Staff Engineer | Adds strategic framing, "at scale" perspective to transitions |
+| Open Source Developer | Loosens tone, adds GitHub/community references, peer-to-peer warmth |
+| Professional QA/SDET | Adds precision to any testing-related sections, surfaces edge cases |
+| DevOps/Platform Engineer | Injects CI/CD tool names, pipeline context where relevant |
+| Security-Conscious Dev | Adds risk callouts, "watch out for X" moments |
+| Developer Advocate | Softens technical sections, adds "here's why this matters" bridges |
+| Junior Dev (Learning) | Adds relatable "I used to struggle with this" moments, humanizes the narrative |
+| Startup CTO | Injects opinionated takes, war-story anecdotes, build-vs-buy framing |
+| Community Lead | Adds inclusive language, community shoutouts, collaborative framing |
+
+**Example blends and their resulting voice:**
+
+| Blend | Resulting voice |
+|---|---|
+| Senior Backend Engineer + Open Source Dev | Deep technical + peer-to-peer warmth. Feels like a senior dev writing for their own blog. |
+| Developer Advocate + QA/SDET | Accessible explanations with real testing precision. Great for "intro to test automation". |
+| Startup CTO + Staff Engineer | Strategic + opinionated. Great for "testing culture" or "why we rebuilt our pipeline" topics. |
+| Open Source Dev + Junior Dev | Highly relatable, energetic, learning-in-public style. Great for community blogs. |
+| QA/SDET + DevOps Engineer | Deep quality + pipeline context. Perfect for CI/CD testing, test reliability topics. |
+| Senior Backend Engineer + Security Dev | Authoritative + risk-aware. Strong for API security, compliance testing topics. |
+
+**Consistency rule:** When blending, do NOT randomly switch voices mid-paragraph. The primary voice runs throughout. Secondary traits appear at specific moments — examples, section intros, callouts, or the conclusion. The reader should feel one coherent author, not two.
+
+---
+
+## Blog Type Differences
+
+### Technical Blog
+- Goes deep on implementation — code snippets, architecture diagrams described, API references
+- Assumes reader knows the basics — no hand-holding
+- References GitHub repos, official docs, specific library versions
+- More H3 subheadings for granular breakdown
+- Comparison tables almost always relevant
+
+### Community Blog
+- Concept-first — explains the why before the how
+- More narrative arc — problem → journey → resolution
+- References real developer experiences, tweets, community discussions
+- Lighter on code — pseudocode or high-level flows preferred
+- Tone is warmer, more inclusive
+- Comparison tables optional, listicles preferred
+
+---
+
+## Quality Self-Check Before Outputting
+
+Before presenting the final output, verify:
+1. Did I read `references/seo-guidelines.md` fully?
+2. Is the primary keyword in the first 10% of the intro?
+3. Are all paragraphs ≤ 4 lines?
+4. Is the meta title ≤ 60 chars and different from H1?
+5. Is the URL slug < 60 chars with exact primary keyword?
+6. Is the meta description 150–160 chars?
+7. Is the blog min 1500 words?
+8. Are LSI keywords used throughout?
+9. Is the persona voice consistent end-to-end? If a blend, does the primary persona dominate and secondary traits appear only at natural moments?
+10. Is the Instagram carousel outline complete with 4–7 slides and CTA?
+
+If any check fails — fix before outputting.

package/index.js

@@ -0,0 +1,7 @@
+const path = require("path");
+
+module.exports = {
+  name: "keploy-blog-generator",
+  skillFile: path.join(__dirname, "SKILL.md"),
+  referencesDir: path.join(__dirname, "references")
+};

package/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "keploy-blog-generator-skill",
+  "version": "1.0.0",
+  "description": "Keploy blog generator skill packaged for npm distribution.",
+  "author": "Dhananjay",
+  "license": "MIT",
+  "type": "commonjs",
+  "main": "index.js",
+  "files": [
+    "SKILL.md",
+    "references",
+    "index.js",
+    "README.md"
+  ],
+  "keywords": [
+    "keploy",
+    "copilot-skill",
+    "skill",
+    "blog-generator",
+    "seo"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "pack:check": "npm pack --dry-run"
+  }
+}

package/references/seo-guidelines.md

@@ -0,0 +1,158 @@
+# Keploy SEO Content Guidelines — Full Reference
+
+> ⚠️ EVERY rule here is NON-NEGOTIABLE. No addition, no subtraction, no skipping.
+
+---
+
+## AIO Optimization
+- Write content in **question-answer format** wherever possible so it gets pulled into AI summaries.
+
+---
+
+## URL Structure
+- Length: **< 60 characters**
+- Keep URLs short and readable
+- Include the **exact primary keyword**
+- No 2 URLs should be the same — check for duplicacy within topic clusters
+- Separate words with **hyphens (-)** in small casing
+- Use hyphens **only where really needed** — overuse looks AI-generated
+
+---
+
+## Page Titles
+- Length: **< 60 characters**
+- Only **one H1** and **one Title** per page — they must be **different from each other**
+- Include **primary keyword towards the beginning**
+- Every page must have a **unique title and H1**
+- Title must be **clickbait** — must encourage the user to click
+
+---
+
+## Blog Content Structure
+
+### Introduction
+- **Max 2 paragraphs**, 5–6 lines each
+- No huge build-up — highlight the problem in 3–4 lines, then go straight to the solution
+- Start with a **hook**
+- **Primary keyword must appear in the 1st paragraph / first 10% of the intro**
+- Do NOT say "this blog is about..." or repeat the table of contents
+
+### Body
+- Add **comparison tables** and **listicles** wherever relevant to the topic
+- Vocabulary: **simple and easy**, suitable for a **25-year-old developer**
+- Write in **first person, story narration style**
+- No analogies, no distracting content
+- Reference **real company names/blogs** for examples, success and failure cases
+- No babysitting content
+- **Paragraph length: max 4 lines** — keep them short for readability
+- Add **bullet points and listicles** to make content LLM-friendly
+- Use **active voice** predominantly — minimize passive voice
+- Use sufficient **transition words** (target Yoast's recommended %)
+- Avoid consecutive sentences with the same structure
+- Use **inclusive and respectful language** — avoid offensive, biased, or judgmental words
+
+### Length
+- **Minimum 1500–2500 words** (check competitor length for the given keyword)
+
+### Quality & Credibility
+Content must be: Accurate, Authoritative, Up-to-date, Complementary, Credible, Transparent, Contextual.
+
+### Readability Reference
+- Model writing style after: **BrowserStack**, **TestSigma**, **Katalon**
+- Reference: https://www.browserstack.com/guide/regression-testing
+
+---
+
+## Headings (H1, H2, H3)
+- **One H1/Title per page only**, followed by H2 and H3
+- Include **relevant keywords in H1/Title and H2 tags**
+- Use secondary keywords in headings wherever possible — **do not force them**
+
+---
+
+## Keywords
+
+### Primary Keyword
+- No fixed density — **match search intent** over density
+- Must appear in the **first 10% of the intro**
+
+### Secondary Keywords
+- Use in headings and subheadings wherever possible
+- **Do not forcefully insert** anywhere
+
+### Tertiary Keywords
+- Target density: **0.5–0.75%**
+
+### LSI Keywords
+- **Not optional** — use relevant LSI keywords wherever possible
+
+### Keyword Variations
+- Aim for variations to be **0.5–1% of total word count**
+- Maintain good readability with keyword variations
+
+---
+
+## Internal Linking
+- Interlink **core/brand keywords** + topic-relevant ones
+- Linked pages must be **relevant to each other**
+- Use **targeted anchor text**
+- Max **5 internal links per 1000 words**
+
+---
+
+## External Links
+- Link to **reputable and relevant external sites** (stats, research, relevant tweets, collaborations)
+- Use `target="_blank"`
+- Anchor text must be **generic** — never use a keyword you want to rank for
+
+---
+
+## Image Optimization
+- **No GIFs**
+- Use images only when necessary
+- Format: **PNG for blogs**
+- File size: **< 100 KB**
+- Compress without losing quality
+- Filename must be a **keyword**
+- **Alt text**: include keywords/synonyms, must be accurate
+- **Title tags**: descriptive
+- Images must be **unique** — if from internet, edit in Canva first
+
+---
+
+## Meta Description
+- Length: **150–160 characters**
+- Include **targeted keywords**
+- Clear description of page content
+- **Unique** per page
+- Must be **clickbait** — encourage clicks
+
+---
+
+## Meta Title
+- Use **primary keyword** towards the beginning
+- Character limit: **≤ 60 characters**
+- Keep **search intent** in mind
+- Not a copy of competitors' meta titles
+- **Unique** per page
+
+---
+
+## Instagram Carousel (Required for every blog)
+
+### Design Specs
+- Dimensions: **1080 × 1350 px**
+- **4–7 slides** (more if needed)
+- **Dark mode** theme (reference: @keploy.io on Instagram)
+- Fonts: Helvetica, Poppins, Roboto, or Open Sans
+
+### Slide Structure
+1. **Cover**: Blog keyword/topic as title, bold modern typography, minimal clutter
+2. **Intro/Definition**: What is it / why it matters
+3. **Key Insights**: 2–3 slides
+4. **Benefits/Examples**
+5. **Outro/CTA**: "Follow @Keploy for more!"
+
+### Content Rules
+- **3–5 bullets per slide**, short and crisp
+- Tone: **educational + engaging**, not robotic or AI-sounding