Start

Introduction

Tinka is a web framework for Go: a small Core plus opt-in first-party packages that share one design language. It takes its sense of a complete, coherent framework from AdonisJS and Laravel, and its restraint from Leaf, but it is designed from first principles for Go and for a world where agents write most of the code and people review it.

Why another Go framework

Go’s standard library already serves HTTP well, so most Go web projects assemble their own stack: a router here, a validation library there, configuration and migrations wired by hand. Every team makes the same small decisions differently, and every agent working in those projects has to rediscover them.

Tinka makes those decisions once. A Tinka App has one way to define routes, one way to read configuration, one way to write a Command, and the same patterns for errors and tests across every package. Strong conventions are the product: they let a person review a change quickly and let an agent get it right the first time.

How Tinka is built

Tinka builds on the standard library instead of hiding it. Handlers work with net/http, cancellation flows through context, and logging goes through log/slog. Nothing runs before go build, and no wrapper sits around go test or go run, so Tinka never slows down the Go toolchain you already use.

Everything beyond Core is a first-party package you import on purpose. An App compiles only the packages it uses, and the core module itself has no dependencies.

Built for agents

Every Tinka Command answers people with readable text and answers agents with a single JSON object, detected automatically. Every docs page has a Markdown twin at the same address plus .md, written for agents to read. The philosophy explains the principles behind these choices.

What exists today

Tinka is in early alpha. Today it ships the Tinka CLI, with tinka version and Agent mode for every Command. Core (HTTP, configuration and lifecycle) and tinka new with Starter kits come next.

Next, install the Tinka CLI.