Give the Project a Readable Map
Organize the source, example data and output by their jobs.
Look around. Try a small click.
This lesson works as a written guide with interactive examples. You can explore here before opening the real application or provider dashboard. A recorded video has not been added yet.
What will make more sense
- A project map explains where each part lives and which role it plays.
- Recognize the choice in a prepared business example.
- Explain a small next step before asking an assistant to act.
One idea to keep
A project map explains where each part lives and which role it plays.
The short lesson
Read the explanation at your pace
A project map is a short explanation of where the important pieces live and what each piece is for. It plays a similar role to a website sitemap, but can describe more than pages. For a small business tool, it may show the brief, source facts, implementation, example data and review notes. You can understand that map before understanding every file format in the project.
The prepared planner folder has a simple arrangement. project-brief.md explains the goal. business-facts.md contains the fictional approved information. planner.html is the local interactive output. review-checklist.md names the checks, and handoff.md describes the current state. These names are not magic commands. They are readable labels that make it easier to point the assistant to the right material and return to the work later.
The project map should distinguish responsibilities. A source-facts file answers what the business has approved. A generated output shows what the tool does. A review note records what was checked. If the tool's wording changes, the assistant should not quietly turn an unapproved output into the new business policy. Keeping the roles separate helps you notice when a draft is being mistaken for an authoritative source.
Avoid creating many folders just to look organized. A small project can start with a few clearly named files. Add structure when it solves a real problem, such as separating public release files from private planning notes. The goal is findability, not a complicated filing system that nobody understands. An agent can propose a map, but it should explain how the arrangement helps the next task.
When a project grows, update the map with the actual current parts. A new connection or data source should not remain hidden in a chat message. Likewise, remove or clearly label obsolete planning notes so they do not compete with the current source. The context course and agent-file course offer deeper ways to keep guidance reusable. This lesson stays with the simplest version: one readable map next to the work.
In the activity, choose which file should supply an approved business rule. Optional practice is opening project-map.md and following one of its file references in VS Code. You are learning how to tell the assistant where to look and why. That small habit reduces guessing, makes handoffs easier and helps you stay involved in the project without needing to read every line of its implementation.
Try it here
Find the source of a business rule
The agent needs to know which enquiry categories are approved for the planner.
This is a local learning example with prepared responses. It does not run VS Code or contact an AI service.
Which file should guide the business categories?
A tiny next step, if you want one
Optional: try 2 small actions at your own pace
You can finish this lesson by exploring the example above. These real-app actions are optional, and there is nothing to submit.
- Optional: open project-map.md and find the brief and output entries.
- Optional: open business-facts.md from the file list without editing it.
A quick confidence check
These checkmarks are a personal reminder. Choose what feels familiar, and come back whenever you want.
Your place is saved in this browser when storage is available. There is no grading or account sync.
Try a short question
Choose an answer to see why it fits. You can try again or explore every explanation.
Is a file name itself a special command to the agent?
Why distinguish source facts from generated output?
If something looks different
My app or provider uses different labels.
Use the linked official guidance for your current product. The lesson teaches the decision rather than requiring a particular screen.
I only want to learn the idea today.
Use the browser activity and confidence questions. The real-app actions are optional, with nothing to submit.
Sources and further help
Read the official product guidance and related learning resources when you need them. You do not need to read every reference now.