Project Assets

Project assets are reference files you upload to help Trinity's AI agents understand your project visually and contextually — wireframes, brand guides, specs, screenshots, prototypes, PDFs.

Accessing Assets

Two places write into the same library:

  • Project Settings → General → Assets tab (Project Assets card) — the full view of everything the project holds: upload, import folders, AI-generate descriptions
  • Architect Assets panel — upload or attach reference material inline while you plan, including during greenfield setup

The Architect panel lists what you attached there; the Settings card shows the whole library. Either way an agent can find the file, so attaching context to a feature proposal doesn't hide it from the rest of the project.

Uploading

You can upload:

  • Individual files — drag and drop or click to browse
  • Entire folders — directory imports preserve the full parent / child / grandchild structure

Supported file types include images (PNG, JPG, SVG, WebP), PDFs, and other common document formats. Files are stored according to your project's storage configuration (Local Only, Trinity Cloud, or BYO S3 — see Project Settings → Storage).

A website can be a reference too. In the Architect Assets panel, paste a URL into the Paste a reference link… box and press Enter (or click Add). Trinity loads the page, takes a full-page screenshot, and saves it as a reference asset attached to the conversation — named after the page's title, with the original link kept alongside it so you can always go back to the live page.

The capture loads the page for real, so it takes a few seconds; the box stays disabled until it finishes, and a link that won't load reports an error instead of saving a blank reference.

Sharing References in the Conversation

You don't have to use the panel at all. Share a link or drop a file straight into the Architect chat, and when it's material worth keeping, Architect saves it into your library for you — a link becomes the same screenshot-and-URL capture the panel produces, and a file is copied into durable storage so it outlives the conversation.

Two things follow from this:

  • A file you drop in chat is temporary until something keeps it. Chat attachments are saved and shared like any other file — you and every other member can open them from any of your devices, and Architect can read them wherever it happens to be running — but they are cleared after a week unless something keeps them. Every attachment's chip, in the composer and beside its message, names its own state — Kept, or Expires in n — so you always know at a glance which files are safe. You don't have to wait on the Architect for that: click the label yourself, on any attachment including one from earlier in the conversation, to keep it right there — no dialog, nothing to confirm. Clicking an attachment that's already kept just confirms it's kept; it never errors. If a file's key can't be resolved, the chip says so instead of showing a broken preview — Expired once it's past its stamp and genuinely swept, or a retryable Failed to load before that, which is worth trying again.
  • Architect decides whether a shared file is a Reference or an Asset — a logo or an icon set it shares into the built app, a brand guide or an inspiration screenshot it keeps as reading material. When the call is genuinely ambiguous it asks you. You can always flip it later with the Reference / Asset toggle (below).

Re-sharing a link Architect already captured on this conversation reuses the existing asset instead of saving it twice.

The Architect Assets panel also carries a collapsed N temporary attachments from this conversation group beneath the imported list — everything you or Architect shared in this draft's chat that hasn't been kept yet, with a Keep button on every row. It's collapsed by default and kept visually separate from the curated list above it, so a stream of passing screenshots never buries the references worth finding again.

Folder Organization

When you import a folder, Trinity preserves the directory structure with parent-child relationships in the asset tree. This keeps your reference library organized the same way you had it on disk.

AI-Generated Descriptions

After uploading, Trinity can automatically generate descriptions using AI:

  1. Files are analyzed first (up to 3 concurrently)
  2. Folders are described from their children's descriptions
  3. Descriptions are saved back to each asset row

This makes assets searchable and, more importantly, lets agents understand what each file contains without having to open it.

Tags

Every asset carries a set of free-text tags for the searchable library. Uploaded reference files are tagged automatically; from the Architect Assets panel, add or remove a referenced asset's tags inline — type a tag and press Enter to add one, click the × on a chip to remove it. Tags are searchable, so a well-tagged library makes the search-the-library box (below) find the right asset faster.

Reference or Asset

Every uploaded file is one of two things, shown as a Reference / Asset toggle on its row in the Project Assets card:

  • Reference — material for the AI agents to read, like a wireframe or a spec. This is what an upload starts as.
  • Asset — a downloadable static file that ships into your built app, like a logo or a font.

Click the toggle to switch a file between the two. The distinction is what tells an implementing agent whether to consult the file or to place it into the project at a real path.

Attaching Existing Assets from the Architect

Beyond uploading new files, the Architect Assets panel lets you pull an asset already in your library into the current conversation without re-uploading it:

  1. Type a query in the Search the asset library box, optionally narrowed by kind
  2. Review the matching hits, each showing its tags
  3. Click Attach on the one you want

The attached asset is referenced, not duplicated — it stays a single row in your library, now linked to this conversation too, with its tags editable inline right there in the panel.

How Agents Use Assets

Planning prompts include an asset block ({{ASSET_BLOCK}}) that tells the planning pipeline what references are available. The planning pipeline then:

  • Lists which uploaded assets each story should consult
  • Passes the relevant asset IDs into the story's assets field
  • Implementing agents read those assets when they hit that story

For example: upload a wireframe for a login page, and the story for building the login page will reference the wireframe so the implementing agent can match the design.

When an implementing agent needs one of these assets as an actual file — a logo that ships into the built app, say — Trinity places the file into the project at the right path itself. That covers anything in your library, not just what you uploaded: a document Trinity wrote for you takes exactly the same route. Where the contents are held with the asset itself, the file is written out with no download at all; only one kept in cloud storage is fetched first, and then only when the machine doing the work doesn't already have a copy.

If a story's plan declares asset needs that aren't uploaded yet, Trinity pauses with a missing_assets gate — skippable via the Skip asset check setting.

Where an Asset Came From

The Project Assets card groups everything by the surface it came from, so an upload is easy to tell apart from a file Trinity manages for you. Each surface also shows just its own group — the Architect Assets panel lists what you attached there, not your whole library.

  • Architect — files dropped into the Architect Assets panel while planning. Greenfield onboarding has no group of its own; it's a conversation on the Architect surface too, so its files land in this group and in Chat Describe below
  • Settings — files uploaded from the Project Assets card itself
  • Chat Describe — files you drop straight into the Architect conversation itself, as opposed to the Assets panel (see Sharing References in the Conversation)
  • Diagnostic Chat — files shared while troubleshooting a stuck run from a gate's diagnostic chat
  • Runtime Conversation — files shared in the /runtime conversation where you describe a skill, command, or hook to build
  • Gate Upload — files you supplied when a run paused at a missing-asset gate, one group per requested file
  • Workspace — documents Trinity keeps in sync with your project (your project's top-level AGENTS.md, your skills, commands, and hooks). Trinity keeps the section of that AGENTS.md listing your repos and packages current as they change, and leaves the rest of the file to you
  • Prototype Project — the files the Architect authored for a prototype: its entry screen, one file per other screen, and the shared styles and script they all run on
  • One group per planning conversation, named after that conversation (or the day you started it) — everything the Architect produced while planning with you: its roadmap and plan drafts, the stack it suggested for each target under stack, the pricing it looked up, generated reports under reports, and links and files you shared under references. Re-running something keeps one file and adds a new version to it, so the group stays readable instead of filling up with near-identical copies.
  • Reference Library — service configuration captured while setting up a service
  • Orphaned — a workspace file Trinity set aside because an agent's edit conflicted with yours; kept so you can recover it
  • Unscoped — a row with no surface recorded

Clear all is offered on the upload groups — the ones that are just a pile of files you handed Trinity (Architect, Settings, Chat Describe, Diagnostic Chat, Runtime Conversation, and each Gate Upload slot). The rest are project artifacts rather than uploads, so they're removed one at a time instead.

Manifest View

When assets are injected into a prompt, Trinity uses a lightweight manifest — a tree view with just file names, types, and descriptions (no binary content, no storage paths). That keeps the prompt compact while still giving agents enough information to decide what to fetch.

Storage Limits

When using Trinity Cloud storage, each person gets one 10 GB managed pool shared across every workspace they own. Uploads come out of the workspace owner's pool — not a separate bucket per workspace. While the closed beta runs, that 10 GB is the whole of the pool and BYO S3 is what takes a project past it; once the beta opens, add-on packs of 10 GB ($5/mo, stack without limit) attach to the owner's pool as well.

If you're uploading in a workspace you don't own and the owner's pool is full, the upload is blocked — the error names the owner so you know whose pool is at capacity. An upload that would put the pool over its cap is blocked immediately, and the owner has a 7-day grace period to fix it; once that grace period fully elapses, every new upload blocks — even one that would otherwise fit — until the pool owner frees space or moves projects onto BYO S3. Once the beta opens, buying an add-on pack clears the block too. Reading or downloading files you've already stored is never blocked, at any point.

BYO S3 and Local Only storage have no Trinity-imposed limits — good choice when you need real volume without growing the owner's managed pool.

See Project Settings → Storage for storage setup details.