Skip to content

GND · Get Nick Done · agent skills + Python

Build agentic data apps that check themselves.

Inspired by the success of GSD (Get Shit Done) for traditional software development, GND is its lighter sibling, built specifically for agentic data apps.

Describe your domain once as an executable ontology: an ORM model of facts, rules and constraints. Your agent answers with structured plans and facts instead of prose, and GND verifies them against the model and reports exactly which rule failed.

Build with your agent Run a check in 60 seconds

An agent's plan checked by GND Asked to reimburse expense 41, the agent proposes a plan that pays it directly. GND checks the plan against the model: the pre_submitted precondition fails and pre_has_approver warns. With that feedback the agent adds the approval and Workday steps; the revised plan passes and the expense is paid. CODING AGENT GND · YOUR MODEL Reimburse Ada's €90 team dinner, expense 41. plan.steps.json · draft 1 plan.steps.json · draft 2 pre: state.pop.yaml then: pay if accepted steps: - reimburse_expense(41) + - approve_expense(41, approver=alice) + - submit_expense_to_workday(41) - reimburse_expense(41) approvals.orm.yaml 3 operations approve_expense requires: draft submit_expense_to_workday requires: approved reimburse_expense requires: submitted · approver on file check $ gnd check --pre state --steps plan report pre_submitted step 1 · reimburse_expense · alethic pre_has_approver warning exit 1 · plan rejected feedback 3 steps · every precondition holds post-state computed exit 0 · plan accepted Paid: expense 41 reimbursed Build agentic data apps that check themselves. GND · Get Nick Done · inspired by GSD
You ask for a payment. The agent answers with a plan: operations over the model, not prose. GND checks the plan, names the precondition that failed, and the agent resubmits a plan that passes. Run this example yourself → · Build an app like it, with real recorded sessions →

Share and reuse ontologies with Apache Ossie

GND imports and exports Apache Ossie ontology files. Start a GND model from an ontology your team already uses, or share your GND model's business concepts and relationships with another team or tool.

See what GND carries across · Try it with the refunds model

How it works

01 / ONTOLOGY

State the rules once. Write them as an ORM model, model.orm.yaml. An agent drafts it with you through Halpin's conceptual schema design procedure, and every rule reads back as a sentence you can confirm.

02 / STRUCTURED OUTPUT

The agent answers in facts. It replies with populations and operation plans, such as approve_expense(41, approver=alice) or recommendation(ada, river), never paragraphs you have to trust.

03 / VERIFY AND FEED BACK

GND decides. gnd check evaluates every constraint: pass, a failed rule with the offending facts, a warning, or cannot decide. Closed feedback goes back to the agent; no answer key leaks.

Because the checker is deterministic, a cheaper model is safe to try: a wrong plan is rejected and retried inside a bounded session, never trusted. In our recorded sessions on one task, a 4B model that never succeeded on its first try was still accepted in two of three bounded sessions, and the checker confirmed the failure when a 3B model did not converge, so you know the final state either way. Claude Code, Codex, any declared command or any OpenAI-compatible endpoint can be the agent (sessions).

The loop, step by step

  1. Write the rules in plain English, in a file such as rules.md.
  2. Model them. /gnd:gnd-model-from-text rules.md reads each rule, asks when a rule could mean two things, and validates the model.
  3. Set up the bot. Any model behind a command can answer; the plan apps show the interface, and /gnd:gnd-codegen builds a project for your own model.
  4. Ask the bot a question in your own words.
  5. It proposes a plan: named operation steps, not prose.
  6. GND checks the plan against every rule, state by state, and names the rule that fails and the facts that break it.
  7. Execute or repair. An accepted plan runs. A refused plan goes back to the bot with the feedback, and it tries again.
  8. Change a rule. /gnd:gnd-model-evolve edits the model; the next plan is checked against the new rule.

Quickstart

In Claude Code, install the plugin:

/plugin marketplace add vasiloglou/gnd-public
/plugin install gnd@gnd-marketplace

Then follow the course planner tutorial. It uses recorded sessions of Claude Code and of small models, so you see what each one actually did. PyRel is optional: GND's own checker needs nothing else. If your data lives in Snowflake, see what PyRel is: you can prototype the same rules locally on DuckDB; Snowflake execution is not yet supported by gnd export.

Learn by building

Kind Pages
Tutorials Build a course planner, Refill prescriptions on a schedule
How-to guides Access requests, Trip budget, Rent schedule, Recorded model runs
Explanation What PyRel is, and when you need it, How a rule becomes a PyRel check

One model in the middle

An exclusion constraint in ORM 2 notation User and Book are joined by two fact types, 'is recommended' and 'rated'. A circled cross connected to both role pairs says no pair may appear in both. ORM 2 · EXCLUSION User (.id) Book (.id) … is recommended … … rated … The circled cross: no (user, book) pair may be both recommended and rated.

GND's intermediate representation is Object-Role Modeling (ORM 2), Terry Halpin's fact-based conceptual modeling method. Every requirement becomes an elementary fact type with explicit constraints, and each constraint reads back as a plain sentence a domain expert can confirm. The diagram says no reader is recommended a book they already rated. GND's checker, synthetic data, code generation and exports all read that same model.

Learn the notation · ORM Foundation · ORM 2 graphical notation

ORM as the intermediate representation Requirements text, existing code, a GSD project or an existing ORM model become one model.orm.yaml. Checking, synthetic data, code generation, verbalization, evolution and exports all read that model. ONE MODEL IN THE MIDDLE Requirements in text gnd-model-from-text Existing code gnd-model-from-code A GSD project gnd-adopt An existing ORM model gnd import rai-orm check · verify facts, plans, derived claims synth · measure test data, verifier rates codegen · conformance the Python project verbalize rules as sentences evolve · diff reviewed change export Soufflé · Lean · PyRel model.orm.yaml the executable ontology facts · constraints modality · provenance operations · derivations ORM 2

Coming from GSD?

GND keeps GSD's discipline (plan, execute, verify, record) and its skills-in-your-agent packaging. It replaces the requirements document with an executable model, so a phase is done when the model's checker says so. Already have a GSD project? The gnd-adopt skill migrates your .planning/ requirements into a GND model, with every requirement accounted for. Adopt a GSD project →

GND is skills plus Python code

The skills tell a coding agent what to produce: a model, a population, a plan, a session contract, an evolution proposal. The Python runtime checks what it produced. The skills follow the Agent Skills format and install into both agents:

Claude CodeCodexAgent Skills formatPython ≥ 3.11

uv tool install get-nick-done==0.2.0
uv tool update-shell

Open a new shell, then choose the Claude Code plugin, Codex plugin, or direct skill installation. The guide also covers installation with pip.

Ask your agent to… Skill It produces GND checks it with
Model a domain by dialogue gnd-model-from-text model.orm.yaml + verbalization gnd validate
Propose a plan your application's skill steps.json gnd check --pre --steps
Work until the checker accepts gnd-dev-session attempts under a session contract gnd exp run
Generate the project gnd-codegen derived tools + your extension gnd conformance
Change a rule gnd-model-evolve a reviewed proposal gnd evolve preview / apply
Read or write documents gnd-extract, gnd-render-doc facts with a digest-bound sidecar gnd verify, gnd doccheck
Export or get a review gnd-export, gnd-review-panel Soufflé, Lean, witnesses, a panel review gnd replay, gnd review finalize

What GND catches

PLANS

A step was skipped

The agent tries to pay a draft expense. reimburse_expense fails its precondition pre_submitted; the agent adds the missing steps.

Check an agent's plan →

SIDE EFFECTS

An approval also flipped a bystander expense to rejected. No snapshot check can see it; the frame check fails the walk.

The frame check →

HARD RULES AND ADVICE

Already read

A recommender suggests a book Ada rated. unread_only fails and names the pair; a genre mismatch is only a warning.

BookRec, chapter 2 →

THE LOOP

Attempt 1 red, attempt 2 accepted

A session contract, closed answer-free feedback, and explicit outcomes: accepted, stagnation, oscillation, budget exhausted.

Drive an agent →

RULE CHANGES

The same output, two model versions: an advisory rule promoted to a hard one rejects yesterday's recommendations, with a blast-radius preview first.

BookRec, chapter 6 →

DERIVATIONS

Did it recommend everything eligible?

Derived fact types with stratified negation. GND names the eligible pair the application missed, and the claimed pair it should not have made.

Derivations →

TEST THE TESTER

Measure the verifier itself

gnd synth generates conforming, boundary and violating populations; gnd measure reports false-pass and false-fail rates per constraint.

Synthetic data →

DOCUMENTS

Facts in, facts out

Render a document from facts with planted distractors, one of them instruction-shaped, then extract the facts back and check both directions.

Documents →

ENGINES

Three engines, one model

Trace vulnerable dependencies in Soufflé, prove a finite policy in Lean, and audit approvals with PyRel.

Verify at scale →

See every capability in the tour →

Verify at the scale you need

GND engine (default)

Lightweight, portable native Python. No database, no service, and three-valued verdicts: unknown never becomes yes or no.

Soufflé

gnd export souffle writes a standalone Datalog program for recursive impact analysis at scale. Tutorial

Lean

gnd export lean writes finite definitions and explicitly unproved obligations; prove them, or find a counterexample. Tutorial

PyRel (optional)

gnd export pyrel writes a standalone PyRel program that runs locally on DuckDB. Snowflake execution is not yet supported by gnd export. Tutorial

Choose your path

You want to… Start here
Understand the ontology, facts and constraints ORM: the executable ontology
See a useful failure in a few commands Run a check in 60 seconds
Build with Claude Code or Codex Work with an agent
See every feature with an example Capabilities tour
Add checks to existing Python code Python API
Find out whether a feature fits your problem Supported capabilities
Improve GND itself Contributor guide

A passing check means the supplied facts satisfy the modeled rules. GND verifies the output, never the producer; you still choose the rules and establish that the facts describe the world. Public builds report assurance as unavailable. The core checker runs locally and the tutorials need no model-provider key. Native Soufflé, Lean and PyRel execution are optional and have their own prerequisites; Snowflake execution is not yet supported by gnd export.