Skill.md検索

React + TypeScript フロントエンド・Python Lambda バックエンド・Firehose・S3 Iceberg データレイク・Athena クエリからなるシステム全体のアーキテクチャを把握できます。 Cognito 認証フロー（OAuth PKCE code flow）・JWT Authorizer・ユーザー ID 管理の詳細を確認できます。 FLAGS ビットマスク（睡眠不足・頭痛・腹痛・運動・アルコール・カフェイン）の仕様と、Firehose・S3・Glue・Athena のデータフローを理解できます。 Terraform モジュール依存関係・状態管理（S3 バケット・DynamoDB ロック）・初回デプロイ後の設定手順を確認できます。 Cognito callback_urls ↔ Amplify domain の循環依存を回避し、GitHub Secrets を正しく設定できます。 health-logger プロジェクトの全体像を理解し、設計・実装を進めたい開発者 AWS インフラ（Cognito・Lambda・Firehose・S3・Athena）の連携を詳しく知りたい人 Terraform で infrastructure as Code を管理し、初回デプロイから本番デプロイまでを正確に実行したい人 フロントエンド・バックエンド・インフラを横断的に修正・拡張したい人 React+TS Amplify フロントエンド → API Gateway → Lambda Python 3.13 バックエンド → Firehose・Athena・S3 Iceberg データレイク・Glue カタログの構成です。Cognito User Pool + Hosted UI で OAuth PKCE code flow を実装し、フロントエンド @aws-amplify/auth v6 でトークン取得、API は JWT Authorizer で sub クレームをユーザー ID として使用します。POST /records では Lambda create_record が Pydantic バリデーション後、Firehose に JSON Lines 形式で出力、S3 Iceberg テーブル化。GET /records/latest では Lambda get_latest が Athena StartQueryExecution で最大10秒ポーリング後、JSON で返却。FLAGS は6ビット（睡眠不足=1, 頭痛=2, 腹痛=4, 運動=8, アルコール=16, カフェイン=32）でビットマスク化。Terraform モジュール依存関係は cognito → amplify・apigw・lambda、s3tables → glue → firehose → lambda。状態管理は health-logger-tfstate-prod S3 バケット・health-logger-tflock-prod DynamoDB ロック・ap-northeast-1 リージョン・143944071087 アカウント。初回 apply 後、amplify_app_url・lambda_artifacts_bucket 確認、GitHub Secrets 更新、terraform.tfvars の cognito_callback_urls・cors_allow_origins を Amplify URL に更新して再 apply する必要があります。

feature/fix/chore/terraformプレフィックスとIssue番号を含む統一的なブランチ名を自動適用し、ブランチ管理を標準化できます 「feat:」「fix:」などの型と日本語説明を含むConventional Commitsを自動生成・適用することで、コミット履歴を読みやすくします Issue・PRテンプレートを定型化し、背景・やることリスト・テスト確認項目を自動チェックすることで、レビュー品質を向上させます ブランチの自動マージ（squash merge）でコミット履歴をクリーンに保ち、あとから変更内容を追跡しやすくします git addを個別指定・git push --forceを禁止するなどのベストプラクティスを実装ルール化し、ミスを防げます チーム開発でコミット履歴がカオス状態になりやすい組織 PRレビューの際に「何をやったのか」を毎回確認しなければならない状況を改善したい GitHub CLIでIssue・PR管理を自動化し、手作業を減らしたい開発チーム 複数プロジェクトで統一的なGit運用ルールを構築したい企業 feature/42-xxx、fix/43-yyyなどのプレフィックス＋Issue番号＋説明の形式でブランチを命名します。コミットメッセージは「feat:説明」「fix:説明」などのtype+説明で統一。Issueテンプレートは背景・やること・完了条件を含め、gh issue createで自動生成。PRテンプレートは関連Issue・変更内容・テスト確認項目・レビュー観点を記載し、gh pr createで自動生成します。マージ戦略はsquash merge（gh pr merge --squash）でコミット履歴をまとめます。ベストプラクティスとして「git add -A禁止」「git push --force禁止」「1コミット=1論理的変更」「1PR=1機能」「CI通過前にマージしない」を遵守。よく使うコマンド（git status・git log・gh issue list・gh pr checks等）も提供。

コードの変更ファイルを検査し、「どのドキュメントを更新すべきか」を自動で特定します。マッピングテーブルを照合することで、変更漏れを防ぎます。 Lambda関数・Terraform・フロントエンド・dbtモデルなど、ファイルパスごとの対応ドキュメントを一覧表示し、更新が必要な箇所を明確にします。 各ドキュメントの更新内容を草案として提示するため、ドキュメント担当者や自動更新ツールが具体的に何を修正すればよいか判断できます。 「要更新」「確認が必要」「更新不要」の3段階で分類し、優先度をつけた対応が可能になります。 ユーザーの明示的な確認なしのドキュメント自動修正は行わず、提案段階にとどめるため、手動チェックを経由した安全な更新を実現します。 PR作成後、対応するドキュメント更新が漏れていないか確認したい開発者 コード変更と同期してドキュメントを最新状態に保ちたい技術リード・PM インフラ・API・データモデル等の変更時に、関連ドキュメントの更新漏れを防ぎたいチーム ドキュメント更新の自動化を目指しつつ、人間の最終判断を挟みたい組織 マッピングテーブルはlambda/*/handler.pyのAPI変更がdocs/API_REFERENCE.mdに対応、lambda/*/handler.pyの新規追加がdocs/LAMBDA_DEVELOPMENT.mdに対応するなど8パターンで構成されています。実行手順は「Step 1: 変更ファイルの取得（git diff main...HEAD --name-only）→Step 2: ドキュメント更新候補の特定（マッピングテーブル照合）→Step 3: 更新内容の草案提示」の3ステップです。出力は「要更新」「確認が必要」「更新不要」の3セクションで分類し、各セクションで対象ドキュメント・更新理由・更新箇所を明記します。禁止事項としてユーザー確認なしのドキュメント自動更新とコードファイルの変更は行いません。documentation エージェントが参照する際は自動参照され、user-invocable は false に設定されています。

GitHub Actions ワークフロー（ci.yml・deploy.yml・terraform.yml）の構造を理解し、トラブルシューティングできます。 CI が失敗したときに、エラーログから原因を特定し、修正案を提示できます。 GitHub Secrets や OIDC 認証（OpenID Connect）の設定ミスを診断・修正できます。 Lambda のデプロイからテラフォーム（インフラストラクチャコード）適用、Amplify ビルドまで、デプロイ全体の流れを確認できます。 ワークフロー失敗時の再実行やログ確認を CLI コマンドで自動化できます。 バックエンド開発者で、CI が失敗して原因がわからず困っている人 インフラ構成（AWS、Terraform、GitHub Actions）を学んでいる初心者 デプロイプロセスの全体像を把握したい人 本番環境へのデプロイ前に、パイプラインの安全性を確認したい人 このスキルは health-logger プロジェクトの 3 つのワークフローを管理します。ci.yml は PR・push 時に Python テスト（pytest）と Node.js ビルド（TypeScript・npm）を実行し、deploy.yml は main ブランチへのプッシュ時に Lambda を ZIP 化して S3 にアップロードし、terraform apply でインフラを更新した後に Amplify ビルドをトリガーします。terraform.yml は terraform/ 配下の変更を検出して、PR では plan、main では apply を自動実行します。認証は GitHub OIDC を使用し、AWS IAM ロール ARN を secrets.AWS_ROLE_ARN_PROD から取得して、アクセスキーをシークレットに保存しません。必要なシークレットは AWS_ROLE_ARN_PROD、AMPLIFY_APP_ID_PROD、LAMBDA_ARTIFACTS_BUCKET_PROD、VAPID_PRIVATE_KEY_PROD です。トラブルシューティングは gh run コマンド（gh run list、gh run view、gh run rerun）と gh pr checks で行い、失敗ログから原因を特定します。ベストプラクティスとして、PR マージ前に CI を必ず通す、シークレット値をコードに含めない、ローカルから terraform apply を実行する場合はユーザー確認後のみに限定します。

テスト・CI・セキュリティなど6つの観点から自動チェックを実行し、デプロイしても安全か判定できます チェック結果を見やすいレポート形式で得られ、問題があれば具体的な対処手順が示されます pytest、TypeScript型チェック、GitHub Actions、open Issue、セキュリティスキャン、Terraform検証を一度に実行でき、確認作業の時間を削減できます NO-GO判定の場合、なぜリリースできないのか・どう対処すればいいのかが明確になります プロダクトマネージャー・技術リーダーでリリース判断を担当している人 デプロイ前の確認作業を効率化したい開発チーム ヒューマンエラーを減らしてリリース品質を上げたい組織 main ブランチへのマージ前に自動で安全性チェックをしたい人 このスキルはリリース前のGo/No-go判定を自動化します。実行時に①pytest・TypeScript型チェック、②GitHub Actions の最新実行状況、③マイルストーンの open Issue、④user_idバリデーション・シークレットハードコードのセキュリティスキャン、⑤Terraform の validate と plan を順次実行します。各チェック項目の結果を表形式レポートで出力し、問題がある場合は対処手順を提示します。デプロイの実行・terraform apply の実行・NO-GO 状態での承認は禁止です。