Dotnet Slopwatch

Slopwatch: LLM Anti-Cheat for .NET

Two-layer slop prevention system for .NET projects:

• Code-Level (SW-xxx) — Automated detection via Slopwatch CLI tool (disabled tests, empty catches, warning suppression)
• Architecture-Level (SLOP-xxx) — Anti-pattern catalog requiring human/LLM judgment (layer violations, responsibility leaks)

When to Use This Skill

Use this skill when:

• Validating LLM-generated C# code changes for reward hacking patterns
• Checking whether Presentation layer code contains domain logic that belongs in Application/Domain layers
• Setting up Slopwatch as a Claude Code post-edit hook
• Integrating anti-slop quality gates into GitHub Actions or Azure Pipelines
• Establishing a baseline for existing .NET projects with technical debt
• Reviewing architecture decisions in layered .NET applications (DDD, Clean Architecture)

Related Skills

• crap-analysis — Identify high-risk code combining complexity with low coverage
• modern-csharp-coding-standards — The coding standards Slopwatch helps enforce
• dotnet-local-tools — Manage Slopwatch as a versioned local tool

Core Principles

1. Zero Tolerance for New Slop — Existing issues are baselined; new shortcuts are blocked unconditionally (基礎と型)
2. Fix, Don't Suppress — Every flagged pattern requires a proper fix, not a workaround (温故知新)
3. LLMs Are Not Special — Same quality rules apply to human and AI-generated code (ニュートラル)
4. Baseline Isolates Legacy — Pre-existing debt is acknowledged but separated from new changes (余白の設計)

Workflow: Install & Use Slopwatch

Step 1 — Install Slopwatch

Add to .config/dotnet-tools.json as a local tool:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "slopwatch.cmd": {
      "version": "0.3.4",  // check latest: dotnet tool search slopwatch
      "commands": ["slopwatch"],
      "rollForward": false
    }
  }
}

dotnet tool restore

Values: 継続は力（ツールをバージョン管理し再現可能に）

Step 2 — Establish Baseline

Create a baseline of existing issues before using Slopwatch on a project:

slopwatch init
git add .slopwatch/baseline.json
git commit -m "chore: add slopwatch baseline"

Legacy code may have pre-existing patterns. The baseline ensures only new slop is caught.

Values: 余白の設計（レガシーを認め、新規の品質を守る）

Step 3 — Run After Every Code Change

# Standard analysis
slopwatch analyze

# Strict mode — fail on warnings too (recommended for LLM sessions)
slopwatch analyze --fail-on warning

When Slopwatch flags an issue, do not ignore it:

1. Understand why the LLM took the shortcut
2. Request a proper fix — be specific about what's wrong
3. Verify the fix doesn't introduce different slop

❌ SW001 [Error]: Disabled test detected
   File: tests/MyApp.Tests/OrderTests.cs:45
   Pattern: [Fact(Skip="Test is flaky")]

→ "Fix the flaky test's timing issue, don't disable it."

Values: 基礎と型（根本原因の修正が型）

Step 4 — Integrate with AI Coding Assistant

4a: Automatic Hook (Claude Code)

Add Slopwatch as a post-edit hook in .claude/settings.json. The --hook flag analyzes only git-dirty files, outputs errors to stderr, and fails on warnings by default:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "slopwatch analyze -d . --hook",
            "timeout": 60000
          }
        ]
      }
    ]
  }
}

4b: On-Demand (Copilot CLI)

Ask @dotnet-shihan to run slopwatch. The agent executes slopwatch analyze via shell and interprets results:

@dotnet-shihan slopwatch を実行して
@dotnet-shihan 近道してないかチェックして

The agent references this skill and the SLOP-xxx catalog during code reviews automatically.

Values: 成長の複利（自動ガードレールで品質を仕組み化）

Step 5 — Add to CI/CD Pipeline

Use as a quality gate in 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 install --global Slopwatch.Cmd
      - run: slopwatch analyze -d . --fail-on warning

Values: 基礎と型（品質ゲートを基盤に組み込む）

Code-Level Detection Rules (SW-xxx)

Automated rules enforced by the Slopwatch CLI tool.

Architectural Slop Patterns (SLOP-xxx)

Design-level anti-patterns requiring human or LLM judgment. These cannot be detected by static analysis alone — they require understanding of architectural intent.

SLOP-001: Layer Boundary Violation

Severity: Error

Symptom: Upper layer (Presentation/ViewModel) uses string.Split, Substring, or Regex to reconstruct domain values from a concatenated string received from a lower layer.

Why It's Dangerous:

• Relies on implicit assumptions about string format (delimiters, order, escaping)
• Domain knowledge leaks into Presentation layer ("product type codes can contain hyphens")
• Fragile under change: format changes break Presentation code silently

Example:

// ❌ SLOP-001: Presentation layer parsing domain values
// compositeCode = "20240101-MFG001-AL-6XN-H12345"
var parts = compositeCode.Split('-');
var productType = parts[2]; // Returns "AL" — WRONG (actual: "AL-6XN")

Product type AL-6XN contains a hyphen, so naive splitting destroys the value.

// ✅ Fix: Extend Application layer response with structured fields
record ComparisonRow(
    // ... existing fields ...
    string CategoryCode,   // Set from domain entity
    string ProductType,
    string LotNumber
);

Prescription: If the upper layer needs data that isn't in the response, extend the lower layer's response — never reconstruct domain values by parsing strings.

Checklist:

• Does the new feature need data not in the current Application layer response?
• If yes, have structured fields been added to the response record?
• Is the Presentation layer free of Split/Substring/Regex on domain strings?

Decision Rule: "Does this Split require knowledge of domain structure to write?" → Yes = SLOP-001 violation. No = legitimate UI formatting.

Values: 基礎と型（DDD layer boundaries are foundational — violating them creates hidden fragility）

Good Practices

1. Strict Mode for LLM Sessions

What: Elevate all rules to error severity during AI-assisted coding.

Why: LLMs are more likely to introduce slop than humans — higher guard rails are justified.

Values: 基礎と型（厳格な型でスロップを排除）

2. Baseline on First Use

What: Always run slopwatch init before first analyze on existing projects.

Why: Without a baseline, every legacy issue triggers false positives, eroding trust in the tool.

Values: 余白の設計（既存の技術的負債を認識して分離）

Common Pitfalls

1. Updating Baseline to Silence Warnings

Problem: Running --update-baseline whenever Slopwatch flags an issue.

Solution: Only update baseline for genuinely justified exceptions (third-party constraints, generated code). Document the reason in a code comment.

2. Disabling Rules Instead of Fixing Code

Problem: Setting "enabled": false for noisy rules.

Solution: Fix the underlying code. If a rule produces false positives, report it upstream; don't disable the guard rail.

Anti-Patterns

"We'll Fix It Later"

What: Accepting slop with a plan to revisit.

Why It's Wrong: "Later" never comes. The shortcut becomes permanent technical debt.

Better Approach: Fix the actual problem now. If time-constrained, create a tracked issue and keep the guard rail active.

Slop-Fixing with More Slop

What: Fixing a disabled test by adding Task.Delay(2000) instead of fixing the race condition.

Why It's Wrong: Replaces one slop pattern (SW001) with another (SW004).

Better Approach: Identify and fix the root cause (race condition, timing dependency, shared state).

Quick Reference

# First time setup
slopwatch init
git add .slopwatch/baseline.json

# After every LLM code change
slopwatch analyze

# Strict mode (recommended)
slopwatch analyze --fail-on warning

# Hook mode (git dirty files only)
slopwatch analyze -d . --hook

# Update baseline (rare, document why)
slopwatch analyze --update-baseline

# JSON output for tooling
slopwatch analyze --output json

Override Decision Table

Resources

• Slopwatch GitHub — Source code and documentation
• Slopwatch NuGet Package
• dotnet-local-tools — Managing local .NET tools
• PHILOSOPHY.md — Development constitution