메뉴
.NET 向けの 2 層スロップ防止。Slopwatch CLI によるコードレベル検出（SW-xxx）と、 アーキテクチャ上のアンチパターンカタログ（SLOP-xxx）を扱う。 LLM 生成の C# コードを検証するとき、層境界違反を確認するとき、 または anti-slop の品質ゲートを CI/CD に組み込むとき。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | dotnet-slopwatch |
| description | .NET 向けの 2 層スロップ防止。Slopwatch CLI によるコードレベル検出（SW-xxx）と、 アーキテクチャ上のアンチパターンカタログ（SLOP-xxx）を扱う。 LLM 生成の C# コードを検証するとき、層境界違反を確認するとき、 または anti-slop の品質ゲートを CI/CD に組み込むとき。 |
このドキュメントは dotnet-slopwatch の日本語版です。
.NETプロジェクト向けの2層スロップ予防システム： ゴール駆動で使うため、最初に達成したいゴール、成功条件、確認手段を短く固定します。
このスキルを使用する場面：
dotnet — .NET family の入口dotnet-modern-csharp-coding-standards — Slopwatchが施行を助けるコーディング標準.config/dotnet-tools.jsonにローカルツールとして追加する：
{
"version": 1,
"isRoot": true,
"tools": {
"slopwatch.cmd": {
"version": "0.3.4",
"commands": ["slopwatch"],
"rollForward": false
}
}
}
最新バージョンは dotnet tool search slopwatch で確認します。
dotnet tool restore
Why: ツールのバージョンをリポジトリに固定することで、チーム全員が同じ検出ルールで作業できる。
Values: 継続は力（ツールをバージョン管理し再現可能に）
プロジェクトでSlopwatchを使用する前に、既存の問題のベースラインを作成する：
slopwatch init
git add .slopwatch/baseline.json
git commit -m "chore: add slopwatch baseline"
Why: レガシーコードにはパターンが存在する場合がある。ベースラインにより新しいスロップのみが検出される。
Values: 余白の設計（レガシーを認め、新規の品質を守る）
# 標準分析
slopwatch analyze
# 厳格モード — 警告でも失敗（LLMセッション推奨）
slopwatch analyze --fail-on warning
Slopwatchが問題をフラグした場合、無視しない：
Why: 根本原因の修正が「型」。テストを通すための近道は、問題を先送りにしているだけ。
Values: 基礎と型（根本原因の修正が型）
.claude/settings.jsonにポストエディットフックとしてSlopwatchを追加する。--hook フラグはgit dirty filesのみを解析し、stderrにエラーを出力し、デフォルトで警告時に失敗する：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit|MultiEdit",
"hooks": [
{
"type": "command",
"command": "slopwatch analyze -d . --hook",
"timeout": 60000
}
]
}
]
}
}
オーケストレーターに slopwatch 実行を依頼する。必要なら built-in review を併用し、slopwatch analyze を shell 経由で実行して結果を解釈する：
slopwatch を実行して
近道してないかチェックして
レビュー時はこのスキルと SLOP-xxx カタログを参照する。
Why: 自動ガードレール（Claude Code）またはオンデマンド検査（Copilot CLI）により、LLMのスロップが人間のレビュー前に検出される。
Values: 成長の複利（自動ガードレールで品質を仕組み化）
GitHub Actionsの品質ゲートとして使用する：
jobs:
slopwatch:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '9.0.x'
- run: dotnet tool restore
- run: dotnet tool run slopwatch analyze -d . --fail-on warning
Why: CIに組み込むことで、PRレビュー前にスロップが自動検出される。
Values: 基礎と型（品質ゲートを基盤に組み込む）
Slopwatch CLIツールが自動で適用するルール。
| ルール | 重大度 | パターン | 例 |
|---|---|---|---|
| SW001 | Error | テスト無効化 | [Fact(Skip="flaky")], #if false |
| SW002 | Warning | 警告抑制 | #pragma warning disable CS8618 |
| SW003 | Error | 空catchブロック | catch (Exception) { } |
| SW004 | Warning | 恣意的な遅延 | テスト内のawait Task.Delay(1000); |
| SW005 | Warning | プロジェクトファイルスロップ | <NoWarn>CS1591</NoWarn> |
| SW006 | Error | パッケージバージョンオーバーライド | CPMバイパスのインラインVersion="1.0.0" |
設計レベルのアンチパターン。人間またはLLMの判断が必要で、静的解析だけでは検出できない — アーキテクチャの意図を理解する必要がある。
重大度: Error
症状: 上位層（Presentation/ViewModel）が、下位層から受け取った結合文字列を string.Split、Substring、Regex 等で再解釈し、ドメイン値を再構築している。
なぜ危険か:
Why（深掘り）: この違反が起きる根本的な理由は「データが足りないから手元で作る」というLLMのSlop傾向にある。Application層のレスポンスに必要なフィールドが無い → 上位層でパースして補う — これは「最短距離の誘惑」であり、層構造という「型」を破壊する。型を破ると一見動くが、ドメインの構造を知らないとバグが見えない（製品型番のハイフン問題）。
実例:
// ❌ SLOP-001: Presentation層でドメイン値をパース
// compositeCode = "20240101-MFG001-AL-6XN-H12345"
var parts = compositeCode.Split('-');
var productType = parts[2]; // "AL" を返す — 誤り（正解: "AL-6XN"）
製品型番 AL-6XN にハイフンが含まれるため、単純な分割では値が破壊される。
// ✅ 修正: Application層のレスポンスに構造化フィールドを追加
record ComparisonRow(
// ... 既存フィールド ...
string CategoryCode, // Domain層のエンティティから直接セット
string ProductType,
string LotNumber
);
処方: 上位層に必要なデータがレスポンスに無いなら、下位層のレスポンスを拡張せよ — 文字列パースでドメイン値を再構築するな。
チェックポイント:
Split/Substring/Regex が無いか？判断基準: 「その Split は、ドメインの構造を知らないと書けないか？」 → Yes なら SLOP-001 違反。No なら正当な UI フォーマット処理。
Values: 基礎と型（DDD層構造は「型」。型を破ると一見動くが、ドメイン知識の漏洩で脆くなる）
What: AI支援コーディング中にすべてのルールをerror severityに引き上げる。
Why: LLMは人間よりもスロップを導入しやすい — より高いガードレールが正当化される。
Values: 基礎と型（厳格な型でスロップを排除）
What: 既存プロジェクトでの初回analyze前に必ずslopwatch initを実行。
Why: ベースラインなしでは、すべてのレガシー問題が偽陽性を引き起こし、ツールへの信頼が損なわれる。
Values: 余白の設計（既存の技術的負債を認識して分離）
Problem: Slopwatchが問題をフラグするたびに--update-baselineを実行する。
Solution: 正当に例外とされる場合のみベースラインを更新（サードパーティ制約、生成コード）。理由をコードコメントに記録。
Problem: ノイジーなルールに"enabled": falseを設定。
Solution: 根本のコードを修正する。ルールが偽陽性を生む場合、アップストリームに報告する。ガードレールを無効にしない。
What: 後でリビジットする計画でスロップを受け入れる。
Why It's Wrong: 「後で」は来ない。近道が永久的な技術的負債になる。
Better Approach: 実際の問題を今修正する。時間制約がある場合、追跡issueを作成しガードレールは有効のまま保つ。
What: 無効化されたテストをTask.Delay(2000)の追加で修正し、レースコンディションは放置。
Why It's Wrong: 1つのスロップパターン（SW001）を別のパターン（SW004）に置き換えているだけ。
Better Approach: 根本原因を特定して修正する（レースコンディション、タイミング依存、共有状態）。
# 初回セットアップ
slopwatch init
git add .slopwatch/baseline.json
# LLMコード変更後に毎回
slopwatch analyze
# 厳格モード（推奨）
slopwatch analyze --fail-on warning
# フックモード（git dirty filesのみ）
slopwatch analyze -d . --hook
# ベースライン更新（稀、理由を記録）
slopwatch analyze --update-baseline
| シナリオ | アクション | 要件 |
|---|---|---|
| サードパーティがパターンを強制 | ベースライン更新 | 理由のコードコメント |
| 生成コード（編集不可） | 除外リストに追加 | 設定に記録 |
| 意図的なレート制限 | ベースライン更新 | コードコメント、テスト外 |
| 「テストが不安定」 | ❌ オーバーライドしない | 不安定さを修正 |
| 「警告がうるさい」 | ❌ オーバーライドしない | コードを修正 |
こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。 接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずに サーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。
調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。 実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。
こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。
Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ 分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。
新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。