Skill.md検索

4つのコードレビューサブエージェント（正確性、仕様整合性、設計、エージェント設計）を並列起動し、変更コードを多角的に分析できます。 検出された問題を「即修正できるもの」と「Issue として起票すべきもの」に自動振り分けできます。 Typo・lint違反・明らかなバグなど判断が明確な修正はその場で直し、仕様変更や判断が必要な問題はGitHub Issueに記録できます。 nr validate で修正後の動作を自動検証し、修正内容を報告書としてまとめられます。 git diff による変更範囲の自動抽出と、ファイル・ディレクトリ指定による柔軟なレビュー対象選択ができます。 マージ前のコードレビュー時間を短縮したい開発チーム バグ・設計問題・仕様ズレを体系的に検出・記録したい開発者 Typo等の些細な問題を自動修正し、本質的な課題に集中したい技術リード マイクロサービス・AIエージェント実装の設計品質を保ちたい人 git diff main...HEAD で変更ファイル一覧・差分内容を取得（またはユーザー指定のファイル・ディレクトリ）し、Agent ツールで correctness-reviewer、spec-compliance-reviewer、design-reviewer、agent-architecture-reviewer の4エージェントを並列起動します。各エージェントは diff と変更ファイル一覧を受け取り、リードオンリーで問題検出のみ行います。Phase 3で4エージェントの報告を統合し、修正意図が明確で局所的かつ仕様変更なしの項目は「即修正」、要件変更・スコープ外・複数アプローチ・技術負債記録が必要な項目は「Issue 起票」に振り分けます。判断に迷う場合はユーザーに確認します。即修正後は nr validate で検証し、Phase 5で修正・検証結果と起票Issue一覧を報告します。

フォーマット確認、Lint チェック、型チェックを nr validate で一括実行し、コード品質の基本を自動確認できます。 bun test で全テスト（*.spec.ts + *.test.ts）を実行し、仕様テストの失敗と単体テスト失敗を区別して報告します。 README.md や DEPS.md などのドキュメントとコード実装の整合性を検証し、ドキュメントの陳腐化を防げます。 検証結果を「PASS/FAIL」の判定フォーマットで明確に報告し、どこに問題があるか一目でわかるようにします。 TypeScript/Bun プロジェクトで品質保証を自動化し、コミット前の品質ゲートを強化したい方 テスト失敗やエラーが発生した際に、根本原因を素早く特定したいエンジニア ドキュメントと実装のズレを早期に発見し、保守性の高いコードベースを保ちたい開発チーム

漠然としたアイデアを対話を通して具体化し、実現したい本当のゴールを引き出せます。 Webで先行事例・類似プロジェクト・関連技術を調べ、すでに存在する解法やベストプラクティスを知ることができます。 技術的実現可能性・既存アーキテクチャとの適合性・工数感などを評価し、アイデアの現実性を判断できます。 検討結果をIDEA.mdに記録することで、別セッションで仕様化を進める際の引き継ぎスムーズになります。 形式張らないブレインストーミング環境で、既存の実装に縛られず自由に発想を広げられます。 新しい機能やアーキテクチャのアイデアを、本格的な設計に進む前にしっかり検討したい設計者・PM 既存事例を調べながら、似たような問題がどう解決されているか学びたい開発者 チームのアイデアを整理し、実現可能なものと保留すべきものを分ける必要がある人 漠然とした「いいかもな」という感覚を、具体的で実現可能なプランに落とし込みたい企画者

エラーが発生した時点で、推測に頼らず体系的に原因を調査し、修正前に根本原因を明確にできます スタックトレースやエラーメッセージから問題発生のタイミングを正確に読み取り、最近の変更との関連性を判定できます 正常に動作している似たコードとの差分を自動抽出して、問題の要因候補を素早く絞り込めます 同じバグに何度も引っかかることを防ぎ、修正後に別の箇所が壊れるという連鎖的な問題を防止できます テスト失敗や予期しない動作が起きた時に、まず「なぜ起きたのか」を確実に理解してから対応できます テストが突然失敗して、どこが悪いのか分からず困っているエンジニア バグの修正を試みても別の場所が壊れる経験を繰り返している開発チーム システム障害の原因特定に時間がかかりすぎていると感じるプロダクト責任者 コードレビュー時に「なぜこのバグが起きたのか」という本質的な質問をしたいリーダー

与えられた仕様書や設計ドキュメントを完全に読み込み、曖昧さなく正確にコードに落とし込みできます 実装前に計画を立て、どのファイルをどの順番で変更するかを整理し、影響範囲を最小限に抑えることができます プロジェクト内の既存のコーディング規約やパターンに自動で合わせるため、チーム全体の一貫性を保つことができます TypeScriptの型安全性を最大限活用し、実装時点で潜在的なバグを防止できます 段階的に実装を進め、各ステップで型チェックやLintを実行して品質を維持できます 仕様書はあるが、どう実装するか決断が必要な設計者やプロジェクトマネージャー 実装品質のばらつきを統一したいテックリーダーやCTO 複雑な機能をシンプルで保守性の高いコードで実装したいエンジニア 仕様にない余分な機能を実装して後で苦労している開発チーム

ユーザーと対話しながら曖昧な要件を明確な仕様に落とし込み、実装前に認識ズレを解消できます 実装に先立って公開インターフェース（API）と型定義を設計し、実装チームへの「契約」となる仕様を整えることができます 既存のテストコードを読み、実は何が仕様なのかを自動抽出し、明確な仕様書として整理できます 仕様に基づいた検証用テスト（仕様テスト）を記述し、実装がその仕様を満たしているかを保証できます 仕様が変わった時に、README等のドキュメントとの整合性をチェックし、管理上の矛盾を防ぐことができます 「これってどういう仕様が正しいの？」という要件定義の曖昧さに悩むプロダクト責任者 テストは書いてあるが、実際の仕様が何なのか分からなくなっているレガシー開発チーム 実装が仕様から乖離して、後でトラブルが起きることを事前に防ぎたいリーダー 複数の設計アプローチで迷っており、トレードオフを明確にしたいアーキテクト

実装されたコードの正常系・異常系・境界値・エッジケースを洗い出し、高い網羅性のテストを効率的に設計できます プロジェクト内の既存テストの書き方を自動で分析し、同じスタイルで一貫性のあるテストを記述できます 条件分岐やループなどのロジックを検証するテストを書き、リファクタリング時に振る舞いの変化を素早く検出できます モック・スタブ（模擬オブジェクト）を適切に活用して、外部依存のないテストを作成し、テストの実行速度を高速化できます テストの失敗から、実装の潜在的なバグや仕様漏れを早期に発見できます 「テストをどこまで書けばいいか」という範囲の判断に迷っているエンジニア リファクタリング時にバグが隠れて、後から問題が見つかることに困っている開発チーム テストの網羅性を高めて本番トラブルを減らしたいQAエンジニアやプロダクト責任者 既存コードのテストがなく、テスト設計から始めたいレガシー開発プロジェクト

型チェック・Lint・テストを一括実行し、コードの品質問題を自動検出できます 仕様テストとユニットテストの失敗を区別し、どちらの問題なのかを明確に診断できます 実装コードが README などのドキュメントで述べられた要件と整合しているかを確認でき、ドキュメントとコードのズレを防ぐことができます エラーが出た場合に、その根本原因と修正案を提示でき、修正チームへのフィードバックが明確になります 完了前に継続的に品質検証を実施し、不具合がある状態での進行を防ぐことができます 本番デプロイ前に品質ゲートを厳格にしたいリリースマネージャーやCTO テストは書いているが、実際に全部パスしているか確かめたことがない開発チーム コードレビュー時に「これって本当に大丈夫？」という懸念を客観的に判定したいレビュアー CI/CD パイプラインの自動検証を強化し、手作業の品質チェックを減らしたい運用チーム