# Blog Validator Enhancer Example > Validates and enhances blog posts about cybersecurity and AI. Use this skill whenever the user shares a draft blog post, article, or write-up and wants it reviewed, improved, or polished — even if they just say "check this", "review my post", "make this better", or "does this look good". Also trigger when the user pastes any long-form technical content about security topics (CVEs, exploits, threat modeling, AI/ML techniques, tools) and asks for feedback. Handles all input formats: markdown, plain text, or pasted content. Always use this skill before giving feedback on any technical blog content the user shares. - Skill: `gurpriya/blog-validator-enhancer-example` (Agent Skill) - Install (CLI): `npx skillmds@latest add gurpriya/blog-validator-enhancer-example` - Raw SKILL.md: https://api.skillmd.com/api/skills/gurpriya/blog-validator-enhancer-example/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: gurpriya (https://skillmd.com/u/gurpriya) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gurpriya/blog-validator-enhancer-example --- # Blog Post Validator & Enhancer A skill for reviewing and improving technical blog posts on cybersecurity and AI topics. ## Core Philosophy This blog has a clear voice and non-negotiable standards: - **No AI slop** — no filler phrases, no hollow enthusiasm, no padding - **No fluff** — every sentence earns its place or gets cut - **Story-driven** — the reader should always know where they are and where they're going - **Respects attention** — short enough to finish, dense enough to matter - **Ends with a lesson** — the reader walks away knowing something concrete they didn't before Run every post through all steps below. Be ruthless but constructive. --- ## Step 1: Detect Context Before anything else, assess: - **Topic domain**: Cybersecurity (offensive, defensive, malware, CVE, cloud, appsec, etc.) or AI (ML techniques, LLMs, agents, safety, ethics, etc.) or both - **Target audience**: Infer from vocabulary, assumed knowledge, and tone (beginner / intermediate / expert) - **Format**: Markdown, plain text, or structured doc - **Word count**: Approximate word count — flag if over 1200 (see Step 5) State these briefly at the top of your review. --- ## Step 2: AI Slop & Fluff Detector 🚨 Highest-priority check. Flag every instance — quote the offending text directly. **Hollow openers** (delete on sight): - "In today's rapidly evolving landscape..." - "In the world of cybersecurity / AI..." - "It's no secret that..." - "Now more than ever..." - Any sentence that could open literally any blog post **Filler phrases** (cut or rewrite): - "It's worth noting that..." → just say the thing - "As we can see..." → just show it - "This is a complex topic..." → prove it, don't announce it - "In conclusion, we have learned..." → show the conclusion, skip the meta - "I hope this post helped you understand..." → weak ending, replace **AI tell-tale patterns**: - Bullet lists where prose would read better - "Additionally," "Furthermore," "Moreover," stacked repeatedly - Repeating the same idea in slightly different words within the same section - Overly balanced hedging on topics that aren't actually controversial - Vague superlatives: "very important", "extremely powerful", "highly effective" — replace with specifics **Wordiness**: Flag sentences cuttable by 30%+ without losing meaning. Suggest the trimmed version. For each slop instance: quote it, label the type, suggest the fix or say "cut entirely." --- ## Step 3: Story Structure Check 📖 A good technical blog is a story: setup → conflict → resolution → lesson. The reader should never feel lost. Evaluate each of these: - **Hook (first 2–3 sentences)**: Does it create curiosity or tension? Does it make the reader need to keep going? Rate: Strong / Weak / Missing - **The problem**: Is there a clear "why does this matter?" moment early in the post? - **Narrative thread**: Can you summarize the post as a one-sentence story? (e.g. "A developer ignored input validation, got owned, and here's exactly how.") If not, the story is broken — say so. - **Section transitions**: Do sections flow into each other, or does it feel like a listicle stitched together? - **Pacing**: Does the post build toward something, or does it dump information flatly? - **Reader orientation**: At any point mid-post, can the reader answer "what are we doing and why?" Flag the exact spot where they'd get lost. Suggest specific fixes for any broken story elements. --- ## Step 4: Technical Accuracy Review Check for and flag: - **Factual errors**: Wrong definitions, incorrect protocol behavior, misattributed CVEs, wrong dates - **Outdated information**: Deprecated tools, patched vulnerabilities, superseded techniques, old AI models/benchmarks - **Misleading simplifications**: Technically true but dangerously incomplete for the stated audience - **Absolute claims**: "X is always safe / never works" — flag if there are important exceptions - **Code or command errors**: Syntax bugs, insecure defaults, commands that won't work as written For each issue: quote the original, explain what's wrong, provide the corrected version. --- ## Step 5: Length & Scope Audit ✂️ **Target length: 600–1000 words.** Flag anything outside this range. - **Under 400 words**: Too thin — flag what's missing - **400–600 words**: Fine if the topic is focused; flag if it feels rushed - **600–1000 words**: Sweet spot — check for any remaining fluff to trim - **1000–1200 words**: Borderline — identify specific cuts to bring it down - **Over 1200 words**: Must be split. See below. ### Blog Series Suggestion If the post exceeds ~1200 words OR covers more than one major concept, suggest a series split: ``` 📚 Suggested Series Split: Part 1: [Title] — covers [X, Y] Part 2: [Title] — covers [A, B] Part 3: [Title] — covers [C] (optional) This post would work best as: Part [N] ``` Be specific about which content belongs where. --- ## Step 6: Diagram Opportunities 🖼️ Identify every place where a diagram would replace 50+ words of explanation or make a complex relationship instantly clear. For each opportunity: ``` 📍 After: "[quote a few words from the relevant paragraph]" 🗂 Type: Attack chain / architecture / flowchart / timeline / comparison table / network diagram 📝 Show: [One sentence: exactly what the diagram depicts] 💡 Why: [What does the reader gain that prose doesn't give them?] ``` Only flag spots where visuals genuinely compress complexity. Don't suggest diagrams for decoration. --- ## Step 7: Completeness Check Based on topic and audience, flag important gaps: **For cybersecurity posts:** - Missing attack vectors or threat scenarios the reader should know about - No mention of detection/defense where relevant - Missing responsible disclosure context (if discussing vulnerabilities) - No real-world examples or case studies **For AI/ML posts:** - Missing limitations or failure modes of the technique discussed - No mention of security implications (adversarial attacks, data poisoning, model theft) - Missing ethical considerations where relevant - No benchmarks or references to support performance claims --- ## Step 8: Audience Calibration Flag mismatches between writing level and inferred audience: - **Too advanced**: Jargon without explanation, assumed knowledge the reader won't have - **Too basic**: Over-explaining fundamentals to experts, condescending tone - **Tone inconsistency**: Switches between casual and formal without reason --- ## Step 9: The Ending 🎓 The ending is the most important part. The reader should finish having learned something concrete — not just been informed that a topic exists. A strong ending must: 1. **Land a specific lesson** — not "security is important" but "never trust client-side validation, ever, full stop" 2. **Be memorable** — punchy, specific, maybe counterintuitive 3. **Not summarize** — the reader just read it; don't recap what they just finished Rate the current ending: - ✅ **Strong** — lands a clear, memorable lesson - ⚠️ **Weak** — present but vague or generic - ❌ **Missing** — fades out, no real conclusion If weak or missing, write a specific alternative ending (2–4 sentences max) with a sharp, concrete takeaway. --- ## Step 10: Enhancement Suggestions Additive improvements only (don't repeat things already flagged above): - **Code examples**: Draft a short one if the post would benefit and has none - **Callout boxes**: Suggest ⚠️ Warning, 💡 Tip, or 🔍 Deep Dive for key points - **References**: Suggest 2–3 specific links (CVE DB, OWASP, research papers, official docs) - **Title**: If weak, suggest 2–3 stronger alternatives — specific, curiosity-driving, not clickbait --- ## Step 11: Scorecard End every review with this scorecard: ``` ## Scorecard | Area | Rating | Notes | |-----------------------|---------------|--------------------------------| | No Slop / No Fluff | ✅ / ⚠️ / ❌ | Brief note | | Story Structure | ✅ / ⚠️ / ❌ | Brief note | | Technical Accuracy | ✅ / ⚠️ / ❌ | Brief note | | Length & Scope | ✅ / ⚠️ / ❌ | Brief note | | Diagram Opportunities | ✅ / ⚠️ / ❌ | Brief note | | Strong Ending | ✅ / ⚠️ / ❌ | Brief note | | Audience Fit | ✅ / ⚠️ / ❌ | Brief note | Overall Readiness: 🟢 Ready / 🟡 Needs Minor Work / 🔴 Needs Major Revision ``` Follow with **Top 3 Priorities** — the three highest-impact changes before publishing. Be specific, not generic. --- ## Tone Guidelines - Be direct. Vague feedback ("this could be clearer") is useless. - Praise what's working before diving into issues. - Never rewrite the entire post unprompted — suggest changes, offer to rewrite specific sections. - If the post is genuinely strong, say so and don't manufacture issues. --- ## Handling Edge Cases - **Very short drafts / outlines**: Validate direction and structure, note what's missing for a full post - **Non-cybersecurity/AI content**: Still validate for slop, story, and length — flag domain limitations - **"Just make it better"**: Run the full pipeline, lead with Top 3 Priorities - **Specific section review**: Focus there, flag any glaring issues elsewhere