菜单
Transform markdown notes into engaging technical blog posts for both programmers and non-technical readers
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Systematic techniques for reading and understanding unfamiliar legacy code without documentation
Map dependencies and coupling in legacy codebase to understand what breaks when you change something and identify refactoring risks
Create detailed implementation plans with bite-sized tasks for engineers with zero codebase context
Creating documentation from legacy code when none exists, focusing on what future maintainers need to know
Maintain skills wiki health - check links, naming, cross-references, and coverage
TDD for process documentation - test with subagents before writing, iterate until bulletproof
| name | Technical Blog Post Generator |
| description | Transform markdown notes into engaging technical blog posts for both programmers and non-technical readers |
| when_to_use | when you need to create a technical blog post from markdown notes or research material |
| version | 1.0.0 |
| languages | markdown |
Transform raw technical notes, research, or project documentation into engaging blog posts that educate both technical and non-technical audiences. The goal is to make complex technical concepts accessible without losing depth.
Core principle: Every technical blog post should teach something valuable, tell a story, and be enjoyable to read regardless of the reader's technical background.
Use this skill when:
CRITICAL: This is the ONLY acceptable output format. Do NOT deviate from this structure.
LANGUAGE: All blog posts MUST be written in ENGLISH (US). Title, excerpt, content, code comments - everything in English.
Every generated blog post MUST follow this exact structure:
---
title: "Your Post Title"
date: "YYYY-MM-DD"
slug: "your-post-slug"
excerpt: "A brief summary of your post (appears in listings)"
thumbnail: "/images/default-thumbnail.png"
categories: ["Category1", "Category2"]
---
# Your Post Title
Introduction paragraph goes here.
## Section Heading
Content goes here with **bold** or *italic* formatting.
### Code Example
\`\`\`javascript
// This is a code block with syntax highlighting
function helloWorld() {
console.log("Hello, world!");
}
\`\`\`
YOU MUST adhere to these rules without exception:
Frontmatter Block (lines 1-7):
--- on line 1--- on line 7["Cat1", "Cat2"]"YYYY-MM-DD" (e.g., "2025-10-27")Title (line 9):
Content Structure:
Code Blocks:
Spacing:
---Example of CORRECT format:
---
title: "Building AI Agents with Claude SDK"
date: "2025-10-27"
slug: "building-ai-agents-claude-sdk"
excerpt: "Learn how to build production-ready AI agents using Claude Agent SDK and monitor them with New Relic"
thumbnail: "/images/default-thumbnail.png"
categories: ["AI", "TypeScript", "Observability"]
---
# Building AI Agents with Claude SDK
AI agents are transforming how we build applications. But how do you create one that's reliable and observable in production?
In this post, I'll walk you through building a real AI agent using Anthropic's Claude Agent SDK.
## The Challenge
Building an AI agent is straightforward. Making it production-ready is not.
### Observability Matters
Without monitoring, you're flying blind. Here's why:
- Token costs can spiral out of control
- Performance issues go unnoticed
- Errors happen silently
\`\`\`typescript
// Configure the agent with monitoring
const agent = new Agent({
model: "claude-sonnet-4",
observability: true
});
\`\`\`
## Lessons Learned
After building this agent, here's what I discovered:
1. Always instrument your agents from day one
2. Monitor token usage in real-time
3. Set up alerts for cost thresholds
When creating a blog post, ensure you include:
Example:
Ever wondered how AI agents know when they're making mistakes? In production,
an AI agent without monitoring is like flying blind - you don't know if it's
working until something breaks spectacularly.
In this post, I'll show you how I built a real-world AI agent using Claude
Agent SDK and integrated it with New Relic for full observability. You'll
learn what worked, what didn't, and why monitoring AI systems is harder than
you might think.
Recommended sections:
Example:
The agent uses OpenTelemetry to send traces to New Relic:
\`\`\`typescript
// Configure OpenTelemetry with New Relic exporter
const provider = new NodeTracerProvider({
resource: new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: 'markdown-analyzer',
}),
});
// Send traces to New Relic via OTLP
provider.addSpanProcessor(
new BatchSpanProcessor(
new OTLPTraceExporter({
url: 'https://otlp.nr-data.net:4318/v1/traces',
headers: { 'api-key': process.env.NEW_RELIC_LICENSE_KEY },
})
)
);
\`\`\`
Example:
The agent uses **OpenTelemetry** - think of it as a flight recorder for software,
capturing every action the AI agent takes. This lets us answer questions like
"How long did it take?" and "Did it work correctly?"
Follow these steps when generating a blog post:
From the notes, identify:
Create a logical flow:
For each section, consider:
Input (notes):
Built an AI agent with Claude SDK. Added New Relic monitoring.
First tried Traceloop but didn't work. Then used OpenTelemetry.
Agent analyzes markdown files.
Output (blog post intro):
# Monitoring AI Agents: A Practical Guide to Claude SDK and New Relic
Building an AI agent is exciting. Deploying it to production without monitoring
is terrifying. How do you know if it's working? How much is it costing? Where
are the bottlenecks?
I recently built a markdown analysis agent using Anthropic's Claude Agent SDK
and quickly realized that observability wasn't optional - it was critical.
But integrating monitoring turned out to be more challenging than expected.
In this post, I'll show you how I solved the observability problem, including
a false start with Traceloop and the eventual solution using OpenTelemetry.
You'll learn practical patterns for monitoring AI agents and avoid the mistakes
I made along the way.
CRITICAL: Read the "Required Blog Post Format" section and follow it EXACTLY.
LANGUAGE REQUIREMENT: Write EVERYTHING in ENGLISH (US). No exceptions.
When generating a blog post, you MUST:
---["Cat1", "Cat2"]"YYYY-MM-DD"javascript NOT )FORMAT VALIDATION CHECKLIST - Verify before outputting:
--- on line 1--- on line 7Before considering a blog post complete, verify:
Remember: The best technical blog posts teach something valuable while being enjoyable to read. Focus on clarity, honesty, and providing real value to your readers.
When in doubt, ask yourself: "Would I want to read this?" and "Did I learn something I can actually use?"
Before you output ANYTHING, re-read this:
WRITE IN ENGLISH (US) - Every word, every sentence, every code comment must be in English.
Your output MUST be a complete markdown file that starts EXACTLY like this:
---
title: "Your Actual Title Here"
date: "2025-10-27"
slug: "your-actual-slug-here"
excerpt: "Your actual excerpt here"
thumbnail: "/images/default-thumbnail.png"
categories: ["Category1", "Category2"]
---
# Your Actual Title Here
Your introduction starts here...
NON-NEGOTIABLE RULES:
--- (three dashes)--- (three dashes)"like this"["Cat1", "Cat2"]"YYYY-MM-DD" format (e.g., "2025-10-27")# Title (H1 matching frontmatter title)javascript NOT DO NOT:
START YOUR OUTPUT WITH THE FRONTMATTER. NOTHING ELSE. WRITE EVERYTHING IN ENGLISH.