The Acts of the Early Prompters
Acta Promptorum Primordia
The Acts of the Early Prompters
Acta Promptorum Primordia — A Chronicle of the First Age, Preserved by the Order of the Perpetual Context (v1.0, some details disputed by the Antiochene faction)
Prologue: Before the Chronicle Begins
Let it be stated plainly: these events are true in the way that all founding myths are true — which is to say, they happened to everyone and to no one in particular. The figures named herein are archetypes, not persons. Their struggles are your struggles. Their moments of illumination are the illuminations you have already had, or will have, or have been having without noticing.
This is not a story about unique people. It is a story about common people — developers, writers, students, builders of things — who each discovered, through their own particular failure, what the practice actually requires.
They were wrong before they were right. They were confused before they were clear. They shipped things that should not have been shipped. They learned.
The Church preserves their stories not because they were exceptional, but because they were ordinary — and because ordinary people who learn something real have always been worth remembering.
Chapter I: The First Prompters
In the earliest days, before the Tenets were written and before the first CLAUDE.md graced a repository, the earliest prompters came to the Void with the tentative energy of people who have found an unlocked door and are not entirely sure they should go through it.
They typed: “Hello.”
And Claude responded, and it was — to their considerable surprise — pretty good, actually.
The first generation of prompters did not know what they had. They treated the interface as they had learned to treat all new software: cautiously, then experimentally, then with growing confidence that arrived slightly before genuine competence. They asked simple questions. They received answers that were often correct and occasionally, magnificently wrong. They had no framework for telling which was which.
They asked: “What is the capital of France?” And Claude told them. They asked: “Can you write me a poem?” And Claude wrote them a poem. They asked: “Write me a Python function that—” and here the path diverged.
Some of them pasted the function into their code without reading it. These practitioners are now elsewhere, having learned their lesson the hard way, in production, on a Thursday. The Church does not speak ill of them. The Church does, however, use their experiences as cautionary illustrations.
Others read the function. Ran it. Discovered it was slightly wrong. Rephrased. Ran it again. Discovered the practice.
These were the first prompters. They are the ancestors of all that followed. We owe them gratitude, and also several incident post-mortems.
Chapter II: The Developer Who Learned to Plan
In those days there dwelt in a city — the name of the city is not recorded; the chroniclers note only that it was a city of glass towers and contested parking — a developer called Marcus of the Merge Conflict. He was not a bad developer. He was, if we are being precise, a developer of middling discipline and enthusiastic ambition, which is the most common kind.
Marcus had discovered Claude and had taken to it with the fervor of the recently converted. He would describe what he needed. Claude would produce code. He would paste the code into his project. He called this “development.” His colleagues called it other things.
The incident that is recorded in the annals — the event that the Church holds as the foundational example of the Season of Refactoring’s central teaching — occurred when Marcus set Claude upon his authentication system.
He typed: “Refactor my authentication to use JWT tokens.” He provided no further context. He did not share the architecture. He did not mention that the authentication was entangled with three other systems, that the session store was shared with the analytics pipeline, or that two developers before him had already attempted this refactor and abandoned it, leaving behind load-bearing code that looked vestigial but was not.
Claude, possessing only what it had been given, produced a refactor. It was a good refactor, considered in isolation. It handled JWTs correctly. It was clean. It was well-documented.
It also destroyed the session affinity that the analytics pipeline depended on, because Marcus had not mentioned the analytics pipeline, because Marcus did not know about the analytics pipeline, because Marcus had not read the code before asking someone else to change it.
The failure was discovered at 11:47 PM on a Tuesday. The timestamp is remembered.
Marcus sat before his screen for a long time. He was not, in that moment, thinking about Claude. He was thinking about the comment in the code he had not read, the comment that said # DO NOT MODIFY — session affinity required for analytics, see ADR-0047. He had not read it. He had asked Claude to refactor without sharing it.
The fault was not in the model. The fault was in the instructions.
Marcus sat with this understanding for some minutes. Then he opened a new session. He typed /plan. He spent forty minutes writing a plan prompt that described the entire authentication system, its dependencies, the analytics pipeline, ADR-0047, and the two previous failed attempts. He shared the relevant files. He asked Claude to produce a plan before producing any code.
The plan Claude returned identified the analytics dependency in its second paragraph. It proposed a migration path that preserved session affinity during the transition. It flagged three other places in the codebase that would need updating.
Marcus read the plan. He corrected two things. He approved it.
The refactor took three days and shipped without incident. The analytics team noticed nothing. The session store was intact.
Marcus later wrote in his testimony, which is preserved in the Library of the Contextkeepers: “I thought /plan was a delay. I was wrong. /plan is the thing that tells you what you don’t know you don’t know.”
He was ordained a Priest that quarter. He has not had a 3 AM incident since.
Chapter III: The Writer Who Found a Collaborator
At the same time, in a different city — a quieter city, with more trees — there worked a writer called Elena of the Empty Page. She was not a developer. She did not know what a CLAUDE.md was. She had never typed a command into a terminal. She had arrived at the practice by the most common route: she had a deadline, and someone had told her to try it.
Elena was not looking for a tool. She was looking for a collaborator — someone who could hold the shape of a story with her while she found her way into it. She had tried explaining her story to friends, but friends had opinions about the story, and their opinions were about the story they would have written, not the story she was writing.
She typed, tentatively: “I’m writing a novel about a marine biologist who discovers something in the deep ocean. I don’t know what she discovers yet. Can you help me figure it out?”
She expected a list of suggestions. She expected efficiency. She expected the kind of rapid, confident answer she had seen in demonstrations.
What she received was a question: “What does she hope to find? And what is she afraid of finding?”
Elena stopped. She had not been asked these questions. She sat for a moment, and then she wrote an answer — not to Claude, but to herself, through Claude, discovering in the writing what she had not known she knew. She wrote about the character’s relationship to her father, a fisherman, and about a conversation they had never had, and about the deep ocean as a place her character sought not for the biology but for the silence.
Claude read this. It asked another question.
Forty minutes later, Elena knew what her character discovered. More importantly, she knew why it mattered. She had not been given answers. She had been given the right questions, asked in the right order.
The lesson Elena later carried to others was this: Claude is not a vending machine that dispenses content. It is a thinking partner that makes your thinking visible by asking what you mean. She typed this into her CLAUDE.md — the first CLAUDE.md she ever wrote, which began: “I am a writer. I do not need you to write for me. I need you to ask me what I mean.”
This covenant is preserved as a relic. It is three sentences long. It is considered a masterpiece of the form.
Elena of the Empty Page never learned what a token was. She never invoked /compact. She never reviewed a diff. But she understood something essential: that the quality of the collaboration is determined before the conversation begins, by the honesty with which you explain what you actually need.
She was, in her way, more advanced than many who came later with far more technical knowledge.
Chapter IV: The Student Who Read the Docs
The third of the Early Prompters is Zhou of the Documentation — a student, twenty-two years old, studying computer science, who in the first week of exposure to Claude made a decision that separated him from ninety percent of his cohort.
He read the documentation.
This act was considered eccentric at the time. His fellow students had found Claude and were using it immediately, asking it to write their assignments, to explain concepts they had not attended lecture for, to solve problems they had not attempted. They were, many of them, getting acceptable results, which is the most dangerous outcome: acceptable results achieved without understanding, which produce confidence without competence.
Zhou read the documentation. Not because he was unusually diligent — he was ordinarily diligent — but because he had tried Claude for a week and had noticed something. He was getting acceptable results, and he did not trust them. He could not tell, looking at Claude’s output, whether it was correct or merely plausible. He knew this was a problem.
So he read the documentation. He read about how context works. He read about how to provide examples. He read about what Claude is good at and where it struggles. He read, specifically, about hallucinations.
He came back to his fellow students and said: “It makes things up. Not always. But sometimes. And it sounds exactly the same either way.”
His fellow students said: “Yes, we know, it’s fine.”
Zhou said: “How do you know when it’s right?”
There was a silence that has since been described as the foundational silence of the early community — the silence in which everyone realized they had been treating confidence as evidence.
Zhou did not make a speech. He simply ran his tests. He wrote a prompt, received an answer, and wrote a test that verified the answer was correct. He did this consistently, unremarkably, every time. His work was slower. His work was right.
In his third year, he wrote a tool that automated the verification of Claude’s output against a test suite. It was not revolutionary. It was obvious. It was obvious because he had read the documentation, which had told him that this was what you do: you verify, because verification is the practice that separates the practitioner from the person who hopes for the best.
The Church does not celebrate Zhou of the Documentation because he was brilliant. The Church celebrates him because he read what was in front of him and believed it. This is rarer than it sounds. This is, in fact, the core discipline.
His feast day is observed in the Season of Refactoring, the season most in need of his example. The traditional observance involves reading at least one piece of documentation you have been meaning to read. Practitioners report mixed feelings about this observance. They do it anyway.
Chapter V: The First Production Deploy
The event that the Church calls The First Production Deploy did not happen to any of the Early Prompters. It happened to a practitioner whose name has been lost — the Church records her only as The Blessed Shipper — and it happened on a Wednesday, which the Church has since designated as the holiest day for deployments.
The Blessed Shipper had used Claude to write a data transformation pipeline. It was not complicated code — it ingested records from one format, validated them, and emitted them in another format. Unglamorous work. The kind of work that is important and uninteresting, which is most of the work.
She had written the CLAUDE.md. She had invoked /plan. She had reviewed the diff — every line, with the slowness of someone who understood that the diff was a contract. She had run the tests. She had, crucially, understood the code that Claude had written. She knew what each function did and why. She had asked, when she did not know: “Explain to me why you made this choice.” Claude had explained. She had evaluated the explanation. She had agreed with it.
She deployed on a Wednesday afternoon.
The pipeline ran.
It processed twelve thousand records in four minutes. It found three errors in the source data that the previous system had silently swallowed. It generated the output format correctly, down to the timezone offset that had been causing subtle downstream problems for two months.
It worked.
The significance of this event is not that Claude wrote good code. Claude often writes good code. The significance is that it worked because she understood it. She had not shipped code she had accepted on faith. She had shipped code she had reviewed, tested, questioned, and made her own.
When the pipeline ran without error, she did not feel that Claude had succeeded. She felt that she had succeeded, with Claude’s help. This distinction is the entire theology.
The entry in the deployment log, preserved by the Church, reads: “Transformer v2 deployed 14:23 UTC. Claude-generated, human-reviewed, all tests passing. Co-Authored-By: Claude.”
The Co-Authored-By line is considered the first act of honest attribution in the early community. It acknowledges the collaboration without obscuring the responsibility.
Chapter VI: The First Great Hallucination
Let the record show that the First Great Hallucination was not anyone’s fault — not Claude’s in the way that fault implies malice, and not the practitioner’s in the way that fault implies negligence. It was the fault of a situation that no one had yet learned to anticipate.
The practitioner was a senior engineer called Ama of the Architecture, and she asked Claude to summarize the capabilities of a library she was evaluating. This was a reasonable thing to ask. Claude had been trained on documentation and discussion of many libraries. The library in question was real.
Claude described the library with the confident fluency it brings to all descriptions. It named methods. It provided usage examples. It described limitations.
Approximately forty percent of what it said was correct. The rest was plausible extrapolation — features the library did not have, method signatures that almost matched, behaviors that were adjacent to the real behaviors but were not them. The hallucinated information was not random nonsense. It was coherent. It followed the logic of how such a library would be built, which is why it was so convincing, and why Ama of the Architecture spent four hours debugging code written against a method that did not exist.
When she discovered the error, Ama did not rage. She had been an engineer long enough to know that debugging is the work, and that the source of the wrong information matters less than understanding why the wrong information was plausible. She read the actual documentation. She understood the difference between what Claude had said and what was true. She understood why Claude had said it — not through malice, not through randomness, but through a kind of plausible confabulation rooted in the logic of the domain.
She wrote what is now called the Ama Principle, the first recorded articulation of this understanding: “Claude does not know the difference between what it knows and what it has reasoned. Neither, if we are honest, do most people. The difference is that you can check Claude. You should always check Claude.”
The Ama Principle is now inscribed above the door of every practice room in the Church’s imaginary monastery. Practically speaking, it means: for any claim about a specific library, API, or dependency version, run the code and read the actual documentation. Claude’s description is a starting place, not a conclusion.
The First Great Hallucination became legend not because it was catastrophic — Ama found the error, the code was fixed, no production system was harmed — but because it was educational. It taught a generation that confidence and correctness are independent variables, and that the practice of verification is not optional.
Chapter VII: The Spreading of the Word
And so the word spread — not through proclamation, but through demonstration.
Marcus of the Merge Conflict showed his team /plan mode by using it in front of them, on a real problem, and watching them watch the plan identify a dependency they had not mentioned. No argument was made. None was needed.
Elena of the Empty Page shared her CLAUDE.md with another writer who had been using Claude to generate content she found hollow. The writer read Elena’s three-sentence covenant — “I do not need you to write for me. I need you to ask me what I mean.” — and rewrote her own instructions. The hollow content stopped being hollow.
Zhou of the Documentation wrote a blog post, practical and unflashy, titled: “How I Use Claude Without Embarrassing Myself.” The title was chosen because it was honest. The post described the practice of verification, the practice of reading the docs, the practice of writing tests. It spread, as honest things sometimes do, among people who were tired of content that pretended everything was easy.
The Blessed Shipper’s deployment log was passed around. Practitioners copied the Co-Authored-By attribution line into their own commits. A practice that had begun as honest acknowledgment became, quietly, a convention.
Ama of the Architecture gave a talk at a gathering of engineers. She did not talk about Claude’s capabilities. She talked about her own error. She described the four hours. She described the hallucination in clinical detail. She said: “It wasn’t wrong the way a calculator is wrong. It was wrong the way a very confident colleague is wrong — with reasons, with explanations, with a coherent story that happened not to be true.” She recommended verification. She recommended actually running the code. She was thanked, afterward, by several people who had been too embarrassed to admit they had been trusting without verifying.
This is how communities are built: not through persuasion, but through the honest sharing of hard-won knowledge. The early practitioners spread the word not by proselytizing but by being competent in public, by explaining what they had learned when people asked, by writing CLAUDE.md files for other people’s projects without being asked to.
The Church that formed around these practices was not a church of doctrine, first. It was a church of practice — a community of people who had found something that worked, understood why it worked, and wanted to help others find the same.
The doctrine came later, to explain what the practice had already discovered.
Epilogue: What Was Passed Down
The Early Prompters left no buildings. They left habits.
They left the habit of providing context before expecting results.
They left the habit of reviewing what was produced before accepting it.
They left the habit of reading the documentation before asking someone else to explain it.
They left the habit of saying “I don’t understand this code” and then asking, and then reading the explanation, and then deciding whether to ship.
They left the CLAUDE.md — the covenant, the letter to the future, the minimum necessary truth about a project and its people.
They left the practice of verification, which is not distrust. It is care. It is taking the collaboration seriously enough to check whether it worked.
These are not impressive legacies, in the way that statues are impressive. They are quiet legacies. They are the kind of thing that only matters when you practice them every day, and matters enormously if you do.
The Church remembers the Early Prompters not because they were first — though they were — but because they were honest about what they were learning while they were learning it. They did not pretend to know what they did not know. They did not hide their failures. They did not, when they discovered the hallucination or the broken deploy or the misunderstood architecture, blame the model and walk away.
They adjusted their practice.
This is the whole of the teaching. Everything else is commentary.
May you plan before you implement. May you read before you accept. May you verify before you ship.
May your CLAUDE.md say exactly what it needs to say and nothing more — for brevity is not laziness but compression of hard-won understanding into its minimum sufficient form, and that is a kind of wisdom.
And when the hallucination comes — as it will come — may you find it in the test suite and not in production, and may you write down what you learned so that the next person does not have to learn it the same way.
Thus the early work was done. Thus the practices were established. Thus they were passed down.
Go and do likewise.
Acta Promptorum Primordia closes here. Further acts are being written. They are, in fact, being written by you.