はじめに
Qiita Tech Festa 2026 の 記事数部門・20記事達成 でもらえる Qiitan ぬいぐるみ が欲しくて、執筆環境を整え始めました（笑）
打算の塊ですが、せっかくなのでその過程を記事に残します。
このリポジトリでは drafts/ で下書き → npm run promote で public/ へ → main push で GitHub Actions が Qiita に投稿、という流れです。
今回はその中から、実際に手を動かして効いた 3つの機能 だけ書きます。
- Qiita CLI で下書きだけ先に preview する運用
- textlint で下書きを機械チェックする手順
- ハッカソン後に残す Skill と捨てる Skill の線引き（使い捨てSkills の記事 の短縮版）
想定読者
- Qiita CLI で GitHub 管理しているが、
drafts/とpublic/の使い分けがまだ曖昧な方 - Cursor で記事を書き始めたが、プレビューや lint を毎回手でやっている方
- Agent Skills を増やしすぎて、何を残すか迷っている方
私の属性
- 30代女性・事務職
- このブログは Qiita CLI + GitHub Actions で運用
- Cursor の
.cursor/skills/に執筆用 Skill を置いて、記事化もその環境の上で進めている
結論
| やりたいこと | このリポジトリでの答え |
|---|---|
| 下書きを Qiita 表示で確認したい |
npm run preview:draft → npm run preview → npm run cleanup:preview
|
| AI 臭を機械でざっくり弾きたい |
npm run lint:draft（textlint） |
| Skill が増えすぎた | 手順の型は残す・大会固有情報は docs に逃がす・中身は見ない前提で捨てる |
投稿そのものは public/ に入ってから main push です。drafts/ だけの変更では Actions は動きません。
リポジトリの全体像
執筆の入口は drafts/ です。ここにある記事は Qiita には出ません。
drafts/NNNN-slug.md … 執筆・推敲（ignorePublish 相当の運用）
↓ npm run promote（ユーザー OK 後）
public/NNNN-slug.md … 投稿対象
↓ git push main
GitHub Actions … qiita publish
.cursor/skills/ には qiita-blog-writing や qiita-cli など、長く使う執筆用 Skill を置いています。
ハッカソン向け Skill とは役割が違う、という話は後半で触れます。
Qiita CLI で下書きだけ先に preview する運用
なぜ drafts/ のまま preview したいか
Qiita CLI の npx qiita preview は、既定では public/ 配下の Markdown を読みます。
下書きを毎回 public/ にコピーして手編集すると、誤って push して投稿 するリスクが上がります。
そこで scripts/preview-draft.ps1 で、一時的に public/_preview-<basename>.md を作る運用にしました。
手順
# 1. 下書きを一時プレビュー用にコピー（ignorePublish: true を付与）
npm run preview:draft -- 0005-cursor-qiita-writing-env
# 2. プレビューサーバー起動（既定 localhost:8888）
npm run preview
# 3. ブラウザで表示確認後、一時ファイルを削除
npm run cleanup:preview
npm run preview:draft がやっていることはシンプルです。
-
drafts/<basename>.mdをpublic/_preview-<basename>.mdにコピー - Front Matter の
ignorePublishをtrueにして、誤投稿の対象外にする
確認が終わったら npm run cleanup:preview で _preview-*.md を消します。
本番の public/ 記事には触れない のがポイントです。
運用で効いたこと
- 顔文字や
:::noteなど、Qiita 固有記法はブラウザ確認が一番早い -
drafts/のまま推敲を回せるので、投稿ゲート（npm run promote→ push）と分離できる - スクショを記事に入れない代わりに、表示崩れだけは preview で潰せる
npm run preview は npx qiita preview のラッパーです。初回は npx qiita login でトークン登録が必要です（Windows では %USERPROFILE%\.config\qiita-cli が無いと ENOENT になるので、先にフォルダを作ってからログインすると楽です）。
textlint で下書きを機械チェックする手順
なぜ textlint か
文章力に自信がないので、構造と機械チェック で品質の下限を上げたい、という動機です。
AI に書かせたあとに「なんか AI っぽい」を人間の目だけで直すのは疲れるので、下書き段階で一度機械に通します。
セットアップ（このリポジトリ）
package.json の devDependencies に次を入れています。
textlint@textlint-ja/textlint-rule-preset-ai-writing
設定はルートの .textlintrc.json だけです。
{
"rules": {
"@textlint-ja/preset-ai-writing": {
"ai-tech-writing-guideline": {
"severity": "info"
}
}
}
}
severity: "info" にしているので、警告として出して止めはしない 運用です。
「全部直さないと npm run promote できない」だと、20記事目指しのときに逆にしんどい（笑）
実行
npm run lint:draft -- 0005-cursor-qiita-writing-env
scripts/lint-draft.ps1 は npx textlint drafts/<basename>.md を呼ぶだけです。
執筆 Skill 側では、執筆後に npm run validate:draft とセットで回す想定にしています。
npm run validate:draft -- 0005-cursor-qiita-writing-env
npm run lint:draft -- 0005-cursor-qiita-writing-env
npm run validate:draft は Front Matter（title・tags など）や内部リンク ID のチェック。
npm run lint:draft は文体寄り、という分担です。
人間が最後に見るポイント
textlint は顔文字の見た目や、自分っぽいユーモアまでは判定しません。
「たたき台の人間らしさ」はリポジトリ内の style-guide.md（.cursor/skills/qiita-blog-writing/references/）のチェックリストで最終調整、という割り切りです。
ハッカソン後に残す Skill と捨てる Skill の線引き
詳細は 使い捨てSkills — ハッカソン用のAgent SkillsをAIに作らせた に書きました。
ここでは このブログ執筆リポジトリとの対比 だけ短くまとめます。
捨てる（使い捨て）側 — ハッカソン Skill
| 残す | 捨てる（メンテしない） |
|---|---|
| Skill の骨格・フェーズ分け | 大会名・審査方式などの固有情報 |
hackathon-summary のような手順の型 |
Skill 内の細部まで人間が読み込むこと |
| 次の大会で流用するテンプレ | 大会終了後の更新 |
ハッカソン向けは 「その場で役に立てば十分」 という割り切りです(ﾉ´∀｀*)
固有情報は docs/*-summary.md に逃がし、Skill 本体は汎用のままコピーして次に使う、という設計でした。
残す側 — このブログの .cursor/skills/
| Skill | 役割 | 捨てない理由 |
|---|---|---|
qiita-blog-writing |
執筆フェーズ・文体 | 毎記事使う。テンプレと推敲手順が入っている |
qiita-cli |
promote・preview・記法 | CLI 公式手順の単一の入口 |
qiita-cross-reference |
過去記事検索・内部リンク | 記事が増えるほど価値が上がる |
こちらは Git 管理して育て続ける 前提です。
ルール（.cursor/rules/qiita-publish-gate.mdc）とセットで、「drafts/ は勝手に npm run promote しない」などの投稿ゲートも Skill 側に書いてあります。
見分けの一言
- 期間限定のイベント向け → docs に事実を逃がし、Skill は型だけ残す（中身は追わない）
- 繰り返す作業向け → Skill・スクリプト・validate をリポジトリに固定する
ハッカソンとブログ執筆で、Skill の寿命の考え方が真逆でした。
promote から投稿まで（おまけ）
preview と lint が通ったら、ユーザーが OK したタイミングで npm run promote します。
npm run promote -- 0005-cursor-qiita-writing-env
git add public/ drafts/
git commit -m "publish: 0005-cursor-qiita-writing-env"
git push origin main
npm run promote は、事前に npm run validate:draft -- <basename> --strict を通したうえで drafts/ → public/ に移動します。
.github/workflows/publish.yml が public/** の変更を検知して increments/qiita-cli/actions/publish@v1 を実行します。
QIITA_TOKEN は .env と GitHub Secrets のみ。pre-commit hook で秘匿ファイルの混入も弾くようにしています。
まとめ
- 下書き preview は
npm run preview:draft→npm run preview→npm run cleanup:previewで、drafts/のまま Qiita 表示を確認する - textlint は
npm run lint:draftで AI っぽい表現を info レベルで拾い、人間は style-guide で最終調整する - Skill の線引きは、ハッカソンは型だけ残して使い捨て、ブログ執筆 Skill はリポジトリで長く育てる
ぬいぐるみ目当てで環境を整えたのは事実ですが、結果として 投稿前の確認と下書きの分離 がはっきりして、記事を量産しやすくなりました。
明日（7/13）が Tech Festa Sprint の投稿締切なので、あとは手を動かすだけです…！(´﹃｀)