Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
A .NET architecture checker that enforces one C# spec and renders the same rules for coding agents.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
SLIDERULE_SOLUTION_PATHWelche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"sliderule": {
"command": "dnx",
"args": [
"SlideRule.Cli",
"--yes",
"mcp"
],
"env": {
"SLIDERULE_SOLUTION_PATH": "your-value"
}
}
}
}Führe das in deinem Terminal aus
claude mcp add sliderule --env SLIDERULE_SOLUTION_PATH=your-value -- dnx SlideRule.Cli --yes mcpTrag die leeren Werte ein, bevor du ihn startest.
In .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"sliderule": {
"command": "dnx",
"args": [
"SlideRule.Cli",
"--yes",
"mcp"
],
"env": {
"SLIDERULE_SOLUTION_PATH": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"sliderule": {
"type": "stdio",
"command": "dnx",
"args": [
"SlideRule.Cli",
"--yes",
"mcp"
],
"env": {
"SLIDERULE_SOLUTION_PATH": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
SLIDERULE_SOLUTION_PATH envDiese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto andypgray bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.3.0) kam vorgestern in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du .NET auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Reelsaw
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Drive a self-hosted Reelsaw: turn long videos into vertical clips, edit, re-render and export them.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
SlideRule is a .NET architecture checker that enforces one C# spec and renders the same rules for coding agents.
A long-lived codebase has layers, boundaries and rules. They live in a few heads, no build step checks them, and the diagrams drift. A change can cross a boundary and the build still passes. A coding agent makes that change quickly and plausibly, and it cannot see which walls are structural. SlideRule's answer is architecture-as-code. The rules become one C# spec, and the spec produces every surface this page names.
AGENTS.md block and per-directory rule cards, and MCP query tools serve the same rules to coding agents.SlideRule is pre-alpha. Minor versions can still change the spec API before 1.0. Status describes what exists today and the versioning rules.
Install the tool, build your solution, and check it:
dotnet tool install -g SlideRule.Cli
dotnet build MyApp.sln sliderule check MyApp.sln
check reads the rules from a spec project, a C# class library in your solution. On a solution with no spec project yet, check stops and reports that it found none. The Getting started page makes one with the SlideRule package, and sliderule graph surveys a solution before it has any rules.
A rule is one statement:
arch.Rule("layering/domain-independent")
.Enforce(domain.MustNotReference(application, infrastructure, api)) .Because("The Domain holds the quote and rate model the rest of the subsystem is built on; it stays free of the layers that depend on it so it can be reasoned about and tested on its own.") .Fix("Move the dependency out of Domain: define an interface here and implement it in the outer layer that needs it.");
That is the whole rule. It has an ID, a posture, a constraint, a reason and a fix. Here the posture is Enforce, and domain and the three layers it must not reference are declared earlier in the spec by namespace pattern. The rule is committed in the clean-architecture example, and CI keeps check green against the codebase it governs. A rule can also cite the page its reason rests on and name a type to copy, as Writing specs shows.
Rules like the one above govern this repository too. One of them keeps the CLI off stdout, because the MCP server speaks JSON-RPC over that channel. Suppose an agent adds a progress printer to the CLI and reaches for Console.WriteLine. When it tries to end its turn, the Claude Code Stop hook in hooks/ runs check over the working tree. The rule goes red, and the hook blocks the stop with this report on the agent's stderr:
FAIL cli/no-stdout — The Host layer must not use `Console.Out`, `Console.Write()` or `Console.WriteLine()`.
because: Stdout is a protocol channel here — the MCP server speaks JSON-RPC over it and CLI output flows through System.CommandLine's console — so a direct Console write corrupts the wire and is invisible to the in-process tests. citation: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#stdio fix: Write CLI output through the command's InvocationConfiguration console; route server diagnostics to the logger or Console.Error. subject: 225 types, 1 generated src/SlideRule.Cli/Rendering/ProgressPrinter.cs:10 — SlideRule.Cli.Rendering.ProgressPrinter uses System.Console.WriteLine() src/SlideRule.Cli/Rendering/ProgressPrinter.cs:15 — SlideRule.Cli.Rendering.ProgressPrinter uses System.Console.WriteLine()
The report gives the rule, its reason, its citation, the fix and each offending line. The subject: line appears only when a rule's subject includes generated code, here 1 of its 225 types. The agent routes the output through the command's console instead, and the next stop is clean.
The SlideRule on itself page shows this repository's own spec on the other surfaces too, from the prose it renders to code scanning and the graph. It also explains how every excerpt on both pages is held to its source.
Every rule has one of the first two, and every scope one of the last two.
| Posture | What it is | What fails |
|---|---|---|
Enforce | the law | every violation, even ones predating the rule |
Migrate | a ratchet over a counted baseline | new violations; baselined sites stay quiet |
Quarantine | containment for a scope | a new reference into the scope |
Caution | dragons for code new callers may use | never fails; a change touching it warns |
Migrate is for a rule the code does not keep yet. sliderule baseline init records the rule's current violations, and any new violation fails from then on. As sites are fixed, sliderule baseline accept-reductions shrinks the baseline, and once it is empty, status suggests promoting the rule to Enforce.
A scope marks code that needs care. Its dragons are notes on why the code is fragile and how to call into it. render puts them on a card in the scope's directory. Quarantine also records the references into the scope on a baseline, and fails any new one except through the surface BoundaryOnlyVia names. Both kinds of scope warn when a change touches them, given check --diff-base . The Writing specs page shows each posture in code, and Operating SlideRule follows a ratchet from capture to promotion.
The three postures after Enforce each answer a way a coding agent goes wrong on an established codebase. Enforce is the law the code already keeps, and a change that crosses it fails wherever the check runs. The Meridian example walks three of those ways on real output.
SqlConnection, so inline SQL reads as house style and an agent writes its next controller the same way. Migrate answers it. The rendered context calls that pattern debt, in words the agent reads before it writes.Quarantine scope makes the gateway the only sanctioned way in.Quarantine or Caution scope answer it. The card on that scope's directory explains what the code does, which part is structural, and how to call in.Each target below reads the same model. Every violation report gives the rule ID, the generated rule sentence, the reason and the exact file:line. A rule's fix, citation and exemplar appear there too when it has them.
| Target | What it is |
|---|---|
sliderule check | one pass-or-fail verdict for the command line and CI |
check --sarif | that verdict as SARIF 2.1.0, for code scanning |
| xUnit adapter | every rule an individually named test |
| build analyzer | a broken rule as a squiggle in the editor and a compiler warning in the build |
sliderule render | the managed AGENTS.md block, per-directory rule cards, and the model as a JSON file |
render --diagram | two Mermaid diagrams: the projects and their references, and the spec's law |
sliderule mcp | arch_check, arch_status, arch_explain, arch_context, and arch_graph, plus a derive_spec prompt |
sliderule hook | check when a Claude Code agent's turn ends; a red rule blocks the stop |
The adapter's failure text is byte-identical to the CLI's. The two share one renderer, and a product test pins them equal. The managed block plus sliderule explain are also the generated architecture documentation, written for agents first and readable by people. The SlideRule on itself page shows the gate that keeps it current.
The Coding agents page explains which agents read the AGENTS.md files and use each surface. It also gives the line a repository with its own CLAUDE.md adds for Claude Code.
NetArchTest and ArchUnitNET run architecture rules inside your unit tests, and they are good at it. SlideRule moves the rules out of test code into one spec and renders every surface above from it.
| Tool | What you write | Where it runs |
|---|---|---|
| NetArchTest | fluent assertions in test methods | your test runner |
| ArchUnitNET | ArchUnit-style rules in test classes | your test runner |
| SlideRule | one spec in its own project | every target above |
The grammar comes from surveying that prior art, and GRAMMAR.md records each divergence. Constraints negate in the verb (MustNotReference), following ArchUnitNET. ArchUnit's FreezingArchRule accepts a rule's current violations as a baseline, and here that is Migrate with its counted baseline. Quarantine applies the same ratchet to a region of code, counting the references into it today and failing any new one that bypasses its sanctioned surface.
Because is mandatory. A rule without one is an invalid spec, and check stops before it evaluates anything, reporting every spec error in one pass. Even the predicate escape hatch, Must(condition, description:), does not compile without its description. Every reason ships to your agents in the rendered context. In the Interchange example, each of the 12 rules has a Citation naming the learn.microsoft.com page its reason rests on. Of those 12, 9 come from a shared rule pack, an ordinary class library of static methods. The pack owns the citation, and the spec picks the
Nur der Anfang wird gezeigt; den Rest findest du im Repo