Agentic SDLC Control Plane (GitHub)

An engineering governance and safety control plane for AI coding agents to enforce strict SDLC discipline, quality gates, and security branch protections.

Governance and evidence controls for AI coding agents working in real GitHub repositories.

Let Claude Code, Cursor, and other Model Context Protocol (MCP) clients work with repository context, review gates, security evidence, and human approval points.

agentic-sdlc-mcpis a software development lifecycle (SDLC) governance layer for teams that already let AI coding agents change production repositories. It turns GitHub context, policy, checks, reviews, security alerts, and release signals into 13 workflow-level MCP tools. Twelve tools are read-only. The only GitHub write tool previews changes by default.

AI coding agents can create code and pull requests without understanding every repository rule. This server gives the agent bounded context and gives reviewers explicit evidence gaps instead of another free-form summary.

This server does not write code, merge pull requests, force-push, create releases, deploy software, or replace human security review.

How it fits into a production agent workflow

The MCP sits between an AI coding agent and GitHub evidence. Repository changes still happen through the agent's normal development environment, and high-impact decisions remain with your team.

flowchart LR Policy["Engineering policy<br>and repository rules"] --> MCP["agentic-sdlc-mcp"] Agent["AI coding agent<br>Claude Code · Cursor · MCP client"] --> MCP MCP --> GitHub["GitHub API evidence"] GitHub --> MCP MCP --> Reports["Briefs · plans · gates<br>reviews · release reports"] Reports --> Agent Reports --> Human["Human review and approval"] Agent -. "Code · commits · pull requests" .-> GitHub Human -. "Merge · release · deploy" .-> GitHub

Use the tools as decision support at the points where an autonomous agent would otherwise guess or rely on stale prose.

You need Node.js 22 or newer. Node 22 and 24 are tested in GitHub Actions. Run the published package directly from npm:

npm install -g agentic-sdlc-mcp agentic-sdlc-mcp

The default transport is stdio. Most MCP clients should start the package for you instead of running it in a separate terminal.

Paste this prompt into Codex, Claude Code, or another coding agent:

Use npm install -g agentic-sdlc-mcp to install and configure this MCP globally. Repository: https://github.com/SakuraCianna/agentic-sdlc-mcp Configure GITHUB_TOKEN and optional repository defaults through the MCP client's secret or environment configuration. On a trusted single-user machine, you may instead run agentic-sdlc-mcp configure or write them to ~/.agentic-sdlc-mcp.json. Never expose the token in chat, logs, or repository files; ask me for missing non-secret details. Then verify the connection with the read-only repo_context tool and summarize its capabilities, required GitHub permissions, and safety boundaries.

Review every command and configuration change before approving it. Node.js 22 or newer is required.

Add the server to Claude Desktop, Cursor, Windsurf, or another MCP client. Inject the GitHub token through the client's secret or environment configuration.

{ "mcpServers": { "agentic-sdlc": { "command": "npx", "args": ["-y", "agentic-sdlc-mcp"], "env": { "GITHUB_TOKEN": "your_github_token_here", "GITHUB_OWNER": "your_organization", "GITHUB_REPO": "your_repository" } } } }

Some Windows MCP clients requirenpxthroughcmd:

{ "command": "cmd", "args": ["/c", "npx", "-y", "agentic-sdlc-mcp"] }

GITHUB_OWNERandGITHUB_REPOare optional defaults. Tool calls can provide repository coordinates explicitly. Use theGitHub permission matrixto grant only the capabilities you enable.

Use agentic-sdlc-mcp to run repo_context for the configured repository. Include package scripts, workflows, governance, and repository policy. Do not create issues or modify GitHub.

Generate a feature plan and pass its issue drafts to create_issue_set with dryRun: true. Show the target repository, titles, labels, body summaries, and warnings. Do not write to GitHub.

See the[client-neutral smoke testfor a five-minute verification path.

The server registers 13 workflow-level tools. MCP clients receive the full input and output schemas at runtime; this catalog explains when to use each tool and how to interpret its result.

- repo_context: Defaults to a bounded README summary. Opt in to package scripts, workflow names, agent instructions, governance, validated.agentic-sdlc.yml, and recent open work. Item and character limits are explicit, and missing sources produce degraded context rather than invented facts.
- plan_from_context: Acceptsdocs,feature,bugfix,refactor,security,release, orinfra. If omitted, the tool returns its inferred work type, confidence, reasoning, andneedsClarification. Repository policy can add required checks and protected-path obligations, but an explicit caller work type wins.
- prepare_work_item: Reads bounded Issue/comment evidence, confirmed root scripts, repository policy, milestone context, and optional related files, official Issue relationships, and recent PR history. It separates Issue-authored criteria from derived requirements. Deep evidence paths expose request budgets and incomplete-source warnings. ItsriskProfileestimates implementation-planning controls; it is not proof of a vulnerability or leaked credential. Ambiguous LLM token-budget and non-credential "secret" wording require explicit credential context before entering the secrets domain.

- create_issue_set: Acceptsplan_from_context.issueDraftsdirectly.dryRundefaults totrueand does not call a GitHub write API. A live batch requiresdryRun: false, preserves successful Issue URLs, and returns safe per-item failures instead of hiding partial completion.

- create_pr_summary: Caps file evidence and reports truncation. Documentation-only changes receive document validation guidance instead of a false missing-code-tests warning.
- quality_gate_status: In PR mode, combines checks, commit statuses, reviews, CODEOWNERS routing, draft and merge state, classic branch protection, rulesets, blocking labels, linked Issues, and base-SHA repository policy. Permission failures remain visible as degraded or unverified evidence.
- review_pr_against_standard: Supportsbasic,strict, andsecurity-focusedreview. It trusts Gitleaks or TruffleHog as primary passing evidence only when the check, workflow, PR head SHA, base workflow job, scanner action, and immutable action SHA can be linked. Internal provenance binds each signal to its exact base workflow and static configuration dependencies without changing the public MCP output schema. Unrelated workflow changes do not invalidate the signal; changes to its workflow (including a previous rename path), Gitleaks root/default orGITLEAKS_CONFIGpath, or TruffleHogextra_args --configpath invalidate only affected scanners. Dynamic, ambiguous, absolute, traversing, or otherwise unbounded configuration remains fail-closed. Its dynamic secret construction scanner is bounded, patch-local analysis, not whole-program data flow or proof that a repository is secret-free. Operators and quantifiers that occur only inside credential-detection regex literals are not treated as runtime credential construction; dynamically assembled patterns and rules remain in scope regardless of their names.

…