Article writer jp
Skill LinkX-Japan/ai-souken-workflows/claudecode/skills/article-writer-jp
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.
What its author says it does
Copied from the file, not written here
Japanese tech article writer with non-duplicate H2/H3 structure design, content generation, and image TODO placeholders. Triggers on requests for 記事作成, 記事を作って, 記事を書いて, 〇〇の記事, テック記事, 解説記事, ブログ記事作成.
SKILL.md
6.1 KB, 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を更新する
生成時の確認事項
記事を作成する前に以下を確認してください：
- 対象: 何について書くか
- 想定読者: 誰に向けた記事か
- 記事のゴール: 読者が何を得られるか
- 比較対象の有無: 比較記事かどうか
- 文体: です・ます調 / だ・である調