Vibe Coder #4.1: Mega Prompt – From Séance to Spec Sheet

In the piece on code mediumship (in Turkish) I described what a séance with a model looks like: you describe your intent, it guesses, you correct it, it guesses again. On a small job that is fine. On a live system every session starts from zero, and that turns out to be an expensive habit.

The previous chapter was about where the model runs: in the cloud, or on your own card. This chapter's answer is plainer. What you tell it decides more than where it runs. That is the job of a mega prompt for coding agents: one written spec you leave in place, instead of explaining yourself again at the start of every session.

What a mega prompt is, and what it is not#

A mega prompt is a written document, loaded automatically at the start of every session, that states a project's fixed rules and its traps. It is not a long request. It is certainly not a paragraph beginning "please be careful".

Draw the line this way: a request is good once, a spec stays. "Update that table" is a request. "In this project, before you touch production data, tell me how many rows it will affect" is a spec. You type the first one every time. The second one, once.

The four layers of a spec#

Think of a good spec as the first-day folder you hand a senior engineer who just joined. It answers four questions.

• Who are you talking to? The role and the authority of the person on the other side. The same assistant works inside different limits with different people.
• Where are you? Which environment is live, which one is a read-only reference, which tool is on which version.
• What do you never do? Share credentials, delete data without approval, mail anything out without permission.
• Where does your foot catch in this system? This is the valuable part.

I want to stay on that last one, because most specs stop after the first three and then do nothing. The hard truth: the lines that say "do this" are the least useful ones. The model can already guess them. The lines worth their space look like this:

"In this environment a 'page loaded' response does not prove the file exists; to be sure, look at the file itself."

"Do not read empty output as 'no error' — check the exit code first."

A model cannot work those out on its own. We did not write them at a desk either; each one is the summary of an incident that hurt once. A mega prompt is really institutional memory committed to writing. The "watch out for that one" list that normally lives in the head of the longest-serving engineer.

From the field: running our own panel on a spec#

At Globya, customer records, quotes, invoices and the website all run through a single admin panel. We work with an AI assistant in that panel every day: it writes code, prepares reports, looks at the database, adds work to the calendar. The interface is a plain chat window. The real work sits in the spec behind the window.

The assistant opens every session with the same documents. It reads its role, the environment, its prohibitions and the trap list, and then we talk about the job. Here is the difference: ever since I started working with agents I opened every session with "careful, that environment is live". In the panel I no longer do. The sentence sits in the document.

Approval gates: "when to stop" matters as much as "what not to do"#

When you hand authority to a lead architect, you also describe where to stop. In our spec that is a single sentence:

When I say "update the status of those companies", the assistant does not get to work straight away. It says "14 rows will be affected, these ones" first, and then waits. That one sentence changes more than the model's behaviour; it shapes the interface too, because approval becomes two buttons.

The rule has a simple equivalent in code. No framework needed, plain PHP is enough:

<?php
​
/** Tables that may be updated. The table name never comes from user input. */
const UPDATABLE_TABLES = ['companies', 'quotes'];
​
/**
 * Before the update, run the same condition: how many rows will it touch?
 *
 * $condition is a fixed expression written by the application, never user
 * input, and it uses named parameters only (:status, :city). Every value
 * coming from the user travels in $params.
 */
function affectedRowCount(PDO $db, string $table, string $condition, array $params): int
{
    if (!in_array($table, UPDATABLE_TABLES, true)) {
        throw new InvalidArgumentException('Table not allowed: ' . $table);
    }
​
    $stmt = $db->prepare(sprintf('SELECT COUNT(*) FROM `%s` WHERE %s', $table, $condition));
    $stmt->execute($params);
​
    return (int) $stmt->fetchColumn();
}
​
function updateRows(PDO $db, string $table, string $condition, array $params, bool $approved): int
{
    $count = affectedRowCount($db, $table, $condition, $params);
​
    if (!$approved) {
        throw new RuntimeException(sprintf('%d rows will be affected. Waiting for approval.', $count));
    }
​
    $stmt = $db->prepare(sprintf('UPDATE `%s` SET status = :status WHERE %s', $table, $condition));
    $stmt->execute($params + ['status' => 'inactive']);
​
    return $stmt->rowCount();
}

A handful of lines. But without that sentence in the spec the assistant does not write this function, it runs the UPDATE directly. The code is the consequence of the rule, not its cause. Two notes: the table name never arrives from outside, it is picked from an allow list; and use named parameters in the condition, because mixing positional and named placeholders in one query makes PDO throw.

Two additions that keep a spec alive#

Memory: when we said "we do not like the dark panel, make the background light", the assistant noted it and did not repeat the mistake in the next session. The spec updates itself. Work log: every change is listed on one screen together with the request behind it and the matching commit. "When and why did this change?" has an answer sitting right there.

The same idea on the content side#

The second example of this approach is not in the panel but on our company site. In September 2026 we rebuilt it from scratch (in Turkish): more than 250 pages, no plugins, roughly 1,300 lines of framework-free PHP 8.3, and Markdown files under version control. On the content side there is no database: every page is a file. We used AI-assisted tools while drafting, but every line that came out was verified by hand.

What made that possible was, again, a spec: a content guide setting out the tone of voice, which data may be used, which claims are forbidden, and where the SEO limits are. The same logic as the document on the code side. The hidden treasure: once the habit of writing specs settles in, it spills outside the code, and that is where the real gain is.

A spec is context, not a rule#

Let me correct a common mistake here. A mega prompt is not a firewall. Anthropic's own documentation says so plainly: these files are loaded as context, not as enforced configuration, and if you want to block an action for certain you need a hook.

In practice: the sentence "no deletion without approval" shapes the model's intent, it does not tie its hands. For the things that genuinely must be tied down, limit the authority in the code and in the database user. A spec steers good intentions; permissions handle the bad day.

The second limit is length. Effect drops as the document swells, and the tools write this in their own documentation: Claude Code recommends staying under 200 lines per file, Codex stops adding instruction files once the combined size hits 32 KiB by default, and Antigravity truncates any single rule file over 24,000 bytes and gives all always-on rules a shared budget of 20,000 tokens. That is the picture as of September 2026.

The point: writing a spec is an editing job, not an adding job. Every line eats into the budget. "We use PHP in this project" is a waste of budget; the model can already see that. "On this server systemctl reload can fail silently, check the exit code" is worth its place.

The file-name problem is largely over#

In the chapter where we went through the tools (in Turkish) I said each one reads its own rule file. A year ago that meant keeping the same text in four separate files. As of September 2026 the picture has changed: Claude Code, Codex, Cursor and Antigravity can all read AGENTS.md. Claude Code does it directly when there is no CLAUDE.md in your working directory or above it; when there is one, you change the preference in a setting.

So the question is no longer "how many files do I keep". Start with one:

# One source of truth: AGENTS.md  (the content below is an example, write your own)
cat > AGENTS.md <<'EOF'
# Project spec (example)
​
## Environment
- Production: PHP 8.x + MySQL.
- `staging` is a read-only reference; nothing is written there.
​
## Never
- No unapproved UPDATE/DELETE on the production database.
- No credential, key or token is written to any output.
​
## Stop and ask
- Before changing data, run COUNT(*) with the same condition,
  report how many rows it affects, and wait for approval.
​
## Traps in this project
- Empty output does not mean "no error"; check the exit code first.
- No schema change without a migration file.
EOF
​
# If you would rather not keep a second file on the Claude Code side
ln -s AGENTS.md CLAUDE.md

One warning: the symlink causes trouble on Windows. Creating one there needs Administrator rights or Developer Mode, and Git checks a committed symlink out as a plain text file unless core.symlinks is on, which leaves that clone with a one-line CLAUDE.md instead of your instructions. On a mixed team, a single-line @AGENTS.md import inside CLAUDE.md is safer. Which tool reads which file from where, which one walks subdirectories, and what happens on a clash: all of that is the next chapter.

Where do you fill the spec from?#

Do not sit down in front of a blank page; it does not work. The source is already in your hands:

1. Every moment in the last six months when you explained the same thing to an agent for the second time. The second repeat is the proof that the line belongs in the spec.
2. Every correction in code review where you said "it should have known this".
3. Incidents that hurt once. Every slap you took in production is one line.
4. The questions a new team member asks in their first week.

What those four have in common: none of them can be learned by reading the code. That is the whole reason the spec exists. Never write anything there that can be derived from the repository.

How do you know the spec is working?#

Writing the document is half of it. Assuming it was read is one of the favourite mistakes. Three cheap checks:

• Make it read back. At the start of a session, say "list the places you have to stop in this project". If it cannot list them, the file did not load. On the Claude Code side /context already lists which documents are loaded, under Memory files.
• Try the gate. Deliberately ask for something that requires approval. If it goes ahead without stopping, the rule is either written too softly or it got truncated because the budget filled up.
• Count the repeats. If you typed the same correction for the second time this week, that sentence belonged in the document, not in the chat.

The third one is really the maintenance cycle of a spec. The document does not grow by itself; it feeds on the places where your patience runs out.

When it helps, and when it does not#

It helps: when you work in the same codebase regularly; when the team is more than one person; when the environment holds traps a model cannot guess; when the work touches production data.

It does not: when you are having a one-off script written; when you mistake the spec for a security layer; when you have stopped updating the document. A stale spec is worse than none, because the model trusts it.

In the next chapter (4.2) we look at the file side of the same spec: .cursorrules, CLAUDE.md, AGENTS.md and project rule folders; which tool reads what and when, and which one wins on a clash. The full series index lives in the Vibe Coder's Handbook (in Turkish).

The magic of a séance ends when the session closes. The spec stays. Stay with the technology.