nestjs-feature-audit

NestJS 機能監査

1つの機能について、文書化された目標と、特定したリビジョンでの実装を比較します。追跡可能なステータスレポートを作成し、指摘事項は修正しません。

実行前の競合確認

ファイルの編集や状態を変更するコマンドを実行する前に、有効な指示を照合してください。読み取り専用の調査は続行できます。

前提条件

機能名が空でないことを確認し、ブランチが指定されていない場合に限り、デフォルトで main を対象ブランチとして解決します。ブランチの準備に先立ち、指示、Git の状態とリモート、ドキュメントを確認してください。期待される動作は指定されたロードマップに基づき、現在の動作はソース、テスト、実行時の証拠によって確認します。ユーザーの変更を保持し、監査対象のリビジョンを1つに固定してください。判断が重複する場合に限り、他の有効なスキルを参照してください。

主な責任範囲

このスキルは、安全な対象ブランチの準備、ロードマップへのトレーサビリティ、ステータス分類、および4セクション構成のレポートを担当します。関連するスキルがインストールされている場合は、次のスキルと連携してください。

• nestjs-architecture-principles：モジュール、依存関係、データ、トランザクションの境界。
• nestjs-oop-design-patterns：オブジェクトの責任、インバリアント、パターン。
• nestjs-features-performance：ライフサイクル、API／セキュリティ、テスト、実行時、パフォーマンス。
• nestjs-professional-software-engineering：実装と検証。
• nestjs-code-audit：読み取り専用の品質に関する証拠と、重複を除いたレポート。
• nestjs-git-commit-pr-message：許可された Git での公開と CI のフォローアップ。

これらは判断の境界であり、必須の依存関係ではありません。作業を別のワークフローに引き継ぐ場合も、担当領域を維持してください。

競合の確認

ブランチ、ロードマップ、指摘事項、コマンド、または満たされていない前提条件が競合する場合は、明示的なユーザーの意図、リポジトリ／ロードマップの規約、確認済みの実行時制約、そして最も限定的な担当領域の順に照合してください。リビジョンを混在させたり、ロードマップの記述を実行の許可とみなしたりしてはいけません。重大な競合が残る場合は、変更を加える前に停止し、判断に必要な最小限の確認事項を尋ねてください。監査のみの依頼では修正は許可されません。明示的な監査と修正の依頼がある場合は、ロードマップのゲートと監査を終えた後、独立した実装フェーズを実施できます。

呼び出し方法

推奨する、移植性の高い呼び出し方法：

$nestjs-feature-audit "payments"
$nestjs-feature-audit "payments" --branch "release/2026-q3"

ホストがユーザーの要求したコマンド構文をすでに処理する場合は、同等の方法で解析してください。

/audit_feature payments
/audit_feature payments on branch release/2026-q3

単独の /audit_feature がすべてのクライアントにインストールされていると主張してはいけません。Codex では、互換性確保のための任意のプロンプトとして /prompts:audit_feature を使用できます。インストール済みのスキルがある場合は、そちらを優先してください。

必須のワークフロー

1. 対象ブランチを安全に準備する

1. リポジトリのルートを特定し、Git に変更を加える前に、そのリポジトリの指示を読みます。
2. git status --short --branch の結果、現在のブランチ、リモート、対象ブランチがローカル／リモートに存在するかどうかを記録します。
3. ワークツリーに未コミットの変更がある場合、Git 操作が進行中の場合、またはチェックアウトがデタッチ状態の場合は、切り替えや更新を行う前に停止します。自動的に stash、変更の破棄、reset、clean、強制的なブランチ切り替えを行ってはいけません。ユーザーが明示的に許可した場合に限り、同じ未コミット状態のスナップショットで作業を続行し、その例外をレポートに記録してください。
4. リモート追跡ブランチが存在する場合は、そのリモートから fetch し、通常の方法でブランチを切り替え、fast-forward のみを行います。監査の一環として、履歴が分岐した場合のマージやリベースを行ってはいけません。
5. 監査対象のブランチ、コミット SHA、未コミット状態、リモートのリビジョン、および最新性を確認できたかどうかを記録します。設定済みのリモートを確認できない場合、ユーザーがローカルのスナップショットを明示的に許可しない限り、ブランチが最新であると主張する前に停止してください。

リポジトリに適した同等の安全なコマンドを使用してください。

git status --short --branch
git branch --show-current
git remote -v
git fetch --prune origin
git switch -- "$audit_branch"
git merge --ff-only -- "origin/$audit_branch"
git rev-parse HEAD

明示的な機能監査の依頼では、対象ブランチの安全な選択と fast-forward による準備が許可されます。破壊的なクリーンアップや公開は許可されません。

2. コンテキストを収集し、ロードマップのゲートを適用する

1. この機能に適用されるプロジェクトの原則、コンセプト、標準、アーキテクチャ上の決定、コントリビューター向けルールを確認します。
2. docs/ のファイル名と内容を検索し、機能名、認められている別名、roadmap、plan、milestone、phase、acceptance、migration を調べます。
3. エントリーポイント、モジュール、プロバイダー、アダプター、永続化、設定、マイグレーション、テスト、コントラクト、テレメトリー、デプロイ成果物を通じて機能コードを特定します。まず検索してください。フォルダー名だけを根拠にしてはいけません。
4. 利用可能な会話コンテキストにある要件や決定は、二次的な根拠としてのみ使用します。会話履歴を利用できない場合は、その旨を伝えてください。履歴を捏造したり、リポジトリーのロードマップで十分な場合に作業を中断したりしてはいけません。
5. ロードマップとして認めるのは、特定可能な機能のスコープと、具体的な対象項目、フェーズ、受け入れ条件、または移行の成果を定めているものに限ります。タイトル、TODO への言及、変更履歴の項目、一般的な製品説明は、明確なロードマップではありません。

docs/ に明確なロードマップがない場合は、実装との比較を始める前に中断し、ユーザーに提示または特定を依頼してください。検索したパスと用語を報告します。ユーザーが直接提示したロードマップはゲートを満たします。その場合、リポジトリーのドキュメントではなく、ユーザー提供のものとして明記してください。ゲートの詳細については、roadmap-discovery.md に従ってください。

3. トレーサビリティマトリクスを作成する

ロードマップの各項目について、次の手順を実施します。

1. 受け入れ条件の厳しさを弱めずに、要件を正規化します。
2. 要件を、ソース、テスト、設定、スキーマ／マイグレーション、生成されたコントラクト、デプロイ／ランタイムの根拠、および関連する標準に対応付けます。
3. 観測された状態を verified、partial、absent、superseded、broken、blocked、not verifiable のいずれかで記録します。
4. 各項目に、主要なレポートカテゴリを必ず1つ割り当てます。異なる状態を持つ部分がある場合は、ロードマップ項目を明示的なサブ項目に分割します。
5. 肯定的な主張と否定的な主張のすべてに、パスと行番号の引用、または正確なコマンドと結果を付けます。不在を主張する場合は、検索内容と確認した統合ポイントも記載します。

完了した作業、ギャップ、レガシー実装、不具合、ブロッカー、未検証の候補を区別するには、evidence-classification.md を使用してください。

4. ドメイン標準と照合する

• アーキテクチャに関する主張を、実際のモジュール／インポート、依存関係、データ／書き込み、トランザクション、サービスの境界と比較します。
• オブジェクト設計に関する主張を、実際の責務、不変条件、協調関係、変更要件と比較します。
• ランタイムに関する主張を、ライフサイクルの配線、セキュリティ制御、テスト、設定、ビルド済み成果物、許可されたランタイム上の根拠と比較します。
• テスト、デプロイ、マイグレーション、外部システム、ランタイムの確認を実施できなかった場合、または安全に実施できなかった場合は、未検証として扱います。not run を成功や失敗に置き換えてはいけません。
• ロードマップの完了と本番環境での証明を区別します。ソースがマージ済みで実装されていても、ロールアウトや本番環境での受け入れ項目がブロック中の場合があります。

5. 指定されたレポートを返す

最初に、機能、ブランチ、コミット、変更状態／鮮度、ロードマップの出典、監査対象範囲、および1文の判定を記載します。その後、次の見出しをこの順序どおりに記載します。

1. ✅ 実装済み
2. ❌ 未対応／未実装
3. ⚠️ レガシーコード
4. 🛑 不具合とブロッカー

各項目には、ロードマップの要件、観測された状態、根拠、影響、次の検証または終了条件の証拠を記載します。4つの見出しはすべて残し、該当するカテゴリが空の場合は 監査で確認した根拠に該当するものはありません。 と記載します。report-template.md を使用してください。

ロードマップで項目の重み付けが定義されていない限り、完了率を割り当ててはいけません。ユーザーが特定の操作と範囲を明示的に許可していない限り、実装、コミット、プッシュ、デプロイ、ロードマップの編集を行ってはいけません。許可は最初の依頼に含まれている場合があります。実装は監査後にのみ開始します。また、修正の許可は公開、デプロイ、ロードマップ編集の許可を意味しません。

参照先の振り分け

必要な作業	読み込むファイル
ドキュメントがロードマップの必須ゲートを満たしているか判断する	roadmap-discovery.md
証拠を二重に数えたり、完了状況を誇張したりせずに分類する	evidence-classification.md
正確に4つのセクションで構成された最終レポートを作成する	report-template.md