Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@doctrine Guide me through the code review skill for my pull request"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Software engineering discipline grounded in named primary standards (OWASP, ITIL, IETF RFCs, ISO, BABOK, SBAR, and more) instead of invented convention. 33 skills covering the software development lifecycle: TDD, code review, incident response, domain modeling, deployment, dependency management, and more.
Three ways to use it, depending on your tool:
Native install for Claude Code: the right skill is auto-invoked from its description, no manual copying.
/plugin marketplace add aethrox/doctrine
/plugin install doctrineToggle it off later from enabledPlugins in ~/.claude/settings.json, same as any other plugin.
Related MCP server: mcp-ai-agent-guidelines
Requires Node.js >= 18.
Every skill is exposed as an MCP prompt: the same content, reachable from any MCP-capable client, not just Claude Code. Add it as a local MCP server:
{
"mcpServers": {
"doctrine": {
"command": "npx",
"args": ["-y", "github:aethrox/doctrine"]
}
}
}(Exact config location and format differ per client; Claude Desktop's claude_desktop_config.json, Cursor's .cursor/mcp.json, etc., but the command/args above are the same everywhere.)
Run it directly to confirm it works:
npx github:aethrox/doctrinegit clone https://github.com/aethrox/doctrine.git
for s in doctrine/skills/*/; do
name=$(basename "$s")
cp -r "$s" ~/.claude/skills/"$name"/
doneRe-run after pulling updates to resync.
Every skill follows the same shape: a one-sentence defining constraint (the fact that makes it behave differently from the obvious default), a numbered set of phases with concrete, checkable rules, and a closing checklist. The skills combine named external standards and established practices with clearly labeled Doctrine policy defaults.
See WORKFLOW.md for how the 33 skills relate to each other: the lifecycle they map to, which ones cross-reference which, and a worked example.
Skill | Standard(s) it encodes | Covers |
Conventional Commits, Semantic Versioning, Keep a Changelog, trunk-based development | Commit classification, version bump, changelog entry, branching model | |
OWASP Top 10, SCA and secret-scanning practice | Injection classes, access control, secrets, dependency and supply-chain risk, safe error handling | |
Google SRE golden signals, SLI/SLO/error budget, the RED method | Structured logging, the four golden signals, SLO definition, alert and runbook discipline | |
Progressive delivery, canary/blue-green/rolling, expand-contract migrations | Decoupling deploy from release, rollout strategy choice, rollback triggers defined up front | |
Microsoft/Google REST guidelines, consumer-driven contract testing | Resource/URL conventions, versioning strategy, backward-compatible vs breaking changes, contract testing | |
SBOM (CycloneDX/SPDX), RFC 8594/9745 deprecation headers, Dependabot/Renovate cadence practice | Dependency inventory, security vs routine vs major-upgrade lanes, deprecation windows, safe major-version migration | |
Google SRE incident management guide, blameless postmortem culture | Severity/declaration, IC/comms/ops roles, mitigate-before-root-cause, blameless postmortem structure | |
Test data management practice, flaky-test quarantine practice | Synthetic vs anonymized production test data, flaky-test quarantine policy, integration/e2e boundary decisions | |
Established per-language formatters (gofmt, rustfmt, black, prettier), pre-commit/CI enforcement practice | Adopting the ecosystem standard, opinionated over configurable, pre-commit + CI enforcement layers, linting vs formatting | |
Kent Beck's red-green-refactor, the testing pyramid, Fowler's test-double taxonomy, FIRST properties | The TDD cycle, what makes a test worth keeping, choosing the right test double, shaping a suite | |
Google's Engineering Practices code review guide, Fowler's code-smell catalog | Improve-over-perfect approval bar, naming smells instead of vague complaints, small-PR discipline, review etiquette | |
David Agans' Debugging: The 9 Indispensable Rules | Reproduce reliably, bisect the search space, change one variable at a time, audit trail, verify the fix against the original failure | |
Eric Evans' Domain-Driven Design, Michael Nygard's ADR format | Ubiquitous language, bounded contexts and translation at boundaries, one-page ADRs, keeping the model current | |
John Ousterhout's A Philosophy of Software Design | Depth as the design metric, information hiding vs. leakage, concrete shallow-module red flags, designing it twice | |
Git's three-way merge model | Resolving hunks by tracing both sides' intent, avoiding whole-file --ours/--theirs, verifying before finishing, merge vs. rebase | |
INVEST criteria, tracer-bullet development, Definition of Ready/Done | Synthesizing a spec, slicing tracer-bullet tickets with blocking edges, INVEST checks, Ready/Done gates, handoff to tdd/code-review | |
Kent Beck/Ward Cunningham's spike solution (Extreme Programming) | Naming the one question a spike answers, timeboxing it, building disposable code, recording the verdict and discarding the code | |
Primary-source citation practice, the CRAAP source-evaluation test | Scoping a checkable question, tracing claims to primary sources, weighing source credibility, citing findings in a saved file | |
ITIL incident priority matrix (Impact x Urgency) | Classifying bug vs. enhancement, scoring impact and urgency independently, verifying before prioritizing, routing to needs-info/ready-to-spec/scheduled/wontfix | |
Fowler's Technical Debt Quadrant, layered on | Scoping a scan, finding shallow-module red flags, classifying findings by how debt was incurred, prioritizing by leave-cost, recording declined findings as ADRs | |
The RFC process (IETF/Rust-style engineering decision records) | Naming the destination, charting open decisions breadth-first, resolving one at a time with recorded reasoning, tracking decided/open/unspecified/out-of-scope, handoff to spec-to-tickets | |
BABOK elicitation techniques (structured interviews, confirm elicitation results) | Mapping the known/needed gap before asking, frontier-round questioning, resolving facts by lookup not by asking, confirming answers before treating them as settled | |
SBAR (Situation-Background-Assessment-Recommendation) handoff communication standard | Structuring a handoff into Situation/Background/Assessment/Recommendation, naming what's already ruled out, confirming receipt via read-back | |
Bloom's Taxonomy, the worked-example effect and fading (cognitive load theory) | Placing the target and learner's cognitive level, opening with a fully worked example, fading scaffolding in stages, matching method to level, checking retention over fluency | |
Survey-design practice: leading/loaded question avoidance, closed vs. open question choice, balanced Likert-scale construction | Scoping the send (recipient, gap), choosing closed vs. open per question, avoiding leading/loaded/compound questions, balancing rating scales, assembling the document | |
ISO 24495-1:2023 Plain Language standard (Relevant/Findable/Understandable/Actionable) | Recognizing a missed-explanation signal, re-pitching instead of repeating, applying all four RFUA principles, keeping vocabulary consistent, confirming it landed | |
The Diátaxis documentation framework, adapted to agent-consumed documents | Classifying content as how-to/reference/explanation/tutorial, writing the how-to as the spine, structuring reference for lookup, relocating explanation to human-read artifacts, skipping tutorial voice | |
Standard operating procedure (SOP) / runbook documentation practice | Scoping to human-authority-only steps, one verifiable action per step, persisting captured values immediately, confirming before advancing, resumability after interruption | |
GitHub's maintainer security best-practices guidance | Inventorying current settings, judging which layers apply to this repo, confirming every setting before enabling it, with branch protection receiving the most scrutiny, recording deliberate skips | |
The C4 model (Simon Brown) | Picking the right zoom level for the audience, consistent box and arrow notation, choosing to show, save, or commit a diagram as code based on what is authorized, updating on structural change | |
ISO 24495-1:2023 Plain Language standard, applied as a default posture | No unexplained jargon by default, framing from the reader's stake, maintaining a running glossary, verifying the explanation is actionable | |
Conventional Commits, applied at authoring time, plus repo-creation-as-first-class-step practice | Splitting commits by intent, naming a new repo for what it is, deciding visibility deliberately, filling description and topics at creation | |
ISO/IEC/IEEE 29148:2018 requirements quality characteristics | Scanning a draft for ambiguity, inconsistency, incompleteness, and unverifiable claims, batching only the blocking gaps, writing decisions into the document and the repository's existing decision record together |
mcp-server.js is a plain Node.js (ESM, no build step) script: at startup it reads every skills/<name>/SKILL.md, parses the name/description out of the frontmatter, and registers each one as an MCP prompt whose content is the full skill text. Run npm test to smoke-test it. The test validates every skill's frontmatter as real YAML, spawns the server and performs a real MCP handshake, asserts an exact prompts/list name match against the discovered skill set, and diffs each prompts/get response against its corresponding SKILL.md file byte-for-byte.
None of the 33 skills have been battle-tested against a real release, incident, or security review yet; they're authored from standards but not yet validated in use. The MCP server has a smoke test (npm test) but hasn't been exercised against a real third-party MCP client (Cursor, Windsurf, etc.) yet, only a scripted handshake. This repo has no SECURITY.md or vulnerability reporting channel yet.
Chain | Address |
Ethereum |
|
Solana |
|
Bitcoin |
|
Adding a new skill or fixing an existing one? See CONTRIBUTING.md.
MIT, see LICENSE.
This server cannot be installed
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for skill documentation, generated by doc2mcp.
MCP server exposing Kettle Logic insight articles & industry guidance as tools + resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aethrox/doctrine'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
