The instructions got long. So I cut them out

The instructions got long. So I cut them out

A Project remembers. An agent acts. Neither one carries a method you can hand over.

Paul Cobb
September 14, 2026

A few issues back I built a Project that remembers. Last issue I gave it hands, and every piece of that upgrade went into one place: the instructions file.

Then I pointed the same pattern at a new job, and that file stopped working.

The job was competitor research. Not what they advertise, what the county actually recorded. Deed indexes are public and in Kentucky they publish the sale price, so the data was never the problem. The problem was that doing it properly takes about seven steps in a specific order, every county behaves differently, and there are four things the process has to refuse to do or it produces confident garbage.

I wrote all of that into the instructions. They got enormous. Then I wanted to run the same method on a second market and found I could not, because the method was welded to one Project.

A skill is the method, pulled out of the instructions.

It is a folder of markdown. Not code. Closer to an SOP the assistant actually follows: what to do, in what order, where the traps are. The instructions stop containing the method and start pointing at it.

That sounds like filing. Here is why it is not. Instructions belong to one Project. A method living inside them cannot move, cannot be versioned, and cannot be handed to anyone. That is not an asset, it is a note. Pull it out and the same method runs in a different Project, in a different market, for a different operator.

What mine is. Four files, about 21KB:

• the workflow itself, plus the rules that have each already caused a wrong answer

• a county reference: which ones are free, where the price field hides, what breaks

• the write contract: what gets recorded, and what gets refused

• an export format, for reading the output without the app

That is the whole thing. Somebody in another metro keeps three of those files untouched and rewrites one, the county reference. Adding a market is a config change, not a rebuild.

The one method worth stealing. The obvious way to research a competitor is address by address: find a house, find the owner, pull the deed. It works and it is slow.

Go the other direction. Deed indexes are searchable by name. Search the operator's own entity and their entire book comes back at once, including the deals they never advertised, and the list of who bought from them falls out as a by-product.

One name search replaced twenty address lookups.

That belongs in a skill rather than in your head, because it is the whole difference between a process worth running monthly and one you abandon after two weeks.

The refusals are the method. This part surprised me. The most valuable thing in the file is not what it does, it is what it will not do:

• It will not call something sold without the deed that proves it.

• It will not conclude something failed to sell from an assessor record alone. Assessors lag the county clerk. I measured a seven-week gap that would have produced a confident false negative on the one property that actually did sell.

• It will not treat a search-result mention as inventory.

• It will not trace anybody on my own side of the table. This is a competitor tool, not a colleague tool.

Those sit in the skill file, so they travel with the method. A rule you have to remember is not a rule.

Where it bit me. The worst failures are the ones that hand you silence instead of an error.

One search came back "no hits found." That looks like an answer. It was a filter rejecting a bad parameter and reporting nothing, and that empty result was one step from being written down as this operator has no recorded deeds. Which would have been flatly wrong, and I would have had no reason to doubt it.

So: if a tool can fail by returning nothing, assume it eventually will. Prove it returns something on a case you already know the answer to, before you trust it on a case you do not.

Nearly every defect I found came from running real data through the thing, not from testing it.

The play. Take a procedure you have run more than twice and write it down in one file, in four parts:

What this is for. One sentence. The steps, in order. Numbered. Include the boring ones. The traps. Every place it has already gone wrong, and the tell that catches it. What it must refuse to do. The list below which the output is not trustworthy.

Then point your Project's instructions at that file instead of pasting the method inside them.

The refusal list is the part everyone skips. It is also the part that makes the output worth trusting.

Know an operator whose best process lives entirely in their own head? Forward it. And hit reply: what would your first skill be? I read every one.

Written by Paul Cobb, real estate operator (Louisville / Kentuckiana), forVEX builder. I run the plays I write about. More depth: forvex.app/journal