mcpField
T
terrashark

terrashark

github.com/lukasniessenクラウド・DevOps713216 回インストール6 週間前に更新
リポジトリ

terrashark について

terrashark は Terraform/OpenTofu の障害リスクを診断し、修正を進めるためのワークフロースキルです。環境の把握からリスク対策、実装、検証までを案内します。

主な機能

  1. 01ランタイムと実行環境の記録
  2. 02インフラ障害モードの分類
  3. 03リスクに応じた資料の読み込み
  4. 04リスク対策を含む修正案
  5. 05実装成果物の生成と検証

活用シーン

  1. 01Terraform または OpenTofu の変更レビュー
  2. 02状態やリソースの移行計画
  3. 03CI のドリフトや危険な適用への対処
  4. 04コンプライアンスと承認制御の追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lukasniessen/terrashark --skill terrashark

インストール後、Claude Code で/terrasharkを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.gitignore
CHANGELOG.md
LICENSE
README.md
CONTRIBUTING.md
CODE_OF_CONDUCT.md
PHILOSOPHY.md
.claude-plugin/
marketplace.json
.claude/
settings.local.json
.github/
CODEOWNERS
dependabot.yml
FUNDING.yml
PULL_REQUEST_TEMPLATE.md
.github/workflows/
stale.yml
validate.yml
deploy-docs.yml
docs/
README.md
.gitignore
SUMMARY.md
contributing.md
changelog.md
book.json
docs/advanced/
comparison.md
token-efficiency.md
docs/architecture/
coding-standards.md
backend-state-safety.md
module-architecture.md
structure-and-state.md
docs/core-concepts/
failure-modes.md
docs/examples/
do-dont-checklist.md

詳細

Terrashark：Terraform/OpenTofu の障害モード別ワークフロー

このワークフローを上から順に実行してください。

1) 実行コンテキストを記録する

コードを書く前に、次の情報を記録してください。

  • ランタイム（terraform または tofu）と正確なバージョン
  • プロバイダー、対象プラットフォーム、状態バックエンド
  • 実行経路（ローカル CLI、CI、HCP Terraform/TFE、Atlantis）
  • 環境の重要度（dev/shared/prod）

不明な場合は、前提を明示してください。

2) 想定される障害モードを診断する

ユーザーの意図とリスクに基づき、1 つ以上を選択してください。

  • ID の変動：リソースアドレスの不安定性、リファクタリングによる破損
  • シークレットの露出：状態、ログ、デフォルト値、成果物へのシークレットの混入
  • 影響範囲：スタックの過大化、境界の不備、安全でない apply
  • CI のドリフト：バージョンの不一致、未レビューの apply、成果物の欠落
  • コンプライアンスゲートの不備：ポリシー、承認、監査制御の欠落

3) 関連する参考ファイルのみを読み込む

主な参考資料：

  • references/identity-churn.md
  • references/secret-exposure.md
  • references/blast-radius.md
  • references/ci-drift.md
  • references/compliance-gates.md

補足資料（必要な場合のみ）：

  • references/testing-matrix.md
  • references/quick-ops.md
  • references/examples-good.md
  • references/examples-bad.md
  • references/examples-neutral.md
  • references/coding-standards.md
  • references/module-architecture.md
  • references/ci-delivery-patterns.md
  • references/security-and-governance.md
  • references/do-dont-patterns.md
  • references/mcp-integration.md

条件付き参考資料（CRR。検出されたシグナルがある場合のみ読み込む）：

  • references/conditional/backend-state-safety.md（バックエンドが s3、azurerm、gcs、remote、cloud、pg、consul、local のいずれか、またはタスクでバックエンドの移行、ロック、状態のバックアップ、復元に言及している場合）
  • references/conditional/trusted-modules.md（プロバイダーが aws、azurerm、google、oci、ibm のいずれかの場合）

タスクが複数の検出済みバックエンド、プロバイダー、またはツールにまたがる場合を除き、複数の条件付き参考資料を読み込まないでください。

4) リスク制御を明示して修正手順を提案する

修正ごとに、次の内容を含めてください。

  • これが障害モードに対処する理由
  • なお発生し得る問題
  • ガードレール（テスト、承認、ロールバック）

5) 実装成果物を生成する

該当する場合、次を出力してください。

  • HCL の変更（型付き変数、安定したキー、上限を定めたバージョン）
  • 移行ブロック（moved、インポート戦略）
  • CI パイプラインの更新（plan/apply の分離、成果物、ポリシーチェック）
  • コンプライアンス制御（承認、ポリシールール、証跡の保存先）

信頼できるレジストリモジュールで要求されたリソースに対応でき、ユーザーが raw HCL を求めていない場合は、正確な version ピンを指定してそのモジュールをデフォルトで使用してください（references/conditional/trusted-modules.md を参照）。

6) 最終化する前に検証する

ランタイムとリスクレベルに合わせたコマンドの実行順序を必ず提示してください。 レビュー済みの plan と承認なしに、本番環境へ直接 apply することは決して推奨しないでください。

7) 出力要件

次を返してください。

  • 前提条件と最低バージョン
  • 選択した障害モード
  • 選択した是正策とトレードオフ
  • 検証／テスト計画
  • 破壊的な影響を伴う変更のロールバック／復旧に関する注意事項

コメント

Markdown 対応