Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Agent-first MCP. 11 AST adapters, 12 named languages, 51 tools, mission outcomes. Local.
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.
Du brauchst
Welche 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": {
"projscan": {
"command": "npx",
"args": [
"-y",
"projscan"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add projscan -- npx -y projscanIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"projscan": {
"command": "npx",
"args": [
"-y",
"projscan"
]
}
}
}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": {
"projscan": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"projscan"
]
}
}
}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.
Diese 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 7. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto abhiyoheswaran1 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 (5.0.3) kam vor 4 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Node.js auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Systemdox
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.
Your architecture in your agents' context: checks, specs, ADRs and docs over MCP, at write time.
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.
Local proof for AI-assisted engineering. projscan gives agents and engineers the repo context, risk checks, proof commands, and review gates they need before editing, handing off, or preparing a release candidate.
Install · Daily workflows · MCP Setup · Commands · Trust · Full Guide
Use projscan when an agent asks one of these questions:
projscan runs core scans on your machine. It respects .gitignore, keeps .env values out of scans unless you opt in, and exposes the same evidence through a CLI and a 51-tool MCP server. The language layer uses 11 AST adapters covering 12 named languages.
Your agent / engineer
(Codex, Claude Code, Cursor, CI, your scripts) | intent, diff, repo files, feedback, proof requests v +----------------------------------------------------------------+
| projscan (runs locally, source stays on this machine) | |||
|---|---|---|---|
| Mission Control -> assess Cards -> simulate risk -> prove | |||
| | | +- allowed files | | | +- forbidden files | | | +- proof receipt | | | +- change passport | | | +- review gate | | | +- live guard | | +- bounded extraction | | | +- regression test first | | | +- leave unchanged | | +- evidence strength | | +- trust memory | | +- AgentLoopKit handoff | | | | CLI + MCP tools, no account, telemetry off by default | +----------------------------------------------------------------+ | next safe action, exact proof commands, handoff packet v Reviewer / CI / LLM provider (only the evidence you choose to pass along)
npm install -g projscan
projscan start
Run without a global install:
npx projscan start
Check the trust boundary first:
projscan privacy-check
projscan start --intent "what can projscan read?" projscan start --intent "does projscan read .env values?"
Use these four workflows before scanning the full command catalog.
projscan start --intent "what files do I need to change for auth?"
projscan start --intent "what should we build next?" # Routes to a before-edit implementation workplan projscan start --intent "is my agent allowed to change billing retry logic?" projscan understand --view change --intent "add auth token refresh" --format json projscan prove --intent "is my agent allowed to change billing retry logic?" projscan preflight --mode before_edit --format json
You get a cited change map, read-first files, likely touched files, blocked inputs, an executable Proof Contract, and a before-edit proof gate. Agent-permission intents route to projscan prove, so start can hand the next agent a contract path instead of a broad checklist.
Success criteria: the agent can name the files to read first, the likely files to touch, the forbidden files to avoid, and the proof commands to run before editing.
projscan start --intent "is my agent allowed to change billing retry logic?"
projscan prove --intent "is my agent allowed to change billing retry logic?" --save-contract .projscan/proof-contract.json
projscan prove --run -- npm test -- tests/billing/retry.test.ts projscan prove --changed --contract .projscan/proof-contract.json --format markdown projscan passport --contract .projscan/proof-contract.json --format markdown projscan proof-broker --contract .projscan/proof-contract.json --pr-comment projscan review-gate --contract .projscan/proof-contract.json --pr-comment
The command path is start -> prove -> run -> changed. Make the bounded edit after the contract exists and before prove --run. start chooses the contract workflow. prove --intent writes .projscan/proof-contract.json only when --save-contract is present. prove --run -- executes a local proof command, records the exit code, captures a redacted log, and fingerprints the current changed files. prove --record-command remains available for imported CI or external evidence when projscan did not run the command. prove --changed checks the current working tree against the contract and local ledger.
You get a Proof Contract before edits and a Proof Receipt after edits. The contract names allowed files, forbidden files, risky contracts, likely tests, missing regression-test evidence, proof commands, safe change shape, rollback, confidence, reviewer guidance, and proofRequirements for each risk surface. The receipt checks the real working tree against that contract and classifies changed files as allowed production, expected tests, documentation, generated proof artifacts, config/security drift, forbidden touches, or unexpected production. The receipt reports proof replay status, Proof Sufficiency, risk delta, commit readiness, and a reviewer checklist.
Sibling Baseframe harness directories (.agentloop/, .agentflight/) are classified as harness evidence, not scope drift: AgentLoopKit and AgentFlight write session state, task status transitions, and verification reports there as part of their sanctioned workflows, so those writes stay informational in the receipt and never trip forbiddenTouched, block commit readiness, or stop the review gate. Auto-generated contracts no longer list them in forbiddenFiles, receipts ignore those entries in contracts saved by older versions, and Team Proof Recipe forbiddenFiles entries are read the same way. To forbid production paths, keep using forbiddenFiles or Team Proof Recipes for non-harness locations.
Dependency-change intents keep their own scope executable: when prove --intent describes a dependency or tooling version change (for example "upgrade projscan to 5.0.1"), the generated contract places package.json and package-lock.json in allowedFiles instead of forbiddenFiles. Unrelated intents keep the manifests forbidden by default. Contract artifacts are restricted to .projscan/proof-contract.json or .projscan/proof-contracts/ .json inside the project root; --save-contract and --contract reject other paths.
Proof Replay records command, exit code, duration, changed-file fingerprint, redacted summary, log path, and source in .projscan/proof-ledger.jsonl. Executed proof logs stay under .projscan/proof-logs/. Ledger matching normalizes package-runner prefixes, so npx projscan assess --mode fix-first --format json, pnpm exec projscan ..., and node_modules/.bin/projscan ... all satisfy a required projscan assess --mode fix-first --format json. prove --changed marks proof as passed, missing, failed, partial, or stale. The receipt JSON includes proofReplay with a replay timeline, changedAfterProof, replay command, and local receipt fingerprint. If the agent edits new files after proof ran, the receipt says the proof is stale before a reviewer reads the diff.
Proof Sufficiency estimates whether the local ledger covers each changed surface. proofSufficiency marks rows as strong, adequate, weak, missing, stale, or failed, then lists the exact gaps reviewers need to resolve.
Team Proof Recipes let a repo encode required proof for sensitive paths in proofRecipes; when a matching recipe is configured, prove --intent adds that recipe's commands, reviewers, and forbidden files to the Proof Contract. prove --changed and projscan evidence-pack --pr-comment then show missing recipe proof, required reviewers, and recipe drift in the Proof Receipt. The recipe does not run proof commands by itself; use prove --run -- or prove --record-command to add evidence to the local ledger. Saved contracts are the source of truth for prove --changed; update the contract when a team recipe changes.
Every prove report includes verifiedWorkflow, a compact JSON summary for agents and MCP clients. It names the phase, next action, next command, scope status, proof status, proof sufficiency status, risk delta direction, reviewer decision, and stale/missing/failed proof flags.
projscan passport turns the contract and receipt into one handoff artifact. It names allowed files, forbidden files, changed files, proof replay status, Proof Sufficiency, reviewer action, and next commands. Save it when a reviewer or another agent needs the whole change story in one JSON file:
projscan passport \
--intent "is my agent allowed to change billing retry logic?" \ --save-contract .projscan/proof-contract.json \ --output .projscan/passport.json
Use projscan proof-broker to build a PR Passport from the same passport evidence. It names required proof rows, missing or stale proof commands, required reviewers from Team Proof Recipes, risky changed files, and the next commands a reviewer should ask for:
projscan proof-broker --intent "<change>" --bootstrap-contract
projscan proof-broker --contract .projscan/proof-contract.json --pr-comment
--bootstrap-contract writes a new Proof Contract only when explicitly requested. It does not execute proof commands and does not silently widen scope.
Use projscan review-gate to produce a review decision from the PR Passport. It reports ready, needs-proof, drifted, or blocked, says whether review can proceed, itemizes proof debt, names the recontract command when scope moved, and can fail CI until the proof debt is gone:
projscan review-gate --intent "<change>" --bootstrap-contract
projscan review-gate --contract .projscan/proof-contract.json --pr-comment projscan review-gate --contract .projscan/proof-contract.json --ci --fail-on-needs-proof
projscan guard checks the current working tree against a saved Proof Contract. Use it after an agent edits files, or run --watch during a session:
projscan guard --contract .projscan/proof-contract.json
projscan guard --contract .projscan/proof-contract.json --watch
<img src="docs/projscan-live-guard.png" alt="projscan Live Guard watch outpu
Nur der Anfang wird gezeigt; den Rest findest du im Repo