Write intake agents can act on

Agents are only as good as what you give them. This page is about the writing itself: where it goes, which level it belongs at, and what separates a line that changes the output from a line that does not.

Put it in the right place

Taiga has four places to write things down, and they are not interchangeable.

Where	What belongs there
Spec	What you are building. The requirements for this project.
Policies	The rules. Compliance and governance your work is checked against.
Knowledge	Reference material. Files agents retrieve from when they need the detail.
Instructions	How you build. The standing house style that applies to everything.

The distinction that trips people up is Spec against Instructions. The Spec is what this one thing does. Instructions are what is true of everything you build, which is why they are written once and inherited rather than restated per project.

Choose the right level

Instructions and knowledge exist at three levels, and each inherits from the one above.

Scope	What belongs there
Organization	The house style every team inherits.
Team	This team’s domain, stack and standards. Inherited by every project in the team.
Project	The specifics of this codebase. The narrowest, most specific layer.

Write it as high as it is true and no higher. A rule that belongs to one codebase, written at the organization, becomes a constraint on every project you will ever create. A rule that is genuinely universal, written per project, is one you will forget to repeat.

Six things worth writing

Replace a preference with a decision, and a description with something an agent can check its own work against.

Strategy	Instead of	Write
Say who you build for	“We build healthcare software.”	“We build clinical documentation tools for hospital nurses. Optimize for speed and interruption recovery.”
State defaults, not opinions	“We prefer modern tooling.”	“Default to TypeScript, Postgres, and AWS managed services. Add a new language or datastore only with clear justification.”
Make the standing expectation explicit	“Quality matters to us.”	“Every plan includes observability and a rollback path. Prefer incremental, flag-guarded delivery.”
Give your domain its vocabulary and rules	“We handle payments.”	“We own Payments. Money is always integer minor units; capture and authorization are distinct.”
Define done	“Ship high-quality endpoints.”	“Every endpoint ships with an integration test and an OpenAPI entry.”
Draw the guardrails	“Be careful around auth.”	“Internal admin tool. Skip onboarding, marketing, and SEO. Do not touch the legacy /auth module.”

Then add the one nobody writes down: the gotcha.

“Staging shares the prod schema; every migration must be backward-compatible in one release.”

That kind of constraint is invisible in the code and obvious to everyone on the team, which is exactly why it never gets written and exactly why an agent violates it. If a new engineer would need to be told, write it down.

What makes a line work

It is falsifiable. Someone reading the output can tell whether it was followed. “Write clean code” cannot be checked. “Every endpoint ships with an integration test” can.

It names the thing. Real module paths, real library names, real table names. Agents read your repository, so a specific reference connects to something they can find.

It says what not to do. Scope is where agents overreach, so a module left alone or a concern ruled out of this product is among the most useful things you can write.

It survives repetition. Instructions apply to everything. Anything true only of the work in front of you belongs in that work’s description.

Answering in Discovery

Discovery is a conversation, so the advice is different. You do not need to prepare anything or know the vocabulary. Answer in your own words.

The one habit worth building: say when something is undecided. An unanswered question leaves a hole in the specification that you can see. A confidently guessed answer leaves one you cannot, and everything generated afterward is built on it.