kumewata/frontmatter
config/agents/skills/frontmatter/SKILL.md
任意のドキュメントに YAML Front Matter を追加し、ドキュメント検索を効率化するためのスキル。技術ドキュメント、設計書、メモ、タスク管理の4種類のテンプレートを提供。
data-ai
Updated Apr 15, 2026
$ install --global
skillsauthnpx skillsauth add kumewata/dotfiles frontmatterInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 15, 2026, 1:10 PM4.1s5 files scanned
SKILL.md
- name:
- frontmatter
- description:
- 任意のドキュメントに YAML Front Matter を追加し、ドキュメント検索を効率化するためのスキル。技術ドキュメント、設計書、メモ、タスク管理の4種類のテンプレートを提供。
- allowed-tools:
- Read, Write, Edit
frontmatter スキル
任意のドキュメントに YAML Front Matter を追加し、構造化メタデータによる効率的な検索を可能にするスキルです。
スキルの目的
- ドキュメントに構造化メタデータ（YAML Front Matter）を追加
- ドキュメントタイプ別のテンプレート提供
- 状況ベース検索（use_when）を可能にする
- タグ・キーワードによるカテゴリ分類と精密検索
- created_at と updated_at の自動設定
使用タイミング
このスキルは以下のタイミングで使用してください：
- 新規ドキュメント作成時: テンプレートから新しいドキュメントを作成したいとき
- 既存ドキュメント更新時: 既存のドキュメントに Front Matter を追加したいとき
- ドキュメント整理時: プロジェクトのドキュメントを検索可能にしたいとき
モード1: 既存ドキュメントへの Front Matter 追加
目的
既存のドキュメントに YAML Front Matter を追加し、検索可能にします。
手順
-
対象ドキュメントを読み込む
Read('<file_path>') -
ドキュメントタイプを特定
ユーザーに以下から選択してもらう：
- technical-doc: API ドキュメント、技術仕様、ハウツーガイド
- design-doc: アーキテクチャ設計、システム設計、コンポーネント設計
- note: 会議メモ、調査メモ、学習ノート
- task: タスクリスト、プロジェクト管理、進捗管理
オプション: ドキュメントの内容から自動判別を提案（最終決定はユーザー）
- タイトルや見出しに「設計」「アーキテクチャ」→ design-doc
- タイトルや見出しに「API」「使い方」「手順」→ technical-doc
- タイトルや見出しに「タスク」「TODO」「進捗」→ task
- その他 → note
-
Front Matter フィールドを記入
ユーザーに以下のフィールドを記入してもらう：
新規作成の場合（必須）:
title: ドキュメントのタイトル（簡潔に）tags: カテゴリタグ（3-8個推奨）use_when: 参照すべき状況（最重要！）keywords: 固有名詞、API名、技術名
既存ドキュメント更新の場合（最低限必須）:
title: ドキュメントのタイトルuse_when: 参照すべき状況
推奨フィールド:
tags: カテゴリタグkeywords: 固有名詞
オプションフィールド:
related: 関連ドキュメントのリストstatus: draft, review, approved（design-doc のみ）completion: 0%-100%（task のみ）
-
created_at と updated_at を自動設定
- 新規作成: 現在日付（YYYY-MM-DD形式）を設定
- 既存更新: updated_at のみを現在日付に更新
-
Edit ツールで Front Matter を挿入
ファイルの先頭に YAML Front Matter ブロックを挿入
モード2: 新規ドキュメントのテンプレート作成
目的
テンプレートから新しいドキュメントを作成します。
手順
-
ドキュメントタイプを選択
ユーザーに以下から選択してもらう：
- technical-doc: 技術ドキュメント用
- design-doc: 設計書用
- note: メモ用
- task: タスク管理用
-
テンプレートを読み込む
Read('~/.claude/skills/frontmatter/templates/<type>.md') -
プレースホルダーを記入
ユーザーに以下を記入してもらう：
{タイトル}: ドキュメントのタイトル{カテゴリ},{技術スタック}: タグ{状況1},{状況2}: use_when の具体的な状況{キーワード}: 固有名詞、API名など
-
created_at と updated_at を自動設定
- 現在日付（YYYY-MM-DD形式）を設定
-
Write ツールでファイルを作成
Write('<new_file_path>', content)
Front Matter フィールドの説明
必須フィールド（新規作成時）
title
- 目的: ドキュメントの簡潔なタイトル
- フォーマット: 文字列
- 例:
Nix Flakes の使い方,API 設計書 - ガイドライン:
- 1行で簡潔に
- 検索しやすい明確な名前
- 本文の H1 とは別（メタデータ用）
tags
- 目的: カテゴリ分類、グルーピング
- フォーマット: リスト形式
[タグ1, タグ2, ...] - 例:
[設計, アーキテクチャ, Nix],[技術ドキュメント, API, REST] - ガイドライン:
- 3-8個推奨
- 広いカテゴリから狭いカテゴリへ
- 日本語タグを基本とする（英語も可）
- 混在は避ける
use_when
- 目的: 状況ベース検索（最重要フィールド）
- フォーマット: 複数行文字列（
>で折り返し） - 例:
use_when: > このドキュメントを参照すべき状況： - Nix Flakes の基本的な使い方を確認したいとき - flake.nix の構造を理解したいとき - ガイドライン:
- 「こういう状況のときにこのファイルを見る」を明確に
- ユーザーが実際に使う言葉で記述
- 2-5個の状況を列挙
keywords
- 目的: 固有名詞による精密検索
- フォーマット: リスト形式
[キーワード1, キーワード2, ...] - 例:
[Nix, Home Manager, flake.nix],[REST API, OpenAPI, Swagger] - ガイドライン:
- 固有名詞（API名、技術名、コンポーネント名）
- 完全一致検索で使われる
- 3-10個推奨
推奨フィールド
related
- 目的: 関連ドキュメントへのリンク
- フォーマット: リスト形式（相対パスまたはファイル名）
- 例:
[design.md, requirements.md],[../setup/installation.md] - ガイドライン:
- 同一プロジェクト内の関連ファイル
- 相対パスで記述
オプションフィールド（ドキュメントタイプ別）
status (design-doc のみ)
- 目的: 設計書のステータス管理
- 値:
draft,review,approved - 例:
status: draft
completion (task のみ)
- 目的: タスクの完了率
- 値:
0%-100% - 例:
completion: 75%
自動設定フィールド
created_at
- 目的: ドキュメント作成日
- フォーマット:
YYYY-MM-DD - 例:
created_at: 2026-02-23 - 自動設定: 新規作成時に現在日付を設定
- 一度設定したら変更しない
updated_at
- 目的: ドキュメント最終更新日
- フォーマット:
YYYY-MM-DD - 例:
updated_at: 2026-02-23 - 自動設定: 新規作成・更新時に現在日付を設定
- スキル起動時に自動更新
ドキュメントタイプ別ガイドライン
technical-doc: 技術ドキュメント用ガイド
対象ドキュメント:
- API ドキュメント
- 技術仕様書
- ハウツーガイド
- チュートリアル
推奨 tags:
[技術ドキュメント, <カテゴリ>, <技術スタック>]- 例:
[技術ドキュメント, API, REST],[技術ドキュメント, 環境構築, Nix]
use_when の例:
use_when: >
このドキュメントを参照すべき状況：
- API の使い方を確認したいとき
- エラーコードの意味を調べたいとき
- 認証方法を確認したいとき
keywords の例:
- API名、エンドポイント名、技術名
- 例:
[REST API, /users, OAuth2]
design-doc: 設計書用ガイド
対象ドキュメント:
- アーキテクチャ設計
- システム設計
- コンポーネント設計
- データベース設計
推奨 tags:
[設計, アーキテクチャ, <技術スタック>]- 例:
[設計, アーキテクチャ, マイクロサービス],[設計, データベース, PostgreSQL]
use_when の例:
use_when: >
このドキュメントを参照すべき状況：
- システムアーキテクチャの全体像を理解したいとき
- コンポーネント間の依存関係を確認したいとき
- 設計判断の理由を知りたいとき
keywords の例:
- コンポーネント名、パターン名、ライブラリ名
- 例:
[UserService, CQRS, PostgreSQL]
オプションフィールド:
status: draft/review/approved
note: メモ用ガイド
対象ドキュメント:
- 会議メモ
- 調査メモ
- 学習ノート
- トラブルシューティングメモ
推奨 tags:
[メモ, <カテゴリ>]- 例:
[メモ, 会議],[メモ, 調査],[メモ, トラブルシューティング]
use_when の例:
use_when: >
このドキュメントを参照すべき状況：
- 2026年2月の定例会議の内容を確認したいとき
- Nix のエラー対処法を調べたいとき
keywords の例:
- 会議名、調査対象、エラーメッセージ
- 例:
[2026年2月定例会議, Nix, build error]
task: タスク管理用ガイド
対象ドキュメント:
- タスクリスト
- プロジェクト管理
- 進捗管理
推奨 tags:
[タスク管理, <プロジェクト名>, <フェーズ>]- 例:
[タスク管理, frontmatter実装, Phase1]
use_when の例:
use_when: >
このドキュメントを参照すべき状況：
- frontmatter 実装の進捗を確認したいとき
- 次に着手すべきタスクを確認したいとき
keywords の例:
- プロジェクト名、主要タスク名
- 例:
[frontmatter, テンプレート作成, SKILL.md作成]
オプションフィールド:
status: pending/in-progress/completedcompletion: 0%-100%
記入例
技術ドキュメントの例
---
title: Nix Flakes の使い方
tags: [技術ドキュメント, 環境構築, Nix]
use_when: >
このドキュメントを参照すべき状況：
- Nix Flakes の基本的な使い方を確認したいとき
- flake.nix の構造を理解したいとき
- Nix コマンドの実行方法を調べたいとき
keywords: [Nix, Flakes, flake.nix, nix run, nix build]
related: [installation.md, troubleshooting.md]
created_at: 2026-02-23
updated_at: 2026-02-23
---
設計書の例
---
title: マイクロサービスアーキテクチャ設計
tags: [設計, アーキテクチャ, マイクロサービス]
use_when: >
このドキュメントを参照すべき状況：
- システムアーキテクチャの全体像を理解したいとき
- サービス間通信の仕様を確認したいとき
- API Gateway の設計判断を知りたいとき
keywords: [UserService, OrderService, API Gateway, gRPC]
related: [api-design.md, data-flow.md]
status: review
created_at: 2026-02-23
updated_at: 2026-02-23
---
メモの例
---
title: 2026年2月定例会議メモ
tags: [メモ, 会議]
use_when: >
このドキュメントを参照すべき状況：
- 2026年2月の定例会議の内容を確認したいとき
- 次回アクションアイテムを確認したいとき
keywords: [2026年2月, 定例会議, アクションアイテム]
created_at: 2026-02-23
updated_at: 2026-02-23
---
タスク管理の例
---
title: frontmatter スキル実装タスク
tags: [タスク管理, frontmatter実装, Phase1]
use_when: >
このドキュメントを参照すべき状況：
- frontmatter 実装の進捗を確認したいとき
- 次に着手すべきタスクを確認したいとき
keywords: [frontmatter, テンプレート作成, SKILL.md]
status: in-progress
completion: 50%
created_at: 2026-02-23
updated_at: 2026-02-23
---
重要な注意事項
YAML 構文
- Front Matter は
---で囲む（YAML 標準） - フィールド名はスネークケース（
use_when, notuseWhen） - 複数行文字列は
>で折り返す - リストは
[要素1, 要素2]または改行 +- 要素形式
use_when フィールドの重要性
use_when が最も重要なフィールドです。これにより「タイトルでは区別できない意図ベース検索」が実現します。
- タイトルだけでは「何について書かれているか」しか分からない
- use_when により「どういう状況で使うか」が明確になる
- 検索時に最優先でマッチングされる
自動更新のタイミング
- created_at: 新規作成時のみ設定、その後は変更しない
- updated_at: 新規作成時と frontmatter スキル起動時に自動更新
- 日付ソース: Claude Code の実行環境の現在日付（UTC ベース）
- フォーマット: YYYY-MM-DD（ISO 8601）
- トリガー: スキルが Write または Edit ツールでファイルを保存するタイミング
doc-search エージェントとの連携
このスキルで追加した Front Matter は、doc-search エージェントで検索可能になります。
検索優先順位:
- use_when フィールド（状況ベース検索）
- keywords フィールド（精密検索）
- tags フィールド（カテゴリ検索）
- 全文検索（最終手段）
チェックリスト
Front Matter 追加前に確認:
- [ ] ドキュメントタイプは適切か？
- [ ] title は簡潔で分かりやすいか？
- [ ] use_when に具体的な状況が記述されているか？
- [ ] keywords に固有名詞が含まれているか？
- [ ] tags は3-8個で適切か？
Front Matter 追加後に確認:
- [ ] YAML 構文は正しいか？（--- で囲まれているか）
- [ ] created_at と updated_at が設定されているか？
- [ ] プレースホルダー（{...}）が残っていないか？
- [ ] ファイルが正しく保存されているか？
Related Skills
kumewata/waza-eval
tools
VerifiedTrustedCommunity
Use when creating a new skill or making a substantial change to an existing skill and you also need to design, update, or review Waza-based executable evaluations. This includes deciding whether Waza is warranted, mapping `evals.json` cases into Waza tasks, choosing fixtures and graders, selecting a valid model with `waza models --json`, and running a local-first `waza run` workflow. Do NOT use for installing the Waza CLI itself or for general skill-authoring advice that does not involve Waza; use `skill-creator` for skill design and this skill for the Waza execution layer. Trigger especially when the user mentions Waza, `waza run`, `waza models`, executable evals, compare, graders, fixtures, or wants to validate a skill change with model-backed evaluation.
SKILL.mdUpdated Jun 3, 2026
kumewata/cc-delegate
tools
VerifiedTrustedCommunity
Use when the user wants Codex to ask Claude Code for a second opinion or review on code, docs, diffs, PR changes, or design notes without modifying files. This delegates bounded review-only analysis through the Claude Code CLI (`claude -p`). Do NOT use for implementation or file edits; keep this skill review-only. Trigger especially when the user says ask Claude, ask Claude Code, cc-delegate, Claude review, second opinion from Claude, compare Codex and Claude, or review this diff/document with Claude Code.
SKILL.mdUpdated May 29, 2026
kumewata/airflow
tools
VerifiedTrustedCommunity
Airflow DAG development skill for writing, reviewing, testing, and debugging Apache Airflow workflows. Use whenever the user mentions Airflow, DAGs, tasks, operators, sensors, schedules, retries, catchup, DAG import errors, DAG parse performance, or workflow orchestration in Python. Also use for Amazon MWAA / Managed Workflows for Apache Airflow work, including MWAA DAG deployment, requirements.txt, plugins.zip, aws-mwaa-docker-images, S3 DAG folders, CloudWatch logs, and MWAA-specific dependency or IAM issues.
SKILL.mdUpdated May 17, 2026
kumewata/tone
development
VerifiedTrustedCommunity
Use when the user asks for help drafting a GitHub PR description, a PR review comment, or a Slack post in their own tone (i.e., their personal writing voice). The skill detects the context (formal for PR / review, casual for Slack) and target_type (pr_description, pr_review, slack), drafts the body with an explicit reflection step that avoids verbose, mechanical phrasing, and stages the draft to `~/.local/state/tone/drafts/` via `tone-stage-draft.sh`. The user later runs `/tone-capture <url>` after posting, which pairs the staged draft with the final body to build a corpus for future tone tuning. Trigger especially when the user mentions PR description, PR review comment, Slack post, または「文を書いて」「文面を作って」「自分らしく」「トーン」「tone」.
SKILL.mdUpdated May 1, 2026