Keeping records
Project instructions
Every project has a GENELOOP.md at its root. Write your standing constraints there once, and stop repeating them in every conversation.
What it is
GENELOOP.md is an ordinary markdown file that lives at the top of each project. It is read at the start of every conversation in that project, so anything in it is context the assistant already has before you type your first message.
It is the difference between explaining your host strain forty times and explaining it once. It is also the difference between getting plans built around enzymes you own and plans built around enzymes you have never bought.
Open it from the GENELOOP.md button at the top of the Projects panel. It cannot be renamed, moved or deleted — the fixed location is what makes it findable.
What to put in it
Facts that are true across the whole project and would otherwise be typed repeatedly.
- Host and strain
- E. coli BL21(DE3), HEK293T, a particular yeast background. This drives codon usage, promoter choice and what is even possible.
- Your backbones
- Which vectors you actually use, and anything non-standard about your copies of them.
- Enzymes and reagents on the shelf
- The single highest-value entry. A plan that only uses enzymes you own is a plan you can run today.
- Selection and induction
- Your antibiotics and concentrations, your inducer and how you use it.
- Naming conventions
- How your lab names constructs, so new files arrive named the way your freezer boxes are labelled.
- Standing preferences
- “Always C-terminal tags unless I say otherwise.” “We do Gibson, not restriction cloning.” “Never use ampicillin in this project.”
- Known traps
- Things that have already bitten you. An internal cut site, a toxic gene product, a region that will not sequence cleanly.
An example worth copying
# Project: Thermostable esterase variants
## Host
E. coli BL21(DE3) for expression, DH5-alpha for cloning.
Grown at 37 C, induced at 18 C overnight for solubility.
## Backbones
- pET-28a(+) — our copy, in this project. N-terminal His6.
- pET-22b(+) — when we need periplasmic export via pelB.
## Enzymes in the freezer
NdeI, XhoI, BamHI, EcoRI, HindIII, NcoI, SalI, DpnI.
We do NOT have BsaI or Esp3I, so Golden Gate is off the table here.
## Selection
Kanamycin 50 ug/mL for pET-28a. Ampicillin 100 ug/mL for pET-22b.
## Conventions
- Constructs are named <gene>-<variant>-<vector>, e.g. estA-M12-pET28a.
- N-terminal His6 unless the assay needs a free N-terminus.
- Always leave the native T7 terminator intact.
## Known traps
- estA has an internal NdeI site at roughly position 400. Do not plan
an NdeI-based strategy without checking it first.
- The wild-type protein is insoluble above 25 C.Roughly one screen. Every line of it removes a question that would otherwise be asked, or a wrong assumption that would otherwise be made.
How to write it
Be specific and concrete
“We prefer soluble expression” is a sentiment. “Induce at 18 °C overnight; the wild-type protein is insoluble above 25 °C” is a fact something can act on.
Write down what is unavailable
Absences are as useful as presences, and they are the thing nobody thinks to write down. If you do not have an enzyme, say so. If a vector is off limits, say so. Otherwise it will be assumed available, because most labs have it.
Keep it to one screen
It is context for every conversation in the project, and a long file dilutes itself — the important constraints get lost among the background. If it is growing past a screen, the material that is not a standing constraint probably belongs in a project document instead.
Update it when reality changes
When you discover a trap, add it. When you run out of an enzyme, remove it. It is worth treating like a shared lab notebook page rather than a form you filled in once.
One per project, and one for your lab
Each project has its own GENELOOP.md. That is deliberate — the constraints for a mammalian expression project and a bacterial one are not the same, and a single file covering both would end up contradicting itself.
But some things are true of your lab in every project: the strains you keep, what is in the freezer, how you name constructs, your biosafety floor. Those go in lab memory, edited under Settings → General. It is read alongside every project’s own file.
The two are read in order — lab first, then the project — so where they disagree, the project file wins. A lab that works at BSL-1 by default and one project that does not is exactly the case this handles: state the default once, state the exception where it applies.
Pulling in a longer document
Keep GENELOOP.md to one screen. When something is genuinely long — a freezer inventory, a vendor’s requirements, a strain table — put it in a project document and reference it with an @ line:
## Enzymes in the freezer
See the full list: @documents/Freezer inventory.mdThe referenced file is loaded in full, right after the file that names it. Paths are project-relative; a reference inside a code block or an HTML comment is ignored, so you can write about the syntax without triggering it.
Rules that only apply sometimes
A constraint that is only true of part of your work does not belong in the file that is read on every turn. Put it in .geneloop/rules/ as its own markdown file and say which paths it covers:
---
paths: sequences/**
---
Always leave the native terminator intact when editing a sequence here.A rule with a paths: line is delivered only once the work actually touches a path it claims. A rule without one is always delivered, which makes it a way to split a long GENELOOP.md into readable pieces rather than a way to scope anything.
What it does not do
It is context, not a rule engine. It makes the right answer far more likely and does not make a wrong one impossible — you still read the plan and check the diff. And it is not a substitute for saying what you want in the moment: it holds what is always true, while your message holds what is true today. Asking for help.