Use Claude to Turn Project Notes into a Dependency Map

Evidence label: documentation-based tutorial with fictional input and an illustrative output. The workflow was not run in Claude and does not claim a reproduced result.

A dependency map is useful when several workstreams look busy but nobody can say what must happen first. Claude’s current prompting guidance recommends clear output requirements, sequential instructions, structured document inputs, and source quotes for long document tasks. This lesson applies those ideas to a small project-note review.

What you will make

You will create a reviewable table with:

• upstream task
• downstream task
• dependency stated in the notes
• owner named in the notes
• missing information
• review status

The table is a planning aid. It does not approve a deadline or assign an owner by inference.

Prerequisites

You need access to Claude with a text input surface. Use a fictional or approved note file. Anthropic’s official prompting guidance says to be clear about the output format, use sequential instructions when completeness matters, and ask for relevant quotes when working with long documents. Those are the controls used here.

Save this as project-notes.txt:

Project: Northwind help-center refresh

Workstream: Content
Owner: Elena
Task: Draft the new setup guide.
Status: First draft is planned after the product screenshots are approved.

Workstream: Product
Owner: Marco
Task: Approve the product screenshots.
Status: The current build may change the settings labels.

Workstream: Support
Owner: Sam
Task: Prepare the support reply macros.
Status: Sam needs the final setup-guide URL before writing the macros.

Open questions:
- The notes do not name a screenshot approval date.
- The notes do not say who confirms that the settings labels are final.
- The notes do not state whether the support macros can be drafted from the current guide.

Three steps

1. Provide the notes

Open Claude and paste the complete contents of project-notes.txt. If the notes are longer, wrap each source document in a clear label such as SOURCE: project-notes.txt before the task instructions.

2. Ask for a source-linked map

Paste this prompt:

Use only the project notes below. Do not infer a dependency that the notes do not state.

Create a Markdown table with these columns:
Upstream task or required input | Downstream task | Supporting quote | Named upstream and downstream owners | Missing information | Status

Rules:
- Include only dependencies stated in the notes.
- Quote the exact sentence that supports each dependency.
- If an owner or date is missing, write "missing in source".
- Keep open questions separate from stated facts.
- Do not create a schedule or recommend a deadline.
- Add a short list of notes that contain no dependency.
- End with a review question for the project owner.

Project notes:
[PASTE project-notes.txt HERE]

3. Review the map

Check every row against the note text. A row is ready for discussion only when the quote supports the relationship and the named owner appears in the source. Ask the project owner to resolve every missing field before turning the map into a schedule.

Illustrative output

This is a manually written example of the expected artifact, not Claude output.

| Upstream task or required input | Downstream task | Supporting quote | Named upstream and downstream owners | Missing information | Status |
|---|---|---|---|---|---|
| Approve product screenshots | Draft new setup guide | "First draft is planned after the product screenshots are approved." | Marco for screenshots; Elena for guide | Screenshot approval date: missing in source | Review |
| Final setup-guide URL available | Prepare support reply macros | "Sam needs the final setup-guide URL before writing the macros." | URL owner: missing in source; Sam for macros | URL availability date: missing in source; whether the current guide can be used | Review |

Notes with no stated dependency
- "The current build may change the settings labels." This describes uncertainty; it does not state a task that must happen first.

Review question for the project owner
Who supplies the final guide URL, and who confirms when the settings labels and screenshots are ready?

The notes leave the settings labels unresolved. They do not name a label-confirmation owner or an approval date. The final URL is a required input for Sam’s work; the notes do not name a publishing task or say who supplies that URL.

Acceptance checks

The map passes when:

1. Both stated dependency relationships are present.
2. Each row includes a supporting quote from the notes.
3. Elena, Marco, and Sam are not reassigned.
4. The missing approval date and label-confirmation owner remain visible.
5. No deadline or schedule is invented.
6. The source note about changing settings labels remains an open question.

Troubleshooting

• Claude invents a date: repeat that dates missing from the notes must be written as missing in source.
• It turns a risk into a dependency: ask it to show the exact sentence that proves the relationship.
• It assigns one owner to every task: require the owner column to use only names appearing beside the relevant task.
• The table becomes hard to scan: ask for one row per stated dependency and move explanations below the table.

Limits and decision

The map shows what the notes support. It does not prove that a dependency is technically real, that an owner agreed to the work, or that a deadline is achievable. Confirm the map with the people who own the work.

TRY: this on a small, approved project note with explicit task names.

SKIP: using it to set a deadline or change ownership without review.

USE: the quotes and missing-information column as the agenda for a dependency review.

For a beginner task, see choose your first AI workflow at work. For the weekly practical version, join The Weekly Verdict.

Sources

• Anthropic: Prompting best practices