القائمة
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | editorial-swarm |
| description | 技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。 |
| argument-hint | <article path> [target reader profile] |
| allowed-tools | ["Agent","TeamCreate","TeamDelete","SendMessage","TaskCreate","TaskUpdate","Read","Write","Edit","AskUserQuestion","Glob","Grep","WebSearch","WebFetch","Bash"] |
| model | sonnet |
| effort | high |
| context | fork |
4 人のレビュアー（anti-ai-slop, fact-checker, narrative-critic, reader-advocate）が peer-to-peer でドラフトをレビューし、severity 付きの提案を集約する。discovery-council の「文章版」。
共通プロトコル: ハンドオフの 4 原則（path 渡し優先 / 長文上・指示下 / coverage-first / quote-first）は
facets/policies/plan-handoff.mdを参照。各 reviewer prompt は閾値カットなしで全件返し、自動 apply は集約側 (Step 4) のみが判断する。
$ARGUMENTS
| 使う | 使わない |
|---|---|
| ドラフトが概ね完成（v0.9 以上）、最終推敲したい | 構成から考える → まず手で書く |
| Zenn / note / ブログ用の技術記事 | 社内メモ・議事録（レビューコスト過剰） |
| 対象読者が明確 | 読者不明 → まず /deep-interview 等で固める |
| 3 ラウンド程度で収束を期待できる品質 | 大規模書き直し → 手で構造から見直す |
AskUserQuestion で以下を一括確認:
対象記事が存在しない場合は AskUserQuestion で path を再確認する。
mkdir -p .editorial
TeamDelete:
team_name: "editorial" # エラーが出なければスキップ
TeamCreate:
team_name: "editorial"
description: "Editorial Swarm: 記事の並列レビュー"
4 つのレビュアーを同時 spawn。各エージェントは facets/policies/council-output-schema.md の 共通 Council JSON schema に従う JSON オブジェクト 1 つを返す:
{
"reviewer": "anti-ai-slop",
"schema_version": "1",
"summary": "1-2 文の総評",
"findings": [
{
"id": "F001",
"category": "ai-slop",
"line_range": "12-15",
"issue": "問題の要約",
"fix": "具体的な修正案（diff 風でなくテキスト置換可能な形）",
"confidence": 85,
"severity": "high",
"quotes": ["問題箇所の引用 30 文字程度"]
}
],
"memo": "free-form notes（任意）"
}
reviewer 別の category 値: ai-slop / fact / narrative / reader-fit。
file フィールド: 記事ファイルが 1 つなので各 finding では省略可（reviewer ごとに memo で記事 path を記録）。
4 reviewer（anti-ai-slop / fact-checker / narrative-critic / reader-advocate）の prompt テンプレートは facets/references/editorial-swarm-prompts.md に集約（段階的開示）。
Read してそのまま各 agent に渡す（$ARTICLE_PATH / $READER_PROFILE を実値に置換）。各 prompt は 30 行以内・出力は上記 Council JSON schema 準拠。
4 エージェントを 1 メッセージ内で同時 spawn。Agent tool の subagent_type: general-purpose でよい。各 agent の output (Council JSON schema 準拠の 1 オブジェクト) は .editorial/round-N/reviewer-X.json に保存する。
各 reviewer の JSON を読み込み、schema_version == "1" を確認した上で findings[] 配列を flatten し、統合テーブル を作成:
| # | reviewer | category | line | severity | confidence | issue | fix | quotes |
|---|---|---|---|---|---|---|---|---|
| 1 | anti-ai-slop | ai-slop | 12-15 | high | 88 | ... | ... | ... |
衝突検出: 同じ line_range を複数 reviewer が指摘している場合は「conflict」フラグを立てる（自動 apply しない）。
集約結果を .editorial/round-N/findings.md に保存する（good_points と memo も併記）。
reviewer が schema 違反の出力を返した場合は、JSON パースを再実行依頼（最大 1 回）。それでも失敗なら その reviewer のラウンドはスキップ し、.editorial/round-N/skipped.md に [NOTE] schema 違反: <reviewer> を記録。他 reviewer 分の findings はそのまま処理する（1 reviewer 失敗で全体停止しない）。
Step 1 で「自動 apply: low + 非競合のみ」が選ばれた場合:
severity == "low" かつ conflict フラグなしの findings を抽出confidence >= 70 のもののみ自動 apply 対象（confidence 低い low はノイズの可能性が高いので保留）line_range の大きいほうから apply して位置ずれを回避）.editorial/round-N/skipped.md に記録以下を AskUserQuestion で提示:
severity in ("medium", "high") の findings1 件ずつではなく 一度に最大 20 件を checkboxes で 提示（API 制約に応じて分割）。各選択肢には [severity/confidence] reviewer: issue の形で表示し、ユーザーが優先度判断しやすくする。
ユーザーが承認したものだけ Edit で apply。却下したものは .editorial/round-N/rejected.md に理由ごと記録（次ラウンドで重複提案を回避する材料）。
# 現在の記事と originals の diff を保存
jj diff "$ARTICLE_PATH" > .editorial/round-N/applied.diff 2>/dev/null || \
git diff "$ARTICLE_PATH" > .editorial/round-N/applied.diff 2>/dev/null
収束判定:
再ラウンド時は rejected.md を各 reviewer の prompt に「これは既に却下された提案なので重複して出さない」として渡す。
## Editorial Swarm 結果（N ラウンド）
### 確定 apply
- [R1] anti-ai-slop: 〜 (line 12-15)
- [R1] fact-checker: 〜 (line 80)
### ユーザー却下
- [R1] narrative-critic: 〜 (理由: 意図的な構成)
### 未解決（MAX_ROUNDS 到達）
- [R3] fact-checker: 〜（要手動検証）
### 成果物
- 記事: $ARTICLE_PATH
- 各ラウンドの diff: .editorial/round-*/applied.diff
- findings 履歴: .editorial/round-*/findings.md
.editorial/summary.md としても書き出す。
facets/references/editorial-swarm-prompts.md に集約Step 1 の前提確認から開始してください。
新機能を実装まで一気通貫で走らせる action skill。Agent Teams で要件・設計・タスク分解・実装・quality-gate を自動実行し、コードがコミット可能な状態になるまで止まらない（Sisyphus Loop）。auto mode でも planning ではなく action として積極発動する。「実装して」「作って」「機能を追加して」「新機能を作りたい」「要件から実装まで一気に」「計画して」「この機能を実装したい」で発動。
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
完成した plan/design を対話で容赦なく詰問し、実装前に穴を潰す。決定木を1枝ずつ降り、各質問に推奨回答を添える。コードで答えが出る点は聞かず自分で調べて埋める。「grill して」「叩いて」「この設計で大丈夫?」「plan を詰めて」「設計を対話レビュー」で発動。※ ゼロから要件を掘り下げるなら deep-interview、非対話で一括批判レポートなら critic。
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。