with one click
with one click
| name | wiki-query |
| description | 既存 Wiki と posts に質問を投げて、引用付きで回答する |
| arguments | [{"name":"question","description":"質問文(自然言語)","required":true},{"name":"save","description":"回答を content/wiki/qa/<slug>.md に保存する場合 true","required":false}] |
推奨モデル: Sonnet 4.6 このスキルは grep + Read による検索と引用付き読解が主な仕事で、Opus の深い推論は過剰。 実行前に
/model sonnetで切り替えるとコスト効率が良い。 横断的に多数の wiki/post をクロスリードする質問でも、Sonnet で品質は十分。
content/wiki/{concepts,tools,guides} と content/posts/ を knowledge base として、自然言語の質問に対して 引用付きで 回答する skill。
karpathy の LLM Wiki パターンの第 3 操作 (Query) に対応する。執筆前の調査と、過去メモの再活用を兼ねる。
/blog を書く前の予習(手順 5.5 の Wiki-as-input を独立に走らせる感覚)/wiki-ingest (出力)、/wiki-lint (健全性) と並ぶ第 3 軸。
ハードコードしないこと。
PROJECT_DIR=$(git rev-parse --show-toplevel)
質問文を分解し、検索に効くキーワードを 2〜5 個程度抽出する。例:
| 質問 | 抽出キーワード |
|---|---|
| 「RAG とプロンプトインジェクションの関係は?」 | RAG, プロンプトインジェクション, prompt injection |
| 「Anolisa は何のツール?」 | Anolisa, anolisa |
| 「Hugo + GitHub Pages のセットアップ」 | Hugo, GitHub Pages, セットアップ |
英語・日本語の表記揺れも候補に含める。
重要 — 安全な grep の組み立て方:
grep -F(fixed string)で正規表現解釈を避ける(C++ [abc] a+b 等の誤マッチ防止)-e "$KW" または末尾 -- でオプション解釈を遮断(-x 等で始まるキーワード対策)$() を直接使わない(AGENTS.md の auto-mode ルール)。年などは別コマンドで変数に入れてから展開する# キーワードを変数に入れる(質問本文を直接 grep に渡さない)
KW="<extracted_keyword>"
# 3-1. Wiki セクション別に grep(concepts → tools → guides の順)
grep -rliF -e "$KW" "$PROJECT_DIR/content/wiki/concepts" 2>/dev/null
grep -rliF -e "$KW" "$PROJECT_DIR/content/wiki/tools" 2>/dev/null
grep -rliF -e "$KW" "$PROJECT_DIR/content/wiki/guides" 2>/dev/null
3-2. 上記 3 つで 1 件もヒットしなかった場合のみ posts/ にフォールバックする:
# Wiki ヒット 0 件の時だけ posts/ を grep
grep -rliF -e "$KW" "$PROJECT_DIR/content/posts" 2>/dev/null
posts のヒット件数が多すぎる(30 件超など)場合は 直近 1〜2 年に絞る。年は変数に入れてから引数に展開する:
YEAR=$(date +%Y)
PREV=$((YEAR - 1))
grep -rliF -e "$KW" \
"$PROJECT_DIR/content/posts/$YEAR" \
"$PROJECT_DIR/content/posts/$PREV" 2>/dev/null
優先順位:
concepts/ > tools/ > guides/ の順)合計 5〜10 ページ程度 を Read で読み込む。冗長になるので全件は読まない。
以下の Markdown フォーマットで回答する。出典がない主張は書かない(ハルシネーション防止)。
## 回答
{2〜10 段落程度の本文。引用元の Wiki / posts から得られた情報を統合して回答する}
## 参照
### Wiki
- [<タイトル>](/blogs/wiki/concepts/<slug>/) — {1 行要約: 該当箇所がどう関係するか}
- [<タイトル>](/blogs/wiki/tools/<slug>/) — {1 行要約}
### Posts
- [<タイトル>](/blogs/posts/YYYY/MM/<slug>/) ({YYYY-MM-DD}) — {1 行要約}
## 既知の限界
{以下のいずれか該当する場合のみ書く}
- Wiki にこのトピックの記事はない
- 関連 posts は見つかったが Wiki ページにまだ蒸留されていない(`/wiki-ingest` 候補)
- 直近 N ヶ月以降の情報のみで、それより古い情報は確認していない
「Wiki / posts に該当する情報はありません」と明示し、外部調査が必要な旨を返す。外部 URL を一次情報にして勝手に答えない(このスキルは knowledge base への問い合わせに専念する)。
## 回答
このリポジトリの Wiki / posts には該当する情報はありません。
`/blog "<topic>"` または `/gist-writer "<topic>"` で新規調査・執筆するのが適切です。
外部の最新情報が必要な場合は WebSearch / aegis_fetch を直接使ってください。
save: true が指定された、もしくはユーザーが明示的に依頼した場合:
content/wiki/qa/<slug>.md
<slug> は質問から生成(英数字とハイフン、小文字、長すぎる場合は短縮)---
title: "<質問の要約>"
description: "<1 行の答え>"
date: YYYY-MM-DD
lastmod: YYYY-MM-DD
aliases: []
related_posts:
- "/posts/YYYY/MM/<slug>/"
tags: ["qa", "<topic-tag>"]
---
hugo --gc でビルド確認v1 は「保存可能」だけ用意。実際に
qa/カテゴリを使うかはユーザー判断。デフォルトは保存しない。
/gist-writer / /blog の Wiki-as-input と同じ思想)/blogs/wiki/..., /blogs/posts/YYYY/MM/<slug>/ を使う入力:
/wiki-query "MCP って何?"
挙動:
MCP, Model Context Protocolcontent/wiki/concepts/mcp.md がヒット/blogs/wiki/concepts/mcp/ への参照を含める入力:
/wiki-query "claude code の hooks の使い分け"
挙動:
/wiki-ingest 候補として案内入力:
/wiki-query "MetaQuest3 のレビュー"
挙動:
/blog / /gist-writer の利用、または外部調査を案内/wiki-ingest <記事パス | カテゴリ | all> — 記事から Wiki ページを生成・更新する逆操作(出力側)/wiki-lint — Wiki の健全性チェック(孤立ページ、欠落リンク、古い記述)/blog, /gist-writer — Wiki を input に積みつつ新規記事を起こす公開済みの blog post から NotebookLM Audio Overview (日本語ポッドキャスト) を生成し、記事フロントマターに紐付ける
Hugo ブログ記事を新規作成し、PR を作成する
既存 blog post に対してファクトチェックを単独実行する。skill 自身が claim を抽出 → claim-atom-verifier (Haiku) を claim 単位で並列 fan-out する swarm を回す
wiki section または個別ページに対して claim 単位の swarm ファクトチェックを実行する。skill 親セッションが claim を抽出し claim-atom-verifier (Haiku) を並列起動する
Wiki ページの `lastmod` を section 別の閾値で評価し、touch されずに古びた候補を浮かせる。refresh サブコマンドで wiki-fact-checker agent を起動して claim を再検証する
ブログ記事を読み込んで Wiki ページを自動生成・更新する