はじめに

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 の投稿締切なので、あとは手を動かすだけです…！(´﹃｀)