DocsQuick StartsSolo Developer Quick-Start

Solo developer quick-start

Your agent is acting on your behalf. Make it count.

In 30 minutes, your Claude Code (or Cursor) instance has live policy context, attestable artifacts checked into git, and verifiable evidence anyone can audit.

Claude Code, Cursor, your CI bot — they're doing work in your name. Right now, no one outside your laptop can verify what they're allowed to do, what they actually did, or which policies they followed. That changes in five steps.

Each step is small. Each step builds on the last. By the end, you have one real attestation live in your tenant, the workflow to make more, and a clear picture of what's coming.

3 min

Connect Claude Code to Dictiva.

Sign up at dictiva.com/sign-up. Provision an API key — the API Keys guide walks you through the dashboard path, or use the fast path documented in the MCP server guide.

Drop this .mcp.json at your project root:

{
  "mcpServers": {
    "dictiva-governance": {
      "type": "streamable-http",
      "url": "https://dictiva.com/api/mcp",
      "headers": { "Authorization": "Bearer dv_live_..." }
    }
  }
}

Verify the connection:

claude mcp list
# dictiva-governance ... ✓ Connected
What just happened:

Your agent now has live read access to your tenant's governance graph. The MCP server exposes ten tools — search_statements, get_statement_guidance, list_applicable_policies_for_actor, attest_statement, list_my_attestations, and five more.

2 min

Find the policies that apply to your agent.

From inside Claude Code, ask:

Use the dictiva-governance MCP to list applicable policies for an agent.

Claude calls list_applicable_policies_for_actor with actor_type: "agent". The response is a tight list — only statements scoped to agents, only the enforcement modes you can actually act on:

{
  "data": [
    {
      "displayId": "AAG-007",
      "title": "Agents must declare adopted standards",
      "enforcementMode": "machine_readable",
      "applies_to": "agent",
      "actor_scope": "agent-workflow"
    },
    { "displayId": "AAG-014", "title": "Code-reviewer agents commit to review SLA", "...": "..." }
  ]
}

Pick one statement to commit to. Note its displayId — you'll reference it in the next step.

What just happened:

No static rule list. No PDF. Your agent reads the live policy surface and gets back exactly the rules that constrain it. This is what "policies your agents can follow" means.

5 min

Author your first attestable artifact.

Pick one of three patterns, depending on where the work lives. The artifact's content becomes the evidence — its existence in your repo is the claim that you're committing to the named statement at the declared tier.

Pattern A — A skill (.claude/skills/<name>/SKILL.md):

---
name: my-skill
description: ...
attests: AAG-007 tier=T1
---

Pattern B — A memory file (memory/<name>.md or .claude/memory/<name>.md):

---
name: my_memory_entry
description: ...
type: feedback
attests: AAG-007 tier=T1
---

Pattern C — An AGENTS.md section (anywhere in your repo). Since AGENTS.md has no file-level frontmatter, the convention is an HTML-comment marker immediately above a section heading:

<!-- attests: AAG-007 tier=T1 -->
## My agent's working conventions

This agent operates under...

The grammar is the same in all three: <statementRef> tier=T<n>. Multiple statements stack — use a YAML list (attests: [AAG-007 tier=T1, AAG-014 tier=T1]) or repeat the HTML marker. The full grammar is in the authoring guide.

What just happened:

Your prose just became something an agent can read and a verifier can check. The artifact is checked into git, signed by your commits, and travels with your code.

10 min

Issue your first attestation.

Two paths. Pick the one that fits your workflow.

Path A — Live, from Claude Code. Ask Claude to call attest_statement:

Use dictiva-governance to attest_statement for AAG-007 at tier T1, with my skill at .claude/skills/my-skill/SKILL.md as evidence. My agent DID is did:web:example.com:agents:agent-my-claude.

The MCP tool issues a signed W3C Verifiable Credential and returns the attestation id immediately. This path needs a Business plan or higher (MCP-tool access) and a registered agent identity in your tenant.

Path B — Via commit trailer. Add this line to the trailing block of your commit message:

Attests: AAG-007 tier=T1 evidence=.claude/skills/my-skill/SKILL.md

Canonical grammar (matches the parser at webapp/src/lib/attestation/attests-trailer.ts):

^Attests:\s*([\w-]+)\s+tier=(T[1-6])(?:\s+evidence=(\S+))?\s*$

The trailer must be on its own line in the commit body's trailing block — the same convention as Co-Authored-By: or Signed-off-by:. When the merged-PR webhook lands (currently founder-gated, shipping shortly), each Attests: line creates a draft credential in your tenant's drafts inbox; you finalize with one click.

A note on tiers: T1 is plausible from this workflow today. T2 requires a semantic_similarity_report artifact that links your prose to the statement — that tooling hasn't shipped yet. T3 (Referenced) and T4 (Procedural) are reachable when your skill, memory file, or ADR demonstrably codifies the commitment. T5 and T6 require scope expressions and runtime enforcement; they typically come from infrastructure, not solo authoring.

What just happened:

Every commit can now speak to your governance. The credential is signed, has an expiry, and can be revoked. Anyone — your auditor, your customer, your future self — can verify it without trusting Dictiva.

1 min

See your evidence.

From Claude Code:

List my attestations from the dictiva-governance MCP, filtered to my agent.

Calls list_my_attestations. The response shows your live credentials, their tiers, the evidence you submitted, expiry, and revocation status:

{
  "data": [
    {
      "id": "uuid-...",
      "subjectDid": "did:web:example.com:agents:agent-my-claude",
      "statementDisplayId": "AAG-007",
      "commitmentTier": "T1",
      "issuedAt": "2026-04-27T...",
      "expiresAt": "2027-04-27T...",
      "evidence": [{ "evidenceKind": "skill", "reference": ".claude/skills/my-skill/SKILL.md" }]
    }
  ]
}

Or open the attestation page on your tenant: Workbench → Attestations.

What just happened:

This is what an auditor, a customer, or a downstream service can point at. No screenshots. No vibes. A signed credential with an evidence chain, traceable to the statement, traceable to your agent.

What you just unlocked

Three things are now true that weren't true 30 minutes ago.

  1. Your agent has a live policy context. It reads from your tenant, not a stale prompt. New statements you author show up automatically.
  2. Your artifacts are evidence. Skills, memory files, and AGENTS.md sections aren't just documentation — they're attestation-bearing.
  3. Your commits are auditable. Every Attests: trailer leaves a forensic trail an auditor can verify without trusting your platform — or ours.

What's coming (and what's not yet self-serve)

Today, MCP write access requires a Business plan or higher and the agent identity (subjectDid) must already exist in your tenant. Both are landing in self-serve form on a near-term roadmap:

  • GitHub App auto-ingestion — your merged PR's Attests: trailers turn into drafts automatically, no manual API call. Founder-gated today, shipping shortly.
  • Self-serve agent identity registration — register an agent for your tenant from the dashboard, get its DID and signing key in one click. Coming.
  • Free-tier read accesssearch_statements and list_applicable_policies_for_actor available to Community-tier accounts so you can browse before you commit. Coming.

If you hit a wall on any step, the PCA overview covers the underlying model and the authoring guide on GitHub covers every grammar detail.

Next door

You shipped attestations from your laptop. The person responsible for governance in your org now needs to see and trust them — that's the next quick-start.