Skip to main content
Glama
AKzar1el

GodPrompt MCP Server

GodPrompt MCP Server

A Model Context Protocol (MCP) server for GodPrompt — AI software-development workflow guidance with task routing, TDD, debugging protocols, verification gates, and progressive disclosure.

MCPVault: verified

Agent Harness Review — US$49

GodPrompt offers a bounded Agent Harness Review for developers and small teams whose coding agents lose context, overstep scope, skip verification, or repeat mistakes.

GodPrompt Agent Harness Review — US$49 one-time. For one repository, send up to three agent-control artifacts (AGENTS.md, CLAUDE.md, project rules, or equivalent) plus one short failure example. The review returns five priority risks, one proposed revised instruction block or patch, and a next-task verification checklist, with a target of 24 hours after payment and usable inputs.

To buy the review, use the US$49 one-time GitHub Sponsors tier. GitHub sign-in is required. After sponsoring, email info@tomiseregi.si with subject [GP-RS1] Agent Harness Review and include the GitHub username used for the sponsorship plus the review inputs. Delivery begins after the US$49 sponsorship is independently verified for this review. The free MIT GodPrompt MCP remains unchanged and free. See a transparent sample deliverable before deciding; it is illustrative, not a client result or benchmark. Full frozen experiment terms.

Related MCP server: prompts-mcp-server

Tools

Tool

Description

get_god_prompt

Full GodPrompt.md single-file payload (~40KB)

get_core_skill

SKILL.md — core protocol (load when relevant, ~10KB)

get_protocols

references/01-PROTOCOLS.md — deep execution guides (~13KB)

get_gates

references/02-GATES.md — verification checklists (~9KB)

get_anti_patterns

references/03-ANTI-PATTERNS.md — red flags & recovery (~9KB)

classify_task

Deterministically route a task to one of 9 GodPrompt task types, or UNCLASSIFIED when no reliable signal exists

get_version

Version info and server metadata

Progressive Disclosure

For minimum context usage, start with get_core_skill, then load get_protocols, get_gates, or get_anti_patterns only when the task requires deeper guidance. Use get_god_prompt when you want everything in one shot.

Example queries

  • "Classify this refactor and tell me which GodPrompt workflow applies."

  • "Show me the verification gates I should satisfy before I claim this bug fix is complete."

  • "Load the debugging protocol for a failing integration test without loading the full GodPrompt."

Evaluation

GodPrompt's benchmark methodology, deterministic task corpus, evaluator logic, and reproducible run/export tooling live in the source project: GodPrompt Bench. No frozen reference-model run or raw benchmark artifacts have been published yet.

The MCP server does not run the benchmark or claim model-level superiority itself; it distributes the GodPrompt content evaluated by that suite.

Connect

Hosted remote (no Node.js required)

Use the public Streamable HTTP endpoint directly in MCP clients that support remote servers:

https://god-prompt-mcp.tomi-seregi99.workers.dev/mcp

The hosted endpoint exposes the same seven read-only GodPrompt tools as the local server and requires no API key or local Node.js runtime. It accepts both the deployed initialize flow and the current MCP 2026-07-28 server/discover flow so clients can connect while the ecosystem transitions between protocol eras. It is also published as a remote option in the Official MCP Registry alongside the installable stdio packages.

Agent Skills over MCP (SEP-2640)

On MCP 2026-07-28, both the hosted and stdio servers advertise the Final io.modelcontextprotocol/skills extension from SEP-2640. Supporting clients can discover the same relevance-scoped god-prompt Agent Skill with skills/list / skills/get, then fetch SKILL.md and its three reference files through resources/read. The skill manifest includes SHA-256 digests and exact byte sizes so clients can verify what they import. Clients that do not implement this extension continue to use the seven existing GodPrompt tools normally.

This transports GodPrompt's existing skill package; it does not force the skill into every request or change the host's own approval, verification, or activation policy. See the MCP Skills extension specification.

ChatGPT Plugin Directory (skill-only)

For the lowest-friction ChatGPT path, install GodPrompt from the first-party Plugin Directory. That published plugin carries the scoped god-prompt Agent Skill; use the custom MCP app setup below when you specifically want the seven callable GodPrompt tools.

ChatGPT (hosted remote MCP)

On ChatGPT web, supported Business and Enterprise/Edu workspaces can connect the hosted endpoint as a custom MCP app in Developer Mode:

  1. Enable Developer Mode, then open Settings > Apps > Create (workspace controls may require an admin or authorized developer).

  2. Use https://god-prompt-mcp.tomi-seregi99.workers.dev/mcp as the MCP endpoint and select no authentication.

  3. Choose Scan Tools, confirm the seven read-only GodPrompt tools, then create and enable the app for the intended workspace users.

ChatGPT connects to remote MCP servers rather than local stdio servers. See OpenAI's Developer mode and MCP apps in ChatGPT documentation for current availability and workspace controls.

npx -y god-prompt-mcp

The public npm package runs the local stdio server directly. It requires Node.js 22+ and no API key or account.

Glama

GodPrompt MCP is published on Glama. Use the server page to inspect the tools and connect it to a supported MCP client.

Kiro

Install this repository as a native Kiro Power to get the portable GodPrompt Agent Skill and MCP server together. In Kiro, open Powers → Add Custom Power → Import power from GitHub, enter:

https://github.com/AKzar1el/god-prompt-mcp

Kiro reads the repository's Agent Plugins 1.0 plugin.json, skills/, and mcp.json; the bundled MCP server activates with the Power instead of requiring a separate user-level MCP entry.

If you only want the MCP server, use the direct install button:

Add to Kiro

Both paths ultimately launch the published npm package through npx. Node.js 22+ is required for the MCP server.

Visual Studio Code

VS Code supports Agent Plugins 1.0 packages directly, so the lowest-friction path installs GodPrompt's portable Agent Skill and bundled MCP server together:

  1. Run Chat: Install Plugin From Source from the Command Palette.

  2. Enter https://github.com/AKzar1el/god-prompt-mcp.

  3. Review the repository source before confirming the install. VS Code discovers the root plugin.json, skills/god-prompt, and mcp.json from the same package.

If you only want the Agent Skill, install it at user scope so VS Code discovers it from ~/.copilot/skills:

gh skill install AKzar1el/god-prompt-mcp skills/god-prompt --agent github-copilot --scope user

If you only want the seven callable MCP tools, use the native MCP install button:

Install in VS Code

The plugin and MCP-only paths both launch the published local stdio server through npx. Node.js 22+ is required; no API key is needed.

Amazon Q Developer

Amazon Q Developer supports both local process MCP servers and remote HTTP MCP servers. For the no-Node path, add GodPrompt to the mcpServers object in the Q CLI or Q Developer IDE agent configuration:

{
  "mcpServers": {
    "god-prompt": {
      "type": "http",
      "url": "https://god-prompt-mcp.tomi-seregi99.workers.dev/mcp"
    }
  }
}

The hosted endpoint is open and requires no API key. If you prefer local stdio, use the same Amazon Q MCP configuration shape with "command": "npx" and "args": ["-y", "god-prompt-mcp"]; that path requires Node.js 22+. See Amazon Q Developer's MCP guide and agent configuration format for the current CLI/IDE configuration locations and scope rules.

OpenAI Codex

GodPrompt can be used in Codex as either a portable Agent Skill or a native local MCP server.

Install the standards-compatible Agent Skill directly from this repository with Codex's built-in $skill-installer:

$skill-installer install https://github.com/AKzar1el/god-prompt-mcp/tree/main/skills/god-prompt

Or register the published stdio server with Codex's native MCP CLI:

codex mcp add god-prompt -- npx -y god-prompt-mcp

Run codex mcp list to verify the registration. The Agent Skill gives Codex the reusable workflow directly; MCP adds GodPrompt's progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Gemini CLI

Install the repository as a native Gemini CLI extension to get both the portable GodPrompt Agent Skill and the MCP server in one step:

gemini extensions install https://github.com/AKzar1el/god-prompt-mcp

Or register only the published local stdio server with Gemini CLI's native MCP command:

gemini mcp add --scope user god-prompt npx -- -y god-prompt-mcp

The explicit user scope keeps this direct registration out of the project's .gemini/settings.json. Run gemini extensions list to verify the extension or gemini mcp list to verify the direct MCP registration. Node.js 22+ is required for the MCP server; GodPrompt itself needs no API key.

Google Antigravity CLI

Antigravity CLI supports Agent Plugins that bundle Agent Skills and MCP servers. Install the existing GodPrompt plugin directly from GitHub:

agy plugin install https://github.com/AKzar1el/god-prompt-mcp

Run agy plugin list to verify the installation. The repository's Agent Plugins 1.0 package supplies both skills/god-prompt and the pinned local stdio MCP server, so no separate skill or MCP registration is needed. Node.js 22+ is required for the MCP server.

GitHub CLI Agent Skills (preview)

GitHub CLI 2.100+ can install the same portable Agent Skill directly into supported coding agents without cloning the repository:

gh skill install AKzar1el/god-prompt-mcp skills/god-prompt --agent codex --scope user

Replace codex with another supported host such as github-copilot, claude-code, or cursor. The explicit skills/god-prompt path intentionally selects the portable skill rather than another distribution-specific package in this repository.

Vercel Skills CLI

The open skills CLI can install the same portable Agent Skill into Codex, Claude Code, Cursor, and many other supported coding agents:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent codex --copy -y

Replace codex with another supported agent when needed. The current CLI discovers the repository's portable god-prompt skill directly and installs SKILL.md plus its referenced protocol files; the MCP server remains separately available through npx -y god-prompt-mcp.

AllAgents

For a project that uses several coding agents, AllAgents can consume this repository once and synchronize GodPrompt to the selected clients. This verified example installs the portable skill for Claude Code, Codex, and Cursor while reusing the repository's bundled MCP configuration:

npx -y allagents@latest skill add AKzar1el/god-prompt-mcp --skill god-prompt --scope project --client claude,codex,cursor --yes

AllAgents resolves the repository as the source of truth, copies the god-prompt skill into each selected client, and materializes the existing local MCP server configuration with the package version already pinned by this repository. Use a different supported client set when your workspace requires it; no separate GodPrompt wrapper or package is needed.

Cline

Cline SDK / Hub 0.0.83+ can load GodPrompt's existing Agent Plugins 1.0 package directly. Cline discovers user-installed plugin packages under ~/.agents/plugins/*, validates the root plugin.json, exposes valid skills/ entries, and starts valid servers from the root mcp.json without writing them into cline_mcp_settings.json.

Install the repository into Cline's user plugin directory:

mkdir -p ~/.agents/plugins
git clone --depth 1 https://github.com/AKzar1el/god-prompt-mcp ~/.agents/plugins/god-prompt-mcp

On the next settings refresh or session build, Cline can expose the god-prompt Agent Skill and launch the bundled local stdio server, whose root mcp.json pins the published GodPrompt MCP package version. Cline intentionally does not auto-scan workspace .agents/plugins directories, so merely opening a repository cannot activate repository-controlled MCP servers; SDK hosts that deliberately trust another package root can opt in through agentPluginPaths.

Amp

Amp can load GodPrompt as an Agent Skill and expose the MCP tools only when that skill is relevant. Install the portable skill with:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent amp --copy -y

The skill includes Amp's sibling mcp.json configuration, pinned to the current GodPrompt MCP package. Amp keeps those seven MCP tool definitions hidden until the skill loads, avoiding a permanently expanded tool context while preserving the full progressive-disclosure surface. Node.js 22+ is required for the MCP server.

Factory Droid

Factory Droid can use GodPrompt as both an Agent Skill and a local MCP server. Install the complete portable skill with the current Skills CLI target for Droid:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent droid --copy -y

Droid discovers compatible project skills under .agents/skills/. To add the callable GodPrompt tools as a local stdio MCP server, use Droid's native MCP command with the published version pinned:

droid mcp add god-prompt "npx -y god-prompt-mcp@1.0.33"

Open /mcp in Droid to verify the server and available tools. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Warp

Warp can use GodPrompt as both an Agent Skill and a local MCP server. Install the complete portable skill into Warp with:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent warp --copy -y

Warp discovers project skills from .agents/skills/ and .warp/skills/. For MCP tools, add a CLI-based MCP server in Warp with command npx and arguments -y, god-prompt-mcp; Warp's Oz CLI can also receive MCP configuration through oz agent run --mcp. The skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Goose

Goose can use GodPrompt as both an Agent Skill and a local MCP extension. Install the complete portable skill into Goose with:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent goose --copy -y

Goose discovers the copied skill under .goose/skills/god-prompt/. To expose GodPrompt's callable tools for a session, start Goose with the published MCP package as an external stdio extension:

goose session --with-extension "npx -y god-prompt-mcp@1.0.33"

Goose currently treats Agent Skills and MCP extensions as separate native surfaces, so this path does not depend on Agent Plugins support. The skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Zed

Zed can use GodPrompt as both a native Agent Skill and a local MCP context server. Install the complete portable skill, including its referenced protocol files, with:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent zed --copy -y

For MCP tools, open Settings → AI → MCP Servers → Add Server → Add Local Server, set the command to npx, and pass -y and god-prompt-mcp as arguments. Zed loads project skills from .agents/skills/ and can forward configured MCP servers to supported external agents. Node.js 22+ is required for the MCP server.

OpenCode

OpenCode v2 natively discovers Agent Skills from .agents/skills/ and supports local MCP servers. Install the same portable GodPrompt skill with:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent opencode --copy -y

To expose GodPrompt's MCP tools as well, register the published local server with OpenCode's native v2 command, then verify the connection:

opencode mcp add god-prompt -- npx -y god-prompt-mcp
opencode mcp list

The add command writes the project MCP configuration for you. If you prefer to configure it by hand, use opencode.json or opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "god-prompt": {
        "type": "local",
        "command": ["npx", "-y", "god-prompt-mcp"]
      }
    }
  }
}

OpenCode 1.x used the same server entry directly under mcp; the v2 schema shown above nests named servers under mcp.servers.

The Agent Skill provides the reusable workflow; MCP adds the seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

TraeCode

TraeCode can use GodPrompt as both a native project skill and a project-level local MCP server. Install the complete portable skill with the current Skills CLI target for Trae:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent trae --copy -y

The Trae target installs the skill under .trae/skills/god-prompt/, where TraeCode can load it when the task matches its description. To expose GodPrompt's callable tools for the project as well, add .trae/mcp.json:

{
  "mcpServers": {
    "god-prompt": {
      "command": "npx",
      "args": ["-y", "god-prompt-mcp@1.0.33"]
    }
  }
}

TraeCode also supports the portable .agents/skills/ convention when Enable .agents Skills Directory is turned on in its import settings. Treat project MCP configuration as executable workspace configuration and enable it only in repositories you trust. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

OpenClaw

OpenClaw can use GodPrompt as both a project Agent Skill and a locally registered MCP server. Install the complete portable skill with the current Skills CLI target for OpenClaw:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent openclaw --copy -y

The copied skill lands under .agents/skills/god-prompt/, one of OpenClaw's documented project skill roots. To expose GodPrompt's callable tools to OpenClaw-managed agent runtimes as well, register the published stdio server:

openclaw mcp add god-prompt --command npx --arg -y --arg god-prompt-mcp@1.0.33
openclaw mcp probe god-prompt

mcp probe opens a live MCP connection and reports the discovered capabilities, making it a direct verification step after registration. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Qoder

Qoder can use GodPrompt as both a native project Skill and a project-level local MCP server. Install the portable skill with Qoder's supported Skills CLI target:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent qoder --copy -y

The Qoder target installs the skill under .qoder/skills/god-prompt/, where Qoder can load it automatically when the task matches the skill description. To expose GodPrompt's callable tools to the project as well, add .mcp.json at the project root:

{
  "mcpServers": {
    "god-prompt": {
      "command": "npx",
      "args": ["-y", "god-prompt-mcp@1.0.33"]
    }
  }
}

Qoder requires approval before using project-level MCP servers by default. After adding or changing the server, start a new session or run /mcp reload, then use /mcp to verify the connection. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Qwen Code

Qwen Code can use GodPrompt through both of its native extension surfaces: Agent Skills and local MCP servers. Install the complete portable skill with the current Skills CLI target for Qwen Code:

npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent qwen-code --copy -y

This installs GodPrompt under .qwen/skills/god-prompt/, where Qwen Code can discover and load the skill when the task matches its description. To add the callable GodPrompt tools as a project-local stdio MCP server, add this to .qwen/settings.json:

{
  "mcpServers": {
    "god-prompt": {
      "command": "npx",
      "args": ["-y", "god-prompt-mcp"]
    }
  }
}

Restart Qwen Code after changing MCP configuration, then open /mcp to verify the server. The Agent Skill provides the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Kimi Code

Kimi Code CLI can install GodPrompt as one native custom plugin containing the existing Agent Skill and local MCP server. Install the current repository branch explicitly:

/plugins install https://github.com/AKzar1el/god-prompt-mcp/tree/main
/reload

The Kimi manifest points at skills/, so the god-prompt skill remains available through Kimi's normal relevance-based skill loading instead of being forced into every session. The same manifest exposes god-prompt-mcp@1.0.33 as a local stdio MCP server, preserving the seven progressive-disclosure tools. The explicit tree/main URL matters because Kimi's bare GitHub-repository install form prefers the latest GitHub release; using main makes the current plugin manifest available without forcing a documentation-only npm/MCP Registry release. Node.js 22+ is required for the MCP server.

JetBrains AI Assistant

JetBrains AI Assistant 2026.2 can use GodPrompt through both supported agent surfaces:

  • Agent Skill: in Settings → Tools → AI Assistant → Skills, open Manage External Registries and add https://github.com/AKzar1el/god-prompt-mcp. The existing skills/god-prompt package can then be installed for supported skill-aware agents such as Codex or Claude Agent.

  • MCP tools: in Settings → Tools → AI Assistant → Model Context Protocol (MCP), add a stdio server with command npx and arguments -y, god-prompt-mcp. Enable Pass custom MCP servers for the coding agent that should receive GodPrompt's progressive-disclosure tools.

The Agent Skill supplies the reusable workflow; the MCP server supplies GodPrompt's callable tools. Node.js 22+ is required for the MCP server.

JetBrains Junie CLI

Junie CLI can install GodPrompt as one extension by reusing this repository's existing Claude-compatible marketplace manifest. In Junie, register the repository and install the listed extension:

/extensions marketplace add AKzar1el/god-prompt-mcp
/extensions install god-prompt-mcp

Junie supports .claude-plugin/marketplace.json as a marketplace format, so no Junie-specific duplicate manifest is required. The installed extension reuses GodPrompt's existing portable Agent Skill and MCP configuration; Junie can also discover the same skill from .agents/skills/ and supports local npx MCP servers. Node.js 22+ is required for the MCP server. Junie CLI is not installed in this repository's qualification environment, so these commands are documented from JetBrains' current extension contract rather than claimed as a local end-to-end runtime smoke.

Devin Desktop / Windsurf

Devin Desktop (formerly Windsurf) and Devin CLI can load GodPrompt's existing Agent Plugins 1.0 package directly from GitHub. After signing in to Devin, install the plugin with:

devin plugins install AKzar1el/god-prompt-mcp

The plugin supplies both skills/god-prompt and the published local stdio MCP server. Run devin plugins list to verify the installation.

If you only want the portable skill, place the complete skill directory at .agents/skills/god-prompt/; Devin also discovers project skills under .devin/skills/ and .windsurf/skills/. If you only want the MCP server, register it directly:

devin mcp add god-prompt -- npx -y god-prompt-mcp

Run devin mcp list to verify the direct server registration. The Agent Skill provides the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.

Cursor

The repository includes a native Cursor plugin manifest plus a portable Agent Plugins 1.0 manifest. Cursor Marketplace can use .cursor-plugin/plugin.json with cursor-mcp.json; Agent Plugins-compatible clients can use root plugin.json with mcp.json. Both launch the same local stdio server through npx -y god-prompt-mcp.

GitHub Copilot

GitHub Copilot CLI supports the portable Agent Plugins 1.0 package at the repository root. Install it through the repository marketplace:

copilot plugin marketplace add AKzar1el/god-prompt-mcp
copilot plugin install god-prompt-mcp@god-prompt

The plugin includes both the GodPrompt MCP server and a standards-compatible god-prompt Agent Skill under skills/god-prompt/. Copilot can load the skill automatically when relevant or invoke it explicitly as /god-prompt, while MCP remains available for progressive-disclosure tool access.

This keeps the marketplace entry, portable plugin, skill, and MCP server in one versioned repository and works for individual, team, and cloud-agent distribution. Direct repository installs (copilot plugin install AKzar1el/god-prompt-mcp) still work in current Copilot CLI releases, but the CLI marks them deprecated in favor of plugin@marketplace installs.

GitLab Duo CLI

GitLab Duo CLI 9.15+ supports Agent Plugins and Git-backed plugin marketplaces. Register this repository once, then install the same portable plugin:

duo plugin marketplace add https://github.com/AKzar1el/god-prompt-mcp.git
duo plugin install god-prompt-mcp@god-prompt

The installed plugin bundles the existing god-prompt Agent Skill and pinned local MCP server, so GitLab Duo users get both workflow guidance and callable tools from the same versioned repository.

Claude Code

The repository includes a Claude Code marketplace catalog alongside the existing plugin and MCP manifests, so users can install the same versioned plugin directly from this GitHub repository without waiting for community-directory review. In Claude Code, run:

/plugin marketplace add AKzar1el/god-prompt-mcp
/plugin install god-prompt-mcp@god-prompt

The plugin bundles the portable god-prompt Agent Skill and the pinned local MCP server. The same package remains structurally ready for Anthropic's reviewed community directory without maintaining a separate implementation.

Claude Desktop extension

GitHub releases include a .mcpb bundle for one-click local installation in MCPB-compatible clients such as Claude Desktop. The bundle runs the same local stdio server and does not require an API key or account.

Current GitHub releases are immutable and include a release attestation. With GitHub CLI installed, verify the release and your downloaded MCPB before installing it:

gh release verify <release-tag> --repo AKzar1el/god-prompt-mcp
gh release verify-asset <release-tag> <downloaded-mcpb> --repo AKzar1el/god-prompt-mcp

The asset check verifies that the local MCPB exactly matches the file recorded in the published release attestation.

Local stdio

npm install
npm run build
node dist/stdio.js

Example client configuration:

{
  "mcpServers": {
    "god-prompt": {
      "command": "node",
      "args": ["/absolute/path/to/god-prompt-mcp/dist/stdio.js"]
    }
  }
}

Privacy Policy

GodPrompt MCP can run either as a local stdio server or through the public Streamable HTTP Worker. Its content tools return static GodPrompt material bundled with the server, and classify_task is deterministic; neither mode calls a model or third-party content API.

  • Data collection and use: GodPrompt application code has no telemetry or analytics and does not request account data. Local stdio tool input stays in the local Node.js process. Hosted remote tool input is sent over HTTPS to the Cloudflare-hosted Worker so it can produce the MCP response.

  • Storage and retention: the MCP request handlers are stateless and have no application database or request-retention path; they do not intentionally persist tool inputs after a request completes. Hosting/provider infrastructure may process connection or request metadata under its own policies.

  • Third-party sharing: local stdio does not transmit tool inputs or bundled GodPrompt content to an external API. The hosted remote necessarily passes the request through Cloudflare infrastructure, but GodPrompt application code does not forward tool inputs to another API or service. The MCP host or AI client may process conversation and tool data under its own policies independently of this server.

  • Contact and policy: see tomiseregi.si/privacy for the current privacy policy and contact information. For support or bug reports, use GitHub Issues.

Development

npm install
npm run build
npm test

npm test builds the stdio server, performs the MCP initialization handshake, and verifies the expected tool list.

Repository discovery metadata is kept in server.json for MCP Registry-compatible consumers and glama.json for Glama.

Updating Content

To update the embedded GodPrompt content:

  1. Pull the latest content from the GodPrompt repository.

  2. Run npm run generate-content.

  3. Run npm test before publishing a new server release.

The generator reads the current source layout: GodPrompt.md, SKILL.md, and the three files under references/.

License

MIT

Project page: GodPrompt — AI software-development system prompt · GodPrompt source

Related MCP servers: Google Search Console · GEO Tracker · Web Validator · Google News & Trends

Available Tools

7 tools
classify_taskClassify software-development taskA
Read-onlyIdempotent
Inspect

Classify one concrete software-development task into one of GodPrompt's 9 task types (BUILD, DEBUG, REFACTOR, CONTENT, DESIGN, SHIP, ANALYZE, AUTOMATE, PLAN), or UNCLASSIFIED when no reliable route is detected. Returns JSON with task_type, deterministic confidence, protocol, matched_signals, alternative_task_types, ambiguous, and recommendation; use it for routing before loading detailed workflow text.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionYesThe task description to classify, e.g. 'fix the login bug' or 'build a REST API for user auth'

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly, idempotent, and non-destructive hints, so the description's job is to add context. It does so by listing the exact return JSON fields (task_type, deterministic confidence, protocol, matched_signals, alternative_task_types, ambiguous, recommendation), noting that confidence is deterministic, and describing the UNCLASSIFIED fallback when no reliable route is detected. This adds meaningful behavioral transparency beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero redundancy. The verb and resource are front-loaded, the output contract is complete, and the usage guidance is placed at the end as a natural conclusion. Every sentence earns its place; nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter classifier with no output schema, the description is fully complete. It enumerates the classification types, the fallback, and all return fields, and it tells the agent exactly when to invoke it (routing before loading workflow text). An agent has everything needed to call this tool correctly without further research.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a clear description and examples, so the baseline is 3. The description adds a subtle but useful nuance by specifying that the input should be 'one concrete' task, which rules out abstract or multi-part descriptions. This is more than pure repetition of the schema and helps the agent choose appropriate input formatting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool classifies a software-development task into one of nine enumerated types (BUILD, DEBUG, etc.) or UNCLASSIFIED. The specific verb 'classify' plus the named resource and the explicit output categories distinguish it from sibling getter tools like get_anti_patterns and get_god_prompt, which retrieve data rather than classify. This is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage context: 'use it for routing before loading detailed workflow text.' This tells the agent when to call this tool in a workflow. It does not explicitly name alternatives or state when not to use it, but the sibling tools are all getters with distinct purposes, so there is no real overlapping scenario. The guidance is clear but lacks an explicit 'when-not' clause.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_anti_patternsGet GodPrompt anti-patternsA
Read-onlyIdempotent
Inspect

Returns references/03-ANTI-PATTERNS.md — red flags, rationalizations, and recovery patterns. Covers the 10 most dangerous anti-patterns that lead to broken code, scope creep, and false confidence. Load when you catch yourself rationalizing. ~9KB.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and a non-destructive profile, so the description only needs to add behavioral context. It adds the exact source path, the approximate size (~9KB), and the kind of content returned, which gives the agent useful expectations beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences with no wasted words. The most important information (what is returned and from where) is front-loaded, and the usage cue and file size each earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only reference tool with no output schema, the description is complete: it names the file, summarizes its contents, gives a usage trigger, and even notes the file size. Nothing an agent needs to decide whether to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. The baseline of 4 applies because the description cannot add parameter-level meaning where no parameters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Returns') and a precise resource ('references/03-ANTI-PATTERNS.md'), then clarifies content with concrete examples: red flags, rationalizations, and recovery patterns. It is clearly distinct from sibling tools like get_god_prompt or get_core_skill because it names the anti-pattern file and its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit trigger condition: 'Load when you catch yourself rationalizing.' This tells the agent when the tool is appropriate, but it does not name when not to use it or compare it to sibling alternatives, so it stops short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_core_skillGet core GodPrompt skillA
Read-onlyIdempotent
Inspect

Returns SKILL.md — the lean core protocol (~16KB) covering the universal 6-phase protocol, Three Iron Laws, and task auto-classification. Load it at the start of a task or after a context reset, then reuse that context instead of reloading it on every message. Start here for progressive disclosure.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description need not repeat that. It adds useful behavioral context beyond the schema: approximate response size (~16KB), that it is a lean protocol rather than the full prompt, and that its content is reusable across a context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states exactly what is returned, the second gives actionable usage guidance, and the final phrase reinforces its role as the entry point. Every sentence contributes meaning without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read-only tool with no output schema, the description is complete: it identifies the return value (SKILL.md), its size and contents, when to call it, and how to handle the returned context. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100% and the description has no parameter burden. The baseline of 4 applies because the description instead clarifies what the returned resource contains and how to use it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific deliverable, 'SKILL.md', and states its contents: the universal 6-phase protocol, Three Iron Laws, and task auto-classification. It also positions it as 'the lean core protocol' and 'Start here', distinguishing it from siblings like get_god_prompt or get_protocols without needing to open their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit timing cues: 'Load it at the start of a task or after a context reset'. It also tells the agent what not to do — reload it on every message — and directs agents to 'Start here for progressive disclosure', which effectively makes it the entry point among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_gatesGet GodPrompt verification gatesA
Read-onlyIdempotent
Inspect

Returns references/02-GATES.md — verification checklists, THE GATE (pre-completion verification), and structured report templates for every deliverable type. Load when you need to verify work before claiming completion. ~9KB.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool is read-only, idempotent, and non-destructiveikuha. The description adds meaningful context about the returned file's contents and its size (~9KB), which goes beyond what annotations alone convey. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences front-load the core return value and follow with a practical usage trigger and size estimate. Every word earns its place; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent tool with no output schema, the description fully covers what an agent needs to know to invoke it correctly and understand what to expect. The annotations handle safety, and the description handles content and purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters)Skip, so there is no parameter schema to supplement. The description appropriately focuses on what the tool returns rather than any parameter details, matching the baseline for a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Returns') and a specific resource (references/02-GATES.md), and further describes what it contains: verification checklists, THE GATE, and structured report templates. This is distinct from sibling tools like get_protocols or get_anti_patterns, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit guidance on when to use it: 'Load when you need to verify work before claiming completion.' It does not explicitly name excluded alternatives, but the context is clear enough for selection among the listed siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_god_promptGet full GodPromptA
Read-onlyIdempotent
Inspect

Returns the complete GodPrompt.md — a single-file universal system prompt for AI software development (47KB, ~1145 lines). Use this when you want the full payload in one shot. For progressive disclosure (smaller context), use get_core_skill and the reference tools instead.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context by disclosing the large payload size (47KB, ~1145 lines) and that it returns the full single-file content in one shot. This helps the agent anticipate context usage, going beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: the first front-loads the primary action and payload description, the second states the primary use case, and the third names the alternative for different needs. Every sentence earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description provides everything an agent needs: what the tool returns, the size, and when to use it versus alternatives. The annotations cover the operational safety profile. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is trivially complete. The baseline for 0 parameters is 4, and the description appropriately avoids inventing parameter details. No compensation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Returns the complete GodPrompt.md', and further identifies it as a single-file universal system prompt. It differentiates itself from siblings by naming get_core_skill and reference tools as alternatives for progressive disclosure. An agent can immediately understand what this tool provides and how it differs from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('when you want the full payload in one shot') and when not to ('For progressive disclosure (smaller context)'), naming the alternative tools. This is clear, actionable guidance with no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_protocolsGet GodPrompt protocolsA
Read-onlyIdempotent
Inspect

Returns references/01-PROTOCOLS.md — deep execution guides for each task type (BUILD, DEBUG, REFACTOR, CONTENT, DESIGN, SHIP, ANALYZE, AUTOMATE, PLAN). Load this when the task requires detailed protocol steps beyond the core skill. ~13KB.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld false, idempotent, and non-destructive, so less is required from the description. The description adds meaningful context by identifying the returned file, its purpose, task coverage, and approximate size (~13KB), going beyond what the schema or annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the resource being returned, and every sentence contributes: return target, content scope, trigger condition, and size. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent retrieval tool, this description is complete: an agent knows what it returns, when to use it, and what content to expect. The sibling context and annotations cover the remaining selection cues.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema description coverage is 100%, so the description has no parameter burden. It still clarifies that the returned artifact is a protocol reference and which task types it covers, which is the only relevant context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Returns references/01-PROTOCOLS.md — deep execution guides for each task type'. It unpacks the document's scope by enumerating the task types and frames it as distinct from the core skill, so an agent can tell it apart from sibling retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use cue: 'Load this when the task requires detailed protocol steps beyond the core skill.' It does not explicitly name exclusionary alternatives like get_gates or get_anti_patterns, but the guidance is clear enough for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_versionGet GodPrompt versionsA
Read-onlyIdempotent
Inspect

Returns JSON with the GodPrompt content version, MCP server version, repository, bundled file sizes and purposes, and task-type/protocol catalog. Use it to verify which GodPrompt content/server version a client is connected to; use the content retrieval tools when you need the actual workflow text.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying the JSON return format and the categories of information it contains. No contradictions; it simply could not mention potential caching or latency behavior, which is minor for a no-parameter version probe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The first sentence front-loads the full output shape, and the second sentence provides usage routing. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description explicitly enumerates the major payload components and gives usage context. For a simple, no-parameter metadata tool, no critical information needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is vacuously 100% and the description does not need to explain parameter semantics. This is the baseline case for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Returns JSON with the GodPrompt content version, MCP server version, repository, bundled file sizes...') and enumerates exactly what the tool provides. This makes it clearly distinguishable from siblings like get_god_prompt and get_protocols, which return actual workflow content rather than metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: 'to verify which GodPrompt content/server version a client is connected to.' It also tells the agent when not to use it by directing it to 'the content retrieval tools' when actual workflow text is needed, effectively naming the alternative category.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.22
    • Changedclassify_task3 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / description / pattern
        Added value: +"[\\p{L}\\p{N}]"
  2. 6 tool updatesv1.0.4
    • Changedget_anti_patterns1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedget_core_skill1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedget_gates1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedget_god_prompt1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedget_protocols1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedget_version1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
  3. 7 tool updatesv1.0.0
    • First observedclassify_task
    • First observedget_anti_patterns
    • First observedget_core_skill
    • First observedget_gates
    • First observedget_god_prompt
    • First observedget_protocols
    • First observedget_version

TDQS

A4.7/5.0

Scored across 7 tools

Disambiguation5/5

Each tool maps to a clearly distinct file or action: full prompt, core skill, individual reference docs, task classification, and version metadata. The descriptions explicitly prescribe when to use each (e.g., full file vs progressive disclosure), so an agent would rarely misselect. Even the overlapping full-prompt and core-skill tools are disambiguated by context size and start-here guidance.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: get_* for content retrieval and metadata, plus classify_task for the single classification action. There are no stylistic clashes or vague names, and the function of each tool is predictable from its name alone.

Tool Count5/5

Seven tools is well within the ideal range for a focused content-delivery and classification server. Each tool covers a distinct artifact or action—full prompt, core skill, three reference files, classification, and version check—and none feels redundant. The count is appropriate for the server's narrow purpose.

Completeness5/5

The set covers the complete documented workflow: core protocol loading, task-type classification, deeper per-type protocols, anti-patterns, gates/checklists, and version verification. Since this is a read-only content server, no CRUD operations are expected. It exposes every referenced file plus a classifier, leaving no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Provides AI-powered selection and generation of specialized system prompts from a database of over 66 templates for Claude Code. It uses semantic search to find the best matching template and can adapt it to fit specific user tasks and contexts.
    -
  • A
    license
    A
    quality
    D
    maintenance
    Automatically generates and manages a prompts system for software projects, enabling persistent context for AI coding assistants through project scanning, requirement clarification, and module tracking.
    8
    22 npm
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Provides specialist context for AI agents, enabling them to work as different roles (UI, DE, SRE, etc.) through MCP prompts and tools.
    7
    9 npm
    1
    MIT