Projects

A project is a container that holds chats, a set of instructions, and a set of documents, so that every conversation about one piece of work starts with the same context. Lesson 4 said a thing you say in one conversation dies with it. Lesson 2 said a thing you want in every conversation goes in your standing instructions.

A project is the middle case, and it is the one most people’s actual work falls into: context you want on every conversation about one thing, and on none of the others.

What is a project?

Every conversation started inside it gets the instructions and can see the documents; every conversation outside it gets neither.

The two halves are named on screen: project instructions and project knowledge. Those are the words to look for; where exactly the button to create one sits is the sort of thing that moves, and it is wherever your projects are listed.

Projects are on the free tier, capped at five. Paid plans lift that cap and add a retrieval mode that kicks in when a project’s knowledge approaches the context limit, letting it hold substantially more than would otherwise fit. Everything else in this lesson works on free.

The two halves

Project instructions are the standing instructions from lesson 2, scoped to this work. The same rules apply: specific beats vague, short beats long, and every line should be something you would otherwise repeat.

For someone running stock control, that might be:

I run stock control for a warehouse with about 4,000 SKUs and one person doing the
counting.

When I ask about a discrepancy, the first question is always whether it is a counting
error or a recording error. Ask me which before assuming.

Write in British English. Money in pounds. Dates as "4 March", never "March 4th".

Do not suggest software. We are not buying software.

Every one of those is a sentence somebody got tired of typing. The last one is the most valuable and the least obvious: a project is as much about what you do not want as what you do.

Project knowledge is the documents. The handbook, the price list, last quarter’s figures, the procedure nobody has written down properly. Anything you would otherwise attach again and again.

The difference from attaching a file to a chat is that it is there for every conversation in the project, without you deciding each time, and without four copies of it accumulating in one conversation.

When it earns its keep

The honest test is a number: have you explained this three times?

Below three, a project is more setup than it saves. Above three, you are paying that explanation tax on every conversation forever, and a project is ten minutes once.

Things that pass the test, in most jobs:

• Recurring work with a house style. Reports, updates, minutes, anything with a shape.
• Anything with reference material that does not change weekly. A policy, a price list, a spec, a set of definitions your organisation uses differently from everyone else.
• Anything where you keep having to say “no, not like that” about the same thing.

Things that fail it:

• One-off tasks. Just have a conversation.
• Work where the reference material changes daily, which means the project is stale and you will not notice.
• A project per client when the only difference is a name. One project and a line saying which client, at the top of each chat.

The failure mode

A project that has accumulated for a year, whose instructions contradict each other, whose documents include two versions of the price list.

Nothing announces this. The answers get vaguer, exactly as in lesson 4, and for the same reason: too much in the room, no marking of what still matters. When two instructions disagree, one wins, and you do not get told which.

The maintenance is small and nobody does it: read your project instructions once a quarter and delete. If a document has a newer version, replace it rather than adding it.

Your turn

Build one for something you do repeatedly. Not a demonstration; real work, or the exercise proves nothing.

1. Create a project. Name it after the work, not after the tool.

2. Write the instructions. Five lines maximum. Include at least one line saying what not to do, because that is the line you will be most glad of.

3. Add one document to the project knowledge. The one you have attached to a chat more than once.

4. Start a chat inside the project and give it the request you saved from lesson 3, with the parts now covered by the instructions deleted.

Check: the answer is as good as the one you got in lesson 3, from a noticeably shorter request. Count the words you saved. That is the per-conversation saving, and you get it every time from now on.

Then the check that finds a broken project, which is worth doing once:

What do you know about this work before I say anything? List the instructions you have
and the documents you can see.

Check: it lists back your instructions and names your document. If a document is missing from that list, it is not in the project knowledge and every answer you get about it will be a guess. If it lists instructions you do not remember writing, you have two sets and they may disagree.

Recap

Standing instructions are for everything. A project is for one body of work: instructions plus documents, applied to every conversation inside it and none outside.

The test is whether you have explained it three times. Below that, setup costs more than it saves.

The most valuable line in most project instructions is the one saying what not to do.

Projects go stale silently, in the same way a long conversation degrades. Read yours occasionally and delete rather than add.

Next: giving it documents, and the specific things it cannot see in them.