From nothing to a working setup

About an hour, most of it once per project. This assumes you have never used GitHub and are not a developer.

What you end up with: one repository your team can read, a harness your AI tools follow, and a habit that makes the output accumulate · 2026-09-18

Before you start

• A GitHub account. Free. Use a personal email, not a client one.
• One AI tool you already pay for — Claude, Copilot or Perplexity. Any of them.
• One real workstream to try it on. Not a test. The habit only sticks on real work.

Nothing here needs client data, and nothing here should ever contain any.

Step 1 · Make the repository

A repository is a folder with a history. Every change is recorded — what changed, who changed it, when, and why. That last part is the reason this is worth doing.

On GitHub, click New repository. Name it after the workstream, lowercase with hyphens — acme-o2c-redesign, not Project Files v3 FINAL. Set it private. Tick Add a README.

Then give it a shape. The shape matters more than it looks: it is what lets anyone — a colleague, or an AI tool landing cold — know where things go without being told.

your-repo/
├── README.md        what this is, who it is for, and its current state
├── decisions/       one file per decision. The part people ask for later
├── analysis/        working papers, comparisons, drafts
├── sources/         what you based things on, with dates
└── canon/           the harness (Step 2)

Four folders. Make them by creating a file inside each — GitHub needs a file to keep a folder.

One repository, one subject

If you cannot say what the repository is of in one sentence, it is two repositories. The most common early mistake is one repository called client-name that becomes a junk drawer within a month.

Step 2 · Add the harness

The harness is the instructions your tools read before they do anything. You write them once, in one file, and the tool-specific files are generated from it.

That last part is the bit that matters. Claude reads a file called CLAUDE.md. Copilot reads .github/copilot-instructions.md. Perplexity reads whatever you paste into a Space. If you maintain those by hand you will have three sets of rules within a month, quietly disagreeing with each other, and no way to tell which one an answer came from.

So you keep one file — canon/CANON.md — and generate the rest:

curl -sL https://raw.githubusercontent.com/EVEglyphDesign/canon/main/harness/install.sh | bash

That writes the source file, the generator, and the tool-specific files. From then on you edit canon/CANON.md and re-run one command; everything else updates together and a check fails the moment they drift apart.

What goes in it

Keep it short. A harness nobody reads is worse than none, because people assume it is being followed. Four things earn their place:

The first three are the same on every project. Only the fourth changes.

Step 3 · Point your tools at it

Claude

Work in a clone of the repository rather than pasting files into a chat window. It can then read and search the actual folder, instead of only what you remembered to paste. It picks up CLAUDE.md automatically.

Copilot

It reads .github/copilot-instructions.md in the repository with no further setup. The generator writes that file for you.

Perplexity, ChatGPT, or anything else

These cannot read your repository, so give them the self-contained copy the generator produces. Paste the whole of canon/PASTE-IN.md into a Space or Project once. When the harness changes, re-paste it — the file carries a stamp at the top so you can tell whether the copy in the Space is current.

Step 4 · The habit that does the work

Ask for a file, not an answer.

This is the single change that makes the difference, and it is almost free. Instead of "what are the trade-offs between these two designs", ask for "a file in decisions/ comparing these two designs, with the recommendation and what it rests on."

Same work, same cost. But one of them is gone when you close the tab and the other one is still there in six months when somebody asks why.

What a decision file looks like

2026-09-18 · Credit block strategy for the O2C redesign

Decision: Block at delivery, not at order entry.

Alternatives considered:
  - Block at order entry — rejected, stalls the call centre
  - No automated block — rejected, AR exposure

Rests on: the September aged-debt extract (sources/ar-aged-2026-09.md),
          and the workshop on 11 Sep with the AR team

Agreed by: D. Theriault, plus AR lead
Revisit if: DSO moves past 45 days

Eight lines. Nobody has ever regretted writing one.

Step 5 · Read before you search

Most wasted AI spend is not caused by a hard question. It is caused by a tool that starts cold and goes looking on the internet for something already sitting in your repository. The harness should tell it to work down this order and stop at the first step that answers:

Step 3 is the one that gets skipped. A repository full of your own decisions costs almost nothing to read and is more reliable than anything a search will return, because it is what your project actually agreed.

Step 6 · Two rules that save you later

Say where things came from. A number without a source is an opinion with a table around it. When something is extracted from a system or a document, note which one and when — a line in sources/ is enough. You will need it the first time someone challenges a figure.

Never delete, supersede. When a decision changes, add the new one and mark the old as superseded. Do not edit history. The reason a decision changed is often more valuable than the decision, and deleting it throws that away.

When the client's front door is Copilot Studio

Some clients already have an agent — a Copilot Studio agent in Teams, say — and it is not going anywhere. It does not read a CLAUDE.md. It calls tools.

That changes where the harness sits, not what it does. The repository is still the record. The client's agent becomes a caller of it, through an MCP server you expose — three tools, read-only, each result carrying where it came from. The agent stays the interface the client knows; the record, the reasoning and the audit trail stay in the client's own custody.

The one thing to write before anything else is the tool contract: what the three tools are, what they take, what they return, and the rule that they never widen access beyond what the client's platform already grants. It is a short file, it is committed to the project repository, and it is what everyone reads to know what the seam does.

Copy the tool-contract template

Three platform facts to check before you commit to it, all verified against Microsoft's documentation on 2026-09-19 and all liable to move: Copilot Studio requires Streamable HTTP transport (SSE was dropped after August 2025); it authenticates by API key or OAuth 2.0; and it reaches the server through Power Platform connectors, so the client's DLP policy has to allow it or the calls fail silently.

What to do next