AI & Skills · 02

How we use Claude Projects.

Projects are persistent workspaces with their own knowledge, memory and chat history. We use them deliberately, not as a default catch-all. This page covers when to create one, how to name it, what goes in knowledge versus chat, and the current inventory.

Active Projects

Naming patterns

Time-bound

Standing

When to create one decision rule

Create when

The work has its own context.

A new substantive work stream begins — a client engagement, a capability area, a research piece, an internal system. The work has context that doesn't belong in a more general Project. You want memory and chat history scoped to this work so other work doesn't pollute it.

Don't create for

A single conversation.

One-off requests, work that fits naturally within an existing Project's scope, or "just to keep things separate" without a clear reason. If unsure, default to using an existing Project. Project proliferation is harder to manage than consolidation.

Naming convention two patterns

Two naming patterns, chosen by whether the work is time-bound or standing.

Pattern A · time-bound

[Client/Event] · [Year] — for work that wraps when the engagement or event ends. Used for client engagements and annual events. Year is part of the name so historical Projects remain unambiguous.

Examples: XDW 2026, VisitBritain AI Programme 2026, Airbnb Rural Tourism Renaissance 2025.

Pattern B · standing

DTTT · [Production] — for workstreams that don't expire. Used for cross-cutting capability areas, operational work, and ongoing research.

Examples: DTTT Production, DTTT Marketing, DTTT Admin & Logistics, DTTT Research.

Rules

Use the client's preferred name (e.g. "Fáilte Ireland" not "FI") for any client-facing references; abbreviate to a short prefix only where space demands it (e.g. job references)
Avoid status suffixes — no v2, no active, no current. Projects evolve in place
Year suffix applies to time-bound work only. Standing Projects do not carry years

When to retire

Engagement closes definitively and won't reopen — keep the Project but stop adding to it
Event year ends — keep as historical reference
Project becomes redundant (work folded into another Project) — archive in Claude, note the consolidation in the new Project's knowledge

Knowledge vs chat what lives where

Project knowledge

Persistent reference.

Briefing documents, methodology and conventions, reference materials and templates, schema documentation, records of decisions, the current state of important systems. The test: if the same information would be useful next month when starting a new chat, it belongs in Project knowledge.

Chat history

The work itself.

Drafting, iteration, problem-solving, specific deliverables produced, ad-hoc questions, in-the-moment decisions. Useful while live, but not what future chats should depend on.

Setup checklist When creating a new Project, populate the knowledge base with a Project instructions or README, any briefing documents, reference materials and templates, and any schema or conventions the Project will touch. Don't over-populate from the start. Add knowledge as it becomes useful.

Current Project inventory 15 active · 2 categories

The Claude UI is the live source. This table reflects the naming convention agreed May 2026. The standalone Internal | Knowledge System Project (where this intranet is built) sits outside both categories.

Project	Type	Notes
Client & Event · time-bound
XDW 2026	Event	X. Design Week — Destination AI Intensive
CAMPUS 2026	Event	Annual capability-building programme
FRONTIERS 2026	Event	Frontiers research event
FDB 2026	Event	Future Destinations Brussels
ATM 2026	Event	Arabian Travel Market activation
WTM 2026	Event	World Travel Market activation
ITB 2027	Event	ITB Berlin activation
VisitBritain AI Programme 2026	Client	AI programme engagement
Visit Greenland Strategy 2026	Client	Strategy engagement
Aruba Tourism Authority 2026	Client	Client engagement
Airbnb Rural Tourism Renaissance 2025	Client	Research partnership engagement
DTTT · standing
DTTT Production	Standing	Production work across the business
DTTT Marketing	Being created	Marketing & communications workstream
DTTT Admin & Logistics	Standing	Operational admin and logistics
DTTT Research	Standing	Research workstream

Cross-Project considerations memory · skills · context

Memory scope

Memory is per-Project when working inside a Project, cross-Project when working outside. A note saved while in BD | Business Development won't appear in Advisory | Visit Skåne. Memory edits should be made in the Project where they're most relevant.

Skill loading

Skills load across all Projects — they live in /mnt/skills/ and are available regardless of which Project you're in. See the skills catalogue for the complete list.

When work crosses Projects

Sometimes a piece of work spans multiple Projects (e.g. a client wants both an advisory engagement and an event hosting partnership). Two approaches:

Work in the lead Project. Pick the Project that owns the primary work stream and do the cross-cutting work there. Reference the other Project's context in passing.
Maintain context in both. For substantial cross-Project work, duplicate the key documents in each Project's knowledge.

The first is usually right. Cross-Project context becomes a maintenance burden if overused.

Anti-patterns things to avoid

Project sprawl.

Creating a new Project every time something feels distinct. Better to have fewer Projects with clear boundaries than many overlapping ones.

Dumping-ground knowledge.

Treating Project knowledge as a place to put anything tangentially related. Knowledge bases work when curated; they break when overloaded.

Stale instructions.

Project instructions that no longer reflect how the Project is being used. If the work has evolved, update the instructions.

Single-use Projects.

Creating a Project for one task, then never returning to it. If the work won't continue, do it in a more general Project.

Maintenance rhythm light touch

Weekly — quick scan of recent Project activity, note anything that needs documenting in the Internal Knowledge System
Monthly — review the Project inventory; archive stale Projects, consolidate where Projects have drifted apart
Quarterly — review Project knowledge for staleness; update briefings and instructions as needed

Light-touch maintenance, not heavy admin. The aim is to keep the system serving the work, not to make work of the system.