@singularity/pdd-agent-tools (0.1.0)

Published 2026-06-26 16:12:22 +00:00 by mhugo

Setup this registry in your project .npmrc file:

@singularity:registry=

To install the package using npm, run the following command:

npm install @singularity/pdd-agent-tools@0.1.0

or add it to the package.json file:

"@singularity/pdd-agent-tools": "0.1.0"

For more information on the npm registry, see the documentation.

pdd-agent-tools-mcp

PDD skills + redteam CLI packaged as a single MCP server for the CentralCloud fleet.

pdd-agent-tools-mcp is an HTTP-based Model Context Protocol server that exposes 21 PDD skills as MCP tools, prompts, and resources that return skill text on demand (CALL-TO-LOAD — see below) and can be self-installed for auto-activation (see Versioned self-install), plus a redteam_* tool per adversarial mode (review, plan, decision, bughunt, architect, verify, hack, ultrareview, harvest) that shells out to the redteam panel runner.

sf-debug-scan is intentionally not in this MCP bundle — it lives in the user's global skills setup (dotfiles .claude/.copilot), out of scope for the MCP server.

How skills work over MCP (CALL-TO-LOAD, not auto-activation)

Mounting this MCP server does NOT auto-activate skills in Claude or any other client. Skills are not Claude Code skills plugins; they are MCP tools that return guidance text when called.

The workflow is:

The server's instructions field (sent to the client at initialize time) contains a compact index of all skill names and triggers, plus a rule: call the matching skill tool before starting relevant work.
When the agent calls a skill tool (e.g. skill_brainstorming), the server returns the full SKILL.md body as text. The agent then follows those instructions for the current task. Per-skill tools are named skill_<name> so the tool list is self-documenting; the skill index in the instructions field is grouped by category.
Nothing happens automatically — the agent must read the instructions field, recognize the trigger, and make the tool call.

This means skill effectiveness depends entirely on whether the client surfaces the instructions field to the model and whether the model acts on it. Most clients (Claude Code ≥ 0.2, Copilot CLI ≥ 1.5) do include the instructions in context.

Discovery tools

Tool	What it returns
`list_skills`	`{bundleHash, categories: {category: [{name, description, category, origin, hash}]}}` — the machine-readable index. The `hash` (12 hex of sha256 over the whole skill package) and `bundleHash` drive versioned self-install
`install_skills`	`{bundleHash, skills: [{name, hash, files: [{path, content}]}], agentsBlock: {begin, end, body, full}}` — full skill packages for self-install (raw SKILL.md with frontmatter + all aux files) plus a Beads-pattern managed `AGENTS.md`/`CLAUDE.md` block (HTML markers carrying `bundleHash`, idempotent). Optional `names` selects a subset; `bundleHash` + `agentsBlock` always full-bundle. Consent + hash-verify before any write.
`server_info`	Full capability matrix and registered counts
`server_logs`	Recent server log lines (redacted) + counts — debug the server itself over MCP
`redteam_list_jobs`	Recent panel jobs (id, kind, status, elapsed, summary)
`redteam_job_trace`	A job's `panel.log` trace tape (redacted) — pull-based span read
`redteam_job_result`	A job's stored `panel-result.json`
`skill_<name>`	Full `SKILL.md` body for that skill

Redteam tools

The redteam_<mode> tools (review, plan, decision, bughunt, architect, verify, hack, ultrareview, harvest) run cross-model adversarial panels and return a structured verdict. They are long-running (30–120 s) and require model-provider API keys in the environment.

Versioned self-install

The MCP server is the single source of skills: clients pull the full skill package from the running server, never from a repo path. To get real auto-activation (skills trigger without an explicit tool call), an agent installs the complete skill packages into its skills dir and re-installs when they drift — all over MCP, no manual sync.

The model:

On connect, call list_skills. Each entry carries a content hash (first 12 hex of sha256 over the whole skill package), and the response carries a bundleHash (one fingerprint over all sorted name:hash lines).
Compare your installed skills' hashes to those. If any are missing or stale (different hash), call install_skills.
install_skills returns {bundleHash, skills: [{name, hash, files: [{path, content}]}]}. Each file's path is prefixed with the skill name (e.g. <name>/SKILL.md, <name>/references/foo.md, <name>/scripts/run.sh). Write each file's content to <your-skills-dir>/<path> verbatim — one of ~/.claude/skills/, ~/.copilot/skills/, or <repo>/.agents/skills/. Pass names to install a subset; the returned bundleHash always reflects the full bundle so it still matches list_skills.
Once installed, the client's own frontmatter-driven loader auto-activates the skills directly: the served SKILL.md is the raw file with its name/description frontmatter intact (no reconstruction needed), and all auxiliary files (references/, scripts/, assets/, …) ship in the same package. The skill_<name> tools remain the call-to-load fallback if you cannot write to a skills dir.

The MCP server serves complete skill packages: the raw SKILL.md (with frontmatter) plus every auxiliary file, recursively. Multi-file skills — using-skills, writing-skills, brainstorming, systematic-debugging, subagent-driven-development — install in full, companion files and all.

Bundled installer + managed AGENTS.md block

One install_skills call is the whole installer. Besides the skill packages it also returns agentsBlock, a managed instruction-file block the agent merges into the client's instruction file (AGENTS.md / CLAUDE.md / GEMINI.md / .github/copilot-instructions.md):

agentsBlock: {
  begin: "<!-- BEGIN pdd-agent-tools skills (<bundleHash>) -->",
  end:   "<!-- END pdd-agent-tools skills -->",
  body:  "<the managed reminder: intro + grouped skill index + CALL-before rule + redteam usage>",
  full:  "<begin>\n<body>\n<end>"   // exactly what the agent writes between the markers
}

This follows the Beads marker pattern: HTML-comment BEGIN/END markers wrap the managed region, the begin marker carries the bundleHash so a re-install detects staleness, and the agent replaces only the text between the markers — never touching hand-written content. The block is therefore idempotent (re-running replaces in place), removable (delete between the markers), and multi-tool-coexistent (each tool's managed block uses its own markers). body is generated from the same shared helper as the server instructions field, so the two never drift, and agentsBlock always reflects the full bundle even when names filters the returned files.

The MCP server is a trust boundary, not a backstop. The server can only direct the agent — it cannot write to the user's machine. So before any write the agent MUST:

Ask the user's consent before writing skill files or merging the block.
Verify the returned bundleHash and file content against list_skills before trusting them.
Only then write each skill file at <skillsDir>/<path> and merge agentsBlock.full into the instruction file by replacing the managed region. To stay idempotent across hash changes, locate the existing region by the stable begin prefix <!-- BEGIN pdd-agent-tools skills (ignore the parenthesized hash, which changes on re-install) through the hash-free end marker, replace that whole region with the new agentsBlock.full, and append once only if no region is found. Matching the new hash-bearing begin as a literal would miss the old block and append a duplicate.

Sandboxing is not a substitute for this: a malicious or compromised server could ship hostile instruction text, and sandboxing does not fully isolate what an instruction-following agent will do once it reads that text. Consent + content verification is the actual control.

No hooks, no gratuitous scripts (by design)

This installer ships NO hooks and adds NO extra scripts. preToolUse hooks fail closed (a broken or slow hook can block every tool call), and an installed hook is a supply-chain risk — it runs unsupervised on every matching event. We intentionally keep the install to data only (skill files + a text block the agent writes under consent); there is nothing that executes on its own.

Manual install (no MCP) still works — distribute the SKILL.md files as a Claude Code plugin:

Claude Code: drop each skill directory into ~/.claude/skills/<name>/SKILL.md or publish a .claudeplugin manifest that lists the skill dir. Claude Code then auto-loads triggers from frontmatter.
Copilot CLI: sync into ~/.copilot/skills/<name>/SKILL.md. The Copilot agent uses the same frontmatter convention.

The MCP server is complementary to plugin auto-activation, not a replacement. It provides:

Redteam adversarial review tools unavailable as dotfile skills.
Central skill text: update skills in one place, all clients pick them up on the next call (or listChanged notification).
The instructions reminder for clients that read it.
The list_skills discovery endpoint for programmatic agents (grouped by category, with each skill's origin provenance).

Why

The dotfile skills pattern works but has known friction:

new skills aren't discoverable mid-session (requires restart)
3-place sync (dotfiles → ~/.copilot/skills/ → ~/.claude/skills/)
per-client install dirs in activation scripts
redteam's jsonrepair dep needs an npm install dance on every HM switch

This server packages skills + redteam behind one MCP server with the full modern feature surface (listChanged, subscribe, logging, sampling, elicitation, tasks/progress). One image, one port (8931), one config entry per client.

Capability Matrix

Capability	Support	Notes
`tools`	✅ listChanged	21 `skill_<name>` tools + `list_skills` + `install_skills` + `server_info` + 9 redteam modes
`resources`	✅ listChanged, subscribe	`skill://<name>` URIs
`prompts`	✅ listChanged	Same body as skill tool, addressed by name
`logging`	✅ server-initiated	RFC 5424 levels, client controls floor
`tasks`	✅ declared via `execution.taskSupport: required` on redteam tools
`sampling/createMessage`	✅ via `extra.sendRequest` from tool handlers
`elicitation/create`	✅ via `extra.sendRequest` from redteam handlers
`notifications/progress`	✅ via `extra.sendNotification` for long redteam runs
Hot-reload	⚠️ sends listChanged on file change; full handler rebuild requires restart

Architecture

┌──────────────────────────────────────────────────────────┐
│ pdd-agent-tools-mcp (HTTP, port 8931)                        │
│ ┌────────────────────┐  ┌─────────────────────────────┐ │
│ │ Skills loader      │  │ Redteam wrapper             │ │
│ │ (chokidar watcher) │  │ (spawn node panel.mjs)      │ │
│ └────────────────────┘  └─────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ MCP server (sdk 1.x)                                 │ │
│ │   tools[]  resources[]  prompts[]  logging          │ │
│ │   extra.sendRequest / sendNotification (per-handler)│ │
│ └──────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Express + helmet + cors + rate-limit + req-id        │ │
│ │   POST /mcp    GET /mcp    DELETE /mcp               │ │
│ │   GET  /healthz /readyz /info                        │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘

Why `redteam` and `redteam-result-handling` exist in two places

skills/<name>/SKILL.md is the MCP-canonical copy the server loads (and the only one carrying the metadata map with category/origin); redteam/skills/<name>/SKILL.md is the self-contained plugin distribution (plugin.json → "skills": "./skills/") that uses paths relative to redteam/. A symlink to ../../skills/<name> would point outside the plugin tree and break when the plugin is packaged alone, so the two copies are kept separate by design.

Local dev

nix develop                # enter dev shell (node + pnpm + biome + vitest)
pnpm install               # install deps
pnpm build                 # compile TS to dist/
pnpm test                  # run vitest
pnpm start                 # run server on :8931

Smoke test:

pnpm build
node dist/server.js &
curl localhost:8931/healthz
curl localhost:8931/info

Nix build (binary + container)

nix build .#default      # bundles node_modules + skills + redteam → ./result/bin/pdd-agent-tools-mcp
nix build .#container     # nix2container OCI image JSON
nix run .#copy-container  # push registry.infra.centralcloud.com/centralcloud/pdd-agent-tools-mcp:git-<sha>

Image is pdd-agent-tools-mcp:latest, listens on :8931, env vars:

Var	Default	Description
`PDD_AGENT_TOOLS_PORT`	`8931`	HTTP listen port
`PDD_AGENT_TOOLS_HOST`	`0.0.0.0`	HTTP bind address
`PDD_AGENT_TOOLS_SKILLS_DIR`	bundled `/lib/pdd-agent-tools-mcp/skills`	Path to skill directories containing `SKILL.md` files
`PDD_AGENT_TOOLS_REDTEAM_DIR`	bundled `/lib/pdd-agent-tools-mcp/redteam`	Path to the `redteam/` directory containing `scripts/panel.mjs`
`PDD_AGENT_TOOLS_NO_HOT_RELOAD`	unset (hot reload on); set to `1` to disable	Disables chokidar file-watching and `listChanged` notifications
`PDD_AGENT_TOOLS_STATELESS`	unset (stateful sessions, default); set to `1` to enable	Stateless HTTP transport mode — each POST creates a fresh transport with no session tracking. Suitable for serverless runtimes and reverse-proxy deployments where sticky sessions are unavailable. GET and DELETE /mcp return 405 in this mode.

Tools reference

Skill tools (21 total, one per skill)

Each skill tool:

Name: skill_<skill-name> (e.g. skill_brainstorming, skill_systematic-debugging). The skill_ prefix makes the tool list self-documenting.
Params: none.
Returns: the full SKILL.md body as text.
Annotations: readOnlyHint: true, idempotentHint: true, destructiveHint: false, openWorldHint: false.
Description: prefixed with Load the <name> skill instructions (returns guidance text, takes no action). followed by the original trigger phrase from the skill's frontmatter.

Skills follow the agentskills.io Agent Skills standard: the only standard top-level frontmatter fields are name and description. Any extra metadata lives in an optional free-form metadata: map. Our two discovery keys live there:

---
name: <skill-name>
description: Use when <trigger phrases...>
metadata:
  category: <category>
  origin: <origin>
---

metadata.category: one of process, review, writing, meta, orchestration, diagnostics. Drives the grouping in list_skills and the instructions skill index.
metadata.origin: provenance — pdd-original for the 7 PDD-original skills, or superpowers (Obra/Jesse Vincent), adapted for the 14 adapted from Superpowers.

Available skills grouped by category (tool name = skill_<name>):

Category	Skill	Origin	Trigger
process	`brainstorming`	superpowers, adapted	Product/design exploration, unclear requirements, multiple viable approaches, UI/UX choices, or new behavior whose intent is not yet bounded
process	`writing-plans`	superpowers, adapted	Having a spec or requirements for a multi-step task, before touching code
process	`executing-plans`	superpowers, adapted	Executing a written implementation plan inline with checkpoints and verification
process	`test-driven-development`	superpowers, adapted	Implementing any feature or bugfix, before writing implementation code
process	`purpose-first-tdd`	pdd-original	Making or evaluating any behavior, plan, prompt, skill, code, test, or operational change that needs purpose, proof, consumer, or falsifier clarity
process	`systematic-debugging`	superpowers, adapted	Encountering a bug, test failure, production incident, unexpected behavior, or build failure before proposing fixes
process	`verification-before-completion`	superpowers, adapted	About to claim work is complete, fixed, passing, ready to commit, or ready for PR
review	`requesting-code-review`	superpowers, adapted	Completing tasks, implementing major features, or before merging to verify work
review	`receiving-code-review`	superpowers, adapted	Receiving code review feedback before implementing suggestions
review	`redteam`	pdd-original	(internal redteam trigger)
review	`redteam-result-handling`	pdd-original	Presenting redteam panel JSON results back to the user
writing	`human-writing`	pdd-original	Creating or revising docs, plans, PR text, handoffs, or other prose that should be sparse, direct, and low-context
writing	`instruction-writing`	pdd-original	Changing prompt templates, AGENTS.md, CLAUDE.md, MCP/tool instructions, skills, governance docs, or any instruction surface
meta	`using-skills`	superpowers, adapted	Starting any conversation or task, before clarifying, inspecting files, planning, editing, or answering
meta	`writing-skills`	superpowers, adapted	Creating, editing, pruning, or verifying skills before deployment
meta	`existing-capability-first`	pdd-original	Adding or changing a capability surface such as a public function, API, command, prompt, workflow, schema, or policy
meta	`quality-contracts`	pdd-original	Changing production behavior, tests, policy gates, validators, docs, or exceptions where correctness or silent failures could ship
orchestration	`dispatching-parallel-agents`	superpowers, adapted	2+ independent tasks, failures, research lanes, or path-scoped investigations that can run without shared state
orchestration	`subagent-driven-development`	superpowers, adapted	Executing a written implementation plan or dispatching 2+ independent implementation tasks
orchestration	`using-git-worktrees`	superpowers, adapted	Feature work needing workspace isolation, branch-safe edits, or a plan that should not run in the current checkout
orchestration	`finishing-a-development-branch`	superpowers, adapted	Implementation complete, verification passes, and the decision is how to merge, PR, clean up, or finish the branch

Utility tools

Tool	Params	Returns
`list_skills`	none	`{bundleHash, categories: {category: [{name, description, category, origin, hash}]}}`. The machine-readable skill index; `hash`/`bundleHash` drive versioned self-install.
`install_skills`	`names?` (`string[]`)	`{bundleHash, skills: [{name, hash, files: [{path, content}]}], agentsBlock: {begin, end, body, full}}` — full skill packages for versioned self-install: raw `SKILL.md` with frontmatter + all auxiliary files (`references/`, `scripts/`, `assets/`), each `path` prefixed with the skill name; plus a Beads-pattern managed instruction-file block (`agentsBlock.full` = `begin`+`body`+`end`, HTML markers carrying `bundleHash`, `body` from the same shared helper as the server `instructions`). Default all; `names` selects a subset, `bundleHash` + `agentsBlock` always full-bundle. Content comes from the in-memory registry, never re-read from disk. The agent must get user consent and verify the bundleHash/content before writing files or merging the block; the server ships no hooks.
`server_info`	none	Full capability matrix, registered skill count, redteam mode list, transport info.
`server_logs`	none	Recent server log lines (redacted) + registered skill count + redteam modes — debug the MCP server itself over MCP.
`redteam_list_jobs`	none	Recent panel jobs (id, kind, status, elapsed, summary).
`redteam_job_trace`	`jobId`, `maxLines?`	A job's `panel.log` trace tape (redacted) — pull-based span/debug read.
`redteam_job_result`	`jobId`	A job's stored `panel-result.json`.

Redteam tools (9 modes)

Tool	Mode	Description
`redteam_review`	review	General code/design review panel
`redteam_plan`	plan	Adversarial plan review
`redteam_decision`	decision	Architecture or approach decision review (ADR)
`redteam_bughunt`	bughunt	Codebase-wide bug hunt
`redteam_architect`	architect	Architecture adversarial review
`redteam_verify`	verify	Verify a fix or validate a finding
`redteam_hack`	hack	Adversarial attack-surface exploration
`redteam_ultrareview`	ultrareview	Deep multi-model review
`redteam_harvest`	harvest	Harvest findings/patterns from a codebase

Redteam tools:

Params:
- input (string, required) — absolute path to the file, plan, or directory under review.
- focus (optional enum) — one of security, performance, correctness, ux, all. If omitted, the tool elicits the focus from the operator (falling back to all). Free-form strings are rejected.
- extra_args (optional string[]) — extra flags passed straight to panel.mjs (e.g. ["--all-files"], ["--verify"]).
Returns: structured content {verdict, findings[], raw, jobId} plus the full panel stdout as text. verdict is the panel verdict (random family), the run summary (bughunt/ultrareview), or a synthesized mode + count line (scatter). findings is the normalized list of findings across the mode's report shape, each rendered as [severity] title (file:line). jobId is the background job id — pass it to the debug/trace tools below to pull the trace tape or stored result.
Annotations: openWorldHint: true (they call external model providers).
Long-running: expect 30–120 s. Progress notifications are emitted.
Keys required: XAI_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY (or whichever providers the panel is configured to use).

Debug / span-trace tools (pull-based)

Read panel job state, debug tapes, and the server's own logs over MCP — no Laminar export. The trace tape is each job's panel.log (the redacted stderr record), read straight from the bundled job registry.

Tool	Params	Returns
`redteam_list_jobs`	none	JSON list of recent panel jobs (`id, kind, status, elapsed, summary`). `openWorldHint: true` (reads the live job store).
`redteam_job_trace`	`jobId` (string), `maxLines?` (number, default 200)	The job's `panel.log` trace/tape (redacted) — the span/debug read.
`redteam_job_result`	`jobId` (string)	The job's stored `panel-result.json` (final merged report).
`server_logs`	none	Recent server log lines (redacted) + registered skill count + redteam modes — debug the MCP server itself over MCP.

All four are readOnlyHint: true, idempotentHint: true.

Debug / trace resources

Templated, read/subscribe-able URIs for the same per-job data:

Resource URI	MIME	Content
`redteam-job://<id>/trace`	`text/plain`	The job's `panel.log` trace tape (redacted).
`redteam-job://<id>/result`	`application/json`	The job's stored `panel-result.json`.

Client config

Copilot CLI (`~/.copilot/mcp.json`)

{
  "mcpServers": {
    "pdd-agent-tools": {
      "url": "http://127.0.0.1:8931/mcp",
      "headers": { "X-Request-Id": "copilot-cli" }
    }
  }
}

Claude Code (`~/.claude/mcp.json`)

{
  "mcpServers": {
    "pdd-agent-tools": { "url": "http://127.0.0.1:8931/mcp" }
  }
}

Cursor (`~/.cursor/mcp.json`)

{
  "mcpServers": {
    "pdd-agent-tools": { "url": "http://127.0.0.1:8931/mcp" }
  }
}

Gemini CLI (`~/.gemini/settings.json`)

{
  "mcpServers": {
    "pdd-agent-tools": { "url": "http://127.0.0.1:8931/mcp" }
  }
}

CentralCloud deploy

Add an entry to the fleet chart and apply via Flux:

# clusters/default/tenants/mikkihugo/apps/pdd-agent-tools-mcp/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: centralcloud-mcp
resources:
  - deployment.yaml
  - service.yaml
  - serviceaccount.yaml

Image: registry.infra.centralcloud.com/mikkihugo/pdd-agent-tools-mcp:<sha>. Service URL inside cluster: http://pdd-agent-tools-mcp.centralcloud-mcp.svc.cluster.local:8931/mcp.

The bundled helm chart in charts/pdd-agent-tools-mcp/ follows the same pattern as alertmanager-mcp / observability-mcp (see /srv/infra).

Tests

pnpm test

21 tests covering:

tests/skills.test.ts — frontmatter parsing, missing-name skip
tests/logging.test.ts — RFC 5424 level filtering
tests/redteam.test.ts — mode schema validation
tests/hot-reload.test.ts — chokidar add/change event capture
tests/server.test.ts — buildServer registered tool count
tests/http.test.ts — supertest-driven /healthz, /readyz, /info

Hard rules

Read-only by default. Skill tools are read-only; redteam tools are read-only (they shell out to a read-only review process). No tool in this server mutates state.
Open-world on redteam. openWorldHint: true because cross-model panels hit external model providers.
Idempotent skills. Tool annotations advertise idempotentHint: true.
Logging on every state change. RFC 5424 levels, structured JSON.
No secrets in the container. Image contains no API keys; the server reads them from the environment at runtime (operator's responsibility).

Known limitations (v0.1)

Hot-reload sends listChanged notifications but does not rebuild the internal handler map. A skill's body is updated in the in-memory cache immediately, but the McpServer's tool registration still references the old body until restart. v0.2 will track handlers in a Map and rebuild on change.
redteam_* tools require API keys for the model providers. The bundled redteam runs scripts/panel.mjs, which reads keys from the environment (e.g., XAI_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY). Configure these via ExternalSecret or envFrom in the helm chart.
No auth on the HTTP transport — relies on the CentralCloud auth proxy or k8s NetworkPolicy for ingress control. Add OAuth / OIDC for public deployment.

Credits

The PDD skillset is forked and evolved from Superpowers by Jesse Vincent (@obra) — https://github.com/obra/superpowers (MIT, Copyright © 2025 Jesse Vincent). If Superpowers helps you, Jesse appreciates sponsorship.

These started from Superpowers and have since diverged substantially (not a verbatim vendor — e.g. writing-skills, systematic-debugging, brainstorming, and writing-plans are largely rewritten), so we maintain them as our own fork:

Adapted from Superpowers (Obra): brainstorming, dispatching-parallel-agents, executing-plans, finishing-a-development-branch, receiving-code-review, requesting-code-review, subagent-driven-development, systematic-debugging, test-driven-development, using-git-worktrees, using-skills (from using-superpowers), verification-before-completion, writing-plans, writing-skills.
PDD-original (this project): purpose-first-tdd (the 9-field PDD contract that the others now reference), quality-contracts, instruction-writing, human-writing, existing-capability-first, redteam, redteam-result-handling. (sf-debug-scan is PDD-original too but is intentionally NOT bundled in this MCP — it lives in the user's global skills setup.)

purpose-first-tdd is the umbrella discipline (purpose + falsifier for any change); test-driven-development is the code-specific red-green practice nested under it — both are kept intentionally.

The managed AGENTS.md/CLAUDE.md block (HTML BEGIN/END markers carrying a version/hash, replace-between-markers idempotency, multi-tool coexistence) follows the marker pattern from Beads by Steve Yegge.

License

Dependencies

ID	Version
@cfworker/json-schema	^4.1.1
@modelcontextprotocol/node	2.0.0-alpha.2
@modelcontextprotocol/server	2.0.0-alpha.2
ajv	^8.20.0
chokidar	^3.6.0
cors	^2.8.5
express	^4.21.0
express-rate-limit	^7.4.0
gray-matter	^4.0.3
helmet	^7.1.0
hono	^4.12.26
jsonrepair	^3.14.1
smol-toml	^1.7.0
uuid	^10.0.0
zod	^4.4.3

Development dependencies

ID	Version
@biomejs/biome	^1.9.0
@types/cors	^2.8.17
@types/express	^4.17.21
@types/node	^22.7.0
@types/supertest	^6.0.2
@types/uuid	^10.0.0
esbuild	^0.28.1
proper-lockfile	^4.1.2
supertest	^7.0.0
typescript	^5.6.0
vitest	^2.1.0

Details

npm

2026-06-26 16:12:22 +00:00

MIT

1.7 MiB

Assets (1)

pdd-agent-tools-0.1.0.tgz 1.7 MiB

Versions (2) View all

0.1.1

2026-06-26

0.1.0

2026-06-26

@singularity/pdd-agent-tools (0.1.0)

Installation

About this package

pdd-agent-tools-mcp

How skills work over MCP (CALL-TO-LOAD, not auto-activation)

Discovery tools

Redteam tools

Versioned self-install

Bundled installer + managed AGENTS.md block

No hooks, no gratuitous scripts (by design)

Why

Capability Matrix

Architecture

Why `redteam` and `redteam-result-handling` exist in two places

Local dev

Nix build (binary + container)

Tools reference

Skill tools (21 total, one per skill)

Utility tools

Redteam tools (9 modes)

Debug / span-trace tools (pull-based)

Debug / trace resources

Client config

Copilot CLI (`~/.copilot/mcp.json`)

Claude Code (`~/.claude/mcp.json`)

Cursor (`~/.cursor/mcp.json`)

Gemini CLI (`~/.gemini/settings.json`)

CentralCloud deploy

Tests

Hard rules

Known limitations (v0.1)

Credits

License

Dependencies

@singularity/pdd-agent-tools (0.1.0)

Installation

About this package

pdd-agent-tools-mcp

How skills work over MCP (CALL-TO-LOAD, not auto-activation)

Discovery tools

Redteam tools

Versioned self-install

Bundled installer + managed AGENTS.md block

Trust boundary: CONSENT + hash-verify before any write

No hooks, no gratuitous scripts (by design)

Why

Capability Matrix

Architecture

Why redteam and redteam-result-handling exist in two places

Local dev

Nix build (binary + container)

Tools reference

Skill tools (21 total, one per skill)

Utility tools

Redteam tools (9 modes)

Debug / span-trace tools (pull-based)

Debug / trace resources

Client config

Copilot CLI (~/.copilot/mcp.json)

Claude Code (~/.claude/mcp.json)

Cursor (~/.cursor/mcp.json)

Gemini CLI (~/.gemini/settings.json)

CentralCloud deploy

Tests

Hard rules

Known limitations (v0.1)

Credits

License

Dependencies

Why `redteam` and `redteam-result-handling` exist in two places

Copilot CLI (`~/.copilot/mcp.json`)

Claude Code (`~/.claude/mcp.json`)

Cursor (`~/.cursor/mcp.json`)

Gemini CLI (`~/.gemini/settings.json`)