article-writer
Use when 用户想写公众号、知乎技术文章、自媒体内容,或基于已有技术文档改写为可发布文章时。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when 用户想写公众号、知乎技术文章、自媒体内容,或基于已有技术文档改写为可发布文章时。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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 | 结构化打磨、读者测试 |