Skill.md検索

ユニットテスト・TypeScript型チェック・カバレッジ測定を自動実行し、コード品質を検証できます。 新しく追加した関数やロジックに対して、テスト記述のルール（命名規約・ファイル配置・import形式）を正しく適用できます。 指定したファイルのみテストを実行したり、ウォッチモードで開発中に継続的にテストを回すことができます。 テスト対象外（プロセス、ファイルシステム、WebSocket等の外部依存）の判定が明確なため、テスト設計の迷いがなくなります。 既存テスト対象モジュール（parser.ts、claude-process.ts、image-store.ts）の追加テストも同じルールで記述できます。 Bridge Serverの開発を行うTypeScriptエンジニア テストコードの品質基準を統一したいチームリード vitest・TypeScriptの型チェックを初めて設定する開発者 CI/CDパイプラインにテスト実行を組み込みたい開発チーム Bridge Server（TypeScript）のテスト実行は3つのステップで構成されています。1) npm run test:bridge でユニットテストを実行（特定ファイルは cd packages/bridge && npx vitest run src/.test.ts、ウォッチモードは npx vitest src/.test.ts）、2) npx tsc --noEmit -p packages/bridge/tsconfig.json で型チェック実行（テストファイル・vitest.config.tsは対象外）、3) npm run test:bridge:coverage でカバレッジ測定（任意）。 テストファイルはソースと同じディレクトリに .test.ts として配置し、describeでグルーピング、itで個別テストを記述します。importはvitestのみ使用し、モジュールは .js 拡張子で import します。テスト対象は純粋関数・ロジック中心（parseClaudeEvent、parseRule、ImageStore.extractImagePaths等）で、外部依存は対象外です。新規テスト追加時は export されている純粋関数を優先し、internal関数をテストする場合は export に変更してから記述します。

タスク完了前に、別のAIコンテキストからコード変更を客観的にレビューできます。 変更ファイルと差分内容から自動的に問題を検出し、PASS/MINOR/FAILで判定されます。 小規模な変更（30行以下）は自己レビューのみで、中～大規模な変更はサブエージェントによる詳細レビューが実行されます。 重大な問題が指摘された場合、修正後に自動的に再レビューし、PASSになるまで繰り返します。 レビュー結果が構造化されたレポート形式で出力されるため、問題点が一目瞭然です。 本番環境へのコミット前に品質を確保したい開発者 コードレビュー時間を削減したい開発チーム 自分のコード変更の問題を事前に発見したい人 人的レビューの前に自動チェックを挟みたいプロジェクト タスク完了前に実行するセルフレビュー手順です。/self-review コマンドで呼び出されるか、大きな変更をコミット前に実行します。まずPhase 1で git diff を使用してコード変更を収集します。Phase 2では code-reviewer サブエージェントを Task tool で起動し、変更ファイル一覧と差分内容を渡してレビューを実行します。変更規模が30行以下の小規模変更の場合はサブエージェント不要で自己レビューのみ対応可能です。Phase 3で PASS/MINOR/FAIL の3段階で判定し、FAIL の場合は修正後に Phase 1-3 を再実行して PASS になるまで繰り返します。100行以上の大規模変更では code-reviewer サブエージェントと詳細分析の両方が実施されます。

差分分析による適切なバージョン選択：前回リリースからのコミット内容を自動分析し、feat/fix/破壊的変更の有無に基づいてMajor/Minor/Patchの推奨バージョンを提示できます。 CHANGELOG自動更新：コミット内容をAdded/Changed/Fixedに自動分類し、CHANGELOGの新セクションを一括追記できます。 リリース前ローカル検証：テスト・型チェック・ビルドを本番CD環境と同じ条件で実行し、問題がないことを確認してからタグpushできます。 アプリ側バージョン同期：Flutter側のexpectedBridgeVersionを自動更新し、アプリが古いBridgeに接続した際の警告表示が正確に動作することを保証できます。 GitHub Actions自動連携：タグpush後、GH Actionsが自動でnpm publish・GitHub Release作成を実行し、手動作業を完全に排除できます。 バックエンドエンジニア：Bridge Serverのリリース作業を安全かつ効率的に実行したい。 リリースマネージャー：バージョンbump・CHANGELOG更新・タグ管理を体系的に管理したい。 DevOps/インフラエンジニア：リリース前検証とGH Actions連携の確実性を高めたい。 技術リード：チーム全体のリリースプロセスを統一・自動化したい。 Bridge Server（@ccpocket/bridge）のリリースプロセスを6段階で実行します。1. バージョン確認と差分収集：package.jsonから現バージョンを取得し、前回タグからのコミット差分をgit logで抽出。2. バージョン決定：feat有無・破壊的変更の有無から、AskUserQuestionで具体的なバージョン番号を提示。3. CHANGELOG更新：コミットをAdded/Changed/Fixedに分類し、packages/bridge/CHANGELOG.mdの先頭に新セクション追記。4. バージョンbump：package.jsonとapps/mobile/lib/constants/app_constants.dartのexpectedBridgeVersionを同期。5. ローカル検証：npm run test:bridge、tsc型チェック、npm run bridge:buildを実行し、全て通過後に次ステップへ。6. コミット・タグpush：git commit、git pushで変更をmainにpush、タグpush後はGH ActionsがOIDC Trusted Publishingでnpm publishと自動リリース作成を実行。