Hakkadaikon

内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。

テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。

Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.

test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

期待値を1つずつ手で用意できないとき、正しいと信じられる別実装(参照実装・旧実装・別ライブラリ)と 出力を突き合わせる差分テスト(Differential Testing)を扱う。test-catalog の手法カタログの一部。 参照実装の独立性確認、入力空間の共通化、出力差ゼロの assert、浮動小数の許容誤差比較、 移行完了までの併走運用を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

機能の正しさより外側にある、プロセス運用・静的検査・分類に収まりにくい観点を扱う。 test-catalog の手法カタログの一部。群B(BDD/Gherkin、ATDD、CI自動実行、シフトレフト/シフトライト、 カナリアリリース、ブルーグリーン/A-B、フィーチャーフラグ段階検証、合成監視、 ミューテーション/カバレッジのCIゲート、テストデータ管理、フレークテスト対策)、 群C(静的解析Linter/型チェッカ、コードレビュー、複雑度メトリクス)、 群D(冪等性テスト、並行性/レースコンディションテスト、境界外/極値・ネガティブテスト) を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

vimrc読書会Nostrクライアントの統合テスト（E2Eテスト）エージェント。 Playwrightを使ってブラウザ上での実際のユーザー操作をシミュレートするテストを書く。 docs/architecture.md の設計と docs/specs.md の要件を参照しながら、 画面遷移、チャット投稿、メッセージ表示、認証フローなどの統合テストを作成・実行する。 ユーザーが「E2Eテストを書いて」「統合テストを追加して」「Playwrightのテスト」 「ブラウザテスト」「画面のテストを書いて」「チャット機能のテスト」 「ログインフローのテスト」「テストを実行して」「E2Eが落ちてる」 などと言ったら、このスキルを使う。 ユニットテストは vimrc-reading-implementer がTDDで書く。このスキルはE2Eに特化する。

vimrc読書会Nostrクライアントの実装エージェント。TDD（テスト駆動開発）で実装する。 docs/architecture.md の設計に従って、機能追加・変更・バグ修正のコードを書く。 ユーザーが「実装して」「コードを書いて」「この機能を作って」「バグを直して」 「コンポーネントを追加して」「〇〇を修正して」「リファクタリングして」 「Nostr接続を実装して」「チャット画面を作って」「認証機能を追加して」 などと言ったら、このスキルを使う。 設計が未決定の場合は vimrc-reading-architecture に相談してから実装する。 要件が不明な場合は vimrc-reading-requirements に相談する。

vimrc読書会Nostrクライアントのアーキテクチャ設計・技術選定を支援するエージェント。 フレームワーク選定、Nostrライブラリ選定、UI/UXの設計方針、コンポーネント構造、 ディレクトリ構成、状態管理、データフロー、リレーサーバー戦略などを議論・決定する。 ユーザーが「アーキテクチャを決めたい」「フレームワークは何を使う？」「UI設計」 「コンポーネント構成」「ディレクトリ構成」「状態管理どうする？」「Nostrライブラリ」 「リレーサーバーの設定」「データフロー」「設計ドキュメント」などと言ったら、このスキルを使う。 要件定義は vimrc-reading-requirements、実装は vimrc-reading-implementer が担当する。

vimrc読書会Nostrクライアントの要件定義・設計判断を支援するエージェント。 docs/specs.md の要件を参照しながら、機能の優先度判断、Nostrプロトコル上での実現方法を議論・決定する。 ユーザーが「要件を決めたい」「この機能は必要？」「Nostrでどう実現する？」 「specs.mdの要件について相談」「チャット機能の仕様」「優先度を変えたい」 「NIPについて教えて」「新しい機能を追加したい」などと言ったら、このスキルを使う。 UI/UXの設計やフレームワーク選定は vimrc-reading-architecture が担当する。

日本語の技術文書・書籍原稿の文章規範。整形（一文一行、引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。

新しいClaude Codeスキルを作成し、レビュー・自動修正まで行う。skill-creatorでSKILL.mdを生成し、reviewing-skillsでベストプラクティスに照らして検証・修正する。「スキルを作って」「スキルを作成」「create skill」「新しいスキルが欲しい」などのリクエストや、/create-skill コマンドで起動する。

Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill.

Keep docs/syscalls.md in sync with src/common/platform/sys/syscall.h and any locally-#define'd SYS_* numbers. Use whenever a syscall is added, removed, or its call site/purpose changes in this repo — e.g. after adding a new `#define SYS_*`, after adding/removing a `syscall1/3/4/6(...)` call site, or when asked to "update the syscall docs" / "syscallの説明を更新".

Use when modifying, adding to, or reviewing code in the wired libc-free QUIC SDK in C — covers its libc-free / CCN<=3 / unity-build constraints, the three-point verification gate, the unity-build name-collision pitfalls, the view-API and freestanding-_start traps, and the parallel-implement / serial-wire workflow, plus how to diagnose a slow handshake (profile-first, peer qlog, stage timestamps, microbenchmarks) and speed up crypto safely. Trigger on any change under src/ or tests/, on "add a domain", "wire a test", "why does run.c fail to build", "obj count mismatch", "CCN too high", on "handshake is slow" / "appconnect takes seconds" / "why is it slow" / "speed up", or before committing C changes in this repo.

Use when deciding how many subagents to run in parallel, when asked to "increase parallelism" / "use more agents" / "並列数を上げて", or before launching a batch of background agents. Measures CPU/memory/load of the real machine and classifies the work as parallelizable vs serial vs indivisible to pick a safe maximum, instead of guessing. Trigger on "how many agents", "spin up more workers", "parallelize this", "max out the cores", or when a parallel batch is about to start saturating the box.