MasashiFukuzawa
UserReusable engineering skills for Claude Code and Codex
Categories
Indexed Skills (26)
done
Definition of Done 品質ゲート（汎用エンジン）。repo の .agents/done.yml を読み、quick/standard/full の3層で検証して quality-gate: PASS 署名を出力する。リポジトリへの変更作業の完了を報告する直前に必ず使う。回答のみ・計画のみ・引き継ぎのみのターンでは使わない。実装中の継続的な型/lint/テスト実行には verification-loop（導入後）を使い、本スキルは完了時の最終ゲートに限定する。
github-issue-create
任意のGitHub Organization／repoへIssueを起票し、Projectへ登録してStatusと明示Priorityを安全に設定するためのdry-run・apply・resumeを提供する。Issue作成、Project Inbox登録、途中失敗からの再開を正のトリガーとして使う。Project自体の新設・構造検証にはgithub-project-provisioningを使う。特定repoのroutingやlabelsを汎用規則として固定する用途には使わない。
github-project-provisioning
GitHub Organization Projectの期待構造を調査し、copy・repo link・auto-addを含む変更計画を作成して承認後に適用・検証する。Project新設、構造drift確認、複数repoの運用Project導入時に使う。Issueを1件起票するだけの場合にはgithub-issue-createを使い、特定Organizationの規約を汎用設定として固定する用途には使わない。
gog-calendar
Google Calendar の読み取り操作（予定一覧・空き時間検索・コンフリクト検出・予定検索）を gog CLI 経由で行う。「今日の予定」「空いてる時間」「来週のスケジュール」等のカレンダー参照系リクエストで使用する。「今日の予定」「空き時間」「予定の衝突確認」などの参照依頼を���のトリガーとし、予定の作成・変更・削除には使わない。
ai-native-engineering
AIが主実装者として継続・並列稼働する前提で、ライフサイクル全体の設計、実装計画、見積もり、スコープ、技術選択を判断する。非自明なarchitecture・security・コアUX設計、基盤選定、ロードマップ・実装計画、工数見積もり、MVP・段階導入・簡易案・将来対応・overengineeringの判断では原則として使う。人間の工数感による妥協と、需要や脅威を確認しない機構追加を両方補正する。仕様と手段が確定した単純修正、技術調査だけ、進捗報告だけには使わない。
autopilot
複数タスクを選択から実装、検証、リリースまで順番に自律処理する。バックログを無人で継続消化する明示依頼に使う。単発タスクには使わない。「自律で進めて」「バックログを全部消化して」を正のトリガーとし、人の判断待ちが必要な単発実装には通常の実装フローを使う。
behavioral-testing
振る舞いを保護する自動テストを設計・実装・レビューする。テスト追加や壊れやすいテストの改善に使う。既存テストの実行だけには使わない。「回帰テストを追加」「モック過多を改善」を正のトリガーとし、型チェックや既存テストを繰���返すだけなら verification-loop を使う。
browser-operations
Playwright CLI やブラウザ制御手段を選び、ログイン引き継ぎと永続セッションを安全に扱う。アドホックなブラウザ操作に使う。staging E2E の能力検証には使わない。「ブラウザで確認」「ログインを引き継いで」を正のトリガーとし、認証済みstagingの破壊的フロー検証には e2e-capability-verification を使う。
claude-review
Claude CLI の独立インスタンスでコードや設計を read-only レビューする。Claude・Anthropic を明示した第三者レビューに使う。一般的なレビューや Codex 指定には使わない。「Claudeに見てもらって」を正のトリガーとし、provider未指定の第三者レビューでは勝手に選ばず、ユーザーへ確認する。
cloudflare-data-pipeline
D1、Vectorize、Queues、Workers をまたぐデータパイプラインの整合性と失敗処理を設計・レビューする。複数サービスの結合部に使う。単一 API の使い方には使わない。「Queue再処理」「D1とVectorizeの不整合」を正のトリガーとし、単一Workerのdeploy安全性には cloudflare-worker-cd を使う。
codebase-audit
コードベース全体を横断監査し、重大度・根拠ファイル・改善案を構造化する。技術負債や設計課題の包括的な洗い出しに使う。単一ファイルや PR のレビューには使わない。「技術負債を洗い出して」「横断的にレビュー」を正のトリガーとし、特定差分のセカンドオピニオンには reviewer skill を使う。
codex-review
Codex CLI の独立インスタンスでコードや差分を read-only レビューする。Codex・OpenAI を明示した第三者レビューに使う。一般的なレビューや Claude 指定には使わない。「Codexに見てもらって」を正のトリガーとし、provider未指定の第三者レビューでは勝手に選ばず、ユーザーへ確認する。
e2e-capability-verification
staging や test 環境で認証付き E2E と機能可否を安全に検証する。破壊的操作や storageState が関わる検証に使う。アドホックなブラウザ操作には browser-operations を使う。「stagingで可能か確認」「認証付きE2Eを検証」を正のトリガーとし、日常的なサイト閲覧やログイン引き継ぎには使わない。
html-artifact
計画、比較、図解、レビューを自己完結 HTML の一枚物として可視化する。表や SVG、並列レイアウトが理解を助ける時に使う。会話内の小さな図には ascii-diagram を使う。「HTML一枚物で」「比較を視覚化して」を正のトリガーとし、production UIや対話内ですぐ読む小さな図には使わない。
progress-report
長時間作業や自律実行の進捗を、背景を知らない判断者向けに再構成して報告する。状況・現在地・次の判断を求められた時に使う。作業再開用の引き継ぎには context-handoff を使う。「今どうなってる」「どこまで進んだ」を正のトリガーとし、次の作業者がそのまま再開するための文書には context-handoff を使う。
typescript-project-foundation
新規 TypeScript project の runtime・package 境界、stack、API/data contract、security、testing、CI/CD を設計・scaffold・検証する���greenfield repository の新設、初期 architecture 決定、foundation plan のレビュー時に使う。既存 project の機能実装・migration・production UI design・単独 API 調査には使わず、該当する実装・migration・frontend・technical-research skill を使う。
gog-chat-readonly
gog CLI で Google Chat のスペース・メッセージ・スレッド・DM を読み取る。Chat 内の情報検索や履歴確認で使う。送信、リアクション、スペース作成などの書き込み操作には��わない。「Chatを検索」「スレッドを確認」などの参照依頼を正のトリガーとし、Calendar参照には gog-calendar を使う。
adr
Architecture Decision Record を起票・更新し、設計判断と既存記録の整合性を保つ。複数案から技術選定した時に使う。軽微な変更やコードベース全体の監査には使わない。「ADRにして」「この決定を記録して」を正のトリガーとし、コードベース全体の設計課題探索には codebase-audit を使う。
ascii-diagram
会話内に小さな ASCII・Unicode 図を描き、構成やフローを即座に説明する。簡潔な図解依頼で使う。保存する複雑な一枚物には html-artifact を使う。「ASCII図で」「会話内で図解して」を正のトリガーとし、表やSVGを含む保存用成果物には使わない。
cloudflare-worker-cd
Cloudflare Workers の deploy、smoke test、失敗時 rollback を設計・レビューする。本番 CD とリリース障害に使う。複数サービスのデータ整合性には cloudflare-data-pipeline を使う。
context-handoff
作業状態を別セッションや別エージェントへ渡す再開可能な引き継ぎ文書を作る。中断・担当交代時に使う。判断者向けの進捗報告には progress-report を使う。「別セッションへ引き継いで」「再開用文書を作って」を正のトリガーとし、現在地を判断者へ報告するだけなら progress-report を使う。
git-worktrees
並列開発の git worktree を作成・同期・整理し、衝突を避ける。別セッションや複数タスクを同時進行する時に使う。通常の単一ブランチ作業には使わない。「worktreeを切って」「別セッションと並列で進める」を正のトリガーとし、単一branch内の通常作業や単なるbranch削除には使わない。
discord-agent
Discord 経由の依頼を Claude Code Worker へ非同期 dispatch し、複数リポジトリの進捗収集と完了返信を管理する。Discord 上の Controller セッションで長時間作業を受け付けた時に使う。通常の対話、Codex、単一コマンドの即答には使わない。
structured-text-parsing
ログ、CSV、JSON、コードなど予測可能な構造化テキストを決定的に解析する。抽出や変換を求められた時に使う。曖昧な自然言語理解には使わない。「JSONから抽出」「ログを集計」を正のトリガーとし、入力形式が定義できず意味解釈そのものが必要な依頼には使わない。
technical-research
非���明な技術課題を、既存実装と一次資料から調査して根拠付きの方針にする。実装前の調査や API の不確実性解消に使う。単純な既知修正には使わない。「公式仕様を確認」「実装前に調べて」を正のトリガーとし、既知の局所修正やコードベース全体の改善監査には使わない。
verification-loop
実装中に型チェック、lint、テストを短い間隔で繰り返す。変更途中の継続検証に使う。完了時の最終品質ゲートには done を使う。「変更ごとに検証して」「lintとtestを回し続けて」を正のトリガーとし、出荷可否を確定する完了時の署名には使わない。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.