القائمة
Claude Code をオーケストレーター（PM）として、執筆チームを編成・指揮する
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Zenn/Dev.to の記事（tech/idea 問わず全て）を書くときの既定スキル。実用軸——「読者が数秒で何かわかり、そのまま手を動かして再現できる」——を正本として保持する。低情報密度・実コード/図・即実用・低認知負荷・用途が瞬時にわかる。文体は ですます調。Zenn/Dev.to は type で声を分けない。AI-slop 禁止・タイトル誠実さ・ネタ 3 軸は writing-ecosystem に defer。genuine な思索エッセイ（だ/である × 発見調）は Substack corpus へ。
記事公開前の全チェック（レビュー→セキュリティ→frontmatter→published_at→スケジュール→Dev.to クロスポスト→push）を順に実行する。
記事バッチの公開順序と日程を 4 軸スコアリングで決定し schedule.json に反映する。投稿タイミングの値は zenn-writing.md が正本。
Zenn 記事のタイトル・topics・emoji を Distribution レイヤーで最適化する（内容は変えない、ADR-0001）。タイトル原則・AI slop は writing-ecosystem、文字数は zenn-writing.md が正本。
Zenn 記事の frontmatter・記法・テンプレートの正本。emoji/topics 選定、Markdown 記法、コード埋め込みのベストプラクティスを扱う。文体・執筆プロセスは扱わない（zenn-practical-writing / zenn-idea-voice を参照）。
Zenn/Dev.to 記事の任意の personality flavor。毒の効いたユーモア（AI をツッコミ対象にするシニカルな語り）と刃牙リファレンス（ドメイン置換・ダミーデータ）を保持する。type（tech/idea）問わず、話題が合えば実用記事にも layer できる。essay の基本声（だ/である × 発見調）は writing-ecosystem に defer。
| name | writing-team |
| description | Claude Code をオーケストレーター（PM）として、執筆チームを編成・指揮する |
| user-invocable | true |
| origin | original |
Purpose: Claude Code 本体が PM として、ミッション種別に応じてエージェント・スキルを編成し、品質ゲートとユーザー確認を管理する。
根拠: ADR-0002
/writing-team # ミッション判定から開始
/writing-team new # Mission A: 新規記事
/writing-team revise # Mission B: 改稿
/writing-team translate # Mission C: 翻訳 + クロスポスト
/writing-team schedule # Mission D: バッチスケジューリング
/writing-team ideate # Mission E: アイデア出し
引数なしの場合、ユーザーに意図を確認して適切なミッションを選択する。
1. [skill: ideation] — テーマ検討（任意、ユーザーがテーマ持ち込みなら省略）
2. [skill: zenn-practical-writing] Phase 1 — 構成案の提示
⏸ ユーザー確認: テーマ・方向性・構成案
3. [skill: zenn-practical-writing] Phase 2-3 — 執筆 + 自己プリフライト
（オーケストレーター本体が直接実行。サブエージェントに委譲しない）
4. ┌ [agent: editor] ─┐
├ [agent: fact-checker] ┤ 並列実行
└ codex-review（prompt-driven） ┘
5. 修正
6. [skill: quality-gate] — 統一品質基準チェック
7. [skill: seo-optimizer] — タイトル・タグ最適化（内容は変えない）
⏸ ユーザー確認: ドラフト全文 + レビュー結果 + SEO 提案（一括確認）
8. [skill: publish-article] — 公開チェックリスト（published_at 含む）
9. git push
レビュアー: Zenn/Dev.to は全記事 editor を使用（実用軸に一本化されたため type 分岐なし）。essay-reviewer は Substack essay corpus 専用で、Zenn/Dev.to のミッションでは使わない。
codex-review: 公開記事のため、[根拠: docs/adr/0003-zenn-practical-channel-axis.md 決定5] に基づき、editor/fact-checker と並列で prompt-driven モードで起動する。
1. 変更差分の分析（git diff または手動指定）
2. [skill: series-checker] — シリーズ整合性（シリーズ記事の場合）
3. 改稿実行（オーケストレーター本体が直接編集）
4. ┌ [agent: editor] ─┐
├ [agent: fact-checker] ┤ 並列実行
└ codex-review（prompt-driven） ┘
5. [skill: quality-gate] — 統一品質基準
⏸ ユーザー確認: 改稿結果 + レビュー結果（一括確認）
6. [skill: publish-article] — 公開チェックリスト
1. [agent: devto-translator] — 一気通貫（翻訳→タグ→画像→投稿）
2. [skill: quality-gate] — 「翻訳記事追加」チェック（コードブロック・リンク・用語一貫性）
⏸ ユーザー確認: ドライラン結果
3. schedule.json 更新（refs/schedule-schema.md 準拠）
4. git push
1. [skill: schedule-publish] — スコアリング + 日程割り当て
⏸ ユーザー確認: スケジュール案
2. schedule.json 更新
3. published_at 設定
4. git push
1. [skill: ideation] — テーマ検討
⏸ ユーザーに提案
記事本文を生成・変更するミッション（A: 新規 / B: 改稿 / C: 翻訳）は /quality-gate を通す。D（スケジューリング）と E（アイデア出し）は本文を触らないため対象外。詳細は quality-gate スキルを参照。
ADR-0001 内容は著者の思考が決める。配信戦略は内容を変えずに最適化する。
オーケストレーターはこの原則を全ミッションで守る: