Cursor Skills¶

Cursor の Agent に渡す専門手順（Agent Skills）の一覧である。 置き場の正はマシン上の ~/.cursor/skills/ である。 このページは、そのスナップショットを docs-hub に書いたものである。

関連: アーキテクチャ

置き場¶

プロジェクト配下の .cursor/skills/ は、いまは使っていない。

一覧（要約）¶

公開の GitHub / gist があるものは出典列にリンクを置く。 自作や手元だけのものは「自作」と書く。

各 Skill の概要¶

japanese-tech-writing¶

出典: gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d

日本語の技術文書（書籍の章、記事、解説、docs の推敲）向けの文章規範である。

扱う範囲の例は次である。

• 整形: 一文一行、中黒並列の回避、ダッシュの制限、定義の太字と「」の使い分け、脚注の使いどころ
• 段落: パラグラフライティング、一段落一トピック、接続の明示、論証の順序
• 論証: ツッコミどころの除去、根拠のない断定化の禁止、区別すべき対象の混同禁止
• 見出し: 「（毎回これ）」のような書き手のメタ補足を括弧で付けない
• 読み手: 負荷の管理、LLM っぽい空句や演出の抑制、冗長の排除

コーディングそのものではなく、日本語の地の文を書く・直すときに使う。

update-docs¶

出典: 自作（この環境用。公開リポジトリはない）

実装・設定・インフラ・運用の変更が、読者向けの docs/ と食い違わないようにする skill である。 更新が必要かどうかの判定は docs-lint が事後に行う。 この skill は書き方と系統の規約を担う。

手順の要点は次である。

1. docs/ の入口と系統（使い方 / アーキテクチャ / 取込 / 運用 / 参照）の地図を取る
2. 読者が知るべき差分だけを分類する
3. 既存ページを最小に直し、収まらないときだけページを足す
4. 「今どうなっているか」はアーキテクチャ、「何をするか」は運用に分ける
5. index と相対リンクを同期する

このリポジトリ群では、guide / architecture / intake / ops / reference と Zensical frontmatter の規約は skill 内の reference.md に置く。

docs-lint¶

出典: 自作

作業完了後に、docs が現状と食い違っていないか 事後チェック する skill である。 update-docs が「何を書くか」なら、こちらは「直す必要があるか」を判定して直す。

python3 ~/.cursor/skills/docs-lint/lint.py

• 終了コード 0 … cursor-skills.md と ~/.cursor/skills/ / ~/.cursor/rules/ が一致
• 終了コード 1 … 差分あり。docs/hub/architecture/cursor-skills.md などを直して再実行

Skills / Rules を追加・削除・改名したあと、コード変更のあと、作業完了の直前に走らせる。

tdd¶

出典: github.com/mattpocock/skills（tdd） / skills.sh のページ

機能追加やバグ修正を テストファーストで進める skill である。 言語非依存で、Python（pytest）などでも使える。

要点は次である。

• 公開インターフェース（seam）で振る舞いを検証する。実装詳細やプライベートに結合しない
• 縦スライス: 失敗するテストを1つ書いてから、通す最小実装を書く。全部のテストを先に並べない
• ループの各周で「良いテストとは何か」「モックの置き場」を参照する（同梱の tests.md / mocking.md）
• seam はユーザーと合意してから書く。未確認の seam にはテストを置かない

/tdd、「red-green-refactor」「テストファーストで」などで発動しやすい。 インストールは npx skills add https://github.com/mattpocock/skills --skill tdd -g -a cursor -y のあと、正本を ~/.cursor/skills/tdd に揃えている。

grilling¶

出典: github.com/mattpocock/skills（grilling） / skills.sh のページ

計画・判断・アイデアを、前提が揃った問い（frontier）のラウンドで聞き切る skill である。 grill-me と grill-with-docs の共通ループでもある。

要点は次である。

• 1ラウンドで、いま答えられる問いをまとめて出す。各問いに推奨回答を付ける
• 事実はコードや環境を調べる。ユーザーに聞くのは判断だけ
• frontier が空になるまで続け、合意の確認なしに実装へ進まない

/grilling、「grill」「grilling session」などで発動しやすい。 インストールは tdd と同じく npx skills add … -g -a cursor -y のあと、正本を ~/.cursor/skills/grilling に揃えている。

grill-me¶

出典: github.com/mattpocock/skills（grill-me） / skills.sh のページ

grilling を起動する入口である。コードやリポジトリを前提にせず、計画を聞き切る。 ファイルは書かない。明示で指名したときだけ読む（disable-model-invocation）。

/grill-me で発動する。

grill-with-docs¶

出典: github.com/mattpocock/skills（grill-with-docs） / skills.sh のページ

grilling と domain-modeling を同時に起動する入口である。 聞き切る途中で、用語が決まったら CONTEXT.md を更新し、逆転コストの高い判断だけ ADR にする。 明示で指名したときだけ読む。

/grill-with-docs で発動する。プロジェクトの用語を揃えたいときに使う。

domain-modeling¶

出典: github.com/mattpocock/skills（domain-modeling） / skills.sh のページ

プロジェクトの用語を磨き、用語集と ADR をその場で書く skill である。 CONTEXT.md を読むだけならこの skill ではない。モデルを変えるときに使う。

要点は次である。

• 既存の用語と食い違う言い方をすぐ指摘する
• 曖昧語には正規の語を提案する
• 実装詳細は CONTEXT.md に書かない。用語集だけにする
• ADR は「逆転しにくい」「文脈なしでは驚く」「本当にトレードオフがある」の三点が揃ったときだけ

/domain-modeling、用語の整理、CONTEXT.md、ADR の話で発動しやすい。

ponytail¶

出典: github.com/DietrichGebert/ponytail（skills/ponytail）

「動く最小」を選ぶコーディングモードである。 怠惰は手抜きではなく、過剰構築を避けるという意味である。

問題を読んで流れを追ったあと、次の梯子で最初に足りる段で止める。

1. そもそも要るか（YAGNI）
2. 既存コードに無いか
3. 標準ライブラリで足りるか
4. プラットフォーム標準機能で足りるか
5. 既に入れている依存で足りるか
6. 一行で書けるか
7. それでも必要なら最小のコード

強度は lite / full（既定） / ultra。 /ponytail、lazy、yagni、過剰設計への不満などで発動しやすい。 意図的に角を落とした実装は # ponytail: 上限, 見直す条件 のコメントを残す。 止めるときは「stop ponytail」「normal mode」。

ponytail-review¶

出典: DietrichGebert/ponytail（skills/ponytail-review）

差分だけを見て、過剰設計・不要な複雑さに限定したレビューをする。 正しさ・セキュリティ・性能は対象外である。

指摘は一行で、場所・タグ・削るもの・代わりを書く。 タグ例は delete:、stdlib:、native:、yagni:、shrink: である。 末尾に削減できそうな行数の目安を出し、直す作業自体はしない（一覧だけ）。

ponytail-audit¶

出典: DietrichGebert/ponytail（skills/ponytail-audit）

ponytail-review と同じ観点だが、対象が リポジトリ全体 である。 削れるもの・stdlib 置換・YAGNI 違反などを、効果の大きい順に並べる。 こちらも指摘だけで、自動修正はしない。ワンショットである。

ponytail-debt¶

出典: DietrichGebert/ponytail（skills/ponytail-debt）

コード中の ponytail: コメントを集め、意図的に先送りした簡略化の台帳にする。 各行から「何を簡略化したか」「上限」「見直すトリガー」を抜き出す。 トリガーが無いものは腐敗しやすいとして印を付ける。 読み取り専用が基本で、ファイルに残すときは明示してから書く。

ponytail-gain¶

出典: DietrichGebert/ponytail（skills/ponytail-gain）

公開ベンチマーク（定番タスク数本 × 複数モデル）の中央値を、ASCII のスコアボードとして表示するだけである。 「このリポジトリで何行減った」といった数値は出さない。 実リポジトリ側の数字は /ponytail-debt や /ponytail-audit を見る。 モード変更もファイル書き込みもしない。

ponytail-help¶

出典: DietrichGebert/ponytail（skills/ponytail-help）

ponytail 一式の強度・各 skill・止め方・既定モード設定の早見表を出す。 表示専用で、モードは変えない。

Rules（Skills とは別）¶

Rules は Skills の自動判定とは別に、セッションへ注入されやすい。 ponytail skill 本体より短く、常時の下限として効く想定である。 docs-auto-push は docs 作業の完了条件として push まで含める。

発動のしかた¶

Skills は次のどちらかで効く。

1. 明示: チャットで /skill名 や「ponytail で」などと指名する
2. 自動: Agent がタスクと description を照合し、関連しそうなら読む

自動は「毎回必ず」ではない。 コーディング依頼なら ponytail が選ばれやすく、テストファーストや red-green なら tdd、計画の聞き取りや「grill」なら grilling、用語・CONTEXT.md・ADR なら domain-modeling、docs の日本語推敲なら japanese-tech-writing、作業完了前の同期確認なら docs-lint が選ばれやすい。 grill-me と grill-with-docs は明示指名が必要である。

ponytail.mdc は Rules なので、Skills の自動判定とは別に常時コンテキストへ入る想定である。 止めるときは「stop ponytail」「normal mode」と書く。

追加・削除したとき¶

~/.cursor/skills/ や ~/.cursor/rules/ を変えたら、作業の最後に docs-lint を走らせる。

python3 ~/.cursor/skills/docs-lint/lint.py

指摘があればこのページの表と各概要を直し、0 になるまで再実行する。 公開 upstream があるものは出典リンクも置く。 入口の表（docs-hub、アーキテクチャ）は、ページ名・説明が変わるときだけ直す。