現在のセッションの調査・検討・作業内容を日本語のレポートにまとめ、Obsidian vault（~/obsidian/abekoh）の _reports/YYYY/MM/ に保存し、当日のデイリーノートにリンクを追記する。
ユーザーが /obsidian-save-report と入力したとき、または「Obsidianに残して」「レポートにまとめて」「今回の調査を記録して」「セッションの結果を保存して」などと依頼したときは必ずこのスキルを使う。
調査結果・技術選定の検討・障害の原因究明・学んだことを後から参照できる形で残したいという意図が読み取れる場合も、明示的にObsidianと言われていなくてもこのスキルを使う。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
このスキルは、いま進めてきたセッションの内容を一本の日本語レポートに再構成し、Obsidian vault に保存する。
想定読者は、数か月後の abekoh 自身である。 会話の流れをなぞった議事録ではなく、結論とその根拠を再構成した文書を書く。 会話中では自明だった前提も、数か月後には失われている。
レポート本文は日本語の技術文書なので、~/.claude/CLAUDE.md の規定どおり、本文を書く前に次の2つのスキルを読んで適用する。
japanese-tech-writing：整形（一文一行、コードブロック、ダッシュと中黒の扱い）、パラグラフの構成、論証の厳密さcognitive-rhythm-writing：段落の密度、文の拍、駄文の判別この2つが表記と文章構造の基準になる。 本スキルの「執筆の原則」は、レポートという文書種別に固有の判断（何を書き、何を捨てるか）を扱う。
date +%Y-%m-%d
モデルIDはシステムプロンプトの「The exact model ID is <id>」から読み取る（例：claude-opus-5）。
フロントマターの model に使う。
保存先は次のパスである。
~/obsidian/abekoh/_reports/YYYY/MM/YYYY-MM-DD-{summary}.md
{summary} は日本語で書く。
そのレポートが何についてのものかが、ファイル名だけで判別できることが条件だ。
/ \ : * ? " < > | # ^ [ ]、および空白例：
| セッションの内容 | ファイル名 |
|---|---|
| newspapers の朝刊が生成されなかった原因調査 | 2026-08-19-newspapers朝刊のトリアージ障害.md |
| 筋トレ記録アプリのデータモデル検討 | 2026-07-05-筋トレ記録アプリの設計検討.md |
| jj (Jujutsu) を触ってみた記録 | 2026-08-20-jujutsuの基本操作を試す.md |
| Obsidian レポート用スキルの作り直し | 2026-08-20-Obsidianレポートskillの改良.md |
デイリーノートに書くウィキリンクは、このファイル名から .md を除いたものと完全に一致させる。
一致しないとリンクが切れる。
フロントマターと # 見出し だけが固定である。
---
tags: [reports]
date: YYYY-MM-DD
model: {モデルID}
---
# {タイトル}
（本文）
タイトルはファイル名の {summary} と同じである必要はない。
ファイル名は一覧で見分けるための短い札、タイトルは中身を的確に言い表す句だと考えて、それぞれ最適なものを選ぶ。
見出し構成は固定しない。 セッションの性質に合った構成を自分で決める。 後述の「執筆の原則」と「構成の型」を判断材料にする。
_reports/YYYY/MM/ は存在しないことがあるので、必ず先に作る。
mkdir -p ~/obsidian/abekoh/_reports/YYYY/MM
そのうえで Write ツールでファイルを書く。
obsidian-cli の create は中間ディレクトリを作らないため、レポート本体の作成には使わない。
mkdir -p と Write ツールの組み合わせが、CLIの有無にかかわらず確実に動く唯一の経路である。
デイリーノートは ~/obsidian/abekoh/_daily/YYYY/MM/YYYY-MM-DD.md にある。
末尾に次のブロックを追記する。冒頭の空行と --- も書式の一部だ。
---
#reports
[[YYYY-MM-DD-{summary}]]
まず obsidian-cli が使えるかを試す。
obsidian daily:read >/dev/null 2>&1
使える場合：
obsidian daily:append content="\n---\n#reports\n\n[[YYYY-MM-DD-{summary}]]"
使えない場合：
Readツールで現在のデイリーノートを読み、末尾にブロックを足してWriteツールで書き戻す。
当日のデイリーノートがまだ存在しないときは、mkdir -p でディレクトリを作り、このブロックだけを内容として新規作成する。
以下は木下是雄『理科系の作文技術』の考え方を、セッションレポートという用途に合わせたものだ。 仕事の文書は自己表現の場ではなく、情報を正確かつ迅速に伝える道具である。 目指すのは、読者に負担をかけず、一通りにしか読めないように伝えることに尽きる。
「今日やったことを書く」ではレポートにならない。 「このレポートは、8/19の朝刊が出なかった原因が、Cron実行エッジの地理的偶然にあると示すために書く」のように、主張を一文で立ててから書き始める。 この一文が、材料を残すか捨てるかの判断基準になる。
一文書一主題を守る。 セッション中に無関係な話題を2つ扱ったなら、レポートも2本に分ける。
数か月後の自分は、まず「で、結局どうなったのか」を知りたい。 冒頭に、背景と結論を含む数文の要旨を置く。 そこを読めば、続きを読むべきかどうかを判断できる状態にする。
説明の順序は概観から細部へ向かう。 調査の時系列をそのまま並べると、最後まで読まないと全体像が見えない文書になる。
段落の最初の文を拾い読みしていくと、それだけで全体の要約になる。 これが理想の状態であり、書き終えたあとに実際に試して検証できる基準でもある。
editions テーブルで 8/19 分だけ status='failed' だった」のように、確認方法とともに書くこの区別を曖昧にすると、数か月後に「これは確認済みなのか、そのとき推測しただけなのか」が分からなくなり、レポートの価値が失われる。
言い回しの上では、責任の所在をぼかす表現を避ける。 「〜と思われる」は、自分の判断なら「〜と考える」、確認済みの事実なら「〜である」と書く。 一方で、本当に不確実なことを断定に変えてはいけない。 確度を落とすのではなく、確度を正確に示す。
数か月後の自分が同じ場所にたどり着けるように、具体的な手がかりを本文に埋める。
要約しすぎて手がかりを失うより、原文を短く引用するほうが後で役に立つ。
試して駄目だった方法、検討して却下した選択肢は、その理由とともに残す。 同じ轍を二度踏まないための情報であり、レポートの価値の少なくない部分がここにある。
型は出発点であって、当てはめる枠ではない。 セッションの性質に合わせて見出しを増やし、減らし、名前を変える。
原因究明・障害調査
# {対象}の{現象}の原因調査
## 概要 （何が起き、何が原因で、どう対処したか／しなかったか）
## 症状と切り分け
## 原因
## 対処と残課題
## 参考資料
技術選定・設計検討
# {対象}の{何を}検討
## 結論 （何を選んだか、なぜか）
## 前提と制約
## 検討した選択肢 （選択肢ごとに、採否の理由を添える）
## 未決事項
学習・調べもの
# {テーマ}
## 要点 （分かったことを数行で）
## {テーマに応じた見出し}
## 分からなかったこと
## 参考資料
実装作業
# {対象}に{機能}を実装
## 概要 （何を作り、どこまで動いているか）
## 設計判断 （なぜその作りにしたか）
## 変更点 （ファイルと変更内容）
## 動作確認
## 残作業
参考資料の節は、URLを並べるだけにしない。 そのページのどこが判断の根拠になったかを一行添えると、後から読み返す価値が生まれる。 参照が一つもなかったなら、節ごと省く。
書き終えたら、保存する前に次を確認する。
{summary} と、デイリーノートのウィキリンクが完全に一致しているかjapanese-tech-writing の表記規範（一文一行、ダッシュと中黒の扱い）に従っているかNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
abekohらしい文体で日本語の記事・文章を執筆する、または既存の文章をabekoh風に書き直すスキル。 「abekoh風に」「自分の文体で」「いつもの調子で」という依頼はもちろん、abekoh名義で公開する技術記事・ブログ記事・ 参加記・登壇レポートの執筆、下書き、リライト、添削を頼まれたときは必ず使うこと。 Zenn・個人ブログ・会社ブログ向けの記事執筆支援でも使う。
The English summary is being prepared. Showing the original description.
説明的な文章に緩急を設計するための規範。緩急を装飾ではなく認知モードの切替（観察→逡巡→断定→再観察）と未回収の緊張の管理として扱い、文の拍、段落の密度波形、節の入り方、緩みと駄文の判別、執筆後の機械的な点検手順を定める。読み物として読ませたい章・記事・解説文を生成するとき、または「密度はあるが平坦でおもしろくない」文章を診断・修正するときに使用する。
The English summary is being prepared. Showing the original description.
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
The English summary is being prepared. Showing the original description.
A relentless interview to sharpen a plan or design.
The English summary is being prepared. Showing the original description.
A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
The English summary is being prepared. Showing the original description.
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
The English summary is being prepared. Showing the original description.