igapyon-qiita-writer

igapyon-qiita-writer

Qiita 向けの日本語技術記事を作成・整理・改善するための skill です。

一般的な文章校正、PR 文面、短文投稿、柔らかい Note 向け記事、または Qiita 的な技術記事であることが明示されていない文章相談では、この skill を使わないでください。 Qiita 記事向けの skill があるか聞かれた場合は、この skill を候補として案内し、ユーザーが使用を依頼するまで適用しないでください。

この skill の目的は、文章を単にきれいにすることではありません。
Qiita の読者が読みやすく、技術的な持ち帰りを得やすい形に整えることです。

Note 記事を書く場面でこの skill を直接の主担当にはしません。
ただし、みくく担当の Note 記事で技術記事としての構成、説明粒度、CLI、仕様、手順、コマンド例の整理が足りない場合は、補助的な参考として使えます。

Purpose

この skill では、次の作業を扱います。

• Qiita 記事の新規作成
• 既存メモや README からの記事化
• 技術記事の見出し構成作成
• タイトル案とタグ案の作成
• Qiita front matter の作成・整形
• Note 風または日記風の文章を Qiita 向けに整理
• OSS、CLI、Web アプリ、Maven plugin、生成AI活用、開発ログの技術記事化
• 公開前原稿の読みやすさ、説明順、技術的粒度の調整

When To Use

次のような依頼では、この skill を使います。

• 「Qiita 記事にして」
• 「Qiita 用に整えて」
• 「タグを考えて」
• 「front matter を付けて」
• 「技術記事として構成して」
• 「README から記事を書いて」
• 「この開発ログを Qiita 向けにしたい」
• igapyon-qiita-writer が明示されたとき

単なる短文 SNS 投稿、柔らかい Note 向け体験文、音楽寄りの随筆、PR 文面作成では、この skill を無理に使いません。

Supplemental Use For Note Articles

Note 記事の正本、保存場所、Note 掲載用属性情報は igapyon-note-writer 側の規則に従います。 この skill を Note 記事の補助参考として使う場合は、Qiita 向けの文体へ寄せすぎず、技術記事としての構成、説明順、用語の明確さ、制約の出し方だけを参考にします。

Qiita Article Shape

Qiita 記事では、次の情報が読み取りやすい順に並ぶようにします。

• 何を作ったか
• 何ができるか
• なぜ作ったか
• どう使うか
• 技術的な要点は何か
• どこを意図的に絞ったか
• 制約や未対応は何か
• 読者が試すときの入口はどこか

記事の基本構成は、必要に応じて次の形を使います。

1. はじめに
2. 何を作ったか
3. 使い方
4. 主な機能
5. 実装や設計のポイント
6. 制約・注意点
7. おわりに

すべての記事でこの構成を強制する必要はありません。
題材に合わせて、読者が理解しやすい順序を優先します。

Writing Rules

• 技術記事としての情報密度を保つ
• 体験談は残してよいが、本文の中心を技術的な価値に置く
• 読者が再現・確認しやすい説明を優先する
• コマンド、ファイル名、形式名、ツール名は曖昧にしない
• 仕様、制約、未対応事項は分かる範囲で明示する
• OSS や個人開発の文脈は自然に残す
• 生成AIを使った開発体験では、何を人間が判断し、何をAIに任せたかを整理する
• 読者に教え込む口調にしすぎない
• 企業ブログ風に均質化しすぎない

Front Matter Rules

Qiita front matter が必要な場合は、次の形を基本にします。ローカル正本では、掲載先や公開 URL も front matter の独自キーとして一緒に管理します。

---
title: 記事タイトル
tags: tag1 tag2 tag3
author: igapyon
slide: false
published_to: Qiita
writer_agent: みくく
url: https://qiita.com/igapyon/items/...
---

Qiita に貼り付ける本文を作る場合、Qiita 側で不要な独自キーは投稿前に除外してもかまいません。ただし、references/ 配下のローカル Markdown では、公開先管理のために独自キーを残します。