Blog Post Writing Skill
Audience and Product Framing (Required)
Write for users of the Tarsk product, not developers inspecting the Tarsk codebase.
Unless the user explicitly asks for developer-facing internals, do not include implementation details about how Tarsk is built.
Avoid unnecessary references to:
- Electrobun or other runtime/framework choices
- repository structure, file paths, packages, or component names
- internal tool wiring, agent plumbing, or code-level architecture
- commit history, PRs, internal migrations, or refactors
- build systems, test setup, or deployment internals
Keep the article at the product layer:
- what the feature does
- who it is for
- how to use it
- when it is useful
- important limitations a user should understand
If platform constraints matter to the user experience, explain them in plain product language rather than internal implementation language.
Research First (Required)
Before writing any blog post, you MUST delegate research:
- Use the
tasktool withsubagent_type: "researcher" - In the description, specify BOTH the topic AND where to save:
task(
subagent_type="researcher",
description="Research [TOPIC]. Save findings to research/[slug].md"
)
Example:
task(
subagent_type="researcher",
description="Research the current state of AI agents in 2025. Save findings to research/ai-agents-2025.md"
)
- After research completes, read the findings file before writing
Human Voice Pass (Required)
After drafting and before saving any blog post, you MUST apply the stop-slop skill:
- Read .agents/skills/stop-slop/SKILL.md
- Read references/phrases.md, references/structures.md, and references/examples.md
- Edit the full draft against the Core Rules and Quick Checks
- Score Directness, Rhythm, Trust, Authenticity, and Density (1-10 each). Revise if below 35/50
- Save the edited post, then generate the cover image
Do not skip this pass. A blog post is not complete until it passes stop-slop.
Content Boundaries (Required)
Every blog post must stand alone. Do not punt detail to other posts on the site.
Do not reference other blog posts. No links to /blog/..., no "see our separate post", no "we covered this in...". If a topic belongs in the current post, write it there. If it does not fit, leave it out.
Do not mention daily changelogs for model updates. Do not write about automated model-list sync, changelog generation, or internal catalog maintenance. Focus on what the reader can do in the app (pick a model, compare context windows, configure a provider).
Do not expose internal implementation detail unless explicitly requested. Keep the writing useful to product users. Avoid codebase internals, framework choices, package names, local file paths, or engineering process detail unless the user specifically asks for a developer-focused post.
Output Structure (Required)
Every blog post MUST have both a post AND a cover image:
blogs/
└── <slug>/
├── post.md # The blog post content
└── hero.png # REQUIRED: Generated cover image
Example: A post about "AI Agents in 2025" → website/src/components/blog/ai-agents-2025/
You MUST complete both steps:
- Write the post to
website/src/components/blog/<slug>/post.md - Generate a cover image using
generate_imageand save towebsite/public/images/blog/<slug>/hero.png
A blog post is NOT complete without its cover image.
Blog Post Structure
Every blog post should follow this structure:
1. Hook (Opening)
- Start with a compelling question, statistic, or statement
- Make the reader want to continue
- Keep it to 2-3 sentences
2. Context (The Problem)
- Explain why this topic matters
- Describe the problem or opportunity
- Connect to the reader's experience
3. Main Content (The Solution)
- Break into 3-5 main sections with H2 headers
- Each section covers one key point
- Include code examples, diagrams, or screenshots where helpful
- Use bullet points for lists
4. Practical Application
- Show how to apply the concepts
- Include step-by-step instructions if applicable
- Provide code snippets or templates only when they are part of the user's actual product workflow or the user explicitly asked for developer-facing material
5. Conclusion & CTA
- Summarize key takeaways (3 bullets max)
- End with a clear call-to-action
- Link to docs, downloads, or product pages only (never other blog posts)
Cover Image Generation
After writing the post, generate a cover image using the generate_cover tool:
generate_cover(prompt="A detailed description of the image...", slug="your-blog-slug")
The tool saves the image to blogs/<slug>/hero.png.
Writing Effective Image Prompts
Structure your prompt with these elements:
- Subject: What is the main focus? Be specific and concrete.
- Style: Art direction (minimalist, isometric, flat design, 3D render, watercolor, etc.)
- Composition: How elements are arranged (centered, rule of thirds, symmetrical)
- Color palette: Specific colors or mood (warm earth tones, cool blues and purples, high contrast)
- Lighting/Atmosphere: Soft diffused light, dramatic shadows, golden hour, neon glow
- Technical details: Aspect ratio considerations, negative space for text overlay
Example Prompts
For a technical blog post:
Isometric 3D illustration of interconnected glowing cubes representing AI agents, each cube has subtle circuit patterns. Cubes connected by luminous data streams. Deep navy background (#0a192f) with electric blue (#64ffda) and soft purple (#c792ea) accents. Clean minimal style, lots of negative space at top for title. Professional tech aesthetic.
For a tutorial/how-to:
Clean flat illustration of hands typing on a keyboard with abstract code symbols floating upward, transforming into lightbulbs and gears. Warm gradient background from soft coral to light peach. Friendly, approachable style. Centered composition with space for text overlay.
For thought leadership:
Abstract visualization of a human silhouette profile merging with geometric neural network patterns. Split composition - organic watercolor texture on left transitioning to clean vector lines on right. Muted sage green and warm terracotta color scheme. Contemplative, forward-thinking mood.
Product Writing Rules
- Prefer product terms users see in the UI over internal engineering terminology
- Explain capabilities and constraints in plain language
- If a feature is limited to a platform or plan, state that clearly without explaining the underlying codebase implementation
- Do not add engineering trivia that does not help a user succeed with the product
SEO Considerations
- Include the main keyword in the title and first paragraph
- Use the keyword naturally 3-5 times throughout
- Keep the title under 60 characters
- Write a meta description (150-160 characters)
Quality Checklist
Before finishing:
- Post saved
- Hero image generated
- Hook grabs attention in first 2 sentences
- Each section has a clear purpose
- Conclusion summarizes key points
- CTA tells reader what to do next
- stop-slop pass completed (no filler phrases, passive voice, em dashes, or formulaic structures)
- stop-slop score 35/50 or higher on all five dimensions
- No links or references to other blog posts
- No mentions of daily model changelogs or automated catalog sync
- No unnecessary Tarsk codebase implementation details
- Written for product users, not developers inspecting internals