Templatical
Author Templatical email templates and integrate the
@templatical/editor SDK that renders them, as one router over both jobs. An
authoring session often ends by wiring its result into an application.
Is the request about a template — its content, design, correctness or output — or about the SDK — installing, mounting, configuring or debugging the editor in code?
Unmatched on the template side →
build. Unmatched on the SDK side →docs.
Before the first command of a session, load reference/cli.md. It carries the invocation and the exit-code contract, and no other playbook repeats them.
reference/talking.md governs how you report back, whichever playbook ran.
| Mode | For | Playbook |
|---|---|---|
build | Write a template from a brief | reference/build.md |
edit | Change a template that already exists | reference/edit.md |
import | Convert from another editor | reference/import.md |
validate | Check a template and read the result | reference/validate.md |
export | Render MJML or HTML | reference/export.md |
live | Preview and co-edit in the browser | reference/live.md |
integrate | Mount the editor in an application | reference/integrate.md |
scaffold | Write the integration into their repository | reference/scaffold.md |
diagnose | Fix an integration that misbehaves | reference/diagnose.md |
docs | Answer a question from the SDK reference | reference/docs.md |
Before acting, load the one playbook that owns the request — its row above for an explicit or clearly implied mode, otherwise the default from the discrimination. Load one, not several; each playbook names what it consults.
Out of scope
- Not a Cloud onboarding flow.
initCloud()and its provider contracts are covered; signing up, issuing keys and plan entitlements happen in Cloud's own dashboard. - Never touches git. File changes are the user's to review and commit.


