blog

GitHub

为 Chorus 项目撰写双语发布博客,遵循特定叙事结构、语气及命名规范。

.claude/skills/blog/SKILL.md Chorus-AIDLC/Chorus

Trigger Scenarios

需要撰写新版本发布博客 生成双语(中英文)产品宣传内容

Install

npx skills add Chorus-AIDLC/Chorus --skill blog -g -y
More Options

Non-standard path

npx skills add https://github.com/Chorus-AIDLC/Chorus/tree/main/.claude/skills/blog -g -y

Use without installing

npx skills use Chorus-AIDLC/Chorus@blog

指定 Agent (Claude Code)

npx skills add Chorus-AIDLC/Chorus --skill blog -a claude-code -g -y

安装 repo 全部 skill

npx skills add Chorus-AIDLC/Chorus --all -g -y

预览 repo 内 skill

npx skills add Chorus-AIDLC/Chorus --list

SKILL.md

Frontmatter
{
    "name": "blog",
    "license": "AGPL-3.0",
    "metadata": {
        "author": "chorus",
        "version": "0.1.0",
        "category": "content"
    },
    "description": "Write release blog posts for Chorus — problem-first narrative, bilingual (zh\/en), following the project's editorial style."
}

Chorus Blog Post

Write bilingual (zh/en) release blog posts for the Chorus landing site.

Prerequisites

  • You know what version / feature to write about (user will tell you, or check recent CHANGELOG / git log)
  • Existing blog posts live in packages/landing/src/content/blog/
  • Naming convention: zh-chorus-vX.Y.Z-release.md (Chinese), chorus-vX.Y.Z-release.md (English)

Editorial Style

These rules come from the project owner. Follow them strictly.

Narrative structure

  1. Open from the reader's pain point, not the feature. Don't start with "we released X." Start with the problem the reader is living with. Describe the scenario vividly so they recognize themselves in it.
  2. One line to introduce the solution. After the pain point lands, say what this version does in one sentence.
  3. Break down the supporting mechanisms. Explain the layers / building blocks that make the solution work. Order them by the flow the user experiences, not by importance.
  4. Industry context as supporting evidence, not the opening. If there are relevant industry trends (e.g., new tools from Anthropic, competitor features), reference them to validate the direction. But they go in the middle or late section, never the lead.
  5. Converge to a conclusion. Tie the pieces back together. The punchline should echo the opening pain point: "this is why you can now do X."

Tone and voice

  • Don't speak for the reader. Never write "you probably think X" or "you definitely feel Y." Describe the situation, let readers identify with it on their own.
  • Casual, not corporate. Write like you're explaining to a sharp colleague, not writing a press release. No marketing speak, no filler adjectives.
  • No em dashes (——) in Chinese. Use commas, periods, or sentence breaks instead.
  • Chinese should read like Chinese. Not translated-from-English. Spoken rhythm, natural phrasing.
  • English should read like English. Not translated-from-Chinese. Prefer short punchy sentences. Avoid "materialize," "leverage," "utilize" — use plain words.
  • Logical consistency matters. The owner will catch contradictions immediately. If you say "we had X from day one," make sure that's actually true. If something was added in a specific version, say so.
  • No filler. If one sentence covers it, don't stretch it to three.

Title

  • Include the version number: Chorus vX.Y.Z: <hook>
  • The hook is the real title. It should make someone want to click.
  • Can mix Chinese and English, use slang, be playful.
  • Examples:
    • "Chorus v0.6.1: 你的时间比 Token 贵,/yolo it!"
    • "Chorus v0.6.0: 给你的 Agent 团队派个监工"

Frontmatter

---
title: "Chorus vX.Y.Z: <hook>"
description: "<1-2 sentences, written as a question or provocation, not a summary>"
date: YYYY-MM-DD
lang: zh  # or en
postSlug: chorus-vX.Y.Z-release
---
  • description should hook the reader, not summarize the post. A question or a challenge works well.
  • postSlug must be the same for both zh and en versions so they link together.

Steps

1. Gather context

# Find the version's CHANGELOG entry
# Read recent commits if needed
# Read the relevant feature code / skill docs to understand what was built

Understand the feature deeply before writing. Read the code, the skill docs, the PR descriptions. Don't write from summaries alone.

2. Draft the Chinese version first

Write zh-chorus-vX.Y.Z-release.md. Chinese is the primary version, not a translation.

Present the draft to the user for review. Expect multiple rounds of feedback on:

  • Narrative structure (what goes first, what to cut)
  • Tone (too stiff, too corporate, too presumptuous)
  • Logical consistency
  • Title and description

Do NOT proceed to the English version until the Chinese version is approved.

3. Write the English version

Write chorus-vX.Y.Z-release.md. This is NOT a literal translation. Rewrite for an English-speaking audience:

  • Same structure and arguments
  • Natural English phrasing and rhythm
  • Adapt metaphors and references that don't cross language boundaries

4. Self-review checklist

Before presenting each version:

  • Opens from pain point, not feature announcement
  • Doesn't speak for the reader ("you probably think...")
  • No em dashes in Chinese version
  • No translation-smell in either language
  • Title has version number + hook
  • Description is a hook, not a summary
  • All factual claims are accurate (which version introduced what)
  • No logical contradictions between sections
  • No filler paragraphs — every section earns its space
  • postSlug matches between zh and en versions

Version History

  • c08357a Current 2026-07-25 08:34

Same Skill Collection

.claude/skills/e2e-verification/SKILL.md
.claude/skills/openspec-apply-change/SKILL.md
.claude/skills/openspec-archive-change/SKILL.md
.claude/skills/openspec-explore/SKILL.md
.claude/skills/openspec-propose/SKILL.md
.claude/skills/plugin-maintenance/SKILL.md
.claude/skills/pr-workflow/SKILL.md
.claude/skills/release/SKILL.md
packages/chorus-dsh/skills/brainstorm-chorus/SKILL.md
packages/chorus-dsh/skills/chorus/SKILL.md
packages/chorus-dsh/skills/code-reviewer-chorus/SKILL.md
packages/chorus-dsh/skills/develop-chorus/SKILL.md
packages/chorus-dsh/skills/docs-chorus/SKILL.md
packages/chorus-dsh/skills/idea-chorus/SKILL.md
packages/chorus-dsh/skills/openspec-aware-chorus/SKILL.md
packages/chorus-dsh/skills/orchestrate-chorus/SKILL.md
packages/chorus-dsh/skills/proposal-chorus/SKILL.md
packages/chorus-dsh/skills/proposal-reviewer-chorus/SKILL.md
packages/chorus-dsh/skills/quick-dev-chorus/SKILL.md
packages/chorus-dsh/skills/review-chorus/SKILL.md
packages/chorus-dsh/skills/task-reviewer-chorus/SKILL.md
packages/chorus-dsh/skills/yolo-chorus/SKILL.md
packages/chorus-pi/skills/chorus/SKILL.md
packages/chorus-pi/skills/develop/SKILL.md
packages/chorus-pi/skills/docs/SKILL.md
packages/chorus-pi/skills/idea/SKILL.md
packages/chorus-pi/skills/openspec-aware/SKILL.md
packages/chorus-pi/skills/orchestrate/SKILL.md
packages/chorus-pi/skills/proposal/SKILL.md
packages/chorus-pi/skills/quick-dev/SKILL.md
packages/chorus-pi/skills/review/SKILL.md
packages/chorus-pi/skills/yolo/SKILL.md
packages/openclaw-plugin/skills/brainstorm/SKILL.md
packages/openclaw-plugin/skills/chorus/SKILL.md
packages/openclaw-plugin/skills/code-reviewer/SKILL.md
packages/openclaw-plugin/skills/develop/SKILL.md
packages/openclaw-plugin/skills/docs/SKILL.md
packages/openclaw-plugin/skills/idea/SKILL.md
packages/openclaw-plugin/skills/openspec-aware/SKILL.md
packages/openclaw-plugin/skills/orchestrate/SKILL.md
packages/openclaw-plugin/skills/proposal-reviewer/SKILL.md
packages/openclaw-plugin/skills/proposal/SKILL.md
packages/openclaw-plugin/skills/quick-dev/SKILL.md
packages/openclaw-plugin/skills/review/SKILL.md
packages/openclaw-plugin/skills/task-reviewer/SKILL.md
packages/openclaw-plugin/skills/yolo/SKILL.md
plugins/chorus/skills/brainstorm/SKILL.md
plugins/chorus/skills/chorus-proposal-reviewer/SKILL.md
plugins/chorus/skills/chorus-task-reviewer/SKILL.md

Metadata

Files
0
Version
96a2f67
Hash
ced6e0be
Indexed
2026-07-25 08:34

Главная - Вики-сайт
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-08-20 07:47
浙ICP备14020137号-1 $Гость$