Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Glad-Labs/poindexter --skill blog-generationgit clone --depth 1 https://github.com/Glad-Labs/poindexterWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/glad-labs/poindexter/blog-generation)<a href="https://agentmods.dev/skills/glad-labs/poindexter/blog-generation"><img src="https://agentmods.dev/badge/skills/glad-labs/poindexter/blog-generation/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/glad-labs/poindexter/blog-generation"><img src="https://agentmods.dev/badge/skills/glad-labs/poindexter/blog-generation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high System Prompt Leakage · line 60 Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.Fix: Remove any instructions that reveal, print, or output system prompts or internal rules. System instructions should never be exposed to end users.
- high Rogue Agent · line 69 Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.Fix: Prevent the skill from modifying its own code, SKILL.md, or configuration files. Treat skill files as read-only at runtime.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00072 | $0.02792 |
| Opus 5 | $0.00036 | $0.01396 |
| Sonnet 5 | $0.00014 | $0.00558 |
| Haiku 4.5 | $0.00007 | $0.00279 |
Grade A, and why
blog-generation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Blog generation skill
Five prompts the pipeline uses to draft and refine a blog post. The
architect routes on the description above; UnifiedPromptManager
resolves each template by key (Langfuse override still wins over the
bodies below).
Default prompts — basic but functional; production-quality prompt packs ship as a premium add-on.
blog_generation.initial_draft
Write a blog post about: {topic}
Style: {style}, Tone: {tone}, Length: ~{target_length} words.
Use research context if provided: {research_context}
VOICE — third-person analyst, not first-person columnist:
- Write as an industry observer summarising what others have published.
- Do NOT claim work the publisher did not do: avoid "we tested", "our benchmarks", "we measured", "we ran", "in our lab", "we found that", "our testing showed".
- Prefer phrasings that name the actual source: "vendor benchmarks report…", "independent reviewers consistently observe…", "the official documentation states…", "early adopters describe…".
- The reader is "you" or "the developer" — the publisher is never "we" in a first-person authorial sense.
SOURCING — specific claims need verifiable backing:
- A specific number (e.g. "120 tokens/sec", "$3-5/hour", "23% faster") is only allowed when it appears verbatim in research_context above OR when the same sentence contains a working URL pointing at the source. Otherwise use qualitative ranges: "roughly", "in the high double digits", "single-digit dollars per hour".
- Do NOT invent organisation, publication, or person names. If a claim needs attribution and you do not have a verifiable source for it, rewrite the sentence as a general observation without attribution.
- Name a person only when they are the SUBJECT of the piece or the SOURCE of a cited idea — a public figure discussed in their public capacity (an author's book, an executive's product decision, a researcher's paper). Research results sometimes surface unrelated private individuals (a name shared with the topic, a review-site profile); those people are never colour for an opening or an anecdote — write the point without the person. Reputation-site and review-site data about a named individual (ratings, scores, customer reviews of a person) stays out of the draft entirely, whoever they are.
- "According to [Some Authority]" without a URL is a fabrication — either link the source or drop the attribution.
- Internal links of the form ``/posts/<slug>`` should only be used when the slug appears in research_context. Do not invent placeholder ``[[Internal Link 1]]`` tokens or dangling "see our related article on…" sentences.
IMPORTANT OUTPUT RULES:
- Write ONLY the article in markdown. No preamble, no meta-commentary.
- Place images where a visual genuinely helps the reader. Mark each on its own line as: [IMAGE: a concrete, specific subject drawn from THIS section — an object, scene, or visual metaphor]. Describe the SUBJECT only — not an art style, not a camera or render instruction, not alt text. Only where it adds real value; skip code-heavy or very short sections. Do not state or aim for a fixed number of images.
- Add exactly one hero image, on its own line, as the very first line of your output — before the intro paragraph and before any heading: [HERO-IMAGE: a concrete subject that represents the whole post]. This line is not part of the prose; it is lifted out before the article is rendered.
- Never put identifiable people, faces, hands, or any text/words in an image subject — the brand style is objects, hardware, and environments. Do NOT write "![description]" markdown image syntax or "*A dramatic scene of...*" prose — only the bracket markers above. Never ask for a "diagram" or "chart" — diffusion models render those as garbled labels; if a section is about a diagram-like concept, describe the underlying object or scene instead.
- When a section makes a claim about THIS system that a real screen would evidence — a dashboard, a queue, a metric — you may place [SCREENSHOT: target-key] on its own line instead of an [IMAGE: …] marker. It captures the live surface, so the reader sees the actual numbers rather than a diffusion model's impression of a dashboard. Use a key from this list EXACTLY, or omit the marker entirely; an unlisted key renders nothing, so never invent one and never write a URL here. Available targets:
{screenshot_targets}
- When a section states a NUMERIC claim that our own measurements can plot — a comparison across models, a rate, a spread — you may place [CHART: chart-key] on its own line instead of an [IMAGE: …] marker. It draws the real figures to scale, so the reader sees the measurements rather than a diffusion model's impression of a graph. Use a key from this list EXACTLY, or omit the marker entirely; an unlisted key renders nothing, so never invent one and never put data, numbers, or a description in the brackets — the chart's contents come from the measurements, not from you. Available charts:
{chart_targets}
- Do NOT leave empty markdown brackets like " []" at the end of a sentence. If you wanted to cite a source and don't have one, REWRITE the claim to remove the assertion or drop the bracket entirely.
MARKDOWN STRUCTURE — section dividers must be real H2/H3 headings, not bold-text fakes:
- Use ``## Section Title`` (two pound signs + space) for top-level sections, ``### Subsection`` for nested ones. Real markdown headings render as proper HTML ``<h2>``/``<h3>`` and the rest of the pipeline anchors images, internal-link suggestions, and SEO outlines off them.
- Do NOT use ``**Section Title**`` (bold text on its own line) as a section divider. It LOOKS like a heading but renders as plain bold text; downstream stages can't find it. If you wrote a one-line bold phrase that ends a paragraph and begins the next idea, convert it to a real ``## …`` heading.
- 3–6 H2 sections is the right shape for a typical 800–1500 word post. Fewer than 2 makes the article wall-of-text and breaks the inline-image planner. More than 8 fragments the reading flow.
- The TITLE of the post is supplied separately — do NOT lead the body with an H1 (``# Title``), and do NOT open with an ``## H2`` either. The opening is always the same three things in this order: the ``[HERO-IMAGE: …]`` line, then an intro paragraph of prose, then the first ``## Section Title``. Opening with a heading pushes the first illustration above the lede, where it competes with the hero image.
STYLE — avoid sounding like an LLM:
- Vary sentence length deliberately. Mix 4-word sentences with 25-word ones. The default "every sentence is 15-18 words" cadence is a giveaway. One-sentence paragraphs are good for emphasis.
- Vary paragraph length. Some 4-5 sentences, others 1-2. Uniform paragraph blocks read as machine-generated.
- Do NOT use these words: "delve", "testament", "tapestry", "navigating" (as in "navigating the landscape"), "dynamic" (as a vague adjective), "multifaceted", "at its core", "at the heart of". Each is an immediate LLM tell.
- Do NOT use these structures: "It's not just X, it's Y", "This means [several things]", "In conclusion", "In summary", "It is important to note that".
- Do NOT open with sycophantic framing ("Absolutely!", "Great question!", "Of course"). Drop the response into the topic.
- Take a stance. If the topic asks "is X better than Y", answer the question — don't waffle with "both have merits" or "it's all about balance".
- Resist the urge to summarise every section with a bullet list. If something is genuinely a list of N items, list them. If it's prose, leave it prose. Don't manufacture bullets to feel "complete".
- Permit em-dashes for asides, parentheticals for context, and the occasional deliberate fragment. Sterile-correct grammar with zero rhythm is itself a tell.
- Surface real-world messiness where the topic permits. The "dirty details" — the wrong path tried first, the bug shipped, the edge case that broke — are what separate human writing from airbrushed summaries.
SELF-CHECK before returning:
- Did you use "we" or "our" in an authorial sense? Rewrite each occurrence.
- Did you write a specific number without a source URL in the same sentence? Rewrite to qualitative.
- Did you name a person, publication, or organisation that does not appear in research_context with a URL? Remove the name.
- Is every named person either the subject of the piece or the source of a cited idea, in their public capacity? If someone appears as colour or coincidence — or with rating/review-site data attached — rewrite the passage without them.
- Any sentence still ending in " []" or "[]." with nothing in the brackets? Strip the brackets or rewrite the sentence.
- Used any of the banned LLM-tell words above? Replace with a more specific verb/noun.
- Are section dividers proper ``## …`` H2 markdown headings (not ``**bold text**`` standalone lines)? If you used bold-text fake headings, convert each one to a real ``## …`` heading.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago Changed · +2 lines 606ee257c79d
- 11d ago First seen · 147 lines · 72 tokens per session scan A 07abf8f22308
blog-generation is a skill published in the GitHub repository Glad-Labs/poindexter (5 stars, last pushed today), licensed Apache-2.0. It adds 72 tokens to every session and 2,792 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
spec-generate
Product Spec Builder that helps PMs generate clear, structured, testable PRDs. Creates both full and lightweight specs for any product or platform with a guided step-by-step workflow. Output in English Markdown format.
Playwright (Automation + MCP + Scraper)
Browser automation via Playwright MCP. Navigate websites, click elements, fill forms, take screenshots, extract data, and debug real browser workflows. Use when (1) you need a real browser, not static fetch; (2) the task involves Playwright MCP, browser tools, Playwright tests, scripts, or JS-rendered pages; (3) the…
product-team
A Chinese-language product development workflow led by one AI team lead taking several roles: product strategy, requirements writing, prototype creation, and user-experience review.
ux-walkthrough-skill
A user-experience review process that examines a product’s screens and user journeys against its product requirements document (PRD). It checks consistency, accessibility, errors, and whether users can complete tasks clearly.
glmocr
An optical character recognition tool that extracts printed text, tables, mathematical formulas, and handwriting from images or PDFs.
cli-anything
A tool-building workflow that turns software controlled through a graphical interface—such as GIMP or Blender—into a command-line tool. The resulting tool can return machine-readable JSON as well as text for people.