Custom Spec Template Marketplace
A spec template marketplace is a Git-backed source thattrellis init --registry
can read when a team wants the same .trellis/spec/ starting point across many
repositories.
Use it for reusable engineering conventions: framework layout, API patterns,
testing rules, release rules, review checklists, and the examples that your
agents should see before writing code. Do not use it as a remote task store or
as a place for project-private runtime state.
Runtime model
trellis init --registry <source> parses <source> as a GitHub, GitLab, or
Bitbucket source, then probes for index.json inside that source path.
Source format:
Repository shape
A common layout is:.trellis/spec/. Do not wrap them in an extra spec/ folder unless you really
want .trellis/spec/spec/... after install.
The inner folder names are your convention. Trellis does not require
frontend/, backend/, shared/, or guides/; those are common because agents
can load focused specs more reliably when large rules are split by area.
index.json contract
index.json lives at the registry source path. In the layout above, users point
--registry at gh:myorg/my-spec-marketplace/marketplace, so Trellis reads:
The important detail is
path: it is relative to the repository root, not
relative to the index.json file.
Authoring workflow
- Start from an existing template or create a new directory under
marketplace/specs/<id>/. - Put reusable rules in topical files. Keep package-specific examples real, but remove project-only assumptions.
- Add or update local
index.mdfiles if the folder uses them as navigation for agents. - Add the template entry to
marketplace/index.json. - Test from a throwaway repository before publishing the template.
.trellis/spec/ files. The template
is a starting point, not a live remote wiki. Teams should edit the installed
specs so they match the actual repository.
What belongs in a spec template
Good template content:- Directory and module conventions for the stack.
- API, database, state, testing, and error-handling rules.
- Examples copied from real projects after removing private names and secrets.
- Review checklists that agents should apply before finishing work.
- Short guides that explain cross-layer tradeoffs for the stack.
- Secrets, internal URLs, customer data, or private incident details.
.trellis/tasks/,.trellis/workspace/, or active task state.- Platform prompt files such as
.claude/,.codex/,.cursor/, or.opencode/. Those belong in Trellis platform customization, not spec templates. - Product PRDs that only make sense for one repository.
Versioning and rollout
Treat template ids as public API for your team. If you need a breaking rewrite, publish a new id such asweb-app-v2 or pin the old behavior to a Git ref:
README.md. Existing projects do not automatically become correct just because
the source template changed; review and merge spec updates intentionally.