dotfiles

ソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。

ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。

簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。

実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。

ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。

ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。

ソースコードの変更後、可読性をレビューしたいときに起動する。リーダブルコード 由来の 8 カテゴリ (命名 / 誤解されない名前 / 美しさ / コメント / 制御フロー / 式の分割 / 変数 / 構造) の基準で変更ファイルを検査し、発見した課題を省略せず 全件出力する。読み取り専用でありコードは修正しない。

Fetches and summarizes the top stories from Hacker News. Use this skill when the user asks for the latest tech news, Hacker News updates, or what's trending on HN.

プルリクエストを作成から完了まで一貫して提出するときに起動する。ナラティブ型の PR 説明文を生成し、PR を作成し、CI チェックを監視し、CI の失敗を自動修正する。 PR ナラティブと CI 修正のワークフローを 1 つの自律フローに統合する。

日本語の Markdown 文書 (README・ドキュメント・ブログ下書き・*.md) を編集した後に起動する。textlint の ja-technical-writing / ja-spacing プリセットで、長すぎる一文・読点過多・文体の混在・全角半角スペースを検出する。さらに文中ハードラップ (文末でない位置で折り返した、意味のない改行) を検出し、段落・箇条書き項目を 1 行に連結して調整する。実在のシンボルを指すコードスニペットへ参照リンクも付与する。日本語の .md を変更したときに使用する。

ユーザーが nix-darwin (macOS システム設定) の依存を更新したいときに起動する。 `nix-darwin/` で `task update` を実行して flake.lock を更新し、専用ブランチを 切ってコミットし push する。flake 依存の更新を 1 つの自律フローにまとめる。

AI で下書きした日本語の prose (ブログ・記事・エッセイ・README の散文・*.md) を、公開前に人間が書いた文章へ戻したいときに起動する。validate__japanese の機械的な lint が完了した後、その散文に主張・体験・主観が含まれるなら続けて起動してもよい。AI 臭の核心は「書き手の不在」とみなし、false agency (モノに人間の動詞をさせる)・命題型 H2・体験の壮大化・必殺技造語・両論併記・リズムの均一さ・偏愛語・全角ダッシュなどを検出する。立場 → 主体 → 構造 → 語彙 → 記号の優先順で指摘し、依頼があれば改稿する。立場・リズム・主体性・具体性・削減の 5 軸を 1〜10 で採点し、35/50 未満なら書き直しを勧める。表・コマンド列・仕様の羅列だけの文書 (主張を含まないリファレンス) には使わない。

ユーザーが GitHub Issue を起票したいときに起動する。バグ報告か機能開発かを判別し、 概要・背景・課題・根本原因 (バグ) / ユーザーストーリー (機能)・目標・提案手法・検証方法・ 受入基準・作業単位・補足・用語集・参考文献の構造で Issue 本文を生成する。提案手法はファイルパス付き コードスニペットと代替案との差分で具体的に示し、受入基準は計測可能な箇条書きで書く。 用語集には本文の専門用語を簡潔な説明と調査用リンクで補足する。

ユーザーが今日の予定確認、タスクの見直し、パーソナルミーティングの実施、 デイリースタンドアップを依頼したときに起動する。gws 経由で選択済みの すべての Google Calendars からイベントを、Gmail から最近の受信メールを、 GitHub (shunsock/hozuki) から open な issue を、GitHub 組織 (eversteel, BeLume-Inc) から未返信の PR コメントを取得する。 その後、イベントやタスクの追加・更新を提案する。

ユーザーが計画や設計を徹底的に問い詰めてほしい、設計をグリル（厳しく精査）してほしい、 あるいは頭の中にある前提や判断材料を引き出してほしいと言及したときに起動する。 共通理解に到達するまで、計画や設計のあらゆる側面についてユーザーを容赦なく インタビューし、意思決定ツリーの各分岐を一つずつ解決していく。

乱れた (fix-up コミット過多・議論の脱線・大規模な書き直し) プルリクエストを、 ユーザーが "restart" / "やり直し" したいときに起動する。既存 PR を close し、 ブランチを新ブランチ上の単一のクリーンなコミットに squash し、過去の PR 議論 (レビューコメント・スレッド・リアクション) を統合した説明文で新しい PR を作成する。 元のブランチを force-push してはならない。必ず新しいブランチを作成する。

プルリクエストを作成するときに起動する。git diff とコミット履歴を分析し、背景・ 意思決定の根拠・トレードオフ・確認事項を重視したナラティブ型の PR 説明文を生成する。 チェックリストではなく、テックブログのように記述する。構成は同梱テンプレートに従う。

ホスト OS にインストールされていないコマンドをユーザーが実行したいときに起動する。 `nix run nixpkgs#<package>` を使い、パッケージを一時的に実行する。恒久的な インストールはしない。brew, curl, wget など Nix 以外の手段は禁止する。

ユーザーが Nix devShell 内でコマンドを実行したいときに起動する。 devShell 定義を持つ flake.nix を検出し、`nix develop -c` 経由で コマンドを実行する。プロジェクトが flake.nix に独自の開発環境を 定義している場合に使用する。

ユーザーがソフトウェアの機能、ライブラリの更新、または OSS の変更を調査したいときに起動する。 公式ソース (ドキュメント、GitHub PR、Issue、リリースノート) を調査し、概要・背景・利点を まとめた構造化レポートを生成する。

PR を作成した後、または PR ブランチへ commit を push した後に起動する。 GitHub Actions の CI を全チェック完了までポーリングする。失敗時は rescue__ci_failure スキルを自律的に呼び出し、fix-commit-push を 1 回適用して から再監視する。監視と修正のループおよびその反復上限を所有する。ユーザーへの 確認は不要。

PR が作成された後、またはそのベースブランチが進んだ可能性があるときに起動する。 GitHub が計算を終えるまで、PR のマージ可能性 (`gh pr view --json mergeable,mergeStateStatus`) をポーリングする。結果が CONFLICTING の場合、 rescue__pull_request_conflict スキルを自律的に起動してコンフリクトを解消し、 その後に再チェックする。ユーザーへの確認は不要である。

失敗した GitHub Actions の CI 実行を診断し単一の fix-commit-push パスを適用する。 失敗を検知した monitor__ci_status から起動される。単独でも実行できる。その場合は 再検証のために monitor__ci_status へ制御を引き渡す。このスキルはポーリングも ループもしない。監視と修正のループは monitor が所有する。ユーザーへの確認は不要。

PR ブランチのマージコンフリクトを 1 パスで解消する。コンフリクトしたファイルを特定し、 両側を統合し、コミットして push する。`CONFLICTING` 状態を検出した monitor__pull_request_conflict から起動される。単独でも実行可能で、その場合は 再検証のために monitor__pull_request_conflict へ制御を引き渡す。コンフリクトが 存在するかどうかの検出はモニターの役割であり、このスキルの役割ではない。 ユーザーへの確認は不要。

GitHub PR にレビュアー (人間または AI) がコメントを残した後に起動する。 レビューコメントを読み取り、要求されたコード変更を適用し、コミットして push する。 レビューフィードバックの各ラウンドごとに繰り返す。ユーザーの確認は不要 — Claude がこのプロセス全体を自律的に起動・実行する。

git worktree 内でコマンド実行やツールが失敗し、その原因がファイルの欠落 (例: .env、 設定ファイル) である可能性があるときに起動する。失敗を解消しうるファイルを見つけるため、 元のリポジトリのディレクトリを調査する。

ユーザーが RSS サービス (Okskolten) の再起動を依頼したときに起動する。 /Users/shunsock/server/rss で Docker Compose の down/up サイクルを実行し、 その後すべてのコンテナが healthy であることを検証する。

ソースファイルの編集・作成・リファクタリング後、かつコミット前に起動する。 thoughtbot/complexity で認知的複雑度を計測し、変更前のベースラインと比較して 悪化していないことを検証する。続いて変更ファイルのテストカバレッジが 低下していないかを確認する。スコアが突出したファイルはリファクタリング候補 として報告する。コミット前の品質ゲートとして機能する。

GitHub Actions のワークフロー YAML ファイル (.github/workflows/*.yml) を編集した後に起動する。 formatter、yamllint、actionlint を実行し、埋め込まれた shell スクリプトと Node.js コードブロックの認知的複雑度をチェックする。すべてのチェックが通るまで修正とレビューを反復する。

HCL (.tf) ファイルを編集した後に起動する。terraform fmt・terraform validate・tflint を実行し、整形・構文・ベストプラクティスを検証する。 Terraform 設定ファイルを変更したときは必ず使用する。