Documenso Ci IntegrationSAFE
Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.
Overview
Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.
4f83675ca38aOBSERVED · 2026-10-08Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: documenso-ci-integration description: 'Configure CI/CD pipelines for Documenso integrations. Use when setting up automated testing, deployment pipelines, or continuous integration for Documenso projects. Trigger with phrases like "documenso CI", "documenso GitHub Actions", "documenso pipeline", "documenso automated testing". ' allowed-tools: Read, Write, Edit version: 1.14.0 license: MIT author: Jeremy Longshore <[email protected]> tags: - saas - documenso - deployment - testing - ci-cd compatibility: Designed for Claude Code --- # Documenso CI Integration ## Output - A credential-free pull-request lane for schema/template/unit checks and a trusted, scoped development integration lane. - A redacted CI receipt with validation outcome and a safe failure/retry procedure. ## Examples Run template/schema/unit checks on every pull request using synthetic documents and signers, then execute one protected-branch development integration check with a scoped secret. If it fails, retain redacted correlation/status evidence; never expose signing credentials, document payloads, or production workspace access to forked CI code. ## Overview Configure CI/CD pipelines for Documenso integrations with GitHub Actions. Covers unit testing with mocks, integration testing against staging, and deployment workflows with secret management. ## Prerequisites - GitHub repository with Actions enabled - Documenso staging API key - Test environment configured (see `documenso-local-dev-loop`) ## Instructions ### Step 1: GitHub Actions Workflow ```yaml # .github/workflows/documenso-ci.yml name: Documenso CI on: push: branches: [main, develop] pull_request: branches: [main] env: NODE_ENV: test jobs: unit-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm test # Unit tests use mocks — no API key needed integration-tests: runs-on: ubuntu-latest if: github.event_name == 'push' # Only on push to main/develop needs: unit-tests steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm run test:integration env: DOCUMENSO_API_KEY: ${{ secrets.DOCUMENSO_STAGING_API_KEY }} - run: npm run test:cleanup # Remove test documents env: DOCUMENSO_API_KEY: ${{ secrets.DOCUMENSO_STAGING_API_KEY }} if: always() ``` ### Step 2: Unit Tests with Mocked SDK ```typescript // tests/unit/document-service.test.ts import { describe, it, expect, vi, beforeEach } from "vitest"; import { createMockClient } from "../mocks/documenso"; import { DocumentService } from "../../src/services/document-service"; describe("DocumentService", () => { let service: DocumentService; let mockClient: ReturnType<typeof createMockClient>; beforeEach(() => { mockClient = createMockClient(); service = new DocumentService(mockClient as any); }); it("creates document with recipients and sends", async () => { const result = await service.createAndSend({ title: "Test Contract", pdfPath: "./fixtures/test.pdf", signers: [{ email: "[email protected]", name: "Test User" }], }); expect(mockClient.documents.createV0).toHaveBeenCalledWith({ title: "Test Contract" }); expect(mockClient.documentsRecipients.createV0).toHaveBeenCalled(); expect(mockClient.documents.sendV0).toHaveBeenCalled(); expect(result.documentId).toBe(1); }); it("handles API errors gracefully", async () => { mockClient.documents.createV0.mockRejectedValue( Object.assign(new Error("Unauthorized"), { statusCode: 401 }) ); await expect(service.createAndSend({ title: "Test", pdfPath: "./fixtures/test.pdf", signers: [], })).rejects.toThrow("Unauthorized"); }); }); ``` ### Step 3: Integration Tests Against Staging ```typescript // tests/integration/document-lifecycle.test.ts import { describe, it, expect, afterAll } from "vitest"; import { Documenso } from "@documenso/sdk-typescript"; const client = new Documenso({ apiKey: process.env.DOCUMENSO_API_KEY! }); const testDocIds: number[] = []; describe("Document Lifecycle (Integration)", () => { it("creates a document", async () => { const doc = await client.documents.createV0({ title: "[CI-TEST] Integration Test", }); testDocIds.push(doc.documentId); expect(doc.documentId).toBeGreaterThan(0); }, 30000); it("lists documents", async () => { const { documents } = await client.documents.findV0({ page: 1, perPage: 5 }); expect(documents.length).toBeGreaterThan(0); }, 15000); afterAll(async () => { // Cleanup: delete test documents for (const id of testDocIds) { try { await client.documents.deleteV0(id); } catch { console.warn(`Cleanup: could not delete document ${id}`); } } }); }); ``` ### Step 4: Add Secrets to GitHub ```bash # Using GitHub CLI gh secret set DOCUMENSO_STAGING_API_KEY --body "api_stg_xxxxxxxxxxxx" gh secret set DOCUMENSO_WEBHOOK_SECRET --body "whsec_xxxxxxxxxxxx" # Verify secrets exist gh secret list ``` ### Step 5: Package.json Scripts ```json { "scripts": { "test": "vitest run tests/unit/", "test:integration": "vitest run tests/integration/ --timeout 60000", "test:cleanup": "tsx scripts/cleanup-test-docs.ts", "test:all": "npm test && npm run test:integration" } } ``` ### Step 6: Pre-commit Hook (Optional) ```bash # .husky/pre-commit npm test -- --run ``` This runs unit tests (with mocks) before every commit, catching issues early without needing API access. ## CI Strategy Summary | Test Type | Runs On | API Key Needed? | Speed | |-----------|---------|-----------------|-------| | Unit tests (mocks) | Every pus
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | PASS |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
4f83675ca38afull audit observations/trust-audit/skill/jeremylongshore__documenso-ci-integration.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-08 | 4f83675ca38a | SAFE | B | 89 | first audit |
Questions
What does the Documenso Ci Integration skill do?
Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.
Is Documenso Ci Integration safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Documenso Ci Integration access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Documenso Ci Integration work with?
Its documentation mentions claude-code. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (4f83675ca38a), read on 2026-10-08. The repository is watched, and a new audit runs when it changes — this is the first audit.