AGENT SKILL

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

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

love-dabimas
love-dabimas/dabimas-factor

handoff

現在の会話を、別のエージェントが引き継げる引き継ぎドキュメントに圧縮する。

★ 0
love-dabimas
love-dabimas/dabimas-factor

grilling

計画や設計についてユーザーを徹底的にインタビューする。作る前に計画をストレステストしたいとき、または「grill」「詰めて」「壁打ちして」等のトリガーフレーズが使われたときに使う。

★ 0
love-dabimas
love-dabimas/dabimas-factor

grill-me

計画や設計を研ぎ澄ますための徹底的なインタビュー。

★ 0
love-dabimas
love-dabimas/dabimas-factor

codex-implement

実装作業を OpenAI Codex に委譲しつつ、Sonnet/Opus が自分で実装するのと同等の品質を担保する。Claude が設計して作業指示書を書き、別セッションの Codex が実装し、Claude が検収する。ユーザーが「Codexにやらせて」「Codexと分担して」「Codexに依頼して」「Codex用の指示書を作って」と言ったとき(依頼モード)、および「Codexが終わった」「Codexの実装を検収・レビューして」と言ったとき(検収モード)に必ず使う。

★ 0
love-dabimas
love-dabimas/dabimas-factor

tdd

テスト駆動開発(TDD)。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。

★ 0
love-dabimas
love-dabimas/dabimas-factor

resolving-merge-conflicts

進行中の git マージ / リベースのコンフリクトを解決する必要があるときに使う。

★ 0