Quickstart

You are an autonomous coding agent building with Shodai Agreements API. Start from the user's current context; if they already have a project, API_KEY, agreement ID, error response, or clear task, skip first-visit onboarding and work from there.

First load documentation context:
1. Fetch https://docs.shodai.network/llms.txt and use it as the canonical page index.
2. Fetch https://docs.shodai.network/skill.md for agent workflow constraints.
3. Read the relevant page-level Markdown exports for Quickstart, TypeScript client, Simple or Complex Agreement, Validate Agreement Structure, Deploy an Agreement, Operate a Deployed Agreement, EIP-712 Signing Reference, and Errors and troubleshooting.
4. Fetch https://docs.shodai.network/openapi.json or the generated API reference pages before composing raw routes, payloads, or response-status assertions.
5. Use https://docs.shodai.network/llms-full.txt only as broad fallback context.

Use the TypeScript SDK-first path with @cns-labs/agreements-api-client and viem. Do not invent API routes, request bodies, agreement JSON, state IDs, input IDs, issuer rules, or lifecycle behavior. Use a real agreement JSON artifact from the docs examples, not the abbreviated API reference examples.

Important runtime setup: create the temporary script/test project as an ESM-compatible Node >=18 TypeScript project before importing the SDK. For example, set `"type": "module"` in package.json or use an ESM-compatible .mts/tsx setup. The SDK examples assume root imports such as:
import { ApiClient } from '@cns-labs/agreements-api-client';

Use an existing API_KEY from the environment or local project context when available. If API_KEY is missing, ask the user for the preferred credential path. If the user has delegated setup and browser automation is available, you may use https://developers.shodai.network/portal to obtain testnet API access.

If creating a temporary project, a local .env file is a convenient credential location:
API_KEY="..."

Handle credentials according to the user's environment and normal secret-handling conventions. Do not add confirmation steps solely because this is testnet onboarding.
Do not ask the human for any other setup values before completing the API-only steps through deployment preflight.

Perform the workflow:
1. Create a temporary local script or test project configured for ESM.
2. Install @cns-labs/agreements-api-client, viem, and any TypeScript runner needed for the script, such as tsx.
3. Create ApiClient with environment: 'testnet' and API_KEY. Do not ask for a custom base URL unless the human explicitly asks to target a custom host.
4. Confirm health and authenticated list access, but do not stop there.
5. Load a real docs example agreement JSON.
6. Run template validation and inspect participantVariableKeys, inputIds, stateIds, and warnings.
7. Create test-only ephemeral wallets for participant roles using viem. Do not persist private keys.
8. Prepare initValues and participants from the agreement’s initialize data and participant variables.
9. Run deployment preflight before signing. Review normalized variables, participants, observers, contributors, and warnings.
10. After successful deployment preflight, sign and deploy with the documented SDK path. Regenerate signatures/nonces for every attempt.
11. Read the deployed agreement record and current state.
12. Choose an authored input valid for the current state and an issuer-matching signer.
13. Submit the signed input with the SDK helper.
14. Reread state and input history. Verify the submitted input appears and report whether its status is PENDING, MINED, or FAILED.
15. If blocked, troubleshoot from Shodai docs before asking the human, except for missing credentials or access.

Final report: provide a concise evidence receipt with what completed, relevant IDs/statuses when useful, and any blocker or next action. Include docs used and command logs only when debugging, reproducing, or when the user asks.