Docs / Concepts

Templates

A template is a reusable starting point for a recurring kind of work, such as a CRUD endpoint, a webhook handler, or a data migration. Starting a feature from one pre-fills the definition form with sensible structure, so authors don’t face a blank page.

A template only ever shapes the definition: the goal, scope, acceptance criteria, and constraints an author would otherwise type from scratch. Everything downstream (the analysis, the canvases, the reviews) runs exactly as it would for any feature; the template just gives the author a stronger first draft to refine.

System and org templates

Templates come from two places, and both appear together on the Templates page (reachable from the sidebar), filterable by category and searchable by name or description:

System templates: A built-in set maintained by REEZN, marked “By REEZN.” They cover common patterns (a CRUD endpoint, a webhook handler, a background job, a data migration, an auth flow, and a reporting endpoint) and are available to every organization out of the box. They can’t be edited or deleted; they are the same for everyone.
Org templates: Templates your organization creates for the way you describe your own recurring work. They sit alongside the system set, tagged “Org” and attributed to whoever created them, and behave identically when used.

What a template carries

A template has three top-level fields plus a block of pre-fill content. The name, category, and description are what you see on the template card and in preview; the pre-fill is what lands in the definition form when the template is used.

Name: A short label for the pattern, for example “Reporting endpoint.” Shown on the card and searchable.
Category: One of API, Integration, Worker, Data, Identity, or Domain, used to group and filter the template list.
Description: A one- or two-line summary of what the pattern is for, shown on the card and at the top of the preview.
Pre-fill: The definition content the template seeds: a goal, optional business value, scope in and scope out, acceptance criteria as Given / When / Then, and constraints. These map one-to-one onto the fields of the new-feature form.

Pre-fill text often uses angle-bracket placeholders like “Expose <resource> via CRUD endpoints,” marking the parts an author is expected to replace with the specifics of their feature.

Who can create org templates

Only org admins can create, edit, or delete org templates; everyone else can browse the library and use any template. (System templates can’t be edited by anyone.) Keeping authorship with admins means the library stays a deliberate, curated set of “the way we describe this kind of work” rather than a sprawl of one-offs.

Starting a feature from a template

There are two ways in, and both lead to the same place: a new-feature definition form with the pre-fill already applied:

From the Templates page, preview a template to see exactly what it pre-fills, then choose Use. If your org has more than one project, you pick which project to create the feature in first.
From the new-feature form itself, choose Use template to pick one from a side panel and apply its pre-fill in place.

Applying a template fills the goal, business value, scope in, scope out, acceptance criteria, and constraints. It does not set the feature title, services, or personas; those stay for the author to choose. Every pre-filled field is fully editable before you submit, so a template is a head start, not a cage.

A template only pre-fills a brand-new feature. Editing an existing feature, or creating a new version, carries that feature’s own definition forward instead, so templates don’t apply there.

Why this exists

Consistent inputs produce consistent plans. Templates encode “the way we usually describe this kind of feature,” so the quality of an analysis doesn’t hinge on who happened to write the first draft, and the recurring scope, criteria, and constraints that are easy to forget are captured by default.