jpskill.com
🛠️ 開発・MCP コミュニティ

quality-gates

Black-Tortoiseプロジェクトの品質を確保するため、テストや監査、アーキテクチャの承認プロセスを統合的に管理するSkill。

📜 元の英語説明(参考)

Auditing, testing, and architecture-governance instructions for Black-Tortoise, covering when to run `architecture:gate`, update docs/AUDIT-*, ship tests, and satisfy `.github/instructions/64-quality-testing-copilot-instructions.md` before merge.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Black-Tortoiseプロジェクトの品質を確保するため、テストや監査、アーキテクチャの承認プロセスを統合的に管理するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

品質ゲートと監査マスターガイド

目的

マージ前のチェックリスト、つまり、どのゲートを通過する必要があるか、どの監査成果物を更新するか、およびリポジトリが期待するテストを、.github/instructions/64-quality-testing-copilot-instructions.md に従って文書化します。

実行するゲート

  • 構造的な変更(新しい依存関係、クロスレイヤーインポート、新しいモジュール)があった場合は、pnpm run architecture:gate を実行してください。これにより、.github/instructions/61-architectural-governance-copilot-instructions.md で説明されている Dependency Cruiser のルールが適用されます。
  • PR の前に、pnpm run lintpnpm run build -- --noEmit、および機能説明書に記載されている関連するユニットスイートを実行してください。
  • git commit によってトリガーされる Husky/lint-staged フックが(package.json に従って eslinttsc --noEmit が)パスすることを確認してください。

ドキュメントと監査追跡

  • 機能、イベント、または重要なワークフローを変更するたびに docs/AUDIT-<module>.md を更新してください。.github/instructions/64-quality-testing-copilot-instructions.md で指定されているように、不変条件、境界、および監査結果を記録してください。
  • 完了する前に、requirements.md および tasks.md に要件/ステータスを文書化してください(ステータス値:not-started、in-progress、completed、blocked)。
  • architecture:gate の失敗ログをキャプチャし、レビュー担当者が最後のパスしたゲート以降の変更点を確認できるように、メモに含めてください。

テストの期待値

  • 変更によって影響を受けるすべてのクリティカルパスとドメイン不変条件をテストでカバーしてください(ユニットストア/ドメインには Jasmine + Karma、ハッピーパスフローには Playwright)。
  • Playwright を、堅牢なセレクター(data-testid、roles)とエミュレーターのリセットとともに使用し、テストが決定論的になるようにしてください(.github/skills/e2e-playwright にこれらのパターンは既に記述されています)。
  • 非同期またはシグナルの遷移を導入する場合は、完全な Arrange-Act-Assert サイクルを実行し、takeUntilDestroyed() または rxMethod の破棄でサブスクリプションをクリーンアップしてください。

このスキルを適用するタイミング

  • ゲートコマンド、監査担当者、またはドキュメントに言及する必要があるテスト、指示、または GA/QA タスクを追加/変更するたびに。
  • 監査資産が docs/AUDIT-* の期待値と同期するように、ドキュメントまたはパイプラインスクリプトを操作するたびに。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Quality Gates & Audit Master Guide

Intent

Document the pre-merge checklist: what gates must pass, which audit artefacts to update, and which tests the repo expects, per .github/instructions/64-quality-testing-copilot-instructions.md.

Gates to Run

  • Run pnpm run architecture:gate after any structural change (new dependencies, cross-layer imports, new modules); this enforces the dependency cruiser rules described in .github/instructions/61-architectural-governance-copilot-instructions.md.
  • Before PR, execute pnpm run lint, pnpm run build -- --noEmit, and the relevant unit suites described in the capability instructions.
  • Ensure Husky/lint-staged hooks triggered by git commit pass (eslint and tsc --noEmit per package.json).

Documentation & Audit Tracking

  • Update docs/AUDIT-<module>.md whenever you change a capability, event, or critical workflow; note invariants, boundaries, and audit findings as specified in .github/instructions/64-quality-testing-copilot-instructions.md.
  • Document requirements/status in requirements.md and tasks.md (status values: not-started, in-progress, completed, blocked) before completion.
  • Capture architecture:gate failures’ logs and include them in your notes so reviewers can see what changed since the last passing gate.

Testing Expectations

  • Cover every critical path and domain invariant touched by your change with tests (Jasmine + Karma for unit stores/domains, Playwright for happy-path flows).
  • Use Playwright with resilient selectors (data-testid, roles) and emulator resets so tests are deterministic (.github/skills/e2e-playwright already describes these patterns).
  • When introducing async or signal transitions, do full Arrange-Act-Assert cycles and clean up subscriptions with takeUntilDestroyed() or rxMethod disposal.

When to Apply This Skill

  • Anytime you add/modify tests, instructions, or GA/QA tasks that must mention gating commands, auditors, or docs.
  • Whenever you touch documentation or pipeline scripts so that audit assets remain in sync with the docs/AUDIT-* expectations.