resume

Interviews the user relentlessly to build career self-knowledge for a job change, career profile work, or negotiation prep. Grounds every question first in the private Obsidian vault (profile/*.md, prior grill logs, grill-ledger.md) and this repo's docs/resume-update-plan.md / docs/action-plan.md gaps, then extracts concrete episodes, chained "why" reasoning, blind spots against the user's own written record, and a decision journal with mandatory confidence follow-ups. Extends the grilling one-question-at-a-time engine; never uses selection-style dialog tools (AskUserQuestion). Use for career or job-change consultation, career grilling, resume grilling, or filling profile/*.md stubs — trigger phrases include "キャリア壁打ち", "キャリア相談", "転職相談", "経歴の壁打ち", "career grilling", "career interview", "profileを埋めたい", "暗黙知を掘り出して". Writes nothing to the private vault without prior /add-dir, and never writes compensation figures, employer/target-company names, or reasons for leaving into this public repository.

設計検討から出てきた決定について「これは ADR (Architecture Decision Record) に値するか」を判定し、値する場合のみ [adr-tools](https://github.com/npryce/adr-tools) の `adr new` コマンドで Michael Nygard 形式の ADR を生成するスキル。**コードを読めばわかる決定は ADR にしない**。値する基準は (1) 将来「なぜこうした?」と疑問になりうる (2) 容易に変更できない one-way door (3) 別の選択肢があり却下した のいずれか。番号採番・slug 生成・テンプレ展開・supersede リンクの相互更新は全て `adr new` / `adr new -s` / `adr new -l` に委譲する。`design` Step 4 から呼ばれる主経路、設計判断を残したい時、「これ ADR にして」「決定記録残して」「architecture decision」「設計判断のドキュメント」のような要請、いずれでも必ず起動すること。本スキルは ADR 単体の生成と判定までで、設計検討自体や実装には関与しない。詳細仕様や API ドキュメントの代わりに ADR を使うことは推奨しない (ADR は「決定」の記録、「使い方」のドキュメントではない)。adr-tools が未インストールの場合は導入手順を提示し、勝手に install しない。

PR 作成後・push 後の CI が失敗した際に、ログから root cause を特定し、修正コミットを当てて再 push する自己修復ループを駆動するスキル。**root cause 不明なまま再試行しない** (NO FIXES WITHOUT ROOT CAUSE)。3 連続失敗で停止し、architecture を疑ってユーザに escalate (3-failure architecture gate)。`pr-review-respond` Phase E から呼ばれる主経路、`gh pr create` 直後で CI が回り始めた時、CI が赤になった時、「CI 直して」「ビルド失敗してる」「テストが落ちてる on CI」「pipeline 緑にして」のような要請、いずれでも必ず起動すること。本スキルは CI ログ取得 → root cause 仮説 → 修正 → 再 push → 再 watch のループ駆動と、停止判断を担う。修正コード自体は呼出側スキル (`tdd` / `tidy-first` / `code-review`) を経由する。flaky / 環境問題と判定したら retry-to-green は禁止 — 原因分類してユーザに返す。

実装が完了した後・PR 作成前に、変更差分を白紙の subagent にレビューさせて Critical / Important / Minor の三分類で findings を返すゲート用スキル。観点は spec 準拠、責務逸脱、依存方向違反、null/error handling、命名、test coverage、副作用混入、unused code、performative comment / dead code 残し、AI 生成パターン (self-consistent assertion 等は `test-review` 参照)。実装直後・「コードレビューして」「PR 出す前にチェック」「実装見て」「これで OK?」「マージ前確認」のような要請、`pr-review-respond` での修正完了直後、いずれでも必ず起動すること。本スキルは subagent によるセルフ・コードレビューで、CodeRabbit / Devin / 人間レビュアーの代替ではなく **PR 起票前のセーフティネット**。findings は実装者 (= 本スキル呼出側) に返り、修正後に `verify-done` を経て PR 起票へ。subagent には書き手の前提知識を持ち込ませない。

git commit を「観測 → ガード → 明示パス staging → ファイル経由メッセージ → 検証」の固定順で作る skill。`git add -A` / `git add .` / heredoc を使わないため、permission / hook で汎用コマンドが拒否される環境でもブロックされずに完走する。「commit して」「コミット作って」「この変更コミットしといて」「stage して commit」「きりのいいところで commit 切って」「一区切りだから記録して」のような要請、および tdd / tidy-first / shipping の各サイクル終端の commit 作成で必ず起動すること。commit までが責務 — push・PR 作成は `shipping`(検証ループ付き)または `commit-commands:commit-push-pr` に、リリースタグは RELEASING.md の手順に、structural / behavioral の分割判断は `tidy-first` に渡す。履歴書き換え (amend / rebase / squash / reset / revert) と commit 取り消しは範囲外 — 新規 commit を作る要請だけを扱う。

ソフトウェア設計の成果物（ADR、ドメインモデル、モジュール構造、アーキテクチャ提案、設計差分、`software-design` skill の提案）を、書き手バイアスのない別エージェントに白紙で読ませて構造化された指摘を返すレビュー専用スキル。philosophy of software design (Ousterhout)、immutable data model (kawasima)、TM法 (佐藤正美)、関数型プログラミング、DDD (Vlad Khononov)、TDD (Kent Beck)、Railway Oriented Programming (Scott Wlaschin)、Fundamentals of Software Architecture、xUnit Test Patterns、CQRS、Event Sourcing、ADR (Nygard)、Secure by Design の 13 レンズを checklist で当てる。「設計レビューして」「ADR レビューして」「設計で抜け落ちている観点ない?」「別エージェントで読み直して」「設計の最終チェック」「この提案で行く?」「集約境界これで OK?」「Result への置き換え、抜けない?」「Secure by Design 観点で監査して」「ADR の Negative consequences 薄い」のような要請、`software-design` の Proposal/ADR 最終確認、PR の設計関連ドキュメント / コード境界の妥当性確認、設計セッション後の「セルフレビューでない外部視点」が必要な場面で必ず起動する。Agent ツールで subagent を dispatch して評価し、書き手（同セッションの主エージェント）にレビューさせない。テスト本体のレビューは `test-review`、調査は `research-practices`、Skill 本体の作成・トリガ調整は `skill-builder` 担当のため、それらの目的が明確な依頼ではこのスキルを起動しない。実装を書き換える作業（コード修正、リファクタリング実施、lint 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。

要件が確定した後、実装に入る前に、構造選択・I/O 境界・依存方向・外部制約を**会話 / 一時ファイル**で検討するスキル。設計ドキュメントを永続化することは目的としない — コードを読めばわかる範囲は書かず、**コードを読んでもわからない外部要因・制約・選択肢と却下理由のみ ADR に蒸留**する (ADR 化は `adr-writer` の責務)。設計の検討内容は temp scratchpad (`<work-dir>/design-scratch.md` 等、配布先で gitignore 推奨) に書き、PR マージ後は破棄。要件 → 実装の間、`pr-review-respond` で VALID_DEFER を新規 issue 化する時、「設計どうする」「アーキ考えて」「どこに置く」「依存方向は」「I/O 境界どこ」「先にデザインして」のような要請、いずれでも必ず起動すること。本スキルは設計の **検討と決定の蒸留** までで、実装・テスト・ADR 文面化は別スキルに渡す。詳細仕様の永続化や spec ファイル化は意図的にしない。

Use this skill whenever working in a repository that uses Effect, even if the current task is in a new file or the user does not explicitly ask for Effect help. Apply it to any work that should follow the repository's Effect patterns, conventions, architecture, or supporting tooling. Also use it for questions about Effect patterns, services, layers, schemas, streams, runtimes, or typed error handling.

agent 向けテキスト指示（skill / slash command / task プロンプト / CLAUDE.md 節 / コード生成プロンプト）を、バイアスを排した実行者に実際に動かしてもらい、両面（実行者の自己申告 + 指示側メトリクス）で評価して反復改善する手法。改善が頭打ちになるまで回す。「この skill うまく起動しない / trigger を直したい / description を調整したい」「このプロンプトが効かない / 期待通り動かない、指示が曖昧かも」「skill を新規作成・大幅改訂したから堅牢化・評価して」「プロンプトを実際に走らせて精度を測りながら詰めたい」のような、指示側テキストの起動率・精度を実測で詰めたい要請で必ず起動する。`retro` が skill 不発を検出して ept-handoff を選んだ後、または `skill-builder` Mode B（trigger 調整）の実体として呼ばれる主経路でもある。逆に、コードのバグ修正・一回限りの使い捨てプロンプト・書き手の主観的好みの反映には使わない。

1 つの変更要求を、受け入れ条件の確定から実装・出荷・PR 決着の監視・ハーネス自己改善まで一気通貫で回す最上位オーケストレータスキル。入口で要求の複雑さを**観測可能な決定表**で判定し、明確で小さければ受け入れ条件を 1 ショット確認して即実装へ、曖昧/大きければ `grill-with-docs` で詰める。以降 `tdd`/`tidy-first` で実装 → `shipping` で品質ゲート〜CI〜レビュー対応を merge-ready まで収束 → `pr-monitor` で merge/close を監視 → 決着で `retro` が自己改善提案、と各段を fresh subagent / skill に委譲する。本スキルはコードを書かず、段の順序と handoff と決定表の告知だけを main で持つ。「最初から最後まで回して」「受け入れ条件決めて実装して PR 決着まで面倒見て」「feature を頭から ship・監視・振り返りまで」、さらに口語の丸投げ「これ実装したいんだけど全部やっといて」「あとは丸ごとまかせる」のような、1 つの変更要求を実装＋後工程まで委任する意図で必ず起動する。設計だけ・実装だけ・出荷だけ・監視だけ・振り返りだけの単機能要請、および「バグ直して」「このタイポ直して」のような単発修正は該当する個別 skill (`grill-with-docs` / `tdd` / `shipping` / `pr-monitor` / `retro`) を名指しで使い、本スキルは起動しない。PR の merge 操作はせず、決着 (merge/close) を監視で待つ。

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

現在進行中の会話を、別のエージェント / fresh session が続きを再開できる「引き継ぎ文書 (handoff)」へ圧縮して書き出すスキル。今何を目指し・どこまで進み・次に何をすべきか・落とし穴・関連 artifact への参照・推奨 skill を 1 枚にまとめ、ワークスペースではなく OS の一時ディレクトリに保存する。既存 artifact (PRD / plan / ADR / issue / commit / diff) の内容は複製せずパスや URL で参照し、API キー・パスワード・PII は redact する。「引き継ぎ書いて」「handoff 作って」「別のエージェントに渡したい」「次のセッションに引き継いで」「コンテキスト圧縮して別 agent に」「この作業を誰かが続けられるようにまとめて」「hand off して」のような要請、長い作業を中断して後で / 別セッションで再開する前、context が膨らんで別 agent に委譲したい時、いずれでも必ず起動すること。引数があれば「次のセッションが何にフォーカスするか」の説明として扱い、その焦点に合わせて文書を仕立てる。本スキルは**進行中作業の状態を継続用に転送する**もので、完了セッションからハーネス改善の学びを抽出する `retro` / `session-retro` とは別物 (あちらは harness 改善提案、こちらは作業継続のための state transfer)。単なる会話要約や、コード実装・commit・PR 作成そのものは範囲外。

汎用性のあるハーネス片 (rule / slash command / subagent / hook / 定型スクリプト) を、 ローカル設定ではなく **配布元 skills リポジトリの feature 枠** (rules/ commands/ subagents/ hooks/) に canonical 形式で収録し、タグリリース → rulesync 経由で consumer 全 repo とクラウド実行 (Routines / cloud セッション / Actions) に届ける ための判定と手順のスキル。ローカル (`~/.claude/*`, `settings.local.json`) に置いた ハーネスはそのマシンでしか効かず、クラウド実行に届かない — 本スキルはその置き場所 ミスを防ぐ。機密 (トークン・private repo 名・内部 URL) や特定マシン依存の内容を **配布しない**判定も担う。 「このルール他の repo でも使いたい」「rulesync で配布して」「これは汎用だから skills repo に」「クラウド実行でも効くようにして」「この hook / command を共通化 して」「どこに置くべき?」のような要請、session-retro の rule handoff で宛先を 決める時、新しい rule / command / hook / subagent を書いた直後の置き場所判定、 いずれでも必ず起動すること。 範囲外: skill 本体の新規作成・トリガ改善 (skill-builder)、rule や教訓の中身の考案 (session-retro 等の生成元)、単一プロジェクト固有の permissions / settings 変更 (update-config 系)、リリース手順単体の質問 (RELEASING.md)。本スキルが持つのは 「配布判定 → 枠選択 → canonical 収録 → リリース → consumer 反映」の経路のみ。

GitHub issue に `claude:ready` ラベルが付いた 1 件を、排他ロック → 入口ゲート (acceptance criteria 検証) → branch → 実装 → ローカルテスト green → commit → push → **PR 作成まで**ヘッドレスで完遂するワークフロー。`linear-issue-driven-development` の GitHub 移植で、最大の差分は**イベント分割**: CI を watch せず PR 作成で終了し、 CI 修正 (`ci-self-heal`) とレビュー対応 (`pr-review-respond`) は Actions のイベント トリガによる有界な反応として別途走る。acceptance criteria の無い issue は実装せず `ambiguous-issue` でエスカレートする (推測で実装しない)。エスカレーションは `needs-human` + 構造化コメント (loop-escalation:v1)、反復上限は `claude-loop:N` ラベルで PR に永続化する。Routine / Actions (ラベルイベント) からの起動が主経路。 `owner/repo#123` 形式の手動再実行、「この issue やっておいて」「claude:ready の issue を処理して」「issue から PR まで自走して」でも必ず起動すること。範囲外: Linear issue (`linear-issue-driven-development`)、対話的な実装後の出荷 (`shipping`)、 CI 修正単体 (`ci-self-heal`)、レビュー対応単体 (`pr-review-respond`)、conflict 解消 単体 (`pr-conflict-resolver`)、PR の merge (人間ゲート)。実行環境はクラウドを想定し、 素の `git` / `gh` / `jq` だけで動くこと。

Linear で "claude:ready" ラベルが付いた issue 1 件を、対象リポジトリの clone → 実装 → commit → PR → CI all-green → レビュー (人間 / CodeRabbit) コメント解消まで ヘッドレスで完遂させるためのワークフロー。 use when: - Anthropic Routines (`/schedule` で登録した recurring agent) が 1 時間毎に この skill をトリガーする - 人間が `/linear-issue <IDENTIFIER>` を打って手動で再実行する 実行環境はクラウド (Anthropic 側 sandbox) を想定しているため、`gw` 等の dotfiles 同梱ヘルパには依存しない。素の `git` / `gh` / `curl` だけで動くこと。 本ループ (loop-ops 駆動) では非対象。GitHub issue は issue-driven-development を使うこと — 本 skill は Linear issue 専用。

GitHub PR で発生した merge conflict を自動修正するための手順とベストプラクティス。 PR コメントで `@claude` 経由で呼ばれた conflict 解決タスクや、ローカルでの rebase / merge conflict を解決するときに必ず参照する。チェックアウト → merge → conflict 解決 → lock ファイル再生成 → 検証 → commit で merge を確定 → push までの一連の安全な流れを、 同梱スクリプト (`scripts/*.sh`) の決定的な実行として定義する。

自分が作成・出荷した PR の状態 (open / merged / closed) を、merge または close に至るまで長期間ポーリングで監視するスキル。`shipping` が merge-ready で停止した後の終端監視として、PR の最終決着 (merge / close) を完了シグナルとして待ち、検出したら `retro` を自動起動する。待機手段は環境に依存しないよう優先順で選ぶ — `/schedule` (cron) があれば登録して main を解放、無ければ `ScheduleWakeup` で self-pace poll、どちらも不可なら `--check-only` の手動再実行を案内する。状態は consumer 側の gitignore パスに永続する。`shipping` 完了直後・`gh pr create` 直後・「PR 監視して」「マージされるまで見張って」「マージ/クローズしたら振り返りまで回して」のような要請で必ず起動する。CI 完了までの短時間監視は `ci-self-heal` (秒〜分)、本スキルは merge / close までの長時間監視 (分〜時間〜日) で責務分離する。PR の merge 操作そのものは行わない — 人間 (または別の自動化) が merge / close した事実を待つだけ。

PR に投稿された自動レビュー (CodeRabbit / Devin) と人間レビュアーのコメントを取得し、各指摘の妥当性を検証したうえで対応するスキル。VALID は修正コミットを当てて該当スレッドに「Fixed in <SHA>」と返信、INVALID_PUSH は根拠付きの pushback コメントを残し resolve しない、VALID_DEFER は issue 化して参照、DUPLICATE は既存対応スレッドを指す。最後に PR へ集約サマリコメントを 1 件投稿し「何を・どう対応した／なぜ対応しなかったか」を 1 箇所で追えるようにする。`gh pr create` 直後・**既存 PR ブランチへ push した直後 (レビュー対応後の再 push を含む)**・「レビュー対応して」「コメント見て対応して」「コードラビット対応」「Devin の指摘片付けて」「PR のコメント全部捌いて」「push したのでスレッド対応して」のような要請、CodeRabbit / Devin / 人間レビュアーが新規コメントを残した時 (監視やイベントでの検知を含む)、PR を merge する前に未解決スレッドを確認したい時、いずれでも必ず起動すること。未解決スレッドが残る PR を離れる前に必ず一度起動する。レビュアー判別はコメント author と本文を読んで行い、bot suffix のような表面的なルールは持たない。本スキルは「読む・直す・返信する・サマリ投稿する」までで、レビュー自体を実行する (CodeRabbit や Devin を呼び出す) ことはしない — 既にレビュー済みの PR に後追いで対応するスキル。GitHub API 呼び出しは同梱の単一エントリ `scripts/prr` (subcommand: `fetch` / `reply` / `resolve` / `summary` / `wait-ci`) に集約しており、`allowed-tools` で `Bash(bash *prr *)` を auto-grant するため consumer 側で permission を追加する必要は無い。

要求定義 (PM フェーズ) を進め、ユーザの「やりたい / 困っている」を Outcome > Output で言語化して Lean PRD を docs/prd/<slug>.md に書き出す skill。INSPIRED の 4 リスク (value / usability / feasibility / viability)、Continuous Discovery Habits の Opportunity Solution Tree と Riskiest Assumption Test、Escape the Build Trap の outcome 重視・feature factory 回避を doctrine とする。顧客が自分自身であるパターンも一級扱いし、自己ヒアリングのバイアス除去プロトコルを内蔵する。発火例 — 「〜を作りたい」「〜が欲しい」「アイデアがある」「〜って作るべき?」「PM 視点で整理して」「要求まとめて」「PRD 書いて」「PRD ドラフト」「discovery 回したい」「opportunity 整理」「outcome 何にする?」「riskiest assumption は?」「自分用ツール作りたい」。要件定義 (spec / 要件) を直接書く依頼、実装方針の検討、UI 仕様の確定、コード生成、API 設計、データモデル詳細は本スキル範囲外で、それぞれ requirements skill / design / data-modeling skill 等に委ねる。ドラフト後は別 agent の prd-review skill にレビューを渡し、合意済み PRD を入力に requirements skill を起動する想定。アドホックに要求整理するより本スキルを優先する理由は、build trap を防ぎ outcome / opportunity / assumption の三層を欠落なく PRD に揃え、下流レビュー・要件定義への引き継ぎ品質を担保するため。

Guide structured research on libraries, frameworks, academic studies, industry practices, and prior art. Use this skill whenever the user asks to research, investigate, survey, compare, evaluate, or benchmark libraries/tools/technologies/methodologies, whenever they ask about world-wide or proven practices, precedents, academic findings, or "how others do it", or when making non-trivial technology decisions — even if the word "research" isn't used. Covers question framing, source evaluation (CRAAP/SIFT/evidence hierarchy), cognitive-bias mitigation, validity checking, source reliability tagging (S0-S5), and structured reporting. Use even when the user just says "check", "look into", "compare", "which should we use", "ちょっと調べて", or mentions specific library/technology names for assessment.

完了したセッション (PR が merge / close された後、長時間セッションの後、新 skill を運用した直後) のトランスクリプトを **バイアスを排した fresh subagent** に網羅解析させ、ハーネス自身の改善提案を返すスキル。tool 統計・権限拒否・subagent 結果・ループ/stall/escalation・skill の不発や暴発・token 浪費・blocking 待ちを洗い、各 finding を「どのレバー (hook / settings allow-deny / skill 編集 / 新規 skill / CLAUDE.md・rule / empirical-prompt-tuning への handoff / none) で直すか」「なぜ局所パッチでは再発するか (class レベルの根本原因)」付きで構造化する。`pr-monitor` が merge / close を検出した直後の主経路、「振り返り」「retro」「セッション分析」「ハーネス改善したい」「allow リスト見直したい」「hooks 候補ある?」「なんでこの skill 起動しなかった?」のような要請で必ず起動する。本スキルは**提案のみ**で、settings / skill / rule / hook の編集・コミットは一切せず、すべて人間承認を待つ。改善の実体 (skill 編集や trigger 調整) は承認後に `skill-builder` / `empirical-prompt-tuning` 等が担う。コードレビューやバグ修正のセッション分析ではなく、**エージェント運用 (harness) の改善**に閉じる。

作業セッション (issue 駆動の自走実行・実装・出荷・リリース) の終端で、transcript / 会話履歴から学びを抽出し、**rule (CLAUDE.md・skill 改訂 = feedforward) / sensor (テスト・lint・CI チェック追加 = feedback) / issue (繰り越し作業、acceptance criteria 必須) / eval-case (golden set 候補)** の 4 分岐に振り分けて提案として出力する振り返り 専用スキル。シグナル源は「失敗した tool 呼び出し」「人間による訂正」「エスカレーション」 の 3 つに限定し、全ログの漫然とした要約はしない。同じ失敗が 2 回目なら issue でなく rule/sensor に昇格させる。rule 提案は特定の失敗にトレースできるものだけに絞り、追加と 同時に既存ルールの剪定候補も提示する。 issue 対応・実装・出荷セッションの終端 (shipping / linear-issue-driven-development の 完了直後)、release 後、「振り返りして」「retro」「レトロして」「このセッションの学びを まとめて」「教訓を残して」「二度と起きないようにして」「学びを CLAUDE.md に反映して」 「詰まったことを issue 化しておいて」のような要請、Stop hook からの自動起動、いずれ でも必ず起動すること。 範囲外: セッションの単純要約 (4 分岐が不要な依頼)、CLAUDE.md 全体の監査・改善 (claude-md-improver 等)、いま起きているバグの根本原因分析 (systematic-debugging)、 skill 本文のチューニング (skill-builder)、コードレビュー (code-review)。出力は全て **提案まで** — CLAUDE.md 書き換え・golden set 追加・issue 起票は人間の承認を経る。

Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

実装が上流スキル (`design`/`software-design` → `tdd`/`tidy-first`) で GREEN になった後の **出荷専用ターミナルステージ**を、各フェーズを fresh subagent に dispatch して構成するオーケストレータスキル。品質ゲート (`code-review`) → 完了ゲート (`verify-done`) → PR materialize (open PR が無ければ `commit-commands:commit-push-pr`、あれば push) → CI 緑化 (`ci-self-heal`) と自動レビュー対応 (`pr-review-respond`、CodeRabbit/Devin/Copilot/人間) を、CI 全 pass かつ全コメント終端まで回し、行き詰まったら escalate する。要するコード修正は behavioral→`tdd` / structural→`tidy-first` の subagent にルーティングし、本スキルはコードを書かずループ制御と収束/escalation 判定だけを main で持つ。「ship して」「実装できたから後は全部やって PR 出して CI もレビュー対応も全部通してマージできる状態にして」「commit-push-pr の検証付き版で」「赤と指摘を全部潰して merge-ready に」のような実装後に出荷まで丸ごと任せる要請で必ず起動すること。commit だけは `commit-commands:commit`、検証ループ不要の commit→push→PR だけは `commit-push-pr`、コードレビューだけは `code-review`、既存 PR のコメント対応だけは `pr-review-respond`、CI 修復だけは `ci-self-heal`、完了確認だけは `verify-done`、実装そのもの (設計/コーディング/未 GREEN/WIP) は上流が担い範囲外。PR は merge せず merge-ready で停止する。

Claude Code skill を新規作成・既存 skill のトリガ精度を測定/改善するためのメタスキル。プロジェクトの skill ディレクトリ（`.claude/skills/<name>/SKILL.md` または top-level `<name>/SKILL.md` の両形式に対応）に新しい skill を scaffold したい時、既存 skill が適切なときに発火しない / 余計な時に発火するのを直したい時、description を eval ベースで最適化したい時、trigger 性能をベースライン測定したい時、Mode C で起動後の本文品質を subagent dispatch で測りたい時、いずれでも必ず起動すること。「skill 作って」「このスキルなんで起動しない」「スキルが暴発する」「skill description 最適化」「skill の eval 作って」「メタスキル」「skill の品質測りたい」のような要請に該当する。プロジェクト規約 (CLAUDE.md / `rules/` / `AGENTS.md` 等) との整合確認も兼ね、特定プロジェクトには依存せず本スキルが置かれたリポジトリと配布先の双方で機能する。プラグインスキル（`plugins/<plugin>/skills/...`）の編集は範囲外。

ソフトウェア設計の判断・指示・成果物（モデル / モジュール境界 / エラー戦略 / アーキテクチャ決定 / セキュリティ）を扱う際に起動するスキル。philosophy of software design (Ousterhout)、immutable data model (kawasima)、TM法 (佐藤正美)、関数型プログラミング、Domain-Driven Design (Vlad Khononov)、TDD (Kent Beck)、Railway Oriented Programming (Scott Wlaschin)、Fundamentals of Software Architecture、xUnit Test Patterns、CQRS、Event Sourcing、ADR (Nygard)、Secure by Design の 13 本を一貫したレンズ群として適用する。「設計どうする」「ドメインモデル作って」「集約をどこで切る」「Result 型に直したい」「例外やめて Railway で」「CQRS 入れる?」「Event Sourcing 採用する?」「ADR 書く」「アーキテクチャ決定を残す」「immutable データモデルに直して」「TM法でモデル化して」「TDD で進めたい」「Deep Module になってる?」「サブドメイン分けたい」「Secure by Design 観点で見て」のような要請のほか、コードを書く前のモデル設計フェーズ、既存設計の妥当性レビュー、トランザクション境界・副作用境界・データ整合性の議論、技術的負債の優先度判断、セキュリティ設計レビューでも必ず起動する。テスト本体のレビューは `test-review`、調査作業は `research-practices`、Skill 自体の新規作成は `skill-builder` の担当のため、それらの目的が明確な依頼ではこのスキルを起動しない。実装そのものを書き下すだけの作業（タイポ修正、lint 違反対応、単純なバグ修正、純粋なパフォーマンスチューニング）は本スキルの範囲外で、本スキルは「どう設計すべきか」を構造化して提示・指摘するためのレンズ集である。設計後の最終レビューは `design-review` を併用する。

振る舞いを変えるコード (新機能 / バグ修正 / 仕様変更) を書く際に必ず Test-Driven Development の RED-GREEN-REFACTOR サイクルを強制するスキル。production code は **必ず先に失敗するテストを書いてから** でしか書かない。「Verify RED」ゲートで失敗理由が typo / import error ではなく「機能が未実装」であることを確認してから実装に進む。先にコードを書いてしまった場合は **そのコードを削除してテストから書き直す**。Tidy First と併用するときは structural change は本スキル対象外 (テスト不要)、behavioral change のみ TDD を適用する。新機能を実装する時、バグ修正を当てる時、API の仕様変更を加える時、`pr-review-respond` Phase C で VALID 修正を behavioral に当てる時、「TDD で」「先にテスト」「赤にしてから」「失敗するテスト書いて」「実装する前に」のような要請、いずれでも必ず起動すること。本スキル単体でカバーするのは 1 振る舞い 1 サイクル。複数振る舞いの設計や ADR 化は対象外。

振る舞いを実装・テストコードを書く**前**に、何をテストすべきかを体系的に導出し「テストケース設計表」(ケース一覧 + 各ケースの導出根拠) として出力する設計スキル。対象の事前条件・事後条件・不変条件を明文化したうえで、入力の形 (範囲を持つ / 条件の組合せ / 状態を持つ / 可逆変換や代数的性質を持つ / 参照実装がある 等) に応じて同値分割・境界値分析 (BVA)・デシジョンテーブル・状態遷移テスト・ペアワイズ/組合せテストと、property-based の invariant / roundtrip / oracle / metamorphic / idempotence を選び分け、Google Software Engineering の Test Sizes (Small/Medium/Large) でどのケースをどのレイヤに置くかまで決める。「テストケース考えて」「どんなテスト書けばいい?」「テスト設計して」「テスト観点洗い出して」「境界値どこ?」「property 何にする?」「この関数の事前条件・事後条件は?」「実装する前にテストケース洗い出したい」のような要請、いずれでも必ず起動すること。既存テストのレビューは `test-review`、RED-GREEN の実行サイクルは `tdd`（本スキルは `tdd` Step 1 の前段として設計表を渡す関係）、テスト diff の検出力監査は `test-mutation-gate` の担当で、いずれも本スキルの範囲外。本スキルは書く前の設計表を出すところまでで、テストコード自体は書かない。

テスト変更を含む diff に対して静的 assertion 監査 (Phase 1) と unit テスト限定の mutation smoke (Phase 2、実コードへの変異注入 + 再実行) を行い、PASS/BLOCK を判定するゲート用スキル。tautology-literal-sharing (critical) / assertion-roulette / overstated-coverage / boundary-gap の 4 チェックを正規表現ベースで実行し、critical が 1 件でもあれば BLOCK として呼び出し元に差し戻す。加えて対象が unit テスト (プロセス内で完結・外部 I/O 無し) の場合のみ `scripts/mutate_and_run.py` で変異注入を行い、survived mutant が 1 件でもあれば BLOCK にする。主経路は `tdd` Step 3.5 (GREEN 確認後・commit 前)・`pr-review-respond` Phase C (VALID 修正のテスト側 diff)・`verify-done` Step 4 (完了宣言直前) の各本文に組み込まれた強制サブステップ呼び出しであり、ユーザからの直接要請にも対応する。「このテスト検出力ある?」「テスト弱くない?」「assertion 監査して」「tautology チェックして」「このテスト実装をなぞってるだけじゃない?」「テストがバグをロックインしてないか見て」「このテスト mutation testing して」のような口語、いずれでも必ず起動すること。テストコードの網羅的レビューは `test-review`、push 後の CI 赤対応は `ci-self-heal`、skill の eval trigger JSON 採点は `skill-builder` Mode B、テストスイート全体の mutation score 算出 (Stryker/mutmut 相当の運用) は、いずれも本スキルの範囲外。

テストコード（pytest / vitest / jest / rspec / go test / pgTAP / ワークフロー定義 等の任意フレームワーク）をレビューする際に使うスキル。test smells（Meszaros 17 種）、Khorikov の 4 属性 (Protection / Resistance to refactoring / Fast feedback / Maintainability)、AI 生成テストのアンチパターン、seam / mock 境界の違反、LLM・エージェント eval の抜け、DB / RLS / 認可テストのカバー、flakiness の原因分類をまとめて点検する。テストファイル（`**/tests/**`, `*_test.*`, `*.test.*`, `*.spec.*`, `supabase/tests/**` など）を含む PR / diff のレビュー時、新規テストファイルの監査時、テストスイートの品質チェック時、flaky テストの原因追跡時、LLM / エージェント eval の厳密性評価時、RLS / 認可テストの存在確認時、いずれでも必ず起動すること。ユーザーの言い方が曖昧でも — 「テスト見て」「このテストいい?」「テストスイート大丈夫?」「このテストなんで壊れる?」「認可のテスト足りてる?」「eval レビューして」「このプロンプトテストでカバーできてる?」— どれも該当する。ただし以下の成果物を生む依頼はこのスキルの範囲外：テスト追加・テスト修正・テスト基盤の移行・テスト並列化・パフォーマンス改善・lint 違反修正。本スキルは「読んで指摘する」レビュー専用で、コードを書き換える依頼には起動しない。アドホックなレビューより本スキルを優先する理由は、構造化されたチェックリスト（Meszaros / Khorikov / AI antipatterns）を一貫適用して findings を出すためである。

既存コードに振る舞いの変更 (機能追加・バグ修正・リファクタを伴う仕様変更) を入れる **直前** に、まず構造の整理 (tidying) が必要かを判定し、必要なら tidying だけを先に独立コミットするスキル。Kent Beck の Tidy First? の規律に従い、structural change (rename / extract / inline / guard clause / dead code 削除 / explaining variable / reading order 等) と behavioral change を **絶対に同一コミットに混ぜない**。新機能を書く前・テストを書く前・PR レビュー指摘の修正前・「リファクタしてから直す」「先に整理」「読みづらいから整える」「巨大関数を分割」「dead code 消す」「ガード節に直す」「変数名を意味あるものに」「先に rename」のような発話、いずれでも必ず起動すること。本スキルは「整理が必要かを判定する → 必要な tidying を 1 つずつ独立 commit する → 振る舞い変更フェーズに渡す」門番で、振る舞いを変える編集は一切しない。pre-commit で混在を物理的に block する hook 設定の指示も含む。

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

「完了した」「動いた」「直した」「pass している」「動くはず」「いけそう」のような完了宣言・成功報告をする直前に必ず起動するゲート用スキル。最後に実際に検証コマンド (test / build / typecheck / lint / smoke) を実行してから何分経ったか、その出力を本セッション内で目視確認したか、未保存変更が無いか、を順番に潰し、満たさなければ完了報告を差し戻す。Iron Law は「NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE」— 過去の green、推測、伝聞、`should work` 系の語彙では完了と認めない。実装スキル (tdd / tidy-first / pr-review-respond / ci-self-heal 等) の終端、PR 作成前、merge 直前、ユーザに「できました」「修正しました」「これで OK です」と返す直前、いずれでも必ず起動すること。本スキル自身は修正もコード生成もしない — 検証実行と判定だけを行う門番。

設計検討から出てきた決定について「これは ADR (Architecture Decision Record) に値するか」を判定し、値する場合のみ [adr-tools](https://github.com/npryce/adr-tools) の `adr new` コマンドで Michael Nygard 形式の ADR を生成するスキル。**コードを読めばわかる決定は ADR にしない**。値する基準は (1) 将来「なぜこうした?」と疑問になりうる (2) 容易に変更できない one-way door (3) 別の選択肢があり却下した のいずれか。番号採番・slug 生成・テンプレ展開・supersede リンクの相互更新は全て `adr new` / `adr new -s` / `adr new -l` に委譲する。`design` Step 4 から呼ばれる主経路、設計判断を残したい時、「これ ADR にして」「決定記録残して」「architecture decision」「設計判断のドキュメント」のような要請、いずれでも必ず起動すること。本スキルは ADR 単体の生成と判定までで、設計検討自体や実装には関与しない。詳細仕様や API ドキュメントの代わりに ADR を使うことは推奨しない (ADR は「決定」の記録、「使い方」のドキュメントではない)。adr-tools が未インストールの場合は導入手順を提示し、勝手に install しない。

PR 作成後・push 後の CI が失敗した際に、ログから root cause を特定し、修正コミットを当てて再 push する自己修復ループを駆動するスキル。**root cause 不明なまま再試行しない** (NO FIXES WITHOUT ROOT CAUSE)。3 連続失敗で停止し、architecture を疑ってユーザに escalate (3-failure architecture gate)。`pr-review-respond` Phase E から呼ばれる主経路、`gh pr create` 直後で CI が回り始めた時、CI が赤になった時、「CI 直して」「ビルド失敗してる」「テストが落ちてる on CI」「pipeline 緑にして」のような要請、いずれでも必ず起動すること。本スキルは CI ログ取得 → root cause 仮説 → 修正 → 再 push → 再 watch のループ駆動と、停止判断を担う。修正コード自体は呼出側スキル (`tdd` / `tidy-first` / `code-review`) を経由する。flaky / 環境問題と判定したら retry-to-green は禁止 — 原因分類してユーザに返す。

実装が完了した後・PR 作成前に、変更差分を白紙の subagent にレビューさせて Critical / Important / Minor の三分類で findings を返すゲート用スキル。観点は spec 準拠、責務逸脱、依存方向違反、null/error handling、命名、test coverage、副作用混入、unused code、performative comment / dead code 残し、AI 生成パターン (self-consistent assertion 等は `test-review` 参照)。実装直後・「コードレビューして」「PR 出す前にチェック」「実装見て」「これで OK?」「マージ前確認」のような要請、`pr-review-respond` での修正完了直後、いずれでも必ず起動すること。本スキルは subagent によるセルフ・コードレビューで、CodeRabbit / Devin / 人間レビュアーの代替ではなく **PR 起票前のセーフティネット**。findings は実装者 (= 本スキル呼出側) に返り、修正後に `verify-done` を経て PR 起票へ。subagent には書き手の前提知識を持ち込ませない。

git commit を「観測 → ガード → 明示パス staging → ファイル経由メッセージ → 検証」の固定順で作る skill。`git add -A` / `git add .` / heredoc を使わないため、permission / hook で汎用コマンドが拒否される環境でもブロックされずに完走する。「commit して」「コミット作って」「この変更コミットしといて」「stage して commit」「きりのいいところで commit 切って」「一区切りだから記録して」のような要請、および tdd / tidy-first / shipping の各サイクル終端の commit 作成で必ず起動すること。commit までが責務 — push・PR 作成は `shipping`(検証ループ付き)または `commit-commands:commit-push-pr` に、リリースタグは RELEASING.md の手順に、structural / behavioral の分割判断は `tidy-first` に渡す。履歴書き換え (amend / rebase / squash / reset / revert) と commit 取り消しは範囲外 — 新規 commit を作る要請だけを扱う。

ソフトウェア設計の成果物（ADR、ドメインモデル、モジュール構造、アーキテクチャ提案、設計差分、`software-design` skill の提案）を、書き手バイアスのない別エージェントに白紙で読ませて構造化された指摘を返すレビュー専用スキル。philosophy of software design (Ousterhout)、immutable data model (kawasima)、TM法 (佐藤正美)、関数型プログラミング、DDD (Vlad Khononov)、TDD (Kent Beck)、Railway Oriented Programming (Scott Wlaschin)、Fundamentals of Software Architecture、xUnit Test Patterns、CQRS、Event Sourcing、ADR (Nygard)、Secure by Design の 13 レンズを checklist で当てる。「設計レビューして」「ADR レビューして」「設計で抜け落ちている観点ない?」「別エージェントで読み直して」「設計の最終チェック」「この提案で行く?」「集約境界これで OK?」「Result への置き換え、抜けない?」「Secure by Design 観点で監査して」「ADR の Negative consequences 薄い」のような要請、`software-design` の Proposal/ADR 最終確認、PR の設計関連ドキュメント / コード境界の妥当性確認、設計セッション後の「セルフレビューでない外部視点」が必要な場面で必ず起動する。Agent ツールで subagent を dispatch して評価し、書き手（同セッションの主エージェント）にレビューさせない。テスト本体のレビューは `test-review`、調査は `research-practices`、Skill 本体の作成・トリガ調整は `skill-builder` 担当のため、それらの目的が明確な依頼ではこのスキルを起動しない。実装を書き換える作業（コード修正、リファクタリング実施、lint 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。

要件が確定した後、実装に入る前に、構造選択・I/O 境界・依存方向・外部制約を**会話 / 一時ファイル**で検討するスキル。設計ドキュメントを永続化することは目的としない — コードを読めばわかる範囲は書かず、**コードを読んでもわからない外部要因・制約・選択肢と却下理由のみ ADR に蒸留**する (ADR 化は `adr-writer` の責務)。設計の検討内容は temp scratchpad (`<work-dir>/design-scratch.md` 等、配布先で gitignore 推奨) に書き、PR マージ後は破棄。要件 → 実装の間、`pr-review-respond` で VALID_DEFER を新規 issue 化する時、「設計どうする」「アーキ考えて」「どこに置く」「依存方向は」「I/O 境界どこ」「先にデザインして」のような要請、いずれでも必ず起動すること。本スキルは設計の **検討と決定の蒸留** までで、実装・テスト・ADR 文面化は別スキルに渡す。詳細仕様の永続化や spec ファイル化は意図的にしない。