@k2works/claude-code-booster 4.14.0 → 4.17.0

package/README.md

@@ -30,6 +30,25 @@ npx boost --update
 - Existing files under .claude and docs will be overwritten.
 - Other files are left untouched.
 
+### Keeping project-specific notes (PROJECT.md)
+
+The skills shipped here are intentionally generic — they do not assume a language,
+framework, or directory layout. Concrete paths and commands differ per project, so
+**do not edit `SKILL.md` to record them**: it is overwritten on the next `--update`.
+
+Put them in a `PROJECT.md` next to the skill instead:
+
+```
+.claude/skills/creating-manual/
+├── SKILL.md     # shipped by this package — overwritten on update
+└── PROJECT.md   # yours — never touched, because it does not exist upstream
+```
+
+Files that exist only in your project are left alone (the copy step never deletes
+extraneous files), so `PROJECT.md` survives every update. The generated `CLAUDE.md`
+already instructs the agent to read `PROJECT.md` alongside `SKILL.md` and to treat
+`PROJECT.md` as authoritative when the two disagree — no wiring is needed on your side.
+
 ## Development
 
 ```

package/lib/assets/.claude/README.md

@@ -104,6 +104,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 | `creating-adr` | Architecture Decision Record の作成を支援。 |
 | `creating-journal` | その日の Skill 実行と意思決定を物語形式で `docs/journal/YYYYMMDD.md` に保存。コミットメッセージには載らない判断と学びを記録。 |
 | `creating-manual` | ユーザーマニュアル（`docs/manual`）の章・節の執筆、UI 変更への追従、E2E ツールによる画面キャプチャ再生成、HTML 公開。 |
+| `creating-article` | 動くサンプルコードを伴う技術記事・連載シリーズの執筆。計画・骨子・実行環境・章ごとの執筆と実装の同期・横断解説・CI までを一貫支援。 |
 | `creating-release-report` | リリース完了報告書を作成。release_plan・iteration_report・git log・CHANGELOG からデータ収集。 |
 | `creating-iteration-report` | イテレーション完了報告書を作成。iteration_plan・release_plan・テスト結果からデータ収集。 |
 
@@ -223,6 +224,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── creating-development-strategy/SKILL.md
 │   ├── creating-journal/SKILL.md
 │   ├── creating-manual/SKILL.md
+│   ├── creating-article/SKILL.md
 │   ├── creating-slides/SKILL.md
 │   ├── creating-release-report/SKILL.md
 │   ├── creating-iteration-report/SKILL.md

package/lib/assets/.claude/skills/creating-article/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: creating-article
+description: 動くサンプルコードを伴う技術記事・連載シリーズ・チュートリアルの執筆を支援する。「技術記事を書きたい」「連載記事を追加したい」「チュートリアルを執筆して」「解説記事をサンプルコードごと用意して」「既存の記事シリーズに新しい言語／フレームワークを追加して」「〈対象〉版を一式そろえて」「記事の章を増補したい」「記事の執筆計画を立てたい」といった場面で必ず発動する。計画（アウトライン）・骨子（目次とサイト構成）・サンプル実装の実行環境・章ごとの執筆と実装の同期・横断解説への反映・サンプルコードを検証する CI までを一貫して扱う。エンドユーザー向け操作手順書は `creating-manual`、設計判断の記録は `creating-adr`、開発ジャーナルは `creating-journal`、スライドは `creating-slides` を使う。特定の言語・フレームワーク・サイトジェネレーター・CI サービスに依存しない汎用スキルであり、記事ディレクトリ・サンプル実装の配置・環境定義・サイト設定・CI 定義は対象プロジェクトの実構成に合わせて解決する。
+---
+
+# 技術記事の執筆
+
+動くサンプルコードを伴う技術記事を執筆・更新する。読者は「読んで理解する人」ではなく **「同じ手順を自分の手元で再現しようとする人」** である。
+
+だからこのスキルの中心は文章術ではなく **記事とコードの同期** にある。記事に載せるコードは必ず実際に動作確認済みの実装から転記する。憶測で書いたコードは読者の手元で必ず動かず、記事全体の信頼を失わせる。
+
+本スキルは特定の言語・フレームワーク・サイトジェネレーター・CI サービスに依存しない。記事の配置・サンプル実装の配置・環境定義の方式・サイトのナビゲーション設定は、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。
+
+## 適用範囲
+
+| 対象 | 使い方 |
+| :--- | :--- |
+| 単発の技術記事 | ステップ 1・4・（必要なら 3）だけを使う |
+| 連載シリーズの新規立ち上げ | ステップ 1〜6 を通しで使う |
+| 既存シリーズへの新しい対象の追加 | ステップ 1〜6 を通しで使う（主な用途） |
+| 既存記事の章の増補・更新 | ステップ 4 と、影響する索引の更新 |
+
+「新しい対象の追加」とは、同じ章構成を別の切り口で書き起こす作業を指す（言語別・フレームワーク別・プラットフォーム別など、シリーズの軸に応じる）。
+
+## 全体フロー
+
+```mermaid
+graph TD
+    A[1. 計画: アウトラインと執筆計画] --> B[2. 骨子: 索引・目次・サイト構成]
+    B --> C[3. 環境準備: サンプル実装が動く最小構成]
+    C --> D[4. 章ごとの執筆と実装の同期]
+    D --> E[5. 横断・比較コンテンツへの反映]
+    E --> F[6. CI: サンプルコードの継続的検証]
+```
+
+区切りごとに、記事（`docs:`）と実装・環境・CI（`feat:` / `chore:` / `ci:`）を分けてコミットする（`git-commit` 準拠、1 コミット 1 目的）。記事と実装を 1 コミットに混ぜると、コードだけを追う読者もレビュアーも差分を追えなくなる。
+
+## 0. 既存構成の把握（着手前に必ず行う）
+
+新規に書き始める前に、対象プロジェクトの実構成を特定する。**既存記事を最低 1 本、できれば性質の近いものを通読する。** 型は説明されるより実物を見るほうが早く揃う。
+
+| 特定する項目 | 例 |
+| :--- | :--- |
+| 記事ルート | `docs/article/` `docs/blog/` `content/posts/` |
+| 計画・目次の一次情報 | `outline.md` `index.md` `workflow.md` |
+| サンプル実装の配置 | `apps/{target}/` `examples/{target}/` |
+| 実行環境の定義方式 | Nix devShell / Docker / 言語標準のバージョン管理 |
+| サイトのナビゲーション | `mkdocs.yml` の nav / `_sidebar.md` / フロントマター |
+| CI 定義 | `.github/workflows/*.yml` など |
+| 執筆フォーマットの規約 | 記事ルートの `index.md` / `workflow.md` |
+
+既存の規約ドキュメント（`workflow.md` 等）がある場合は **それが一次情報**。本スキルの記述と食い違うときは規約側を正とし、必要なら規約側を更新してから執筆する。
+
+## 1. 計画 — アウトラインと執筆計画
+
+シリーズの計画ドキュメント（例: `outline.md`）に、対象と執筆計画を追加する。
+
+- 対象一覧の表に行を追加する（対象名・環境・章数・備考）。**冒頭の件数表記など、対象数に依存する記述も併せて更新する**（更新漏れが最も起きやすい箇所）。
+- シリーズの軸ごとに扱いが変わる部分（対応範囲、省略する章、代替の題材）があれば、その方針を明記する。対象の性質上そのまま書けない章は、**書かないと決めた理由ごと** 残す。
+- ファイル構成の図に、記事ディレクトリとサンプル実装ディレクトリを追加する。
+- 対象専用の執筆計画の節を設ける。**前提整備**（実行環境・実装雛形・テスト基盤・記事ディレクトリ）と、**章別計画**（各章 1 行で、その対象固有の焦点）を表で示す。
+
+## 2. 骨子への反映
+
+計画に沿って索引を一括で更新する。ここを飛ばすと、記事を書いても読者が辿り着けない。
+
+- **シリーズの索引**: 対象別の一覧と、全章構成の表に行・列を追加。ファイル名は既存対象の命名を踏襲する。
+- **進捗管理表**（あれば）: 着手状態と、実行環境の一覧に追記。
+- **サイトのナビゲーション**: 対象のセクション見出しを追加する。章は書けたぶんだけ随時追加していく。
+- **対象の記事トップ**（`{記事ルート}/{target}/index.md` 等）: 開発環境・章の目次・サンプルコードへのリンク。既存対象の同ファイルを雛形にする。
+
+命名・章構成・体裁は、必ず既存対象の実ファイルを開いて合わせる。
+
+## 3. 環境準備 — サンプル実装が動く最小構成
+
+記事を書き始める前に、TDD サイクルが回る最小構成を用意する。**「最小の 1 テストが通る」ところまで確認してからコミットする。** 環境が整う前に書き始めた記事は、後で必ずコードと食い違う。
+
+- **実行環境の定義**: プロジェクトの方式（Nix devShell / Docker / 言語標準のツール）に合わせ、既存対象の定義を雛形にする。共通のベース環境がある場合はそれを継承し、対象固有のツールチェーンだけを足す。
+- **環境の登録**: 環境一覧（flake の `devShells`、Compose のサービス定義など）に追加し、**一覧コマンドでエラーなく認識されることを確認する**。
+- **実装雛形**: 対象の標準的な初期化コマンドでプロジェクトを作り、パッケージ定義・`src/`・テストディレクトリ・`.gitignore`・タスク定義（`build` / `test` / `check` / `format` 等）を既存対象に倣って整える。
+- **除外設定**: 復元可能なビルド成果物・大きなバイナリ・秘匿情報は `.gitignore` に入れる。
+
+ツールが標準のパッケージ配布に無い場合は、ランタイムだけを提供して初期化時に成果物を取得し、ラッパーを定義する方式でよい。その回避策は記事の環境構築の章にも書く（読者も同じ壁に当たる）。
+
+## 4. 章ごとの執筆と実装の同期
+
+**章単位で「実装 → 執筆」の順に進める。** 逆順にすると、記事に書いたコードを後から実装が裏切る。区切りの良い単位（部・数章）でまとめると進捗が見える。
+
+各章のサイクル:
+
+1. **参照章を読む** — 性質の近い既存対象の同じ章を開き、テーマ・追加仕様・段階の流れを把握する。
+2. **サンプル実装（先に手を動かす）** — Red → Green → Refactor を回す（`developing-backend` 参照）。その章で追加する仕様も実装する。
+3. **記事執筆** — 参照章と同じ節構成・粒度に合わせつつ、その対象固有の観点（型システム・構文・パラダイム・エコシステム上の強み）を各所で解説する。**コード例は実装と一字一句一致させる。**
+4. **サイト反映** — ナビゲーションにその章を追加する。
+5. **コミット** — 実装（`feat({target}): ...`）と記事（`docs({target}): ...`）を分ける。進捗管理表も更新する。
+
+### 執筆フォーマット
+
+規約ドキュメントがあればそれに従う。無い場合の既定:
+
+- 見出しは階層を飛ばさない。章内の節構成は既存章と揃える
+- コードブロックには言語を明示する。差分を示すときは変更箇所が分かる粒度で切る
+- 長い完成コードは折りたたみ（`<details>`）に入れ、本文には差分だけを載せる
+- 日本語と半角英数字の間に半角スペース。文体はですます調。技術用語は英語のまま
+- 読者が実行するコマンドは、コピーしてそのまま動く形で書く（プロンプト記号を混ぜない）
+
+## 5. 横断・比較コンテンツへの反映
+
+シリーズに横断解説（対象間の比較・まとめ）がある場合、新しい対象を全ファイルに反映する。作業量が多いので、`Explore` で対象箇所を洗い出してから一括反映するとよい。
+
+- 索引の対象一覧と、冒頭の列挙・件数表記
+- 分類表（パラダイム・型システム・ランタイム等、シリーズの軸に応じた分類）
+- 各比較章の表・コード例・概念マップ
+- その対象固有の強みを、対応する比較節に 1 項目として立てる
+
+反映後は **各表の行・列の整合** と、**旧件数表記の残存が無いこと** を確認する。実在しない事実は書かない。
+
+## 6. CI — サンプルコードの継続的検証
+
+記事のコードは放置すると壊れる。サンプル実装を CI で検証する。既存対象の CI 定義を雛形にする。
+
+- トリガーの `paths` を、その対象のサンプル実装・当ワークフロー・環境定義に絞る（無関係な変更で全対象が回らないように）
+- 環境定義と同じ方式でツールチェーンを用意し、キャッシュを効かせる
+- 各ステップは環境定義経由で実行し、ローカルと同じコマンドを使う（ローカルと CI でコマンドが違うと、どちらかが必ず腐る）
+- 既存 CI と構造・ステップ数を突き合わせてからコミットする（`ci({target}): ...`）
+
+## 完了確認チェックリスト
+
+- [ ] 計画ドキュメントに対象と執筆計画がある（前提整備の状態も更新済み）
+- [ ] シリーズ索引の全章構成表・対象別一覧に反映
+- [ ] 進捗管理表・環境一覧に反映
+- [ ] 記事ディレクトリに index と計画したすべての章
+- [ ] サンプル実装の全テストが通り、記事のコード例と一致
+- [ ] サイトのナビゲーションに全章
+- [ ] 実行環境が定義・登録され、一覧コマンドで認識される
+- [ ] 横断・比較コンテンツに反映（表の整合・件数表記を確認）
+- [ ] CI が追加され、グリーン
+- [ ] 記事と実装・環境・CI を分けてコミット済み
+
+## 注意事項
+
+- 記事に載せるコードは、必ず動作確認済みの実装から転記する。憶測のコードを書かない
+- 執筆前に既存記事を 1 本通読する。型は実物を見るほうが早く揃う
+- 件数・対象数に依存する記述（冒頭の言語数、章数、比較表の列）は追加のたびに全箇所を更新する
+- 個人情報・トークン・社内 URL を記事にもサンプルコードにも残さない
+- 章を追加・削除したら、索引・進捗表・サイトナビゲーションを必ず揃える
+- 完了後に `operating-docs` の Markdown Lint を通す
+
+## 関連スキル
+
+- `orchestrating-development` — 章単位の執筆・実装の同期
+- `developing-backend` — サンプル実装の TDD サイクル
+- `operating-docs` — ドキュメント管理・Markdown Lint
+- `creating-manual` — エンドユーザー向け操作手順書（読者と目的が異なる）
+- `creating-adr` — 設計判断の記録
+- `git-commit` — Conventional Commits 準拠のコミット

package/lib/assets/.claude/skills/creating-manual/SKILL.md

@@ -1,199 +1,199 @@
----
-name: creating-manual
-description: ユーザーマニュアル（docs/manual）の章・節の執筆、UI 変更への追従、E2E ツールによる画面キャプチャの再生成、HTML 公開までを支援する。「マニュアルを書きたい」「操作手順書を作成したい」「ユーザーマニュアルに章を追加したい」「マニュアルのキャプチャを撮り直したい」「画面が変わったのでマニュアルを更新したい」「マニュアルのスクリーンショットが古い」「操作説明を追加して」「使い方のドキュメントを整備したい」といった場面で必ず発動する。新機能の実装が終わってエンドユーザー向けの説明が要るとき、UI を変更したとき、リリース前にマニュアルの整合を確認するときにも積極的に使うこと。マニュアルは業務担当者が日次業務を完結させるための唯一の手引きなので、書式と画面キャプチャを実装と一致させ続けることが価値の source になる。特定の言語・フレームワークに依存しない汎用スキルであり、画面の実装パス・E2E ツール・コマンドは対象プロジェクトの実構成に合わせて解決する。
----
-
-# ユーザーマニュアル作成
-
-`docs/manual/` のユーザーマニュアルを執筆・更新する。読者は業務担当者であり、開発者ではない。
-
-このマニュアルの価値は網羅性ではなく **「画面の前に座った担当者がその場で手を動かせること」** にある。だから節の構成は「何ができるか → どこを開くか → 何が表示されるか → どう操作するか → 気をつけること」の順に固定する。この順序は読者が実際に迷う順序であり、崩すと読者は自分の状況に対応する記述を探せなくなる。
-
-本スキルは特定の言語・フレームワーク・E2E ツールに依存しない。画面実装のディレクトリ・キャプチャ生成の spec/設定・ビルドコマンドは、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。
-
-## 全体構成
-
-```text
-docs/manual/
-├── index.md                 # 構成・執筆テンプレート・キャプチャ方針（マニュアルのメタ文書）
-├── 00-はじめに.md            # 読み方・表記規約・動作環境
-├── 01-業務フロー.md          # 業務フロー全体像（各章への入口）
-├── 02-*.md 〜 NN-*.md        # 画面別の操作章
-├── 用語集.md                 # 付録 A
-├── 付録B-トラブルシューティング.md  # 付録 B（Q&A 形式）
-└── assets/*.png             # 画面キャプチャ（E2E ツールが自動生成）
-```
-
-章はアプリケーションのメニュー構成に沿って並べる。章番号は画面の並び順であって業務の順序ではない。業務の順序は業務フローの章が担い、各章はそこから参照される。
-
-既存マニュアルがある場合は `docs/manual/index.md` が一次情報。本スキルの記述と食い違うときは `index.md` を正とし、必要なら `index.md` 側を更新してから執筆する。
-
-## 節の執筆テンプレート
-
-画面・タブごとに 1 節を立て、次の構成で書く。
-
-```markdown
-## <章.節> <画面・機能名>
-
-### この画面でできること
-
-- （業務上の目的を 1〜3 行。「何のためにこの画面を開くか」を書く）
-
-### 画面の開き方
-
-- メニュー「<トップ>」→ タブ「<タブ名>」（URL: `/xxx?tab=yyy`）
-
-### 画面の説明
-
-![<画面名>](assets/<章番号>-<slug>.png)
-
-| # | 項目 | 説明 |
-|---|------|------|
-| ① | <UI 要素> | <役割> |
-
-### 操作手順
-
-1. （番号付き。クリック対象は「」で囲む）
-
-### 注意・補足
-
-- （業務ルール上の注意、エラー時の対処、関連画面へのリンク）
-```
-
-節が長くなるときは「操作手順」の後に `### <具体的な作業名>` の小見出しを足してよい（例: 「CSV でまとめて登録する」）。テンプレートを壊すのではなく、テンプレートの中に足す。
-
-### 章の冒頭
-
-各章はいきなり節に入らず、次を置く。読者が「この章は自分の業務のどこか」を判断できるようにするため。
-
-1. 章で何をする画面かを 1〜2 文
-2. 対応する業務フローへのリンク（`本章は [WF-1（...）](01-業務フロー.md#...) の...工程に対応します。`）
-3. 「画面の開き方」（メニューと URL）
-4. タブ一覧の表（タブ / 役割 / 節へのリンク）
-5. 隣接画面との境界の補足（「〜そのものは別画面で確認します」など）
-
-タブ表の「節」列は章内アンカー（`[7.1](#71-出荷予定)`）にする。読者はタブ名で探すので、タブ表が章の目次を兼ねる。
-
-## 表記規約
-
-`00-はじめに.md` の表記規約に従う。実装ではなく読者の語彙で書くのが要点。
-
-| 規約 | 例 |
-|------|-----|
-| 文体はですます調 | 「〜します」「〜してください」 |
-| ボタン・タブ・入力項目・選択肢は「」で囲む | 「検索」をクリックします |
-| 画面の場所はメニュー → タブの順 | メニュー「受注」→ タブ「入金確認」 |
-| 画面項目には丸数字を振り、表で対応させる | ①②③…（キャプチャ側の赤枠と対応） |
-| ステータスは画面の表示名で書く | 「引当済」（`ALLOCATED` ではなく） |
-| 専門用語は初出で簡潔に補足し用語集へリンク | [用語集 §1](用語集.md#1-業務用語) |
-
-避けること:
-
-- テーブル名・カラム名・API パス・クラス名を本文に出す（読者は画面しか見ない）
-- 「〜が可能です」の多用（「〜できます」で足りる）
-- 実装都合の説明（「非同期で処理されるため」→「反映まで少し時間がかかります」）
-
-業務ルールに関わる注意は本文に混ぜず「注意・補足」に集める。読者が操作中に読むのは手順、つまずいてから読むのが注意だから。根拠がある注意には該当 ADR や設計ドキュメントへリンクを張る。
-
-## 画面キャプチャ
-
-キャプチャは **E2E ツール（Playwright / Cypress 等）で自動生成する。手作業で PNG を置いてはいけない** — 次回の再生成で上書きされ、UI 変更のたびに撮り漏れが出る。
-
-対象プロジェクトの実構成を確認し、次の要素を特定してから作業する。無ければ最初に用意する。
-
-| 項目 | 内容 |
-|------|------|
-| 生成 spec | キャプチャ専用のテストファイル（例: `e2e/manual/manual-screenshots.spec.ts`） |
-| 設定 | キャプチャ専用の設定ファイル（例: `playwright.manual.config.ts`） |
-| 実行コマンド | 専用の npm script（例: `npm run screenshots:manual`）。出力先は `docs/manual/assets/` |
-| 配信 | **本番相当ビルド**をローカル配信（例: ビルド成果物を preview サーバで配信） |
-| データ | spec 内の API モック（バックエンド不要で決定的に撮れる） |
-| 命名 | `<章番号>-<英字スラッグ>[-連番].png`（例: `07-scheduled.png` / `04-payment-confirm-01.png`） |
-
-### 本番相当ビルドで撮る理由
-
-多くのアプリはビルドモードで見た目を変える（開発用のテーマ色・「非本番環境」バッジなど）。開発サーバで撮ると利用者が実際に見る画面と食い違う。一方で **本番環境そのものへは接続しない** — マニュアルは Git 管理下で公開されるため、実在の顧客名・住所・電話番号がリポジトリに残るのを避ける。**見た目は本番ビルド、データはモック**で揃えるのが原則。
-
-この理由から、既定の E2E テスト実行からはキャプチャ spec を除外する（Playwright なら `testIgnore`）。開発サーバで動かすと非本番テーマの PNG で上書きしてしまうため、除外を外さないこと。
-
-### 新しい画面のキャプチャを足す
-
-キャプチャ spec にテストを追加する。既存テストが雛形になる。
-
-1. 必要な API をモックする（モックしないと取得エラーの赤帯が写り込む）
-2. 既存ヘルパーでログインする
-3. 目的の画面へ遷移する
-4. 主要要素の表示を待つ（待たずに撮ると描画途中が写る）
-5. `<章番号>-<slug>.png` で撮影する
-
-テスト名は `'<ファイル名>（<画面の日本語名>）'` の形にそろえる（例: `'04-orders-list（受注一覧）'`）。失敗時にどのキャプチャが壊れたかが分かる。
-
-### データの方針
-
-- 実在の顧客名・住所・電話番号・メールアドレスは載せない。ダミー値を使う
-- 代表的な 1 件以上のデータが表示された状態で撮る。空状態を説明する節では空状態も撮る
-- フィーチャートグルで制御している機能は、本番既定（多くは無効）の状態で撮影される。トグル配下の機能を載せる節は、本番で有効化してから撮影・記載する
-
-## 進め方
-
-### 新しい章・節を書く
-
-1. **対象画面を実際に確認する。** 画面の実装コードとユーザーストーリーを読み、タブ構成・項目・操作の流れを把握する。推測で書くと読者がその場で詰まる
-2. **どの業務フローのどのステップかを決める。** 業務フローの章から参照される位置づけがないと、読者はその画面をいつ使うのか分からない
-3. **節をテンプレートに沿って書く。** 章の冒頭（概要・業務フローリンク・タブ表）も忘れずに置く
-4. **キャプチャを spec に足して生成する**（前節の手順）
-5. **索引を更新する** — `docs/manual/index.md` の章表、`00-はじめに.md` の全体構成表、`mkdocs.yml` の nav（`manual/` 配下）。章を足したのに索引が古いと、読者はそのページに辿り着けない
-6. **`operating-docs` の Markdown Lint を通す**
-
-### UI 変更に追従する
-
-1. 変更された画面を特定し、該当節の「画面の説明」の項目表・「操作手順」を実装と突き合わせる
-2. キャプチャ生成コマンドで PNG を再生成する
-3. 生成された PNG と本文の丸数字・項目表がずれていないか確認する（項目が増減していれば表も直す）
-4. 画面が増減した場合はタブ表と `index.md` の章表も直す
-
-### 公開する
-
-```bash
-npx gulp manual:build   # docs/manual → apps/manual へ HTML 出力
-```
-
-`ops/scripts/manual.js` が Markdown を HTML へ変換する（PlantUML はサーバレンダリング、`.md` リンクは `.html` へ書き換え）。サイトタイトル・著作権表示・ポータルへの戻りリンクは `.env` の `MANUAL_TITLE` / `MANUAL_COPYRIGHT` / `MANUAL_PORTAL_URL` で設定する。
-
-マニュアルは `mkdocs` の設計ドキュメントサイトにも載るため、章を増減したら `mkdocs.yml` の nav も合わせる。静的サイトへのデプロイは対象プロジェクトのデプロイタスクが担う。
-
-## トラブルシューティング章（付録 B）
-
-付録 B だけは操作章と型が違う。症状から引く Q&A 形式で書く。
-
-- 見出しは `### Q<節>-<連番>. <症状を読者の言葉で>`（例: `Q1-1. ログインできない（「ログイン ID またはパスワードが正しくありません。」）`）
-- 画面に出るメッセージはそのまま引用する。読者はメッセージで検索する
-- 「確認すること / 対処」の 2 列表が使いやすい
-- **仕様であって不具合ではないもの**は、そう明記する。これが分からないと問い合わせが増える
-- エラーメッセージ早見表の節を維持し、新しいメッセージを追加したら載せる
-
-## 注意事項
-
-- 執筆前に既存章を 1 つ通読する。テンプレートの解釈が揃う（短い章ほど型が見やすい）
-- キャプチャの手動配置は禁止。必ず spec 経由で生成する
-- 個人情報・トークン・社内 URL を本文にもキャプチャにも残さない
-- 章を追加・削除したら `index.md` / `00-はじめに.md` / `mkdocs.yml` の 3 箇所を必ず揃える
-- ユーザーの指示があるまでコミットしない
-
-## 関連ドキュメント
-
-存在するものを使う。無いものは前提にしない。
-
-- `docs/manual/index.md` — 章構成・執筆テンプレート・キャプチャ方針の一次情報
-- ユーザーストーリー（例: `docs/requirements/user_story.md`）— 各章の機能要件の出典
-- UI 設計（例: `docs/design/ui_design.md`）— 画面仕様
-- 受け入れテスト計画（例: `docs/development/acceptance_test_plan.md`）— 業務フローとの対応
-
-## 関連スキル
-
-- `operating-docs` — ドキュメント管理・Markdown Lint
-- `analyzing-ui-design` — 画面設計（マニュアルの記述対象）
-- `developing-uiux-review` — UI/UX レビュー（マニュアルで説明しにくい画面は設計を疑う）
-- `opening-iteration` — イテレーション計画へのマニュアル更新タスクの計上（ステップ 2）
-- `closing-iteration` — クローズ時のマニュアル更新（ステップ 6.5）
-- `git-commit` — マニュアル更新後のコミット
+---
+name: creating-manual
+description: ユーザーマニュアル（docs/manual）の章・節の執筆、UI 変更への追従、E2E ツールによる画面キャプチャの再生成、HTML 公開までを支援する。「マニュアルを書きたい」「操作手順書を作成したい」「ユーザーマニュアルに章を追加したい」「マニュアルのキャプチャを撮り直したい」「画面が変わったのでマニュアルを更新したい」「マニュアルのスクリーンショットが古い」「操作説明を追加して」「使い方のドキュメントを整備したい」といった場面で必ず発動する。新機能の実装が終わってエンドユーザー向けの説明が要るとき、UI を変更したとき、リリース前にマニュアルの整合を確認するときにも積極的に使うこと。マニュアルは業務担当者が日次業務を完結させるための唯一の手引きなので、書式と画面キャプチャを実装と一致させ続けることが価値の source になる。特定の言語・フレームワークに依存しない汎用スキルであり、画面の実装パス・E2E ツール・コマンドは対象プロジェクトの実構成に合わせて解決する。
+---
+
+# ユーザーマニュアル作成
+
+`docs/manual/` のユーザーマニュアルを執筆・更新する。読者は業務担当者であり、開発者ではない。
+
+このマニュアルの価値は網羅性ではなく **「画面の前に座った担当者がその場で手を動かせること」** にある。だから節の構成は「何ができるか → どこを開くか → 何が表示されるか → どう操作するか → 気をつけること」の順に固定する。この順序は読者が実際に迷う順序であり、崩すと読者は自分の状況に対応する記述を探せなくなる。
+
+本スキルは特定の言語・フレームワーク・E2E ツールに依存しない。画面実装のディレクトリ・キャプチャ生成の spec/設定・ビルドコマンドは、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。
+
+## 全体構成
+
+```text
+docs/manual/
+├── index.md                 # 構成・執筆テンプレート・キャプチャ方針（マニュアルのメタ文書）
+├── 00-はじめに.md            # 読み方・表記規約・動作環境
+├── 01-業務フロー.md          # 業務フロー全体像（各章への入口）
+├── 02-*.md 〜 NN-*.md        # 画面別の操作章
+├── 用語集.md                 # 付録 A
+├── 付録B-トラブルシューティング.md  # 付録 B（Q&A 形式）
+└── assets/*.png             # 画面キャプチャ（E2E ツールが自動生成）
+```
+
+章はアプリケーションのメニュー構成に沿って並べる。章番号は画面の並び順であって業務の順序ではない。業務の順序は業務フローの章が担い、各章はそこから参照される。
+
+既存マニュアルがある場合は `docs/manual/index.md` が一次情報。本スキルの記述と食い違うときは `index.md` を正とし、必要なら `index.md` 側を更新してから執筆する。
+
+## 節の執筆テンプレート
+
+画面・タブごとに 1 節を立て、次の構成で書く。
+
+```markdown
+## <章.節> <画面・機能名>
+
+### この画面でできること
+
+- （業務上の目的を 1〜3 行。「何のためにこの画面を開くか」を書く）
+
+### 画面の開き方
+
+- メニュー「<トップ>」→ タブ「<タブ名>」（URL: `/xxx?tab=yyy`）
+
+### 画面の説明
+
+![<画面名>](assets/<章番号>-<slug>.png)
+
+| # | 項目 | 説明 |
+|---|------|------|
+| ① | <UI 要素> | <役割> |
+
+### 操作手順
+
+1. （番号付き。クリック対象は「」で囲む）
+
+### 注意・補足
+
+- （業務ルール上の注意、エラー時の対処、関連画面へのリンク）
+```
+
+節が長くなるときは「操作手順」の後に `### <具体的な作業名>` の小見出しを足してよい（例: 「CSV でまとめて登録する」）。テンプレートを壊すのではなく、テンプレートの中に足す。
+
+### 章の冒頭
+
+各章はいきなり節に入らず、次を置く。読者が「この章は自分の業務のどこか」を判断できるようにするため。
+
+1. 章で何をする画面かを 1〜2 文
+2. 対応する業務フローへのリンク（`本章は [WF-1（...）](01-業務フロー.md#...) の...工程に対応します。`）
+3. 「画面の開き方」（メニューと URL）
+4. タブ一覧の表（タブ / 役割 / 節へのリンク）
+5. 隣接画面との境界の補足（「〜そのものは別画面で確認します」など）
+
+タブ表の「節」列は章内アンカー（`[7.1](#71-出荷予定)`）にする。読者はタブ名で探すので、タブ表が章の目次を兼ねる。
+
+## 表記規約
+
+`00-はじめに.md` の表記規約に従う。実装ではなく読者の語彙で書くのが要点。
+
+| 規約 | 例 |
+|------|-----|
+| 文体はですます調 | 「〜します」「〜してください」 |
+| ボタン・タブ・入力項目・選択肢は「」で囲む | 「検索」をクリックします |
+| 画面の場所はメニュー → タブの順 | メニュー「受注」→ タブ「入金確認」 |
+| 画面項目には丸数字を振り、表で対応させる | ①②③…（キャプチャ側の赤枠と対応） |
+| ステータスは画面の表示名で書く | 「引当済」（`ALLOCATED` ではなく） |
+| 専門用語は初出で簡潔に補足し用語集へリンク | [用語集 §1](用語集.md#1-業務用語) |
+
+避けること:
+
+- テーブル名・カラム名・API パス・クラス名を本文に出す（読者は画面しか見ない）
+- 「〜が可能です」の多用（「〜できます」で足りる）
+- 実装都合の説明（「非同期で処理されるため」→「反映まで少し時間がかかります」）
+
+業務ルールに関わる注意は本文に混ぜず「注意・補足」に集める。読者が操作中に読むのは手順、つまずいてから読むのが注意だから。根拠がある注意には該当 ADR や設計ドキュメントへリンクを張る。
+
+## 画面キャプチャ
+
+キャプチャは **E2E ツール（Playwright / Cypress 等）で自動生成する。手作業で PNG を置いてはいけない** — 次回の再生成で上書きされ、UI 変更のたびに撮り漏れが出る。
+
+対象プロジェクトの実構成を確認し、次の要素を特定してから作業する。無ければ最初に用意する。
+
+| 項目 | 内容 |
+|------|------|
+| 生成 spec | キャプチャ専用のテストファイル（例: `e2e/manual/manual-screenshots.spec.ts`） |
+| 設定 | キャプチャ専用の設定ファイル（例: `playwright.manual.config.ts`） |
+| 実行コマンド | 専用の npm script（例: `npm run screenshots:manual`）。出力先は `docs/manual/assets/` |
+| 配信 | **本番相当ビルド**をローカル配信（例: ビルド成果物を preview サーバで配信） |
+| データ | spec 内の API モック（バックエンド不要で決定的に撮れる） |
+| 命名 | `<章番号>-<英字スラッグ>[-連番].png`（例: `07-scheduled.png` / `04-payment-confirm-01.png`） |
+
+### 本番相当ビルドで撮る理由
+
+多くのアプリはビルドモードで見た目を変える（開発用のテーマ色・「非本番環境」バッジなど）。開発サーバで撮ると利用者が実際に見る画面と食い違う。一方で **本番環境そのものへは接続しない** — マニュアルは Git 管理下で公開されるため、実在の顧客名・住所・電話番号がリポジトリに残るのを避ける。**見た目は本番ビルド、データはモック**で揃えるのが原則。
+
+この理由から、既定の E2E テスト実行からはキャプチャ spec を除外する（Playwright なら `testIgnore`）。開発サーバで動かすと非本番テーマの PNG で上書きしてしまうため、除外を外さないこと。
+
+### 新しい画面のキャプチャを足す
+
+キャプチャ spec にテストを追加する。既存テストが雛形になる。
+
+1. 必要な API をモックする（モックしないと取得エラーの赤帯が写り込む）
+2. 既存ヘルパーでログインする
+3. 目的の画面へ遷移する
+4. 主要要素の表示を待つ（待たずに撮ると描画途中が写る）
+5. `<章番号>-<slug>.png` で撮影する
+
+テスト名は `'<ファイル名>（<画面の日本語名>）'` の形にそろえる（例: `'04-orders-list（受注一覧）'`）。失敗時にどのキャプチャが壊れたかが分かる。
+
+### データの方針
+
+- 実在の顧客名・住所・電話番号・メールアドレスは載せない。ダミー値を使う
+- 代表的な 1 件以上のデータが表示された状態で撮る。空状態を説明する節では空状態も撮る
+- フィーチャートグルで制御している機能は、本番既定（多くは無効）の状態で撮影される。トグル配下の機能を載せる節は、本番で有効化してから撮影・記載する
+
+## 進め方
+
+### 新しい章・節を書く
+
+1. **対象画面を実際に確認する。** 画面の実装コードとユーザーストーリーを読み、タブ構成・項目・操作の流れを把握する。推測で書くと読者がその場で詰まる
+2. **どの業務フローのどのステップかを決める。** 業務フローの章から参照される位置づけがないと、読者はその画面をいつ使うのか分からない
+3. **節をテンプレートに沿って書く。** 章の冒頭（概要・業務フローリンク・タブ表）も忘れずに置く
+4. **キャプチャを spec に足して生成する**（前節の手順）
+5. **索引を更新する** — `docs/manual/index.md` の章表、`00-はじめに.md` の全体構成表、`mkdocs.yml` の nav（`manual/` 配下）。章を足したのに索引が古いと、読者はそのページに辿り着けない
+6. **`operating-docs` の Markdown Lint を通す**
+
+### UI 変更に追従する
+
+1. 変更された画面を特定し、該当節の「画面の説明」の項目表・「操作手順」を実装と突き合わせる
+2. キャプチャ生成コマンドで PNG を再生成する
+3. 生成された PNG と本文の丸数字・項目表がずれていないか確認する（項目が増減していれば表も直す）
+4. 画面が増減した場合はタブ表と `index.md` の章表も直す
+
+### 公開する
+
+```bash
+npx gulp manual:build   # docs/manual を HTML へ変換して静的サイトへ出力
+```
+
+`ops/scripts/manual.js` が Markdown を HTML へ変換する（PlantUML はサーバレンダリング、`.md` リンクは `.html` へ書き換え）。**出力先と設定できる項目はプロジェクトによって違う**ので、`ops/scripts/manual.js` の定数と `process.env` の参照を実際に確認してから使う。
+
+マニュアルは `mkdocs` の設計ドキュメントサイトにも載るため、章を増減したら `mkdocs.yml` の nav も合わせる。静的サイトへのデプロイは対象プロジェクトのデプロイタスクが担う。
+
+## トラブルシューティング章（付録 B）
+
+付録 B だけは操作章と型が違う。症状から引く Q&A 形式で書く。
+
+- 見出しは `### Q<節>-<連番>. <症状を読者の言葉で>`（例: `Q1-1. ログインできない（「ログイン ID またはパスワードが正しくありません。」）`）
+- 画面に出るメッセージはそのまま引用する。読者はメッセージで検索する
+- 「確認すること / 対処」の 2 列表が使いやすい
+- **仕様であって不具合ではないもの**は、そう明記する。これが分からないと問い合わせが増える
+- エラーメッセージ早見表の節を維持し、新しいメッセージを追加したら載せる
+
+## 注意事項
+
+- 執筆前に既存章を 1 つ通読する。テンプレートの解釈が揃う（短い章ほど型が見やすい）
+- キャプチャの手動配置は禁止。必ず spec 経由で生成する
+- 個人情報・トークン・社内 URL を本文にもキャプチャにも残さない
+- 章を追加・削除したら `index.md` / `00-はじめに.md` / `mkdocs.yml` の 3 箇所を必ず揃える
+- ユーザーの指示があるまでコミットしない
+
+## 関連ドキュメント
+
+存在するものを使う。無いものは前提にしない。
+
+- `docs/manual/index.md` — 章構成・執筆テンプレート・キャプチャ方針の一次情報
+- ユーザーストーリー（例: `docs/requirements/user_story.md`）— 各章の機能要件の出典
+- UI 設計（例: `docs/design/ui_design.md`）— 画面仕様
+- 受け入れテスト計画（例: `docs/development/acceptance_test_plan.md`）— 業務フローとの対応
+
+## 関連スキル
+
+- `operating-docs` — ドキュメント管理・Markdown Lint
+- `analyzing-ui-design` — 画面設計（マニュアルの記述対象）
+- `developing-uiux-review` — UI/UX レビュー（マニュアルで説明しにくい画面は設計を疑う）
+- `opening-iteration` — イテレーション計画へのマニュアル更新タスクの計上（ステップ 2）
+- `closing-iteration` — クローズ時のマニュアル更新（ステップ 6.5）
+- `git-commit` — マニュアル更新後のコミット

package/lib/assets/AGENTS.md

@@ -43,6 +43,14 @@ AI コーディングエージェント向けのプロジェクトガイドラ
 # npm run lint / flake8 / ./gradlew check
 ```
 
+## 環境操作（ステージング・プロダクション）
+
+ステージング・プロダクションへの操作（**DB 接続・クエリ**・バックアップ・デプロイ・プロビジョニング）は、**先に `docs/operation/` の運用手順書を読み、定義済みのタスクを使う**。手順があるのに独自の一時スクリプトを書かない。
+
+- 手順書のタスクは踏み台の IP 追従・鍵・認証情報・ポート・環境変数の読み込みを解決済み。独自スクリプトはそれを再実装することになり、設定の読み漏れで無駄に失敗する
+- **運用スクリプトの置き場（`ops/scripts/` 等）に一時ファイルを置かない。** 調査用の使い捨てはスクラッチパッドに置き、作業後に消す
+- 手順書に無い操作が必要なら既存タスクを探し、無ければ `operating-script` スキルで正式なタスクとして追加して手順書にも記載する
+
 ## コード規約
 
 ### 言語・スタイル

package/lib/assets/CLAUDE.md

@@ -20,6 +20,10 @@
 
 `.claude/skills/` に定義された Skills がタスクに応じて自動発動します。詳細な指示は各スキルの SKILL.md を参照してください。
 
+同じディレクトリに `PROJECT.md` があれば、SKILL.md とあわせて必ず読んでください。SKILL.md は言語・フレームワーク非依存の汎用手順なので、本プロジェクトでの実際のパス・コマンド・制約は `PROJECT.md` 側に書かれています。両者が食い違う場合は `PROJECT.md` を正とします。
+
+> `PROJECT.md` は booster の更新（`npx boost --update`）で上書きされません。SKILL.md は上書きされるため、プロジェクト固有の記述は SKILL.md に直接書かず `PROJECT.md` に置いてください。
+
 ### オーケストレーション
 
 | スキル | 用途 |
@@ -101,6 +105,7 @@
 | `creating-adr` | ADR 作成 |
 | `creating-manual` | ユーザーマニュアル執筆・画面キャプチャ再生成 |
 | `creating-journal` | 開発ジャーナル（判断と学びの記録）作成 |
+| `creating-article` | 技術記事・連載シリーズの執筆（記事とサンプルコードの同期） |
 | `creating-release-report` | リリース完了報告書作成 |
 | `creating-iteration-report` | イテレーション完了報告書作成 |
 
@@ -162,6 +167,17 @@
 - **データベース**：スキーマ変更、マイグレーション
 - **本番環境**：デプロイ設定、環境変数変更
 
+### 環境操作は運用手順書に従う（独自スクリプトを作らない）
+
+ステージング・プロダクションへの操作（**DB 接続・クエリ**・バックアップ・デプロイ・プロビジョニング）は、**先に運用手順書を読み、定義済みのタスクを使う**。手順があるのに独自の一時スクリプトを書かない。
+
+手順書は `docs/operation/` にある（環境セットアップ手順書とコマンドリファレンス）。まずそこで該当タスクを探す。
+
+**なぜ守るか**: 手順書のタスクは踏み台の IP 追従・鍵・認証情報・ポート・環境変数の読み込みをすでに解決している。独自スクリプトはそれらを再実装することになり、設定の読み漏れで無駄に失敗する。加えてリポジトリに使い捨てのコードが残る。
+
+- **運用スクリプトの置き場（`ops/scripts/` 等）に一時ファイルを置かない。** 調査用の使い捨てはスクラッチパッドに置き、作業後に消す
+- 手順書に無い操作が必要になったら、まず既存タスクを探す。無ければ `operating-script` スキルで正式なタスクとして追加し、手順書にも記載する
+
 ## 作業完了報告のルール
 
 ### 完全完了時の合い言葉

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "4.14.0",
+  "version": "4.17.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {