Generating Contracts with AI

SignStack primitives are structured YAML — an ideal format for AI generation. Describe a contract in plain English, and AI produces the primitives (schemas, assets, templates, functions if needed, blueprint) as working resources.

Across all three paths below, the AI doesn't just emit YAML and hand you a problem — it validates, previews, and iterates on the output before giving you a final result. You get a working contract, not a draft you have to debug.

Three ways to generate. Pick whichever fits how you work.

In Studio

Open the New Contract flow in Studio and describe what you want:

"A consulting services agreement where the company signs first, then the consultant countersigns. Capture name, email, rate, and start date for the consultant."

Studio generates the primitives as drafts and opens them in the preview, ready to iterate on.

In the CLI (using SignStack's AI)

From your terminal, pass the prompt inline:

signstack generate "a consulting agreement where the company signs first,
then the consultant countersigns"

This calls the same hosted AI endpoint Studio uses — the output matches what Studio would produce for the same prompt. Files land in a new folder inside your current directory.

With Your Own AI (SignStack Skill)

If you'd rather let your own AI assistant do the generation — whether it lives in your IDE, a desktop app, or the browser — the flow is two steps:

1. Run signstack skill install once to drop the SignStack Skill files into your project.
2. Prompt your AI to generate a SignStack contract. It reads the skill for the primitives/format knowledge it needs and produces working YAML.

Use this path when you want your existing AI assistant to drive the generation — it already has your codebase context, and the skill gives it SignStack knowledge.

Example Prompts

All three paths accept the same kind of prompt. A few shapes that work well:

Simple contracts:

• "Generate an NDA between two companies with mutual confidentiality obligations"
• "Create a freelance services agreement where the company signs first, then the contractor countersigns"

Multi-document workflows:

• "Generate an employee onboarding package with an offer letter, NDA, and benefits enrollment form. HR signs the offer letter first, then the new hire signs all three documents"
• "Create a SaaS subscription agreement with a master services agreement and an order form. Both the vendor and customer sign the MSA, then the customer signs the order form"

Complex orchestration:

• "Generate a board resolution where 3 board members vote in parallel, and the resolution passes when any 2 approve (quorum)"
• "Create a rental lease where the landlord signs, then tenant and guarantor sign in parallel"

What Gets Generated

For CLI generation, you get a complete project folder with the primitive YAML files and any supporting assets:

agreements/<contract_name>/
├── definitions/           # JSON Schema files for each data entity
│   ├── employee.json
│   └── company.json
├── html/                  # HTML/Handlebars templates for each document
│   └── offer_letter.hbs
├── css/                   # Stylesheets
│   └── styles.css
├── scenarios/             # Test data for preview
│   └── standard.json
├── schema.yaml            # Schema primitives
├── asset.yaml             # Asset primitives
├── template.yaml          # Template primitives
├── function.yaml          # Function primitives (if the contract logic needs them)
└── blueprint.yaml         # Blueprint primitive

In Studio, the primitives land directly in your namespace as draft resources you can preview and publish.

After Generation

The CLI operates per resource — point it at the blueprint and it walks the whole dependency graph:

# Validate the blueprint and every primitive it depends on
signstack validate <blueprint_key>@1.0.0

# Preview the rendered PDF
signstack preview <blueprint_key>@1.0.0

# Deploy (pushes blueprint and its dependencies in order)
signstack push <blueprint_key>@1.0.0

# Run with test data
signstack run <blueprint_key>@1.0.0 --scenario standard

Updating Existing Contracts

AI isn't just for starting fresh. Point it at an existing contract and ask for a change — "add a manager approval step for deals over $100k", "swap the signer order", "add an NDA envelope" — and AI reads the current primitives, applies the change, and returns the updated YAML.

• In Studio — open the contract and describe the change in the AI chat.
• In the CLI — signstack modify <blueprint_key>@<version> "<change>" targets a specific blueprint (and walks its dependency graph for the AI's context). Uses the same hosted AI as Studio.
• With your own AI (Skill) — with the skill installed, tell your AI to update the SignStack primitives in your project.

Across all three paths, AI validates and previews the updated contract before returning it. You get working output.

Customizing Generated Output (By Hand)

The generated YAML is standard SignStack primitives. Customize it the same way you would hand-written YAML:

• Edit schemas to add or remove entity fields
• Modify HTML templates for layout and content changes
• Adjust how data maps to the document — data.transform for HTML templates, per-field value expressions for PDF templates
• Restructure blueprint orchestration for different signing flows (parallel, conditional, quorum)
• Add custom functions for complex business logic

After making changes, run signstack preview <blueprint_key>@1.0.0 to render the document or signstack run <blueprint_key>@1.0.0 --scenario standard for a full end-to-end check.

Don't Need to Start from Scratch?

For common contract types, fork a starter from the Library instead of describing one from scratch. Try to run a listing as-is, Customize to fork it into your namespace as an editable draft.