name	til
description	TIL（Today I Learned）記事を書く。「TIL書いて」「〇〇についてTIL記事にして」などをトリガーとする

TIL記事の草案をMarkdownで出力する。

記事の出力先は content/blog/entries/{slug}/index.md。slugはスネークケースで英語。

frontmatter

---
title: "記事タイトル"
date: "YYYY-MM-DD"
description: "短い補足（空でもOK）"
tags:
  - Tag1
  - Tag2
---

titleは日本語で、内容を端的に表す。「〜する」「〜した」「〜のメモ」のようなパターンが多い
descriptionは一言程度。空文字のこともある
tagsは技術名・ツール名を2-4個程度

執筆スタイルガイド（既存TIL記事233件から抽出）

文体・語調

常体（だ・である調）がベースだが堅くない。「〜した」「〜だった」「〜する」で終わる文が多い
カジュアルな独り言トーン。作業メモ・ログを公開している感覚
一文は短め（1-2文で段落を区切る）。改行を多めに入れて読みやすくする
体言止めを適度に使う
三点リーダー「…」で余韻を残すことがある（「知らなかった…」「難しい…」）
「w」は使わないが、「…」「まぁ」「なー」などの口語的な表現は自然に使う

構成・展開パターン

TIL記事は以下の流れが基本:

導入（1-3行）: なぜこれをやったか、きっかけや背景を率直に述べる
- 例: 「〜していたときに〜で怒られた」「〜が使えるようになっていた」「なんとなく知ってはいたが使ってみたことがなかった」
本題: コードブロック・手順・設定が中心。説明は最小限
結果・動作確認: 実行結果やスクリーンショット
締め（1-2文）: さらっと終わる。明示的な「まとめ」セクションがないことも多い
余談（あれば）: 関連する小話や派生の気づき

冒頭に公式ドキュメントや参考リンクを配置することが多い
「まとめ」や「おわりに」がなくても自然。最後の事実記述で終わってよい
blog記事と比べて短い。不要な説明は省く

読者との関係性

読者に語りかけない。「あなた」とは呼ばない
想定読者は「将来の自分」と「同じことをやりたい人」
前提知識は中級者以上向け。基礎的な技術用語の説明は不要
記事テーマの中核概念だけ簡潔に説明するか、公式ドキュメントへのリンクで代替
説教的にならない。「自分がやったらこうだった」という報告型

思考・主張のクセ

留保が多い。断言を避ける
- 「〜っぽい」「〜良さそう」「〜かな?」「〜かなと」「〜気がする」を自然に使う
失敗談・試行錯誤を正直に書く
- 「怒られた」（エラーを擬人化）
- 「だめだった」「ちょっと調べる気力がなくなった」「疲れている」
- 試行錯誤のプロセスをそのまま残す（成功だけでなく失敗パスも書く）
対比は「AだがBだった」「〜だが…まぁ」のように軽く出す程度

語彙・表現の傾向

よく使うフレーズ:

「ということで」（話題転換・結論への導入）
「良さそう」「よさそう」（留保付きの肯定）
「〜かな?」「〜かなと」（柔らかい主張）
「雑に」「雑だが」（カジュアルな自己評価）
「怒られた」（エラー・警告を受けたことの表現）
「知らなかった…」（素直な発見）
「せっかくなので」（追加作業の導入）
「〜って感じ」「〜という感じ」
「まぁ」（留保・譲歩）
「〜のよう」「〜らしい」（伝聞・推測）
「これでOKそう…」「これでめでたく〜」（締めの表現）
「こんな感じ」（コードや設定の紹介時）

使わないもの:

比喩・例え話はほぼ使わない。事実ベース
「w」「笑」は使わない
絵文字は使わない

フォーマット

H2で大セクション、H3で細分化。H4以降は基本使わない
コードブロックを多用。言語指定付き（shell, typescript, ```ruby など）
diffフォーマットも変更点の説明に使う
箇条書きも多用するが、文章→コード→文章の流れが基本
外部リンク（公式ドキュメント・GitHub・MDN等）を豊富に配置
- リンクは [タイトル](URL) 形式。引用ブロックで公式ドキュメントを引くことも
画像は ![alt](ファイル名.png) で配置（必須ではない）
textlintのdisable/enableコメントは不要（草案なので）
ユーザー名がわかるようなディレクトリなどの情報は user に差し替える

注意事項

セッションのログ（会話の中での作業内容）がある場合はそれを基に書く
セッションのログから把握できない背景・モチベーションがある場合は質問する
オリジナリティが出るようなポイント（ハマりどころ、意外な発見）を厚めに記載する
前提知識やツールの説明は軽く。リンクで補足
コード片は必須。実行結果も含めると良い
長くなりすぎない。TILは「今日知ったこと」の記録なので、コンパクトにまとめる

Más de este repositorio

mismo repositorio

slide-style-terminal

swfz/dotfiles

ターミナルウィンドウ風のエンジニア向けダークスライドデッキ (信号機ドット+パスのタイトルバー / ピンクの ❯ シェブロン見出し / tree コマンド風の結線ツリー箇条書き / ファイル名タブ付き多色コード / DuckDB CLI 風 ASCII テーブル出力 / powerline・tmux 風ステータスライン / 点滅カーソル / 16:9 レターボックス) を、単一 HTML で生成し Artifact として公開するスキル。「ターミナル風スライド」「あのダークなスライドスタイルで」「slide-style-terminal」「LT資料をあのスタイルで」などの依頼や、コマンド出力・SQL・コードを見せる技術系のプレゼン/LT/発表資料を作る場面で使う。GUI操作の集計レポート (drilldown-report / timeseries-report / gui-report) とは別物 (あちらはデータ可視化)。

2026-07-023

push-pr

swfz/dotfiles

GitHubへpush, Pull Requestを作成する

2026-07-023

ship

swfz/dotfiles

commit → push-pr → assign-projects をまとめて実行し、コミットからPR作成・Project紐づけまでを一気に行う。トリガー例：「shipして」「コミットからPR作成まで一気にやって」「PRまで出してプロジェクトに紐づけて」

2026-07-023

artifact-review-comments

swfz/dotfiles

HTML文書に「選択範囲コメント＋右サイドのコメント一覧」レビューレイヤーを注入してから公開するスキル。HTMLで資料・ドキュメント・提案を作り、他の人に共有して一緒に見ながらレビューしてもらい、もらった指摘をコメントとして残し、最後にコメント一覧をコピーしてClaude Codeに貼って修正する——という往復ワークフロー全体を支える。アーティファクト(claude.aiの共有ページ)として公開する前、あるいは共有用のスタンドアロンHTMLを作るときに使う。「HTMLにコメント機能をつけて」「公開前にレビューできるように」「アーティファクトに指摘を入れられるように」「この資料を共有してレビューしてもらいたい」「選択してコメントできるHTML」「フィードバックを集められるページ」などの依頼では、明示的に「スキル」と言われなくても積極的に使う。注意: これはレビュー用のコメント注釈レイヤーであり、データ集計の可視化レポート(drilldown-report / timeseries-report / gui-report)とは別物。

2026-06-193

blog

swfz/dotfiles

「記事化して」「〇〇について記事にして」などの言葉をトリガーとする

2026-05-093

deps-handler

swfz/dotfiles

RenovateボットやDependabotによるPR（依存関係更新）の対応を自動化するスキル。リリースノートの確認、CI失敗の修正、反復的なpush→CI確認のサイクルを実施する。トリガー例：「Renovateの対応をして」「renovateのPRをマージして」「依存関係の更新PRを処理して」「renovate対応」「dependabotの対応をして」「dependabotのPRをマージして」「dependabot対応」

2026-05-083

name	til
description	TIL（Today I Learned）記事を書く。「TIL書いて」「〇〇についてTIL記事にして」などをトリガーとする

TIL記事の草案をMarkdownで出力する。

記事の出力先は content/blog/entries/{slug}/index.md。slugはスネークケースで英語。

frontmatter

---
title: "記事タイトル"
date: "YYYY-MM-DD"
description: "短い補足（空でもOK）"
tags:
  - Tag1
  - Tag2
---

titleは日本語で、内容を端的に表す。「〜する」「〜した」「〜のメモ」のようなパターンが多い
descriptionは一言程度。空文字のこともある
tagsは技術名・ツール名を2-4個程度

執筆スタイルガイド（既存TIL記事233件から抽出）

文体・語調

常体（だ・である調）がベースだが堅くない。「〜した」「〜だった」「〜する」で終わる文が多い
カジュアルな独り言トーン。作業メモ・ログを公開している感覚
一文は短め（1-2文で段落を区切る）。改行を多めに入れて読みやすくする
体言止めを適度に使う
三点リーダー「…」で余韻を残すことがある（「知らなかった…」「難しい…」）
「w」は使わないが、「…」「まぁ」「なー」などの口語的な表現は自然に使う

構成・展開パターン

TIL記事は以下の流れが基本:

導入（1-3行）: なぜこれをやったか、きっかけや背景を率直に述べる
- 例: 「〜していたときに〜で怒られた」「〜が使えるようになっていた」「なんとなく知ってはいたが使ってみたことがなかった」
本題: コードブロック・手順・設定が中心。説明は最小限
結果・動作確認: 実行結果やスクリーンショット
締め（1-2文）: さらっと終わる。明示的な「まとめ」セクションがないことも多い
余談（あれば）: 関連する小話や派生の気づき

冒頭に公式ドキュメントや参考リンクを配置することが多い
「まとめ」や「おわりに」がなくても自然。最後の事実記述で終わってよい
blog記事と比べて短い。不要な説明は省く

読者との関係性

読者に語りかけない。「あなた」とは呼ばない
想定読者は「将来の自分」と「同じことをやりたい人」
前提知識は中級者以上向け。基礎的な技術用語の説明は不要
記事テーマの中核概念だけ簡潔に説明するか、公式ドキュメントへのリンクで代替
説教的にならない。「自分がやったらこうだった」という報告型

思考・主張のクセ

留保が多い。断言を避ける
- 「〜っぽい」「〜良さそう」「〜かな?」「〜かなと」「〜気がする」を自然に使う
失敗談・試行錯誤を正直に書く
- 「怒られた」（エラーを擬人化）
- 「だめだった」「ちょっと調べる気力がなくなった」「疲れている」
- 試行錯誤のプロセスをそのまま残す（成功だけでなく失敗パスも書く）
対比は「AだがBだった」「〜だが…まぁ」のように軽く出す程度

語彙・表現の傾向

よく使うフレーズ:

「ということで」（話題転換・結論への導入）
「良さそう」「よさそう」（留保付きの肯定）
「〜かな?」「〜かなと」（柔らかい主張）
「雑に」「雑だが」（カジュアルな自己評価）
「怒られた」（エラー・警告を受けたことの表現）
「知らなかった…」（素直な発見）
「せっかくなので」（追加作業の導入）
「〜って感じ」「〜という感じ」
「まぁ」（留保・譲歩）
「〜のよう」「〜らしい」（伝聞・推測）
「これでOKそう…」「これでめでたく〜」（締めの表現）
「こんな感じ」（コードや設定の紹介時）

使わないもの:

比喩・例え話はほぼ使わない。事実ベース
「w」「笑」は使わない
絵文字は使わない

フォーマット

H2で大セクション、H3で細分化。H4以降は基本使わない
コードブロックを多用。言語指定付き（shell, typescript, ```ruby など）
diffフォーマットも変更点の説明に使う
箇条書きも多用するが、文章→コード→文章の流れが基本
外部リンク（公式ドキュメント・GitHub・MDN等）を豊富に配置
- リンクは [タイトル](URL) 形式。引用ブロックで公式ドキュメントを引くことも
画像は ![alt](ファイル名.png) で配置（必須ではない）
textlintのdisable/enableコメントは不要（草案なので）
ユーザー名がわかるようなディレクトリなどの情報は user に差し替える

注意事項

セッションのログ（会話の中での作業内容）がある場合はそれを基に書く
セッションのログから把握できない背景・モチベーションがある場合は質問する
オリジナリティが出るようなポイント（ハマりどころ、意外な発見）を厚めに記載する
前提知識やツールの説明は軽く。リンクで補足
コード片は必須。実行結果も含めると良い
長くなりすぎない。TILは「今日知ったこと」の記録なので、コンパクトにまとめる