{
  "markdown": "# SignatureAPI Agent Skills\n\nAgent Skills for [SignatureAPI](https://signatureapi.com), the e-signature API. Two skills that\nlet AI coding agents build and troubleshoot e-signature integrations directly from the command\nline: one for building a signing flow, one for diagnosing one that already exists.\n\n## Install\n\n**Let your agent do it.** Paste this into Claude Code, Codex, Cursor, or any agent that can read a\nURL, and it installs the right thing for itself:\n\n```text\nSet up SignatureAPI for me. Read https://signatureapi.com/docs/ai-toolkit/mcp/connecting-clients.md\nand follow the section for the agent you are running in. If I am working on a codebase, install the\nSignatureAPI plugin (skills plus MCP server) rather than the MCP server alone. Ask me before opening\na browser for sign-in, and never print tokens or keys. When you are done, prove it works by listing\nmy 5 most recent test-mode envelopes, then tell me what you changed and how to undo it.\n```\n\n**Or do it by hand.** There are two install paths. They share the same skill content but are not equivalent — pick\nbased on whether you also want the hosted MCP server (`https://mcp.signatureapi.com/mcp`,\nOAuth-authenticated) configured.\n\n**Cross-runtime** (Claude Code, Codex, Cursor, Copilot, Amp, Antigravity, and others) — installs\nthe two skills only, no MCP configuration:\n\n```bash\nnpx skills add signatureapi/skills\n```\n\n**Plugin install** — installs the same two skills *and* configures the hosted MCP server in one\nstep. Every ecosystem below installs from this same repo root — nothing is mirrored per\necosystem, so the plugin path and the `npx skills` path always carry identical skill content:\n\n| Ecosystem | Install |\n|---|---|\n| Claude Code | `/plugin marketplace add signatureapi/skills` then `/plugin install signatureapi@signatureapi` |\n| Cursor | **Dashboard → Plugins → Add Marketplace**, import `signatureapi/skills`, then **Customize → Install** the `signatureapi` plugin (see [Cursor's plugin docs](https://cursor.com/docs/plugins)) |\n| Codex | `codex plugin marketplace add signatureapi/skills` then `codex plugin add signatureapi@signatureapi`, then `codex mcp login signatureapi` |\n| Grok Build | `grok plugin marketplace add signatureapi/skills` then `grok plugin install signatureapi --trust` (or `/marketplace` inside Grok Build) |\n| Gemini CLI | `gemini extensions install https://github.com/signatureapi/skills` |\n| Any agent-plugins.org-compatible client | Point it at this repo root — `plugin.json` and `mcp.json` follow the [agent-plugins.org 1.0.0 schema](https://agent-plugins.org/specification) |\n\nInstalling the plugin configures the MCP server; SignatureAPI sign-in is a separate step.\nClaude Code reports `! Needs authentication` until you run `/mcp`. Codex's marketplace manifest\ndeclares `policy.authentication: \"ON_INSTALL\"`, so an interactive install may offer the sign-in\nright away; if it does not (a non-interactive install verified on 2026-09-04 did not), run\n`codex mcp login signatureapi`. Gemini CLI's manifest declares `oauth.enabled: true`; run\n`/mcp auth signatureapi` inside Gemini CLI if it does not prompt.\n\nEach plugin install is all-or-nothing: skills and MCP server install and uninstall together.\nThere's no flag to take one without the other, and (for Claude Code) `claude mcp remove` refuses\nto remove a plugin-owned server. If you want the skills without the MCP server, use the\n`npx skills` path instead.\n\nWorking directly in this repo also picks up the MCP server via the checked-in root `.mcp.json` —\nthe same file the Claude Code and Grok Build plugins install elsewhere.\n\n## Skills\n\n- **[signatureapi-integrate](skills/signatureapi-integrate)** — build or change an integration:\n  create an envelope, place signature fields, wire up webhooks, and verify the whole flow end to\n  end against a real test-mode envelope.\n- **[signatureapi-diagnose](skills/signatureapi-diagnose)** — diagnose a misbehaving integration:\n  an envelope stuck in processing, a webhook that never arrived, a recipient who never got the\n  signing email, a missing deliverable, or a validation error on create.\n\nThe two surfaces are kept apart on purpose. The code an agent writes into your application calls\nthe REST API (`https://api.signatureapi.com/v1`); the MCP server and the bundled scripts are the\nagent's own tools for inspecting and proving the flow while it works, and never a runtime\ndependency of your app. The skills inline concepts and gotchas only — field names, enum values,\nevent types and limits are read from the published OpenAPI spec on demand, and a CI test fails\nthis repo whenever an identifier a skill mentions stops existing in that spec.\nEach `SKILL.md` also carries a handful of scripts for the parts an agent shouldn't improvise:\nquerying the OpenAPI spec instead of reading a 108 KB docs page, minting a test document and\ncreating a test envelope, watching for events or receiving webhooks locally, walking a real\nbrowser through a ceremony, and pulling a verdict for a stuck envelope.\n\n## Requirements\n\n- A SignatureAPI key in the `SIGNATUREAPI_KEY` environment variable. Read from the environment\n  only — never pass it as a command-line argument, since argv is exposed in shell history and\n  process listings on any shared or logged system.\n- Node.js 22 or later.\n\n## Safety\n\n- **signatureapi-integrate works in test mode only.** A `key_live_` key is refused, and there is\n  no flag or setting that bypasses this — the capability doesn't exist in the code. Test-mode\n  envelopes are free, watermarked, not legally binding, and send no email to recipients.\n- **signatureapi-diagnose is read-only by construction.** Every script issues GET requests only,\n  and its `allowed-tools` frontmatter restricts it to read-only tools even if a script is added\n  later. It runs against either a test or a live key and reports which mode it resolved, so\n  diagnosing a production envelope during an incident is safe.\n\n## Docs\n\n- Full documentation: https://signatureapi.com/docs\n- Agent router (start here for machine-readable docs): https://signatureapi.com/AGENTS.md\n- OpenAPI spec: https://spec.signatureapi.com/openapi.yaml\n\n## Contributing\n\nIssues and pull requests are welcome: https://github.com/signatureapi/skills\n\nAfter changing a skill's `SKILL.md` frontmatter (name, description) or the\npackage version, run `npm run manifests` and commit every regenerated manifest in the same\nchange — `npm test` fails otherwise. That's every per-ecosystem plugin/marketplace manifest\n(`.claude-plugin/`, `.cursor-plugin/`, `.codex-plugin/`, `.agents/plugins/`, `.grok-plugin/`,\n`gemini-extension.json`, root `plugin.json`/`mcp.json`), the root `.mcp.json`, and\n`agent-skills.json` — all derived from `skills/*/SKILL.md` frontmatter and the `MCP_URL`\nconstant in `generate-manifests.mjs`, never hand-edited. The\n`agent-skills.json` payload is also served from elsewhere (the\n`https://signatureapi.com/.well-known/agent-skills` discovery endpoint), so\nthat redeploy has to happen together with the commit, not sometime after\nit — a stale served copy re-introduces the exact stale-manifest problem\n`npm test` exists to catch.\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n",
  "bytes": 7192,
  "sha": "303fe4e8a69e8c458ad643327e37d6be0c5debd54ec3c4b1db7e4aba1cc2503d",
  "repo_slug": "signatureapi/skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_signatureapi_skills_7d57b889/readme"
}