writing-artifacts について
断片的な考えを公開可能な成果物に整えるライティングワークフローのスキルです。文書、長文、ビジュアル成果物に対応し、ソフトウェア文書には専用の手順を用います。
主な機能
- 01主題、読者、形式の設定
- 02段階的な素材収集と構成
- 03ジャンルに応じた構成方法
- 04レンダリング前の文章推敲
- 05ソフトウェア文書専用の手順
活用シーン
- 01考えを公開可能な文章に整理
- 02ソフトウェアリポジトリ内の文書作成
- 03HTMLページや図表向けの内容作成
- 04既存文の推敲と変更点の報告
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ohyeh/ agent-scripts --skill writing-artifactsインストール後、Claude Code で/writing-artifactsを入力して読み込まれたか確認します。
詳細
writing-artifacts
生産ラインです。生の思考を受け取り、公開できる成果物に仕上げます。各工程をオーケストレーションします。各工程の手法はそれぞれ独自の SKILL.md に記載されています。その工程に進んだ時点で読み、記憶を頼りに作業してはいけません。
Stage 0 — 枠組みを決める(質問は1ラウンド、その後に進む)
何かを書く前に、3つの点を明確にします。SUBJECT(1文)、READER(誰が理解する必要があるか)、OUTPUT FORMAT です。出力先に応じた既定の形式は次のとおりです。すぐ共有するもの → md · ユーザーが2回見返すもの、または誰かに見せるもの → html ページまたは Artifact · 視覚的な比喩やヒーロー画像が必要なもの → 画像の工程を追加します。ユーザーがすでに形式を指定している場合は、質問しません。
サイズを最初に: 形式を選ぶ前に、コンテンツの規模を見積もります。分量の表(文章、ダッシュボード、図、モーション)と品質基準は artifacts-rules に記載されています。確認を求めずに適用します。
読者プリセット — ELI5: 「5歳児にもわかるように」「とても簡単に」「完全外行」という指定があれば、READER = その分野について何も知らない人、FORMAT = 大きな画像と少ない言葉で伝える Artifact とします。事実は変えずに、表現を簡単にします。根拠となる説明なしに専門用語を使ったり、「簡単に」「ただ」「明らかに」といった表現を使ったりしてはいけません。
ジャンル分岐、この段階で決定: リポジトリ内のソフトウェアドキュメント(README、API ドキュメント、チュートリアル、手順ガイドなど、リポジトリ内に置かれるもの)は、構成の工程を差し替えます。writing-beats/writing-shape の組み合わせの代わりに、Stage 2 で documentation-writing(Eight Rules + Diataxis、docs/ の配置およびリンクのルール)を実行します。Stage 1 の情報収集と Stage 3 の stop-slop による指針は変更しません。それ以外のすべて(問題の説明、インシデント、意思決定、長文の文章など)には、以下の既定の流れを適用します。
Stage 1 — 情報を掘り起こす(広げる)
writing-fragments を使い、題材についてわかっていることをすべて、生の断片として書き出します。根拠、時系列、感情、考えかけの内容などを含めます。まだ構成は考えません。実態が不明瞭なアイデア(既知のインシデントではないもの)については、先に adhd を実行して並行して発想を広げ、その後、残った案を断片化します。
Stage 2 — 構成する(絞り込む)
次から1つだけ選びます。
writing-beats— 読者を何らかの結論へ導く必要がある場合に使います。問題の経緯、インシデントの記録、意思決定の根拠などが該当します。各用語を、それに基づいて展開する前に説明します。writing-shape— 内容がすでにおおむね整理されており、段落ごとに整えるだけでよい場合に使います。
Stage 3 — 推敲する
stop-slop を全工程の基準として読み込んだうえで、下書きを直接推敲します。この段階だけの基準ではありません。無駄な文言、曖昧な表現、AI らしい単調なリズムを排除します。
Stage 4 — 形式に仕上げる(形式の分岐)
md/ 通常の文章 → 推敲済みの文章をそのまま納品します。完了です。htmlページ / Artifact / 図 / 画像 → 完成した文章をコンテンツの要件としてusing-design-skillsに渡し、パイプラインの構成はすべて任せます(権威ある情報源の選定、画像生成への委任、スクリーンショットによる根拠を使った品質確認の反復を担当します)。自分でインラインのスタイルを設定してはいけません。この時点で文章は確定しており、デザインで変えるのはレイアウトであって、文言ではありません。
Stage 5 — 編集内容を報告する(成果物ではなく、同じターン内で)
納品後、変更点と理由を挙げて最大5行を追加します。文ごとではなく、編集の種類ごとに1行とします。説明を補った専門用語、明示した前提、並べ替えた構成、削った内容を挙げます。よりきれいな表現ではなく、問題点を示します。
入力が既存の文章の場合、各行を before → after の形式にし、問題が伝わる最短の箇所を引用します。新規の文章の場合は before の部分を省き、何を、なぜ削ったかを報告します。
この報告は成果物に含めません。
境界
- まず言葉、次にピクセルです。推敲が終わっていない下書きを Stage 4 に進めてはいけません。質の低い文章をデザインし直しても、見栄えのよい質の低い文章になるだけです。
- 前の工程に戻れるのは1回だけです。レンダリングによって構成上の欠落(実際には説明されておらず、可視化できないセクション)が見つかった場合は、そのセクションだけ Stage 2 に戻してから、再度レンダリングします。
- このスキルは、題材に関する文章の成果物を担当します。通常の文章とリポジトリ内のソフトウェアドキュメントの両方が対象です(Stage 0 のジャンル分岐で構成の工程を選びます)。議論から生まれた計画ページは、
artifacts-rules(Plan page)の指示に従って直接作成します。