dabifaku-manual
統合版ダビふぁくのnote向け取扱説明書(note-article/配下)を作成・更新する。ユーザーが「取説」「マニュアル」「note記事」の作成・更新、仕様変更のマニュアルへの反映、スクショの撮り直しを求めたときに使う。影山優佳さん風の文体ガイドとスクリーンショット自動撮影スクリプトを含む。
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- dabifaku-manual
- description
- 統合版ダビふぁくのnote向け取扱説明書(note-article/配下)を作成・更新する。ユーザーが「取説」「マニュアル」「note記事」の作成・更新、仕様変更のマニュアルへの反映、スクショの撮り直しを求めたときに使う。影山優佳さん風の文体ガイドとスクリーンショット自動撮影スクリプトを含む。
02 资源文件 3
- 脚本scripts/capture.js6.9 KB
- 脚本scripts/capture2.js6.0 KB
- 参考文档style-guide.md3.7 KB
03 SKILL.md 正文
統合版ダビふぁく取説の作成・更新
note-article/ 配下にある note 掲載用の取扱説明書を、実装準拠の内容と指定の文体で作成・更新するためのスキル。前任者(Claude Fable 5)が作成した現行原稿と同じクオリティを維持することがゴール。
成果物の構造(この形を崩さない)
note-article/
├── README.md … 掲載手順・チャプター構成表・画像対応表(使用章つき)
├── chapters/ … 00〜10 の連番つき .md。1章=1ファイル
│ ├── 00-hajimeni.md … タイトル・前書き・目次
│ ├── 01〜09-*.md … 機能ごとの章
│ └── 10-faq-owarini.md … FAQ・締めの挨拶
└── images/ … 01〜13 の連番つき .png(章の登場順)
- 章の並びは「導入 → ホーム/カテゴリ → 血統表の基本 → 集計の読み方 → 応用機能 → 保存/整理 → FAQ」の流れ。新機能の章を足すときもこの流れに挿す。
- 画像は基本 iPhone サイズ(390×844 @2x)。PC 版の説明用に 1 枚だけデスクトップサイズ。
- 画像を追加・差し替えたら README.md の対応表も必ず更新する。
ワークフロー
1. 事実確認 — 必ず実装を読む
旧原稿や記憶からの引き写しは禁止。 数値・文言・挙動は毎回コードで確認する。主な参照先:
| 知りたいこと | 読む場所 |
|---|---|
| 統合版の全体仕様(カテゴリ・作業枠・自動保存・移行) | docs/dabifaku_unified_spec_draft.md |
| ホーム画面・カテゴリ追加ダイアログの文言/制限 | vue/components/home/home-page.js, category-dialog.js |
| 作業枠タブの挙動・削除ダイアログ文言 | vue/components/workspace/workspace-tab-bar.js |
| 集計ヘッダー(ニトロ/クロス/理論/ボタン類) | vue/components/header/factor-summary-header.js |
| 配合理論の種類と判定条件 | vue/logic/theory/compatibility.js |
| 馬検索・選択(モバイル/PC) | vue/components/pedigree/mobile-horse-picker.js, desktop-horse-autocomplete.js |
| 子系統・メモモード、ハート、自家製馬の因子ボタン | vue/components/pedigree/memo-cell.js, pedigree-row.js, horse-cell.js |
| 配合の保存・復元ダイアログ | vue/CombinationDialog.js |
| 自家製馬の因子ダイアログ | vue/factor-dialog.js |
執筆時点(2026-07)の実装準拠の事実。更新前に必ず再確認すること(仕様変更が予告されている):
- カテゴリ名は12文字まで、アイコンは12種類
- 配合保存のタイトルは10文字まで、保存リストは最新15件
- 配合理論は7種(面白/見事/よくでき/完璧/超完璧/奇跡/至高)。32マス全部埋まってから判定
- ニトロは14因子(短・速・底・長・走・中・強・雷・堅・難・適・丈・早・晩)
- ハートは3状態(白抜き=手動指定可 / ピンク=手動指定中 / グレー塗り=自動判定済みで押せない)
- 自家製馬(★)の因子は「短・速・底・長・堅・難」から1〜2個
- 最後の作業枠は削除不可。リセットボタンが消すのは今の作業枠だけ
- 配合保存・自家製馬は全カテゴリ・全作業枠の共有資産(カテゴリ削除で消えない)
- 統合版初回起動時、旧データがあれば「既存データ」カテゴリに自動移行(データは消えない)
2. 影響範囲の特定
仕様変更の反映なら git log / git diff で変更箇所を見て、上の表から該当章を割り出す。章と画像の対応は note-article/README.md の表が正。
3. スクショ撮影
同梱の Puppeteer スクリプトで実アプリを操作して撮る(手動キャプチャ・合成画像は不可)。
準備:
1. サーバー起動: .claude/launch.json の "static"(python -m http.server 8766)を preview_start で起動
2. 一時ディレクトリで npm install puppeteer-core(システムの Chrome を使うのでブラウザDL不要)
3. スクリプトを一時ディレクトリへコピーして node で実行
scripts/capture.js … クリーンプロファイルから初回起動〜カテゴリ作成〜馬選択〜作業枠追加
〜ホーム編集モードまでの一連フローを再現し、画像01〜09を撮影
scripts/capture2.js … capture.js のプロファイルを引き継ぎ、PC表示・子系統/メモモード・
配合保存ダイアログ・手動クロスの画像10〜13を撮影(capture.jsの後に実行)
- スクリプト内の
OUT(出力先)、CHROME(Chrome のパス)は環境に合わせて確認する - UI 変更でセレクタが壊れたら、preview ツール(preview_snapshot 等)で実 DOM を確認してから直す
- 撮影後は必ず Read ツールで画像を開いて目視確認(欠け・未描画・意図と違う状態がないか)
- デモデータの慣例: カテゴリ「王座予選(トロフィー)」「スタスタ」「肌馬さがし」、配合はキタサンブラック×エアグルーヴ(クロスにノーザンテーストが出て赤字の見本になる)
4. 本文の執筆・修正
文体は同梱の style-guide.md に厳密に従う。書き終えたら同ガイドのチェックリストで自己検収する。
5. 仕上げ
note-article/README.mdのチャプター構成表・画像対応表を実態に同期- 章をまたぐ相互参照(「第7章で!」など)が章番号の変更で壊れていないか確認
公開時の注意(重要)
影山優佳さんは実在の方。ご本人が書いたと誤認される形での公開はなりすましになるため、ファンによる文体模写・二次創作である旨の表記を入れることを推奨し、原稿を新規作成する場合は冒頭・末尾に断り書きを入れた状態で納品する。最終的な表記の調整・掲載判断はユーザーが行う(現行原稿はユーザーが表記を調整済み。勝手に戻さない)。
04 同仓库更多 Skills
handoff
現在の会話を、別のエージェントが引き継げる引き継ぎドキュメントに圧縮する。
grilling
計画や設計についてユーザーを徹底的にインタビューする。作る前に計画をストレステストしたいとき、または「grill」「詰めて」「壁打ちして」等のトリガーフレーズが使われたときに使う。
grill-me
計画や設計を研ぎ澄ますための徹底的なインタビュー。
codex-implement
実装作業を OpenAI Codex に委譲しつつ、Sonnet/Opus が自分で実装するのと同等の品質を担保する。Claude が設計して作業指示書を書き、別セッションの Codex が実装し、Claude が検収する。ユーザーが「Codexにやらせて」「Codexと分担して」「Codexに依頼して」「Codex用の指示書を作って」と言ったとき(依頼モード)、および「Codexが終わった」「Codexの実装を検収・レビューして」と言ったとき(検収モード)に必ず使う。
tdd
テスト駆動開発(TDD)。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。
resolving-merge-conflicts
進行中の git マージ / リベースのコンフリクトを解決する必要があるときに使う。