🚀 Building Yours

A beginner’s impulse is to dump all the rules at once. Starting small is the opposite: the smallest prompt that already delivers value.

Every rule you don’t need anymore is still debt—dead code that confuses the model and hides the real cause of errors.

Minimum viable · small surface = easy debugging · add only when there's a real need.

Only two parts: who the agent is (identity) and what it commits to doing (a contract). Everything else is optional.

It’s the core that must be there. Without it, there’s no prompt; with more than that in v0, you’re already anticipating.

Identity · single contract · irreducible core.

Anticipating means writing a rule for a problem that hasn’t happened yet. It seems prudent, but it’s accumulated debt.

Speculative rules bloat the prompt, create conflicts, and obscure which rules really matter.

YAGNI in prompts · rules only for real failures · avoid speculative accumulation.

"Works" isn't a feeling. It's a concrete criterion—input + expected behavior—that says unambiguously whether v0 meets the contract.

Without an anchor test, you add rules blindly and never know whether the next line helped or hurt.

Objective criterion · input→output case · anchor before growing.

We built a complete prompt-v0 for an inbox triage agent — identity + 1 contract only, nothing else.

Seeing the assembled MVP makes the concept tangible: you can recognize what’s core and what would be premature.

Triage agent · lean prompt · one paired test case.

Two small files versioned in git: the prompt-v0 and the first test it passes.

It’s the foundation of your personal lab—the first and most important baseline in the evolution repo.

prompt-v0 · anchor test · first commit.

Prompts evolve through use. The engine is a short, honest cycle: run it on a real case, observe the failure, fix it.

Without the cycle, you "improve" the prompt in the dark. With it, every change comes from a real observed failure.

Short cycle · real case · observed failure, not imagined.

The mature correction applies a single pattern from the Trail 1 catalog — it doesn't pile on standalone rules.

It’s what separates a prompt that ages well from an increasingly hard-to-maintain “onion of rules.”

One standard per fix · catalog · avoid layering up.

A scheduled ritual: every N cycles, you stop adding and merge, cut, or rewrite redundant rules.

Adding is easy; removing takes courage. Without the ritual, the prompt only grows and never shrinks.

Scheduled ritual · merge/cut · a prompt that breathes.

The diff from Opus 4.8 to Fable 5: lots of new content added, and yet a leaner prompt where it mattered.

It’s real proof that evolution and consolidation can coexist: the provider adds and prunes in the same round.

Official diff · add and prune · living reference.

Every cycle and every consolidation become a commit. Git turns the prompt into an artifact with a traceable history.

Without version control, you lose the history and can't revert a rule that made things worse.

Commit per change · readable diff · reversibility.

Each changelog entry labels the change by the pattern applied and the failure that prompted it.

The commit records what changed; the changelog records why—and the why lets you review the decision later.

Recorded rationale · pattern + failure · reviewable decision.

One sentence supports the entire path: every added rule needs a documented reason AND a test to justify it.

It’s the filter that keeps the prompt lean and auditable—without it, rules creep in out of habit and never leave.

Why + test · input filter · auditable prompt.

It's not a code unit test — it's an input case plus expected behavior that would fail without the rule.

If you can't write the test that would fail, the rule has no measurable effect — and is probably unnecessary.

Failing test · input→output · measurable effect.

The prompt has a gate, and the test is the key. A rule without a test stays in the queue — not in the prompt.

It seems rigid, but that's what prevents the pileup from coming back: nothing gets added without evidence that it makes a difference.

Entry gate · test = key · rule in queue vs. in prompt.

Connects directly to Pattern 3 (Rule with a Reason): a bare prohibition is followed literally but fails outside the exact case.

The reason gives the model the principle, not just the instance — that's what makes the rule apply to cases you haven't written.

Principle > blanket prohibition · generalization · Pattern 3.

The deliverable: a minimal test suite linked to the changelog—a test for every rule worth keeping, no more and no less.

Links each rule to its evidence and rationale, closing the loop between prompt, test, and history.

Minimal suite · 1 test per rule · prompt↔changelog traceability.

The golden rule mirrors the providers’ direction: the industry moved from "more rules" to "measured rules."

Test-based decisions are reproducible and defensible; opinion-based decisions lead to endless debate.

Evidence > opinion · reproducibility · market-aligned.

Everything you built in Tracks 1 through 4 comes together in a single repo: prompt, changelog, and tests all in one place.

A cohesive, versioned artifact is what you take into the real world — ready for maintenance and review.

Cohesive repo · prompt + changelog + tests · final artifact.

Each changelog entry points to exactly one pattern in the Track 1 catalog—it’s not enough to say "I added a rule".

Labeling by pattern connects your practice to theory and makes every decision verifiable against the catalog.

Pattern label · T1 catalog · traceable decision.

The tests don't verify the prompt text—they verify the behavior it produces. Each test is a promise.

Testing behavior (not words) lets you rewrite and trim the prompt without worrying about breaking what matters.

Behavior contract · input→output · refactor safely.

The approval criterion is counterintuitive: the submitted prompt must have fewer lines than the intermediate draft.

Trimming while keeping all tests green proves maturity—you say the same thing with less.

Density > volume · green test suite · concision as a goal.

This isn't a matter of taste; it's a procedure: run the suite (starting from green), cut or merge, then run it again — it only counts if it stays green.

Consolidating by measuring with tests removes the fear of cutting: the suite tells you right away if you broke something.

Green baseline · cut→rerun · measured procedure.

The delivered repo isn't the end — it's the start of your practice, the place where you apply the track's rituals from now on.

Internalizing the rituals (cycle, consolidation, golden rule) is what separates those who took the course from those who actually maintain prompts.

Living repo · ongoing rituals · practice beyond the course.