Singularity
Repositories
1
 Projects Packages
2

@singularity/pdd-agent-tools (0.1.1)

Published 2026-06-26 16:35:38 +00:00 by mhugo

Installation

@singularity:registry=
npm install @singularity/pdd-agent-tools@0.1.1
"@singularity/pdd-agent-tools": "0.1.1"

About this package

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:

  1. 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.
  2. 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.
  3. 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, registered counts, and lazy self-update metadata
check_update npm dist-tag check for the running package; reports restartRequired when @latest is newer
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:

  1. 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).
  2. Compare your installed skills' hashes to those. If any are missing or stale (different hash), call install_skills.
  3. 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.
  4. 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.

Trust boundary: CONSENT + hash-verify before any write

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:

  1. Ask the user's consent before writing skill files or merging the block.
  2. Verify the returned bundleHash and file content against list_skills before trusting them.
  3. 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 + check_update + 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

Npm-backed clients should launch the stdio server with online dist-tag resolution:

npx -y --prefer-online @singularity/pdd-agent-tools@latest

The package's managed installer also writes prefer-online=true beside the CentralCloud registry mapping in .npmrc. That makes future launches refresh metadata before reusing a cached package.

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, and lazy self-update metadata.
check_update none {packageName,currentVersion,latestVersion,registry,updateAvailable,restartRequired,updateCommand,checkedAt,error?} from the npm registry. Read-only; never restarts the running server.
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

For local stdio clients, prefer npm-backed launch over a repo-local path:

{
  "mcpServers": {
    "pdd-agent-tools": {
      "command": "npx",
      "args": ["-y", "--prefer-online", "@singularity/pdd-agent-tools@latest"]
    }
  }
}

check_update reports when a newer npm package exists. A running stdio MCP server cannot hot-replace itself; reconnect/restart the MCP server so npx resolves the latest package on process start. Current Codex CLI releases expose codex mcp list/get/add/remove/login/logout; they do not expose a codex mcp restart command.

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)

  • check_update can detect package drift, but a running stdio server still requires a client reconnect/restart before npm can launch the newer package.
  • 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

MIT. Forked skill content adapted from Superpowers carries its original MIT license (Copyright © 2025 Jesse Vincent); see https://github.com/obra/superpowers.

Dependencies

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:35:38 +00:00
1
MIT
latest
1.7 MiB
Assets (1)
pdd-agent-tools-0.1.1.tgz 1.7 MiB
Versions (2) View all
0.1.1 2026-06-26
0.1.0 2026-06-26