Think about who receives
A delivery needs to work for someone who hasn’t followed the project conversations. Explain the goal, what exists, how to run it, and how to recognize the expected outcome. Avoid relying on phrases like “just do it like before.”
Choose a small project, like the order center, and prepare your kit. The recipient should be able to locate the files and understand the limitations without reading an entire history. The README works as an entry point, not as a dump for all notes.
Why learn
Delivery quality determines the cost of continuity. A useful tool loses value when only its author knows how to start, test, or update it.
✓ Do
Test the README steps in a clean context.
✗ Avoid
Publish all files from the folder without checking.
Key concepts
Organize the material by function
Separate code, examples, documentation, and evidence. Use descriptive names and consistent paths. Private working documents, credentials, and materials that don’t belong in the distribution should be left out of the published set.
A folder of evidence can include test results and captures of important states. You don’t need to keep every temporary file. Choose what demonstrates behavior and explain how it was produced, so the check can be repeated.
Why learn
Organizing by function reduces search time and prevents mixing examples with real data. It also makes reviewing the set to publish simpler.
A way to apply
- Organize files and write the entry point.
- Run the instructions with the provided examples.
- Review the distribution and deliver continuity context.
Key concepts
Write executable instructions
List prerequisites, the start command, and a test action. Execute the instructions exactly in a clean folder or an equivalent context. If a step depends on something installed globally, record that dependency.
Avoid instructions that promise a nonexistent automation. If the task requires a manual decision, explain the criterion. The reader should know what to expect after each step and how to recognize a common error without having to guess.
Why learn
An instruction is only validated when it was followed. This test reveals missing files, hidden dependencies, and path names that work only on the writer’s computer.
projeto/
README.md
src/
exemplos/entrada.csv
docs/arquitetura.md
docs/decisoes.md
evidencias/verificacao.md
CHANGELOG.md
# Before publishing:
git status --short
git diff --cached --stat
Key concepts
Build a small knowledge base
Choose the documents that explain the project and record subject, version, and location. An index of ten items is enough to start. The base can feed a dossier, but it needs to keep the link between answers and the document.
When a file changes, review the summaries that depend on it. A “living” base doesn’t mean generating content endlessly; it means having an update routine with an owner, frequency, and change criterion. Mark outdated materials instead of letting them compete with the current version.
Why learn
An organized base preserves decisions and reduces repeated questions. Update control prevents old answers from looking current just because they’re still easy to find.
✓ Do
Keep fictitious examples separate from private data.
✗ Avoid
Document a function that doesn’t exist yet.
Key concepts
Do a publish review
Before versioning, check the exact set of files. An ignore prevents adding new unwanted files, but it doesn’t automatically remove files that were already tracked. Review the status and the content prepared for the commit.
After publishing, test the links and the files that should open. Record the delivered version and the next steps. The result of the publish is a reference point for maintenance, not the end of the need to verify future changes.
Why learn
The review prevents distributing private material or an incomplete version. Identifying the delivery makes it possible to connect documentation, code, and test results.
| Criterion | Expected evidence |
|---|---|
| Reproduction | Another person can run the example. |
| Coherence | README, map, and code describe the same version. |
| Continuity | Limitations and the next step are identified. |
Key concepts
Practice: deliver to a second reader
Assemble the kit for the order center or another small project. Ask someone to follow the README, open the diagram, run the example, and find a known limitation. If you’re studying alone, repeat the steps in a new folder.
Record where you had doubts and adjust the smallest necessary part. At the end, write a continuity summary with current status, decisions, and the next task. The kit is complete when it allows using and continuing the project without depending on the conversation that created it.
Why learn
This practice closes the course by connecting implementation and maintenance. You move from an AI-produced response to a delivery that can be checked, shared, and improved.
Your exercise
Prepare a kit with README, an input example, expected output, a flow map, and a verification log. Check the files that will be shared.
Download practice sheetCheck the commented answer
The README points to the other documents and includes tested steps. The input uses fictional data; the output lets you verify the rules. The map matches the implemented flow. The verification reports results and limitations, and the next step describes a single, clearly bounded improvement.
Check your understanding
Adding a folder to .gitignore removes files that are already tracked?
Key concepts
What stays from this module
A delivery kit with instructions, a map, evidence, and next steps.
- ✓ Another person can run the example.
- ✓ README, the map, and the code describe the same version.
- ✓ Limits and the next step are identified.
Progress records your reading. The practice is completed when you check the submission.