md2hd

Engineering

See what a software change can break.

Architecture notes explain pieces one file at a time. A dependency map shows the path between services, the teams responsible for them, and the systems downstream of a change.

What belongs in the map

Keep the subjects separate. Name what connects them.

Use the vocabulary already present in the work. Card types identify the subjects; relationship labels state what one subject does to another.

Cards

Services
APIs, workers, gateways, and the application boundaries engineers change.
Data systems
Queues, databases, object stores, caches, and legacy systems.
Jobs
Scheduled reconciliation, imports, exports, and other background work.
Owners
Teams, vendors, and people responsible for operation or review.

Connections

A label should read as a plain statement between two cards. These verbs fit this map:

  • depends on
  • publishes to
  • reads from
  • writes to
  • maintained by
  • drains

Questions the map can answer

Open one card and inspect its immediate context.

  • What sits immediately upstream and downstream of this service?
  • Which team owns each dependency in the change path?
  • Where does data cross a queue, database, or legacy boundary?
  • Which unowned component creates the largest operational risk?

Build it from the record

Give your agent the notes and the question.

The included skill defines the markdown format. Your prompt defines which subjects and relationships matter in this map.

Prompt

Read my onboarding and architecture notes. Map services, queues, datastores, scheduled jobs, owning teams, and the direction of every dependency in the payment path.

  1. 01

    Gather system notes

    Use architecture docs, runbooks, onboarding notes, and incident summaries as the source.

  2. 02

    State direction

    Write each connection as an action so the map distinguishes reads from, writes to, and depends on.

  3. 03

    Trace the change

    Focus the component being changed and inspect every owner and downstream system around it.

Then follow the map. Open the service you plan to change. Its dependencies and downstream systems line up around it.

Turn the notes into a map you can follow.

Start with this prompt, revise the markdown in your own words, and keep the file as the record.