Search the docs, videos, blog, apps, teams, skills and release notes.
At a glance
What it is
Engineering blog post creation covering article structure and narrative arc, technical explanation techniques, code example design, diagram creation, SEO optimization for developer content, editorial process, audience calibration, measuring post impact, and building a consistent publishing cadence.
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
The whole file, exactly as it downloads. Read it before you rely on it.
SKILL.md
511 lines · 2,290 words
Technical blog writing communicates engineering ideas, decisions, and learnings to a developer audience. The best engineering blogs build trust, attract talent, share knowledge, and establish thought leadership. This skill covers crafting compelling technical articles: from choosing topics and structuring narratives, through writing clear explanations with effective code examples, to optimizing for discovery and measuring impact.
Engineering blog post creation covering article structure and narrative arc, technical explanation techniques, code example design, diagram creation, SEO optimization for developer content, editorial process, audience calibration, measuring post impact, and building a consistent publishing cadence.
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
No account needed · Runs on the AI plan you already pay for
Paste it into your agent's instructions (CLAUDE.md, AGENTS.md or a custom GPT), or add it to a bot in Murage.
Ask Ember for the bot, then switch the skill on in its settings.
Step 1
Send your Chief of Staff this message. It proposes the bot and its role first, and creates it when you say go.
Send this to Ember
“Create a bot that uses the Technical Blog Writer skill, and show me the plan first.”
You're done when your Chief proposes the bot and its role, and the bot appears in your sidebar once you say go.
Step 2
You're done when you see the bot’s skills and the library.
Step 3
You're done when the skill shows as on for that bot.
Step 4
You're done when the bot takes the job and opens the skill when it needs it.
Prefer to do it yourself? Choose + in the sidebar, then New Bot.Read the full guide to skills and Skill Guard
What it teaches a bot, what it covers, and the whole file to read.
What it covers
Overview
Article Archetypes
Article Structure
Writing Clear Technical Explanations
Code Examples in Blog Posts
Technical Diagrams
SEO for Technical Content
Editorial Process
Measuring Blog Post Impact
Writing Checklist
When to Use
Output Format
Example
Edge Cases
Type Structure Example Title
------------------------------------------------------------------------
How-We-Built-It Problem -> Solution -> "How We Migrated 2TB
Results -> Lessons to PostgreSQL with
Zero Downtime"
Deep Dive Concept -> Internals -> "How JavaScript
Implementation -> Garbage Collection
Implications Really Works"
Comparison Criteria -> Analysis -> "Kafka vs Pulsar:
Benchmarks -> Verdict A Practical Comparison
for Event Streaming"
Postmortem Timeline -> Root Cause -> "The 4-Hour Outage
Fix -> Prevention That Changed How We
Deploy"
Tutorial/Guide Problem -> Steps -> "Building a Real-Time
Working Code -> Dashboard with
Extensions WebSockets"
Opinion/Approach Thesis -> Evidence -> "Why We Stopped Using
Counter-arguments -> Microservices for
Conclusion Everything"
Announcement What -> Why -> How -> "Introducing Our New
Get Started GraphQL API"# [Title: Specific, Benefit-Oriented, Under 70 Characters]
**Subtitle or summary line**: One sentence expanding on the title.
## Introduction (3-4 paragraphs)
Paragraph 1: The hook. Start with the problem, a surprising fact,
or a relatable scenario. Make the reader think "I've had that problem"
or "I didn't know that."
Paragraph 2: Context. What system/project/team is this about?
What scale or constraints are relevant?
Paragraph 3: Preview. What will the reader learn? What approach
did you take? Give them a reason to keep reading.
Paragraph 4 (optional): Scope. What this post covers and doesn't cover.
## Background / Problem Statement
Describe the problem in enough detail that the reader understands
the constraints. Include:
- What the system looked like before
- What wasn't working (performance? reliability? developer velocity?)
- What you tried that didn't work (optional but engaging)
## The Approach / Solution
The technical meat. Organize by:
- Chronological steps (for how-we-built-it)
- Conceptual layers (for deep dives)
- Criteria (for comparisons)
Include code examples, architecture diagrams, and data.
### Subheading for Each Major Section
Each section should:
1. Explain what and why (not just how)
2. Include a code example or diagram
3. Call out gotchas or non-obvious decisions
4. Be readable independently (someone skimming can learn from just this section)
## Results
Show the impact with data:
- Before/after metrics
- Performance benchmarks
- Graphs or tables
## Lessons Learned / Key Takeaways
3-5 bullet points. What would you tell someone starting this
same project today?
## Conclusion
2-3 sentences. Reinforce the main point. Optionally invite
discussion or point to related work.
---
*Author bio. Links to Twitter/GitHub. "We're hiring" if applicable.*1. ANALOGY-FIRST
"A load balancer works like a restaurant host -- it greets
every incoming customer (request) and seats them at the
table (server) with the shortest wait time."
2. CONCRETE-BEFORE-ABSTRACT
BAD: "A closure is a function that captures its lexical scope."
GOOD: "When you write a counter function that remembers its count
between calls, that's a closure. The inner function
'captures' the count variable from its parent."
3. PROGRESSIVE DISCLOSURE
Start with the simple version, then add complexity:
"At its simplest, a database index is like a book index --
it tells you which page (disk location) has the data you want.
But unlike a book index, a database index is a B-tree
data structure that..."
4. SHOW-THEN-EXPLAIN
Show the code or diagram first, then explain it.
Readers pattern-match faster than they parse prose.
5. CONSTRAINT-DRIVEN
"We needed sub-100ms response times, 99.99% availability,
and the ability to handle 50K requests/second. These
constraints led us to..."BEFORE (verbose, passive):
"It was determined by the team that the implementation of a
caching layer would be beneficial for the purpose of reducing
the latency that was being experienced by our users when they
were accessing the dashboard."
AFTER (concise, active):
"We added a Redis cache in front of the dashboard API.
Response times dropped from 800ms to 45ms."
Rules:
- Active voice: "We chose" not "It was decided"
- Remove hedge words: "basically", "actually", "simply"
- Specific numbers: "45ms" not "much faster"
- Short sentences for complex ideas
- One idea per paragraph
- Delete any sentence that doesn't teach or advance the narrativeGuidelines:
1. MINIMAL BUT COMPLETE
Show enough to understand, not the entire codebase.
Strip boilerplate but keep enough context.
2. ANNOTATED
Add comments explaining the non-obvious parts:
// Use SET NX to ensure only one worker acquires the lock
await redis.set(lockKey, workerId, 'NX', 'EX', 30);
3. RUNNABLE (when possible)
Link to a GitHub repo or CodeSandbox where readers
can run the complete example.
4. HIGHLIGHT THE KEY LINES
In a 20-line code block, the reader's eye should be
drawn to the 3-4 lines that matter most.
5. SHOW INPUT AND OUTPUT
Don't just show the code. Show what happens when you run it.
6. LANGUAGE-APPROPRIATE
Use the language your audience uses.
A Kubernetes article should use YAML, not JSON.### The Problem: N+1 Queries
Our dashboard was making one database query per user to get
their recent orders:
# Slow: N+1 queries (1 + N separate queries)
users = User.objects.all()[:50]
for user in users:
orders = Order.objects.filter(user=user).order_by('-created')[:5]
# This executes a new query for each user!
With 50 users on the page, this made 51 database queries and
took 1200ms.
### The Fix: Prefetch Related
Django's `prefetch_related` batches these into 2 queries:
# Fast: 2 queries total (1 for users, 1 for all their orders)
users = User.objects.prefetch_related(
Prefetch(
'orders',
queryset=Order.objects.order_by('-created')[:5]
)
)[:50]
**Result:** 51 queries -> 2 queries. 1200ms -> 45ms.When to use each type:
Architecture Diagram:
- Show system components and their relationships
- Keep to 5-8 boxes max (simplify for the reader)
- Use consistent shapes: rectangles for services,
cylinders for databases, clouds for external services
Sequence Diagram:
- Show request flow across services
- Great for explaining auth flows, API interactions
- Keep to 5-7 participants max
Flowchart:
- Decision trees, error handling logic
- Good for "when to use X vs Y" decisions
Timeline:
- Incident postmortems
- Migration stories
- Performance optimization journeys
Data Visualization:
- Before/after performance charts
- Growth metrics
- Benchmark comparisons
- Always label axes and include units
Tools:
- Mermaid (embeds in Markdown, version-controllable)
- Excalidraw (hand-drawn style, approachable)
- D2 (text-to-diagram, good for architecture)
- Chart.js / Observable (data visualizations)on_page_seo:
title:
- "Include the primary keyword naturally"
- "Keep under 60 characters"
- "Front-load the important words"
- "Include the technology name (React, Kubernetes, etc.)"
- "Bad: 'Our Journey with Caching'"
- "Good: 'Redis Caching Patterns for High-Traffic APIs'"
meta_description:
- "150-160 characters summarizing the value"
- "Include the problem and the solution"
- "Example: Learn how to reduce API latency from 800ms to 45ms
using Redis caching patterns. Includes code examples and
production configuration."
headings:
- "H2s should be scannable and keyword-rich"
- "Developers skim headings before deciding to read"
- "Use question format for FAQ-style sections"
url_structure:
- "Use descriptive slugs: /blog/redis-caching-patterns"
- "Avoid dates in URLs (content stays relevant)"
- "Keep short: 3-5 words in the slug"
content_optimization:
- "Answer the search query in the first 2 paragraphs"
- "Include code blocks (Google indexes code samples)"
- "Use schema markup for HowTo and FAQ content"
- "Internal link to related posts"
- "External link to official docs (signals authority)"
keyword_strategy:
- "Target long-tail developer queries"
- "'how to implement rate limiting in express' over 'rate limiting'"
- "Include error messages as keywords (developers search for errors)"
- "'ECONNREFUSED postgresql docker' is a real search query"1. PITCH (Author, 15 min)
- Working title
- Target audience (who and what they know)
- Key takeaway (one sentence)
- Rough outline (section headings)
- Estimated length and timeline
2. DRAFT (Author, 2-8 hours)
- Write complete first draft
- Include code examples (tested)
- Add placeholder notes for diagrams
3. TECHNICAL REVIEW (Peer, 1 hour)
- Is the technical content accurate?
- Are the code examples correct and idiomatic?
- Are there security implications not addressed?
- Would you share this with your team?
4. EDITORIAL REVIEW (Editor, 30 min)
- Is the structure logical?
- Is the writing clear and concise?
- Are there jargon or assumptions to unpack?
- Does the title and intro hook the reader?
5. POLISH (Author, 1-2 hours)
- Address review feedback
- Add diagrams and visuals
- Write meta description and social copy
- Final code testing
6. PUBLISH
- Schedule for optimal day/time
- Share on social channels
- Submit to aggregators (Hacker News, Reddit, dev.to)
- Monitor comments and respond
7. MEASURE (1 week post-publish)
- Page views and time on page
- Social shares and backlinks
- Comments and discussion quality
- Conversion metrics (signups, hires)Technical accuracy:
[ ] Code examples compile/run correctly
[ ] Technical claims are supported (benchmarks, docs)
[ ] No security anti-patterns in code examples
[ ] Version numbers and APIs are current
Writing quality:
[ ] Clear thesis stated in introduction
[ ] Each section advances the narrative
[ ] No unnecessary jargon (or jargon is defined)
[ ] Consistent voice and tense throughout
[ ] Conclusion summarizes key points
Developer experience:
[ ] Code is copy-paste ready
[ ] Diagrams add understanding (not just decoration)
[ ] Post is scannable (good headings, short paragraphs)
[ ] Estimated reading time is accuratemetrics:
reach:
- page_views: "Total and unique"
- referral_sources: "Where readers come from"
- social_shares: "Twitter, LinkedIn, HN, Reddit"
- backlinks: "Other sites linking to this post"
engagement:
- average_time_on_page: "Target: > 4 minutes"
- scroll_depth: "% reaching end of article"
- bounce_rate: "Target: < 60%"
- comments: "Quality and quantity"
business_impact:
- developer_signups: "API key registrations from blog"
- documentation_visits: "Blog -> docs conversion"
- job_applications: "Mentions blog in application"
- brand_mentions: "Social mentions citing the post"
content_health:
- evergreen_traffic: "Still getting views after 6 months?"
- search_rankings: "Position for target keywords"
- update_needed: "Are code examples still current?"Before Writing:
[ ] Topic fills a gap (not already well-covered elsewhere)
[ ] Target audience clearly defined
[ ] One clear takeaway identified
[ ] Outline reviewed with teammate
During Writing:
[ ] Introduction hooks reader in first paragraph
[ ] Technical explanation uses concrete examples
[ ] Code examples are tested and minimal
[ ] Diagrams used where text alone is insufficient
[ ] Key terms defined on first use
[ ] Active voice throughout
Before Publishing:
[ ] Technical review by subject matter expert
[ ] Editorial review for clarity and flow
[ ] All code examples retested
[ ] Links verified (no 404s)
[ ] Images have alt text
[ ] Meta title and description optimized
[ ] Social sharing image/card configured
[ ] Reading time estimate addedUse this skill when:
Designing or implementing technical blog writer solutions
Reviewing or improving existing technical blog writer approaches
Making architectural or implementation decisions about technical blog writer
Learning technical blog writer patterns and best practices
Troubleshooting technical blog writer-related issues
Do NOT use this skill when:
The question is about a fundamentally different technology domain
A more specific sibling skill covers the exact topic needed
The user needs a complete hands-on tutorial rather than expert guidance
# Technical Blog Writer Analysis
## Context Assessment
[Situation summary and constraints]
## Recommended Approach
[Primary recommendation with rationale]
## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]
## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]
## Next Steps
- [Immediate action item]
- [Follow-up action item]Input: "Help me implement technical blog writer for a medium-scale production application"
Output: A structured analysis covering current state assessment, recommended technical blog writer approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.
Legacy system integration: When technical blog writer must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities
SKILL.md
511 lines · 2,290 words
The text of SKILL.md is shown as it downloads, under the Apache-2.0 license, by Ferrox Labs. The license is the one in the file's own frontmatter.
Your new bot
Technical Blog Writer bot
Waiting in your sidebar once you say go.
No account needed · Runs on the AI plan you already pay for