article-writer
Use when 用户想写公众号、知乎技术文章、自媒体内容,或基于已有技术文档改写为可发布文章时。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Menü
Use when 用户想写公众号、知乎技术文章、自媒体内容,或基于已有技术文档改写为可发布文章时。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Hard gate before merging into a protected branch: run Parts A→B→C→R→D (OpenSpec archive association, rebase/conflict pre-check, coverage preference, pr-code-review with optional light depth via pr-review-gate, tip-pin merge). Do NOT merge while an associated OpenSpec change is still active; do NOT skip on a direct "merge MR" command. Triggers — 「合并 tip」「merge tip」「合并纪律」「push 后合并」「archive 合入」「合并前门控」「rebase 检查」「冲突预检」「合并前 rebase」「先 archive 再 merge」「合并前 code-review」 / merge discipline, archive-before-merge, rebase pre-check, coverage gate, pr code review before merge.
Dual-axis (Standards∥Spec) multi-perspective PR review with confidence ≥80 filtering, severity calibration, plan alignment, and optional GitHub/GitLab review comment. Best-of: Claude /code-review pipeline + mattpocock dual-axis + Superpowers plan/severity habits. Triggers — 「PR 代码审查」「审查这个 PR」「code-review」「/code-review」「审 PR」「pull request review」「双轴审查 PR」 / pr code review, review this PR. Do NOT use as a name alias for mattpocock code-review or Superpowers requesting-code-review.
Optional code-delivery discipline: decide whether this run needs commit + PR/MR, then commit/push via git-commit and create or update the PR/MR. Use after verification (and OpenSpec archive when the host requires it) and before feature-branch-closeout. Do NOT use for protected-branch merge (merge-discipline) or release→main shipping (git-release-finish). Triggers — 「提交并开PR」「提交并开MR」「代码交付」「开PR」「开MR」「delivery-discipline」 / deliver code, commit and open PR, open merge request.
Post-verification feature-branch closeout menu: after verify (and archive when applicable), and after optional delivery-discipline when code delivery is needed, present PR / merge / keep / continue options; optional worktree cleanup; selecting merge MUST load merge-discipline Parts A→B→C→R→D; keep/continue MUST NOT trigger merge gates. Open/update PR delegates to delivery-discipline. Triggers — 「分支收尾」「feature 收尾菜单」「合入或保留分支」「branch closeout」 / feature branch closeout, post-verify branch menu. Do NOT use as a name alias for finishing-a-development-branch.
End-to-end Jira bug-fix workflow (stages 0-10), driven by a single Jira link, from intake through PR/MR merge and Jira writeback. Manual mode (default) pauses for confirmation between stages; auto/force modes run end-to-end. Triggers — 「修复这个 bug [URL]」「帮我修复 [URL]」「jira-fix [URL]」「自动修复 [URL]」「强制修复 [URL]」「继续修复」「从上次继续」 / fix this bug, jira-fix, auto fix, force fix, resume fix. Do NOT use for batch fixes across multiple issues — use jira-fix-batch instead.
OpenSpec-flavored end-to-end Jira bug-fix workflow that persists root cause, behavior change, fix plan, verification, and archive into OpenSpec artifacts (openspec/changes/<name>/, archived into openspec/specs/) instead of leaving them only in chat context or Jira comments. Use when a Jira issue needs long-term behavioral-contract traceability, team review, or auditability. Do NOT use for a quick fix needing no traceability — use jira-fix-workflow instead. Triggers:「opsx-jira-fix」「OpenSpec Jira 修复」「规范化修复 Jira」「opsx修复Jira」「Jira OpenSpec 修复」「opsx自动修复Jira」「用OpenSpec修复Jira」「opsx-jira-fix-workflow」 / opsx jira fix, OpenSpec Jira fix workflow.
| name | article-writer |
| version | 1.0.0 |
| user-invocable | true |
| description | Use when 用户想写公众号、知乎技术文章、自媒体内容,或基于已有技术文档改写为可发布文章时。 |
| triggers | ["写公众号","写知乎","技术文章"] |
4 步流程:搜索资料 → 撰写文章 → 生成标题 → 排版优化。适用于公众号、知乎、掘金等平台。REQUIRED: 全文应用中文标点规范(见 Step 2 格式区)。
When NOT to use: 纯学术论文(用 ml-paper-writing)、小说创作(用 writer-memory)、项目内文档(用 doc-coauthoring)
关键动作:必须先读取项目上下文,再读取源材料,最后确认目标平台。
主题需补充时用 WebSearch:并行多源、优先最新、深度总结。若用户已提供完整源材料,可跳过。
| 类型 | 框架 |
|---|---|
| 技术科普 | 科普 → 案例 → 总结 |
| 原理剖析 | 表象 → 深入分析 → 结论 |
| 使用教程 | 效果展示 → 步骤教学 → 升华 |
| 工具测评 | 介绍 → 使用过程 → 评测结论 |
通用结构:效果展示 → 问题描述 → 步骤教学 → 升华总结
中文标点规范(全文严格遵守):
| 标点 | 使用 | 不使用 |
|---|---|---|
| 逗号 | , | , |
| 句号 | 。 | . |
| 分号 | ; | ; |
| 冒号 | : | : |
| 问号 | ? | ? |
| 感叹号 | ! | ! |
| 括号 | () | () |
| 书名号 | 《》 | - |
例外(保持原文):技术术语(JavaScript、React 等)、代码/命令、URL/路径、版本号/数字。书名号内的英文标点可保留(如《JavaScript: The Good Parts》)。
代码块前后留白、语法高亮。
生成 5 个标题,要素:痛点明确、数字吸引、结果导向、情绪调动、悬念设置。
| 要素 | 示例 |
|---|---|
| 痛点 | 「还在手动切换 Node?」 |
| 数字 | 「3 分钟」「5 个技巧」 |
| 结果 | 「效率暴涨 10 倍」 |
可选 Vibe Coding 格式:《Vibe Coding 10X 提效:[成果],[痛点]》
| 阶段 | 关键动作 |
|---|---|
| 准备 | 读项目上下文、源材料、确认平台 |
| 搜索 | 需补充时 WebSearch,有源材料可跳过 |
| 撰写 | 选结构模板、1000–1500 字、中文标点规范 |
| 标题 | 5 个、含痛点/数字/结果 |
| 排版 | 3–5 行/段、配图位、代码留白 |
| 错误 | 修正 |
|---|---|
| 跳过项目上下文 | 先读再写,保持风格一致 |
| 忽略中文标点规范 | 中文标点、术语规范必用 |
| 标题泛泛 | 必须含痛点或数字或结果 |
| 有源材料仍大搜 | 以源材料为主,仅补充验证 |
| Skill | 作用 |
|---|---|
| wechatsync | 多平台同步 |
| doc-coauthoring | 结构化打磨、读者测试 |