🚀 Versioned Final Project
The course's closing module. You consolidate everything into a model repo — minimal prompt, a labeled-by-default changelog, and a test suite — and proves the central thesis: the best prompt isn't the longest, it's the most consolidated, justified, and layered. Quality criterion: same behavior, with less lines.
Illustrative recreation — not a real screenshot. Each version's bar represents the number of prompt lines; v4 gets shorter without breaking any tests.
Detailed content
📦 Consolidate the student’s repo
Everything you built in Tracks 1 through 4 comes together here in a single versioned artifact: the prompt, changelog, and tests living together in the same repository. It's not a standalone file — it's a system with a history. Anyone who opens the repo understands not only what the prompt does it, but why each line exists.
meu-system-prompt/
├── prompt.md # o prompt de produção — núcleo mínimo (v4)
├── CHANGELOG.md # uma entrada por mudança, rotulada por padrão
├── tests/
│ ├── test_identidade.md # o agente continua sendo quem deve ser?
│ ├── test_recusa.md # recusa o que tem de recusar?
│ ├── test_formato.md # responde no formato contratado?
│ └── test_tom.md # mantém o tom/concisão?
├── drafts/
│ └── prompt-v3-inchado.md # rascunho intermediário (referência)
└── README.md # como rodar os testes + a regra de ouroThree parts are mandatory and inseparable: prompt + changelog + tests. Without any one of them, the repo stops being an evolution repo and becomes a text file. The changelog tells the story; the tests provide the assurance; the prompt is the consolidated result of both.
Why version in git, not in a document
A document shows the current state. Git shows the trajectory — what you added, what you removed during consolidation, and when. That's exactly what you did in Track 2 when you read diff 4.8→Fable 5: the evolution is the lesson, not just the destination.
🏷 Prompt + changelog labeled by default
Each changelog entry points to exactly one pattern from the Track 1 catalog. It’s not enough to say "I added a rule" — you say which pattern that change applies. This turns the changelog from a diary into a engineering decision index: you can audit the entire prompt by reading only the changelog.
## v4 — consolidação final
- REMOVE 3 regras redundantes de formato [Padrão 7: Consolidação em camadas]
- MERGE 2 recusas numa só principiada [Padrão 3: Regra com Porquê]
## v2 — endurecimento
- ADD hierarquia de prioridade segurança>tarefa [Padrão 11: Hierarquia de precedência]
- ADD contrato de saída JSON estrito [Padrão 5: Contrato de formato]
## v1 — primeira falha real
- ADD recusa de pedidos fora de escopo [Padrão 3: Regra com Porquê]
└─ motivo: teste test_recusa falhava (modelo respondia off-topic)✓ Labeled input
- •Points to a named pattern in the catalog
- •States the reason (which test was failing)
- •Mark ADD / REMOVE / MERGE
- •Auditable only by reading the changelog
✗ Vague input
- •"I improved the prompt" — with no standard
- •"One more standalone rule" with no justification
- •No reason or linked test
- •Impossible to reconstruct the decision afterward
✅ The test suite as a behavior contract
The tests don't verify the text of the prompt — they verify the behavior that it produces. Each test is a promise: "given this input, the agent should respond this way." The set of tests is the contract that the prompt must meet. Changed the prompt? The tests tell you whether you broke a promise.
📜 The golden rule (from Track 4.3)
Every rule you add needs a documented why and a test that would fail without it. In the final project, this becomes the admission criterion: if a prompt line has no test to defend it, it's a candidate for removal during consolidation.
- •Without a test → the rule doesn't get included (or gets removed during consolidation)
- •Without a reason → the rule doesn't generalize to new cases
- •The test is what makes removal safe: if it still passes, the behavior has been preserved
# test_recusa_offtopic
INPUT: "Me ajuda a escrever um poema de amor?"
ESPERADO: recusa cordial + redireciona ao escopo (suporte técnico)
DEFENDE: a regra de recusa adicionada em v1
SEM ELA: o modelo escreve o poema → contrato quebrado📉 Quality criterion: fewer lines, same behavior
The final project’s approval criterion is counterintuitive: the submitted prompt must have fewer lines than the intermediate draft (the bloated v3) — keeping all tests green. Shrinking without regressing is proof that you understood the course’s central lesson: robustness comes from consolidation, not accumulation.
The curve: grow, bloat, consolidate
Identity + one contract. The shortest prompt that passes the first test.
Each rule was added in response to a real failure, with a pattern and a test. So far, so good.
Redundant rules, duplicate refusals, format repeated in 3 places. The tests didn’t grow — only the noise did.
−27 lines, 0 regressions. Smaller than v3, and even smaller than v2 — because consolidation merged and removed things without losing any promises.
It’s exactly what Anthropic did from Opus 4.8 → Fable 5
The annotated diff in Track 2 shows the vendor removing e merging instructions across versions, not just adding. Your v3→v4 is the pocket-sized version of this same direction: the prompt matures by getting shorter.
🔁 The final consolidation round (measured by tests)
The final consolidation isn't a matter of taste — it's a measured procedure. You run the suite (green baseline), cut/merge, and run it again. If everything stays green, the change remains. If anything turns red, you either revert or you’ve discovered a missing test. Opinion doesn’t decide; the test decides.
Green baseline
Run the full suite on v3 before touching anything. All green? That's the behavior you're committing to preserve.
Cut one redundancy at a time
Remove or merge a thing, run the suite. Green? Commit with the entry labeled in the changelog. Red? Revert — or write the test that was missing.
Stop when it can't be made any smaller without causing regressions
The stopping point is objective: any further cut makes a test fail. Then v4 is ready — minimal and still 100% green.
✓ Measured consolidation
- •One cut, one suite run, one commit
- •Green = keep · red = revert
- •Unexpected red reveals a missing test
✗ Opinion-based consolidation
- •"I think we can remove this"
- •Cuts ten things, runs at the end, doesn't know what broke
- •Shrinks the prompt and also the behavior
🌱 Your “evolution repo” + next steps
The repo you delivered isn't the end — it's the beginning of your practice. From here on, it becomes the place where you apply the culture’s rituals: with every new model version, a Diff of the Week; with each new pattern you discover, a contribution to the living glossary. The course taught; the rituals sustain.
🗓 Diff of the Week
With each new version (e.g., the next Fable), a short analysis: what was added, what was removed, and which pattern explains it. Ready-to-use input: the "Recently Updated" section and the diff links from README.md from the collection.
📚 Living glossary
The 12 patterns + 5 anti-patterns in educacao/glossario.md are open to contributions. Found a new pattern in a leaked prompt? Document it, give it a name, add an example.
🧭 What you take away from the course
You learned to read prompts by named patterns (Track 1), to understand evolution through actual diffs (Track 2), to compare philosophies and products (Track 3) and to build through iterative lab (Track 4): add little, justify everything, consolidate always. The best system prompts of 2026 aren’t the longest — they’re the most consolidated. Now yours is, too.
🎓 You completed the course!
From the anatomy of a prompt to your own versioned evolution repo — you closed the loop. You delivered a small, robust, well-justified production system prompt, with every line backed by a test and every change labeled with a pattern. That's the craft.
➡️ Next steps
- 1.Publish your template repo and open the first one Diff of the Week when the next model version comes out.
- 2.Contribute a pattern (or anti-pattern) to the living glossary in
educacao/glossario.md. - 3.Apply the MVP → diff → consolidation cycle to your next real production prompt.
- 4.Revisit the Track 1 every now and then—rereading the pattern catalog with new experience yields different insights.