Tana Templates for Projects, Research, and Reusable AI Context

The most useful Tana templates ask for information you will reuse: a project outcome, the source behind a research claim, and a clear next step. Start with those small patterns before installing a complete workspace system. A template should reduce decisions during capture and improve what you can find later.

Use Tana for the working notes and fenbs for the accepted project decisions and reusable prompts that different assistants need to read. Neither a neatly filled template nor an AI summary makes an uncertain claim true; keep its evidence and approval status visible.

What should you check before installing a template?

Tana describes its installable templates↗ (opens in a new tab) as configurations of supertags, fields, commands, and views. Installation copies them into a workspace; the installed version has no ongoing connection to the original. Read what a template adds before putting it beside existing work.

• Purpose: can you name the repeated activity it improves?
• Required input: can you fill it from information you actually have?
• Output: does it help you find an answer, make a choice, or continue work?
• Overlap: does it introduce another task or project structure alongside one you already use?
• Maintenance: who will change the template when the workflow changes?

Test an unfamiliar configuration in a separate workspace before using it on important work. Create one realistic note, retrieve it, and update it. If you cannot explain what a command changes, inspect it before running it. A small pattern you understand is easier to maintain than a larger one you cannot repair.

What belongs in a reusable project note?

A project note should tell your future self what the work is for and where to continue. Avoid a large list of fields that repeat the task list. The project supplies the reason for the work; individual actions supply the next observable steps.

Project: Customer onboarding guide
Outcome: A new customer can complete the first setup alone.
Owner: [person responsible]
Current question: Which setup steps need screenshots?
Source links: [current product instructions and approved examples]
Approved decisions: [choice, person, reason, date]
Open questions: [question and person who can answer]
Next action: Test the draft steps against the product.
Done means: Steps tested and approved by the project owner.
Last reviewed: [date]

Replace bracketed prompts with facts, or write that the answer is unknown. For example, do not populate an approval date just because a meeting discussed the draft. Add the actual decision when the person responsible makes it.

Recreate recurring attributes as fields if you need to filter or review them. Tana supertags↗ (opens in a new tab) let a type of note share a field template. Keep explanations as ordinary child notes when you do not need a field for them.

Use a separate task list pattern for actions rather than turning the project note into an endless checklist. When a decision affects another person or assistant, record its accepted version in fenbs project context.

How should a research template preserve evidence?

Build around one source and one question. The important separation is between what the source says and what you conclude from it. That makes later review possible even when an AI assistant helped create the summary.

Source: [title and author or organization]
URL: [original source]
Accessed: [date]
Question: What am I trying to establish?
Relevant passage or location: [page, section, or timestamp]
Source finding: [plain summary of the supported point]
My interpretation: [what I think it means for this project]
Limitations: [missing information, scope, or conflicting evidence]
Project connection: [reference to the project]
Follow-up: [next source or check needed]

A hypothetical source might describe setup behavior for administrators while your guide serves ordinary customers. Record that limitation before turning the source into instructions. More sources are useful only if they address the uncertainty that remains.

Give the note a title that helps retrieval, such as “Setup access differs for administrators,” rather than “Interesting article.” Keep the original URL even after the summary is polished. A later reviewer needs a path back to the material, not just a confident conclusion.

For repeated operating instructions that grow out of the research, use the SOP template. Research notes explain evidence; an approved procedure tells someone what to do. Maintaining that boundary prevents a tentative finding from quietly becoming a rule.

What makes an AI context template reusable?

Reusable context describes the current state of a job, not the entire history of every conversation. Include the outcome, the rules people agreed on, the material relevant to this step, and the limits of what has been checked. Keep the reusable instructions separate from the facts that change each session.

Goal: Review the onboarding draft for unsupported instructions.
Inputs: [draft] and [selected source notes].
Rules: Do not treat suggestions as approved decisions.
Task: Identify claims that lack supporting source material.
Output: Claim, source location, concern, and suggested next check.
If evidence is missing, say so. Do not fill gaps from assumption.
After review, summarize what changed and what remains unresolved.

Test a prompt with a deliberately incomplete source note. A useful result identifies the gap instead of creating an answer. Then test it with a supported claim to make sure it recognizes evidence rather than objecting to everything.

For work that must continue across AI apps, keep the accepted prompt and the current project record in fenbs. That gives connected assistants a shared starting point without requiring each person to reconstruct the pattern from a private notebook.

How do you keep reusable notes from changing together?

Be clear whether you want the same information in another place or a new, independent note. Tana documents that ordinary copy and paste inside its outline creates references; Duplicate creates an independent copy↗ (opens in a new tab). Choose deliberately when reusing an example project.

Run a simple check before using the pattern broadly. Change a harmless line in the new note and inspect the original. The result should match your intention. Keep example content obviously fictional and remove old names, dates, and approvals from any copied project.

Review the pattern after several uses. Remove questions you never answer and add a field only when a missing fact caused a real problem. The second-brain topic hub offers other capture and reuse approaches; the best pattern is the one that makes your next action clearer.

Ask someone unfamiliar with the example to fill a fresh version. Notice which labels require explanation and which answers they cannot establish from the available material. Rewrite ambiguous questions before adding more instructions. A reusable pattern should make the needed facts easier to supply, including an honest unknown when the evidence is missing.

How to reuse approved context with fenbs?

1. Create a free account, free for one person with no credit card, and add one active project.
2. Add the project goal, selected source links, and current tasks. Copy only the information the next session needs and say what remains uncertain.
3. Record the choices a person approved in Decisions and rules. Save the tested reusable instructions in Skills and prompts.
4. Follow the guide in Integrations to connect a supported AI app through MCP, a standard way to use outside tools, with browser sign-in.
5. Ask the assistant to read the context and relevant prompt before work, then save task progress and Where we left off before stopping.

fenbs does not install Tana templates or import your notebook. Keep Tana when you need a flexible personal outline; use fenbs when the project instructions and handoff need to stay available across supported assistants. For a detailed operational handoff rather than a source note, start from the runbook template.