Get AI summaries of any video or article — Sign up free
Introducing the Tana Pattern Library thumbnail

Introducing the Tana Pattern Library

CortexFutura Tools·
5 min read

Based on CortexFutura Tools's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Importing from the Tana Pattern Library starts with linking to a shared workspace or node, then using “clone reference” to bring the pattern into the user’s own graph.

Briefing

Tana’s Pattern Library makes it possible to import complete workflow “packages”—including Super Tags, their Fields, and related collections—into a personal workspace with a few copy-and-paste steps. Instead of rebuilding a setup field-by-field, users can reference a shared pattern, then clone it into their own graph so it behaves like anything they created themselves. That shift matters because it turns experimentation into a low-risk process: patterns can be renamed, edited, and deleted without breaking other work.

The workflow starts with linking to a shared workspace. By right-clicking a workspace title and choosing “Link to node” (or copying the link), then pasting it into a user’s own workspace, the pattern library content appears as a normal reference. From there, specific patterns—such as a “micro and Nano cycles” setup—can be copied into the user’s graph. The key step is “Clone reference,” which converts the referenced pattern from a dotted-outline reference into actual nodes inside the user’s workspace. Once cloned, the Super Tags and their Fields become usable immediately; the user can run the Super Tag like any other, and can rename the cloned components (e.g., “TPL microcycle” becomes “demo microcycle”) to match personal conventions.

Editing and cleanup are treated as first-class features. If a cloned pattern doesn’t work as expected, the user can delete the node(s) directly from the graph. The transcript demonstrates that deleting the cloned Super Tag nodes removes them from the workspace, enabling rapid iteration. A tradeoff is made explicit: cloned patterns are a “hard copy” at the moment of cloning. They do not automatically update when the original library releases new versions (V2, V3, etc.), so users retain full control over what exists in their graph.

Beyond importing, the transcript also details how to share patterns with others. The approach is to create a new workspace and publish it read-only so anyone with the link can view its contents. Within that workspace, a user can build a workflow template—such as a “journal entry” workflow—by creating Fields (about, how to use it) and attaching the necessary Super Tags. The transcript emphasizes a structural requirement for sharing: the workflow’s Super Tag must be a direct child of the Super Tags field (not merely a reference), which is handled by “bring reference node here” to remove the dotted outline and place the node correctly in the hierarchy.

Finally, sharing can be done at two levels. Users can share the entire published workspace (letting others browse all patterns inside), or share individual patterns by copying a “get link to node,” pasting it into another workspace, and cloning the reference. In the demo, cloning an individual “journal entry” workflow into a personal workspace allows the user to run the Super Tag and generate journal entries using configured Field logic such as “date from ancestor day node” and “entry time.”

Cornell Notes

Tana’s Pattern Library lets users import reusable workflow components—Super Tags, Fields, and collections—into their own workspace quickly. The process uses references first (via a linked workspace or node), then “Clone reference” to turn a pattern into real nodes inside the user’s graph. Once cloned, the setup can be renamed, edited, and deleted like anything else, making experimentation low-risk. A key limitation is that cloned patterns do not auto-update when the library changes; users get a snapshot at clone time. Sharing works by publishing a read-only workspace and ensuring shared Super Tags are placed as direct children under the Super Tags field so others can clone and use the workflow.

How does a user move a pattern from the Tana Pattern Library into their own workspace so it becomes editable and runnable?

First, the user links to the shared workspace (right-click the title and choose “Link to node,” or copy the link and paste it into their workspace). This creates a reference that can be browsed. Then, to make the pattern usable as part of the user’s own graph, the user focuses on the pattern and runs “clone reference.” After cloning, the dotted-outline reference disappears and the Super Tags/Fields become contained in the user’s graph, where they can run the Super Tag and edit the configuration.

What’s the practical difference between referencing a pattern and cloning it?

A reference keeps the pattern tied to its source workspace and appears with a dotted outline. Cloning reference converts it into actual nodes inside the user’s graph (no dotted outline), so the user can rename components, modify Fields, and delete nodes without affecting the original library. The transcript demonstrates this by cloning a “micro and Nano cycles” pattern and then running the cloned Super Tags as if they were created locally.

Why does deleting a cloned pattern work, and what does it imply about experimentation?

Because cloned patterns are real nodes in the user’s graph, deleting the node removes the cloned Super Tags from the workspace. The transcript shows deleting the demo microcycle and demo Nano cycle nodes, after which the Super Tag no longer appears. This supports experimentation: users can test changes and simply delete the cloned setup if it doesn’t fit.

What limitation comes with cloning patterns from a shared library?

Cloned patterns are a hard copy at the time of cloning. They do not receive automatic updates if the library releases newer versions (V2, V3, etc.). Users must re-clone to pick up fixes or improvements, which is why the transcript frames cloning as a way to guarantee what’s inside the graph matches the user’s snapshot.

How do users share their own workflow patterns so others can clone them correctly?

Users create a new workspace and publish it read-only so others can access it via link. Inside, they document the workflow with Fields (like description and instructions) and attach the required Super Tags. A structural requirement matters: the Super Tag must be placed as a direct child under the Super Tags field. The transcript shows using “bring reference node here” to remove the dotted outline and make the Super Tag a direct child, ensuring the shared workflow works when cloned elsewhere.

What are the two ways to share patterns, and how does each affect what the recipient gets?

One method shares the entire published workspace, letting recipients browse all patterns inside. The other shares individual patterns by copying a “get link to node,” pasting it into another workspace, and cloning the reference. The recipient then gets just that specific workflow (e.g., a journal entry workflow) and can rename and run its Super Tag in their own graph.

Review Questions

  1. When would a user choose “clone reference” instead of keeping a pattern as a reference?
  2. What structural placement requirement must be met for a Super Tag to be shareable under a workflow’s Super Tags field?
  3. Why might a user need to re-clone a pattern after the library releases a new version?

Key Points

  1. 1

    Importing from the Tana Pattern Library starts with linking to a shared workspace or node, then using “clone reference” to bring the pattern into the user’s own graph.

  2. 2

    Cloned patterns become fully editable and runnable like locally created Super Tags, including the ability to rename them.

  3. 3

    Deleting cloned nodes removes the associated Super Tags from the workspace, enabling fast experimentation without long rebuilds.

  4. 4

    Cloned patterns do not auto-update when the library releases new versions; recipients get a snapshot from the clone time.

  5. 5

    Sharing patterns requires publishing a read-only workspace and organizing workflow documentation plus Super Tags within it.

  6. 6

    For shared workflows to work reliably, Super Tags must be direct children under the workflow’s Super Tags field, not merely references.

  7. 7

    Patterns can be shared either as a whole published workspace or as individual node links that others can clone into their own graphs.

Highlights

Cloning a referenced pattern turns dotted-outline references into real nodes inside a workspace, making Super Tags immediately usable.
Hard-copy cloning trades convenience for control: no automatic updates, but the graph always matches the cloned snapshot.
Sharing templates hinges on hierarchy: Super Tags must be direct children under the workflow’s Super Tags field for others to clone and run them.
Publishing a read-only workspace plus link-based sharing lets co-workers adopt workflows without rebuilding Fields and configurations from scratch.

Topics