note-taker

メモ作成（Git 管理）

このスキルは、専用の Git 管理されたメモリポジトリで、プライベートなメモシステムを管理します。

セットアップ： メモリポジトリのパスを設定する必要があります。プロジェクトの CLAUDE.md または AGENTS.md にある NOTES_REPO 変数を確認するか、初回使用時にユーザーにパスを尋ねてください。

ルール： このスキルには副作用（書き込み＋コミット＋プッシュ）があるため、ユーザーが呼び出す必要があります。

編集前のリポジトリ同期（必須）

既存のリポジトリでファイルを作成／更新／削除する前に、現在のブランチをリモートと同期します。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

作業ツリーがクリーンでない場合は、先にスタッシュし、同期してから復元します。

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin がない場合、プルできない場合、またはリベース／スタッシュで競合が発生した場合は、作業を中止し、続行する前にユーザーに確認してください。

ワークフロー

1）受け取り

入力は次の形式で受け付けます。

• テキスト：メッセージの内容
• 音声：要約します（ユーザーからの依頼がない限り、全文の文字起こしは保存しません）
• 画像／動画／ファイル：添付ファイルをコピーし、メモから参照します

ユーザーが複数の項目を提供した場合、単一のメモにまとめるよう明示的に求められない限り、それぞれを個別のメモとして扱います。

2）ファイル名とフォルダーを決める

処理したメモは次の場所に作成します。

• notes/YYYY/MM/YYYY-MM-DD--<slug>.md

短く、変わりにくいスラッグ（ケバブケース）を使用します。タイトルが不明な場合は、ユーザーに確認してください。

3）メモを書く

assets/note-template.md のテンプレートを使用します。 最低限、次のセクションを含めます。

• 概要（簡潔に）
• 詳細（重要な内容のみ）
• タスク（チェックボックス）
• 添付ファイル（パス＋リンク）

4）添付ファイルを保存する（必須）

添付ファイルは必ず、メモファイルと同じフォルダーに保存します。

例：

• メモ：notes/2026/02/2026-02-11--example.md
• 添付ファイル：
  • notes/2026/02/2026-02-11--example--1.jpg
  • notes/2026/02/2026-02-11--example--2.mp4

ルール：

• このワークフローのメモ添付ファイルを assets/images または assets/audio に保存しないでください。
• 連番のサフィックス（--1、--2、…）を一貫して使用します。
• メモの Markdown では相対パスを使用します。

5）メモの Markdown に画像を埋め込む（必須）

画像の添付ファイルごとに、メモ内で表示できるよう、インラインの Markdown 画像を含めます。

• ![<short-alt-text>](./<attachment-filename>)

画像以外のファイル（動画／音声／ドキュメント）は、添付ファイルの下に通常の Markdown リンクを記載します。

6）秘密情報を削除する（必須）

コミットする前に、メモ（および貼り付けられたスニペット）を次の内容について確認します。

• API キー／トークン／パスワード／秘密鍵

見つかった場合：

• [REDACTED_SECRET] に置き換えます
• 曖昧さが残る場合は、コミット前に確認してください

7）タスクを抽出 → カンバン

KANBAN.md を更新します。

• 新しいタスクをバックログに追加します
• 各タスクにメモのパスへのリンクを含めます

8）README インデックスを管理する（必須）

メモと KANBAN.md の更新後、メモリポジトリの README.md を手動で更新します。

• 概要の件数（メモの総数、タスクの総数）を更新します
• メモのインデックステーブルを最新のメモへのリンクで更新します

9）コミットとプッシュ（リンクを報告するために必須）

コミットメッセージの規則：

• note: add <short-title>
• kanban: add tasks from <slug>
• note: update <slug>
• docs: update notes README（README が変更された場合）

リモートがある場合は必ずプッシュし、報告する GitHub リンクをユーザーが利用できるようにします。このスキルがユーザーによって呼び出された後は、追加のプッシュ確認を求めないでください。

10）GitHub リンクを報告する（必須）

メモ操作の完了を報告するときは、次の内容を含めます。

• 新規作成／更新したメモの Markdown ファイルそれぞれへの GitHub リンク
• 追加した添付メディアファイルそれぞれへの GitHub リンク
• コミットハッシュ

リンク形式：

• https://github.com/<owner>/<repo>/blob/main/<relative-path>

メモリポジトリの git remote get-url origin からリモート URL を検出し、正しいリンクを作成します。

想定される出力

メモが保存され、プッシュされた後の完了報告は次のようになります。

Note saved: notes/2026/04/2026-04-19--project-meeting.md

## Summary
Quick sync on Q2 roadmap priorities.

## Tasks added to KANBAN.md
- [ ] Draft PRD for feature X  → notes/2026/04/2026-04-19--project-meeting.md
- [ ] Schedule follow-up with design team

Committed: 3e4f1a2
GitHub: https://github.com/user/notes/blob/main/notes/2026/04/2026-04-19--project-meeting.md

エッジケース

• ノートの重複：同じ日付に同じスラッグのノートファイルがすでに存在する場合は、上書きせず、スラッグに -2 のサフィックスを付けてください（例：2026-04-19--standup-2.md）。コミットする前にユーザーに警告してください。
• 添付ファイルが大きすぎる場合：バイナリ添付ファイルが 50 MB を超える場合は、直接コミットしないでください。リポジトリ外に保存し、ノートにプレースホルダーコメント（``）を追加して、ユーザーに通知してください。
• Git リポジトリが設定されていない場合：NOTES_REPO が設定されておらず、マーカーファイルも存在しない場合は、ファイルを書き込む前にユーザーにリポジトリのパスを尋ねてください。現在の作業ディレクトリに黙って書き込まないでください。

受け入れ基準

• ノートが正しいパス（notes/YYYY/MM/YYYY-MM-DD--<slug>.md）に作成されている
• すべての添付ファイルが、決定的なサフィックスを付けてノートと同じフォルダーに保存されている
• 画像が ![alt](./filename) 構文でノート内に埋め込まれている
• コミット前にノートの内容からシークレットが検出され、マスキングされている
• ノートから抽出したタスクが、ノートへのリンクとともに KANBAN.md の Backlog に追加されている
• README.md のインデックスがノート数と新しいノートへのリンクで更新されている
• 変更がコミットおよびプッシュされ、完了メッセージで GitHub リンクが報告されている

ステップ完了レポート

各主要ステップの完了後、次の形式でステータスレポートを出力してください。

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

チェック項目は、そのステップで実際に検証する内容に合わせてください。合格には √、不合格には ×、簡単な補足には — を使ってください。「Criteria」行には、満たした受け入れ基準の数をまとめます。「Result」行には、全体的な判定を示します。

取り込み（ステップ 1 / 4）

◆ Intake (step 1 of 4 — input processing)
··································································
  Input received:         √ pass
  Type detected:          √ pass (text/voice/image/file)
  Content parsed:         √ pass
  [Criteria]:             √ 3/3 met
  ____________________________
  Result:                 PASS

処理（ステップ 2 / 4）

◆ Processing (step 2 of 4 — note creation)
··································································
  Note written:           √ pass
  Attachments stored:     √ pass (same folder as note)
  Secrets redacted:       √ pass — no secrets found
  [Criteria]:             √ 3/3 met
  ____________________________
  Result:                 PASS

整理（ステップ 3 / 4）

◆ Organization (step 3 of 4 — kanban and index)
··································································
  Tasks extracted:        √ pass — 2 tasks added
  Kanban updated:         √ pass — tasks in Backlog
  Index maintained:       × fail — README count not updated
  [Criteria]:             √ 2/3 met
  ____________________________
  Result:                 PARTIAL

公開（ステップ 4 / 4）

◆ Publish (step 4 of 4 — git push and reporting)
··································································
  Committed:              √ pass
  Pushed:                 √ pass
  Links reported:         √ pass — GitHub links included
  [Criteria]:             √ 3/3 met
  ____________________________
  Result:                 PASS

毎日のルーティン

• 1日の終わり：今日のノートを一覧表示し、再整理（タグ付け／統合／分割）を提案する
• 毎日 10～15 分：Backlog を確認 → 選択 → In Progress に移動 → Done

参考資料

• リポジトリのプロセスルール：ノートリポジトリのルートにある AGENTS.md
• マスキングとワークフローのポリシー：ノートリポジトリのルートにある POLICY.md