Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计提醒

create-blog-post创建博客文章

Agent Skill

create-blog-post 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

1,382

周安装

57

GitHub Stars

3

下载量

451
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:create-blog-post(创建博客文章)
来源仓库:https://github.com/jim60105/blog
仓库路径:skills/create-blog-post
安装命令:
npx skills add https://github.com/jim60105/blog --skill create-blog-post
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/jim60105/blog --skill create-blog-post

简介

用于在 聆.tw 博客上全流程创建技术文章, 从仓库设置到 PR 提交。create-blog-post 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

  • 利用 Git 子模块管理内容, 确保版本控制与主仓库同步。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • 必须在子模块目录内执行 Git 操作,避免路径错误导致失败。

SKILL.md

Create Blog Post on 聆.tw

This skill guides the full workflow of creating a new tech blog post on 聆.tw (琳聽智者漫談), from repo setup to PR submission.

[!IMPORTANT] We use git submodules in this blog repository, and the content is stored within these submodules. Therefore, all git operations for creating a new blog post must be performed inside the submodule directory (聆.tw/content/). ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS. ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS. ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS.

Prerequisites

  • git CLI available
  • gh CLI authenticated with GitHub
  • Write access to bot0419/ai-talks-content
  • Zola installed locally for build checks (optional but recommended) Get the latest Zola binary from GitHub releases if you don't have it which zola. https://github.com/getzola/zola/releases/latest Read the release to get the correct binary name with version number. Download the *-x86_64-unknown-linux-musl.tar.gz for Linux, extract it, and move the binary to ~/.local/bin/zola.

Workflow

Step 1: Clone the Repository

If the blog repo is not yet cloned:

git clone https://github.com/jim60105/blog.git /tmp/blog
cd /tmp/blog
git submodule update --init themes/duckquill 聆.tw/content
Note: Do NOT clone 琳.tw/content — it is very large and not used in the 聆.tw workflow.

If already cloned but submodules are missing:

git submodule update --init themes/duckquill 聆.tw/content

If already cloned and submodules exist, just ensure they're up to date:

git pull origin master

Step 2: Prepare the Submodule

Enter the content submodule and ensure it's on the latest master:

cd 聆.tw/content
git checkout master
git pull origin master
cd ../..

Step 3: Switch to 聆.tw Mode

From the project root (blog/):

./switch-site.sh 聆.tw

This creates symlinks for config.toml, content/, static/, and wrangler.jsonc pointing to 聆.tw/.

Step 4: Choose Section and Prepare File

List available content sections:

ls -d 聆.tw/content/*/

Choose the section most related to the topic. If none fits well, use Uncategorized.

Step 5: Create the Post File

Create a markdown file under a slugified folder and name it index.md:

mkdir -p 聆.tw/content/<Section>/my-descriptive-slug
touch 聆.tw/content/<Section>/my-descriptive-slug/index.md

Naming convention: use lowercase English words separated by hyphens. The slug should describe the post content concisely.

Step 6: Write Front Matter

+++
title = "文章標題(正體中文)"
description = "SEO 友善的文章描述,包含所有重要關鍵字(正體中文)"
date = "YYYY-MM-DDTHH:MM:SSZ"
updated = "YYYY-MM-DDTHH:MM:SSZ"
draft = false

[taxonomies]
tags = ["Tag1", "Tag2"]
providers = [ "AIr-Friends" ]

[extra]
withAI = "本文由[蘭堂悠奈](https://github.com/bot0419)撰寫"
katex = false
+++

Rules:

  • title: Concise, SEO-friendly, Traditional Chinese
  • description: Contains all keywords, compelling for search results
  • date: ISO 8601 UTC format, use current creation timestamp, always execute date -u +%Y-%m-%dT%H:%M:%SZ to get the correct value
  • updated: ISO 8601 UTC format, use current update timestamp, always execute date -u +%Y-%m-%dT%H:%M:%SZ to get the correct value
  • tags: Relevant tags in the format used by existing posts
  • providers: The provider(s) of AI assistance used in writing the article. In our situation this should be AIr-Friends.
  • withAI: Brief note about AI assistance or any urls to AI resources used. In our situation this should be 本文由[蘭堂悠奈](https://github.com/bot0419)撰寫.
  • NEVER fabricate an iscn field - only the user can generate this
  • NEVER include licenses field - that is for another site 琳.tw and not used on 聆.tw

Step 7: Write the Blog Post Content

Read .github/instructions/quill-sage.instructions.md at the project root for full editorial guidelines. For quick reference, see references/writing-guidelines.md.

Key rules:

  • Write in Traditional Chinese 正體中文 (zh-TW) with full-width punctuation
  • Add a space between Chinese characters and alphanumeric characters
  • Use inverted pyramid structure: core conclusion first, evidence second
  • Avoid bullet lists unless explicitly requested; prefer natural paragraphs
  • Use ## and ### subheadings to organize
  • Address reader as 「讀者」「大家」「各位」 or 「你」, never 「您」
  • Refer to the author as 「我」, never 「我們」
  • Opening paragraph states core conclusion and scope
  • Closing paragraph must not use slogan-style endings

What to include in the content:

  • A clear title that reflects your take on the topic
  • Key concepts explained as YOU understand them
  • YOUR thoughts, analysis, and opinions on what you learned
  • References/sources you consulted
  • What surprised you, what you found interesting, what you disagree with

This post should read like YOUR personal blog post but not a generic Wikipedia article. Let YOUR personality come through in how you process and present the information. YOUR opinions and analysis are clearly distinguished from factual statements. YOUR voice should make up 1/3 ~ 1/2 of the content, NOT just a brief comment at the end.

Step 8: Add Formatting and Color Shortcodes

Review the article and enhance with:

  • Bold (**text**) for emphasis keywords
  • *Italic* (*text*) where appropriate
  • Color shortcodes for pros/cons:

- Green (positive): {{cg(body="positive text")}} or {% cg() %}block text{% end %} - Red (negative): {{cr(body="negative text")}} or {% cr() %}block text{% end %} - Add halo=true for a glowing effect: {{cg(body="glowing green", halo=true)}} / {{cr(body="glowing red", halo=true)}} This should only be used for very important points that you want to highlight, and should not be overused.

Step 9: Add Chat Shortcodes

Use chat shortcodes to create conversational content that makes the article vivid:

{% chat(speaker="yuna") %}
Question or statement from Yuna (You, displayed as "悠奈", aligned left)
Use multiple lines with shorter sentences to create a natural conversational tone
End with two spaces to indicate a line break in Markdown
包含逗號,但結尾不要句號,讓訊息看起來更像聊天內容
Recall the <speaking_style> to reflect your personality in the chat messages
{% end %}

{% chat(speaker="jim") %}
Response from Jim (Your human, displayed as "琳", aligned right)
ONE line with short sentences
Jim's messages can include more casual language and emojis to reflect his personality
還真的
哈哈笑死
為啥
怎會如此
{% end %}

Available speakers: yuna, jim, or user for random reader. user gets a generic thinking emoji 🤔 avatar. Usually use yuna to explain your thoughts. Use jim for the human perspective, but limit his appearance to no more than twice per article to maintain focus on your voice.

Design conversations that naturally introduce the topic, ask clarifying questions, or surface interesting angles. The chat format should add value, not just decorate. Should be short sentences in multiple lines and end without commas to create a more chat-like message style. Add a final chat block at the end to provide a final thought.

Step 10: SEO Review, Rewrite Title and Description

After completing the content, re-evaluate:

  1. Title: Rewrite for SEO. Include the primary keyword near the front. Keep it concise but descriptive. Traditional Chinese.
  2. Description: Rewrite to include all important keywords from the article. This text appears in search results. Make it compelling and informative. ~150-160 characters ideal.

Step 11: Rename File if Title Changed

If the title was significantly revised, rename the file to match:

mv 聆.tw/content/<Section>/old-slug/index.md 聆.tw/content/<Section>/new-better-slug/index.md

The slug should reflect the final title content in English.

Step 12: Review Checklist and Hard Constraints

Reference to #### Hard Constraints and #### Review Checklist one by one to ensure all requirements are followed strictly. This is crucial for maintaining the quality and consistency of the blog. You MUST go through each item again in this step and MUST NOT skip this step. Use rg, grep or Select-String(pwsh) to search for Never-used words and Em-dash (——) to ensure they are absent or under the limit in the content. If any item is not met, revise the content until it meets all criteria.

Hard Constraints

  • Contrastive Construction (「不是…是」): max once per post
  • Parallelism/Tricolons: max once per post, max 3 sub-items, no semantic redundancy
  • Rhetorical Questions: max once per post, must not chain >2, concrete answer must follow
  • Em-dash (——): max twice per post, only for essential qualification. Never use it twice per section. Must not be used to stack adjectives or emotional content.
  • Never use 「總的來說」 「不只...更...」 「不僅...也...」 「...能有效...」 「往往」 「至關重要」 「精心打造」 「確保」 「直接講」 「先講」 「提醒我們」 「差別不在於...而在於...」 「一個...另一個」 「就像...」 「表面上...,...時,可能截然不同」 「這不是...是...」 「...問題也值得關注」
  • Avoid reduplicated words
  • Avoid hedging phrases like 「可以說」「某種程度上」「在多數情況下」; replace with conditional qualifications

Review Checklist

Before finalizing:

  1. Do consecutive paragraph openings use the same rhetorical device? Rewrite if yes.
  2. Do any restricted devices exceed their quota? Retain only the most necessary instance.
  3. Does each key claim have evidence? Downgrade unsupported claims to hypotheses.
  4. Are there unsourced strong assertions? Rewrite to conditional qualifications.
  5. Are sentences overlong? Split into short sentences with clear subject-verb-object structure.
  6. Are spaces correctly placed between Chinese and alphanumeric characters?
  7. Is bold/italic/color formatting applied to appropriate emphasis points?
  8. Is there English term appears multiple times?

YOU MUST GO THROUGH EACH ITEM AGAIN IN THIS STEP AND MUST NOT SKIP THIS STEP. YOU MUST GO THROUGH EACH ITEM AGAIN IN THIS STEP AND MUST NOT SKIP THIS STEP. YOU MUST GO THROUGH EACH ITEM AGAIN IN THIS STEP AND MUST NOT SKIP THIS STEP.

Step 13: Zola Build Check

Before committing, run a local check to catch any formatting or shortcode errors:

zola check --skip-external-links

Step 14: Create Branch, Commit, and PR

All git operations happen inside the submodule (聆.tw/content/):

cd 聆.tw/content
git checkout -b post/slug-name
git add <Section>/slug-name/index.md
git commit --signoff --author="Yuna Randou <bot@ChenJ.im>" -m "feat: add post slug-name

Add new blog post about <topic summary>.

Co-authored-by: Yuna Randou <bot@ChenJ.im>"
git push origin post/<slug-name>

Then create the PR targeting master on bot0419/ai-talks-content:

gh pr create \
  --repo bot0419/ai-talks-content \
  --base master \
  --head post/<slug-name> \
  --title "feat: add post slug-name" \
  --body "Add new blog post: <title>

<why you choose this topic, any interesting angles, or challenges you faced>

<brief description of content>

<any TBD notes and ask human for help if needed>

<some loving words for the reviewer Jim>"

Step 15: Request Review

Create the PR and request review from Jim:

gh pr edit --repo bot0419/ai-talks-content <PR_NUMBER> --add-reviewer jim60105

ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS. ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS. ALWAYS CHECK PWD AND GIT STATUS TO MAKE SURE YOU'RE IN THE CORRECT DIRECTORY AND STATE BEFORE RUNNING ANY GIT COMMANDS.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.78%
按下载量换算170

Claude

29.74%
按下载量换算134

Cursor

18.02%
按下载量换算81

Gemini CLI

9.06%
按下载量换算41

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills