blog-writing

Category: Content & Multimedia | Uploader: SShadowS | Downloads: 0 | Version: v1.0（Latest）

Style guide and conventions for writing CentralGauge blog posts. Use when creating or editing blog posts, devlogs, announcements, or any public-facing written content about CentralGauge benchmark results, updates, or findings. Ensures consistent voice, tone, and formatting across all posts.

Changelog: Source: GitHub https://github.com/SShadowS/CentralGauge

Directory Structure

Current level: .claude/skills/blog-writing/

📄 SKILL.md 2.9 KB

SKILL.md

---
name: blog-writing
description: Style guide and conventions for writing CentralGauge blog posts. Use when creating or editing blog posts, devlogs, announcements, or any public-facing written content about CentralGauge benchmark results, updates, or findings. Ensures consistent voice, tone, and formatting across all posts.
---

# CentralGauge Blog Writing Style Guide

## Voice & Perspective

- **First person singular.** Always "I", never "we". CentralGauge is a single-person project.
- Write as the project author speaking directly to a technical audience.
- Example: "I audited each task and found..." not "We audited each task and found..."

## Tone

- **Professional but direct.** Not corporate, not casual. Think senior engineer writing a post-mortem.
- Be honest about mistakes and what was broken. Transparency builds credibility.
- Avoid hedging language ("perhaps", "it seems like", "it might be"). State findings directly.
- No hype or marketing speak. Let the data speak for itself.

## Formatting

- Use `---` horizontal rules to separate major sections.
- Bold key terms and task IDs on first mention in a section.
- Use tables for comparative data (rankings, before/after scores).
- Code references use backticks: `cleanCode()`, `Insert(true)`, `CG-AL-H002`.
- Keep paragraphs short (3-5 sentences max). Technical readers skim.

## Structure

1. **Title**: Descriptive, not clickbait. State what changed or what the post is about.
2. **Opening**: 2-3 paragraphs setting context. What was the situation, what changed, why does this post exist.
3. **Body sections**: Each with a clear heading. One topic per section.
4. **Data/Rankings**: Include tables when available. Show the numbers, don't just describe them.
5. **Closing**: What's next. Keep it brief, 1 short section.
6. **Sign-off**: End with a notable data point or cost figure in italics as a coda.

## Content Rules

- Always include specific task IDs (e.g., CG-AL-H002) when discussing fixes or results.
- When describing a bug fix, explain: what was broken, why it mattered, what the fix was.
- Attribute score changes to specific causes. Don't just say "scores improved."
- Include cost data when relevant. Benchmark economics matter to readers.
- Reference the GitHub repo at the end for readers who want to dig deeper.

## Things to Avoid

- Emojis. Never.
- "We" or "our team" or "the team." It's "I" and "my."
- Rhetorical questions as section headers.
- Filler phrases: "It's worth noting that", "Interestingly enough", "As you can see."
- Apologetic tone. Don't say "unfortunately" or "sadly." Just state what happened and what was fixed.
- Over-explaining what LLMs or Business Central are. The audience already knows.

## Project Links

- **GitHub**: https://github.com/SShadowS/CentralGauge (account: SShadowS)
- Always use this URL when linking to the repo in blog posts.

## Blog Location

- Blog posts live in `docs/blog/` as markdown files.
- Naming convention: `YYYY-MM-<slug>.md` (e.g., `2025-02-benchmark-update.md`).

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

blog-writing

Directory Structure

SKILL.md

Report

Notice