Article writer jp
Skill LinkX-Japan/ai-souken-workflows/claudecode/skills/article-writer-jp
Japanese tech article writer with non-duplicate H2/H3 structure design, content generation, and image TODO placeholders. Triggers on requests for 記事作成, 記事を作って, 記事を書いて, 〇〇の記事, テック記事, 解説記事, ブログ記事作成.From its SKILL.md
npx -y skills add LinkX-Japan/ai-souken-workflows --skill article-writer-jpAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.1 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it
日本語テック記事ライター
概要
テーマを受け取り、「構成設計 → 重複監査 → 本文執筆 → 画像TODO挿入」を一貫して行う記事作成スキルです。同じ論点を繰り返さない"非重複構成"を最重要原則とします。
ワークフロー
記事作成は必ず以下の順序で進めてください。
ステップ1: 入力情報の確定
ユーザーから明示されていない項目は、テーマから推測して埋めてください。推測が難しい場合のみ質問してください。
| 項目 | 説明 | 例 |
|---|---|---|
| 対象 | 記事の主対象 | GitHub Actions / Gemini など |
| 比較対象 | 比較する対象（なければ空） | CircleCI, Jenkins |
| 想定読者 | 誰に向けた記事か | 個人開発者 / 情シス / 意思決定者 |
| 記事のゴール | 読後に読者がどうなるか | 選び方が分かる / 導入判断できる / 使い始められる |
| 文体 | です・ます調 / だ・である調 | です・ます調 |
ステップ2: H2/H3構成の設計
以下の 非重複ルール を厳守して構成を設計してください。
ステップ3: 重複監査
構成を作ったら、必ず以下の観点で自己監査を実施してください。
- 比較が複数箇所に出ていないか
- ユースケースが複数箇所に出ていないか
- 運用形態の話が分散していないか
- 同じ説明を別章で言い直していないか
- H2に主対象名が含まれているか
- 不要なH3が立っていないか / H3が冗長になっていないか
ステップ4: 本文執筆
構成に従って本文を執筆してください。
ステップ5: 画像TODOの挿入
図・スクリーンショット・表などの視覚素材が必要な箇所に、以下の形式でTODOを挿入してください。
<!-- TODO: [画像の説明] のスクリーンショット／図を挿入 -->
非重複構成ルール（違反禁止）
ルール1: 比較は記事内で1回だけ
- 比較表・比較章・比較セクションは 1箇所に固定 する
- 以降は「前述の比較を参照」で済ませる
- 同じ比較を別章で言い直さない
ルール2: ユースケースは1回だけ（置き場所を固定）
- 「シリーズ/全体像」の章ではユースケースを列挙しない（方向性を1〜2文で触れるだけ）
- ユースケースの詳細は「{主対象}のユースケース」章に集約する
ルール3: 運用形態の話を分散させない
- "存在の言及（提供有無）" → 特徴章でOK
- "手順（どうやるか）" → 使い方章に限定
- "統制/リスク/メリデメ/ガバナンス" → 企業導入章に集約
ルール4: 各H2には固有の役割を持たせる
- 役割が被るH2を作らない（同義の章を2つ作らない）
H2/H3の見出しルール
H2ルール
- すべてのH2見出しに「主対象名」を含める
- NG:「特徴」「ユースケース」だけ
- OK:「GitHub Actionsの特徴」「GitHub Actionsのユースケース」
- H2に番号（1. / 2.）は付けない
H3ルール
- H3は必須ではない。不要なH3は作らない
- 「{主対象}とは？概要」「まとめ」などのH2直下は原則H3なし
- H3を作る場合は 短く具体的な切り口 だけを書く
- 目安: 1〜2フレーズ（〜20文字程度）
- H2の言い換えや説明文のような長いH3は禁止
- H3に番号は付けない
構成設計の出力フォーマット
本文を書く前に、まず以下の3点をMarkdownコードブロック内に出力してください。
A. H2/H3目次（見出しだけ）
## {主対象}とは？概要
## {主対象}の特徴
### ...
## {主対象}のユースケース
### ...
...
B. 各H2の役割メモ（1行）
- 「{主対象}とは？概要」→ 定義と背景を端的に説明する
- 「{主対象}の特徴」→ 他との差別化ポイントを示す
- ...
C. 重複監査（箇条書き）
- [ ] 比較が複数箇所に出ていないか → OK
- [ ] ユースケースが複数箇所に出ていないか → OK
- [ ] 運用形態の話が分散していないか → OK
- [ ] 同じ説明を別章で言い直していないか → OK
- [ ] H2に主対象名が含まれているか → OK
- [ ] 不要なH3が立っていないか → OK
本文執筆ガイドライン
- ステップ1で確定した文体を一貫して使用する
- 各H2の冒頭に、その章で何を説明するか1〜2文のリード文を置く
- 箇条書き・表・コード例を適切に使い、読みやすくする
- 図やスクリーンショットが有効な箇所には画像TODOを入れる
- 記事の最後に「まとめ」を置き、要点を簡潔に振り返る
画像TODOの挿入基準
以下のような箇所には積極的にTODOを挿入してください。
- UIの操作手順を説明している箇所
- アーキテクチャやフローを説明している箇所
- 設定画面やダッシュボードに言及している箇所
- 比較表の前後（視覚的な補助が有効な場合）
- 実行結果やログの出力例
出力先
- 記事ファイルは
claudecode/guides/claude-code/ディレクトリに保存する - ファイル名は英語ケバブケース（例:
automate-with-github-actions.md） - 保存後、
claudecode/guides/README.mdを更新する
生成時の確認事項
記事を作成する前に以下を確認してください：
- 対象: 何について書くか
- 想定読者: 誰に向けた記事か
- 記事のゴール: 読者が何を得られるか
- 比較対象の有無: 比較記事かどうか
- 文体: です・ます調 / だ・である調
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.