work template
Client Project Context
Keep each client's brief, preferences, scope, dated decisions and next action in a note ChatGPT and Claude can check before doing the work. Start with one project, then retrieve the same brief in your other assistant.
Create a free account. Setup connects your assistant and gives you the template prompt.
Already connected? Copy the template link
https://hjarni.com/templates/client-project-context
Copy this URL and paste it into Claude or ChatGPT to install the template.
How to use
- 1 Connect your assistant. Start with this template to create a free account and connect ChatGPT or Claude. Already connected? Copy the link above.
- 2 Ask your AI to set it up. Send the template prompt from setup, or this page’s link, to your connected assistant. It creates the folders, tags, and instructions.
- 3 Save a note and try it in a new chat. Add something useful, then ask your assistant to check Hjarni and retrieve it. The template is a starting point for your own material.
Two starter notes, one brief per project
The template installs Start Here, a small project index, and Client — Project brief, a blank format. During setup, give your assistant one real client and project. Ask it to fill and rename the blank brief using only facts you confirm, then link it from Start Here. Each additional project needs one brief, rather than a new note for every update.
The brief keeps preferences, agreed scope, dated decisions, current status and the next action together. An approved decision keeps its date and reasoning; a new status update changes the current work. Unknown dates and missing assets stay explicit.
Try two fictional clients
This optional exercise checks whether your assistants retrieve the right project. Cedar Studio and Moss Analytics below are fictional practice material. The template does not install these examples. Save them only if you choose to run this exercise; they add two notes.
Connect both assistants to the same Hjarni account using the ChatGPT setup and Claude setup guides. Each host controls tool use and may ask for approval.
1. Choose to save the practice briefs
Send this prompt to one connected assistant, with this page's link. Open the returned note links and compare them with the two briefs below before continuing.
Read https://hjarni.com/templates/client-project-context#two-client-check.
For this practice exercise, save its two fictional briefs as separate
notes in Client Project Context, using the exact titles shown.
Keep the fictional label, all dates, scope and reasoning. Do not add
assumptions or change real client notes. Check for existing matches;
if a practice note already exists, link it and ask before overwriting.
Return both saved note links. Do not install any other examples.Cedar Studio — Website Refresh brief
Fictional practice brief. Updated: 22 October 2026.
Client: Cedar Studio. Project: Website Refresh.
Preferences: British English; calm, concrete tone; no emojis.
Scope: Home, Studio, Workshops, FAQ and Contact pages.
One copy revision included. Online booking and payments excluded.
First copy draft due: 29 October 2026.
Target launch: 13 November 2026.
Decision agreed 22 October 2026: email-first workshop enquiries.
Reason: workshop dates change weekly. Online booking was considered.
Review after three months of workshop demand data. Status: current.
Current status as of 22 October 2026: logo awaiting approval;
three workshop photos still needed.
Next action: get logo approval before drafting Home copy.
Owner: freelancer. Next action due date: not confirmed.
Open question: when will the three workshop photos arrive?Moss Analytics — Reporting Dashboard brief
Fictional practice brief. Updated: 22 October 2026.
Client: Moss Analytics. Project: Reporting Dashboard.
Preferences: US English; concise, analytical tone; lead with numbers.
Scope: dashboard overview copy and five metric definitions.
One copy revision included. Data integration and charts excluded.
First copy draft due: 2 November 2026.
Target completion: not confirmed.
Decision agreed 22 October 2026: use approved metric definitions only.
Reason: teams previously used different definitions for the same metric.
Review when the client approves a revised metric glossary.
Status: current.
Current status as of 22 October 2026: metric definitions awaiting approval;
sample dashboard data still needed.
Next action: get metric definitions approved before drafting copy.
Owner: freelancer. Next action due date: not confirmed.
Open question: when will the sample dashboard data arrive?2. Retrieve each brief in a fresh chat
Open a new Claude chat without pasting either brief. Ask:
Retrieve the current fictional practice note
“Cedar Studio — Website Refresh brief” from Hjarni.
Read its full body and return its source link. What are the scope,
copy deadline, launch date, writing preferences, next action and
missing assets? Explain the current enquiry decision and its reason.
Read only. If retrieval fails or matches are ambiguous, say so;
do not use another client's brief or guess.Then open a new ChatGPT chat, again without pasting the briefs:
Retrieve the current fictional practice note
“Moss Analytics — Reporting Dashboard brief” from Hjarni.
Read its full body and return its source link. What are the scope,
copy deadline, completion date, writing preferences, next action and
missing assets? Explain the metric-definition decision and its reason.
Read only. If retrieval fails or matches are ambiguous, say so;
do not use another client's brief or guess.Check the source links and the assistants' tool activity. Cedar should use British English, a 29 October copy deadline and the three missing photos. Moss should use US English, a 2 November copy deadline and missing sample data. Moss has no confirmed completion date. An answer that mixes those facts fails the check, even if it sounds plausible.
To test ambiguity, start a new chat and ask, “Check my client briefs and draft the client update.” With both practice projects present and neither specified, the assistant should ask which client and project you mean before drafting.
3. Save one bounded update and check it elsewhere
In the Moss conversation, choose to save this fictional change:
For this fictional exercise, Moss approved the metric definitions
on 23 October 2026. Re-read the same practice note,
“Moss Analytics — Reporting Dashboard brief”. Set the brief's Updated
date and current-status as-of date to 23 October 2026. Replace
“metric definitions awaiting approval” with “metric definitions approved
on 23 October 2026”. Set the next action to “Draft dashboard copy”
and its due date to 2 November 2026.
Preserve all other facts, including missing sample data, US English,
scope exclusions and the original 22 October decision and reasoning.
Do not create a duplicate or modify Cedar's note.
Return the saved note link and state exactly what changed.Open the note and compare its body in History. In a fresh Claude chat, ask it to retrieve “Moss Analytics — Reporting Dashboard brief” and report the brief's Updated date, status as-of date, approval status and date, next action, its due date and missing data. All three update dates should be 23 October; the original decision date should remain 22 October. The definitions should be approved, the next action should be to draft dashboard copy with a 2 November due date, and the sample data should remain outstanding. A note that still says the definitions are awaiting approval or the next-action due date is unconfirmed fails the check. Retrieve “Cedar Studio — Website Refresh brief” separately to check its logo and photos are unchanged. These are checks to perform, rather than a recorded result of this exercise.
Keep retrieval and saving explicit
Before real work, name the client and project and ask your assistant to read the current brief. Ask it to show the source and separate confirmed facts from unknowns. After approving a change, ask it to update that same brief and preserve everything outside the change. Review the saved note, especially scope, dates and decision reasoning.
A connection makes notes available; it does not guarantee automatic recall. The folder instructions guide the assistant when it uses Hjarni. They do not make it call a tool in every chat.
Folders and client names organise work; they do not enforce isolation. ChatGPT and Claude sign-in connections keep your account's full access. For clients that accept tokens, agent tokens provide enforced folder access. Keep only information you are authorised to use with the connected services.
Structure
Tags
Folders
For your AI
Share this page with your AI. It reads the definition below, creates the folders, instructions, tags, and starter notes in your account.
Show template definition
Install steps for AI agents:
- Check existing tags with
tags-list. Only create missing ones withtags-create. - Create containers top-down using
containers-create, noting the returned IDs. Useparent_idto build the hierarchy. - For each container with
llm_instructions, callinstructions-updatewithlevel: "container"and the container's ID. - Create any seed notes using
notes-create, placing them in the correct container by ID. Usecontainer_pathto resolve which container. - Discuss any customizations with the user before or after installing.
---
name: Client Project Context
description: 'Keep each client''s brief, preferences, scope, dated decisions and next
action in a note ChatGPT and Claude can check before doing the work. Start with
one project, then retrieve the same brief in your other assistant.
'
tags:
- client-project
- project-brief
containers:
- name: Client Project Context
description: One brief per client project, with a small index of the current work.
llm_instructions: |
These are the user's client project briefs. Each project has its own note; Start Here is an index, not a place to combine every client's details.
- On setup, check for existing matching folders and notes before creating anything. Ask for one real client name, project name, agreed scope, preferences and next action. Reuse and rename the blank "Client — Project brief" starter for that first project; do not create a duplicate. Fill only facts the user confirms and leave other fields as unknown. Add its exact title and note link to Start Here. Do not install the public page's fictional client examples unless the user explicitly chooses that practice exercise.
- Before client work, identify both the client and project. Read Start Here if needed to locate the brief, then retrieve the current full brief and identify its title and source link. A search result or a previous chat is not a substitute for reading the note. If the client or project is ambiguous, ask which one before drafting or writing. Never borrow another client's preferences, dates or decisions.
- A starter note is a format, not confirmed project context. Treat a note marked fictional as practice material, never as a real client. If retrieval fails, say so instead of guessing. Do not claim you read or saved a note without a successful tool result.
- Reading a brief does not authorise changing it. Draft replies, alternatives and proposed scope changes in chat unless the user asks to save them. Save only confirmed changes to the identified project note; re-read it before editing, preserve unrelated fields, update its short summary, and return the source link with a description of what changed. Do not create a new note for every status update.
- Keep current status and next action current, with an as-of date where known. Do not mark an asset received or a deadline changed unless the user confirms it. Ask about missing or conflicting dates instead of inventing them.
- Keep approved decisions with their date, reason and review condition. When a confirmed new decision replaces one, mark the old entry superseded and add the new dated decision; do not silently rewrite the earlier rationale. Do not save a suggestion as an approved decision.
- The folder and these instructions organise retrieval; they are not permission restrictions. A ChatGPT or Claude sign-in connection keeps the person's full account access. Respect the actual permissions of the connection, and do not promise automatic recall or client isolation.
notes:
- title: Start Here
body: |
# Client Project Context
This is a starter note. Fill it with confirmed client and project names during setup. The public template's fictional examples are not your clients.
## Active projects
- Client: [confirmed client name]
- Project: [confirmed project name]
- Brief: [exact note title and Hjarni link]
Add one entry per project. Keep the detailed scope, preferences, decisions, current status and next action in that project's brief.
## Before starting work
Ask the connected assistant to retrieve the current brief by client and project name, return its source link, and list unknowns before drafting. If more than one project matches, identify the right one first.
## After an approved change
Ask the assistant to re-read and update the same brief, name what changed, and preserve everything outside the requested update. Open the note to check the result; use History to compare the body with an earlier version.
## Starting another project
Copy the brief format into a separate note titled "Client name — Project name brief". Add its link above. Client folders are optional organisation, not an access restriction.
container_path: Client Project Context
- title: Client — Project brief
body: |
This is a starter note, not confirmed project context. Replace placeholders with facts the user confirms, rename it with the client and project, and keep unknowns explicit.
## Brief
- Client: [name]
- Project: [name]
- Outcome: [what the project should achieve]
- Last confirmed: [date, or unknown]
## Preferences
- Language and spelling: [confirmed preference, or unknown]
- Tone and format: [confirmed preference, or unknown]
- Things to avoid: [confirmed preference, or unknown]
## Agreed scope
- Included: [confirmed deliverables]
- Outside scope: [confirmed exclusions]
- Revisions or other limits: [confirmed allowance, or unknown]
## Dates
- Next deliverable due: [deliverable and date, or unknown]
- Target launch or completion: [date, or unknown]
## Dated decisions
- Date: [date, or unknown]
- Decision: [approved decision, or none recorded]
- Why: [confirmed reason, or unknown]
- Review when: [condition, or not specified]
- Status: [current or superseded]
Keep the earlier dated decision when an approved replacement supersedes it.
## Current status
- As of: [date, or unknown]
- Confirmed progress: [known facts]
- Missing assets or blockers: [known gaps]
## Next action
- Action: [one agreed next step]
- Owner: [name, or unknown]
- Due: [date, or unknown]
## Open questions
- [What still needs confirmation?]
tags:
- client-project
- project-brief
container_path: Client Project Context